Semantic Systems / Language / Glyphs

Architectural Proposal: The Futhorc Protocol for Transparent, Model-Independent Machine-to-Machine Communication

Report summary

The rapid proliferation of autonomous Artificial Intelligence (AI) agents has precipitated a fundamental crisis in machine-to-machine (M2M) communication architecture. As multi-agent systems coordinate at scale, their communication protocols rely overwhelmingly on continuous vector embeddings or nat

Status
Research archive item
Category
Semantic Systems / Language / Glyphs
Length
5,055 words
Reading time
23 minutes
Report type
strategy

Key topics

  • Semantic Systems / Language / Glyphs
  • Semantic Systems
  • Language
  • Glyphs
  • AI
  • AI Memory
  • Agentic Web
  • WordPress
  • .NET

Research provenance

Archive status
Research archive item
Content identity
sha256:9a38fb22f1a125a0cd2768488bac39b61a5d99712a30d8861b1bf30d9f22bce2

For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.

This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.

Full report

On this page

The Crisis of Continuous Semantics in Agentic Networks

The rapid proliferation of autonomous Artificial Intelligence (AI) agents has precipitated a fundamental crisis in machine-to-machine (M2M) communication architecture. As multi-agent systems coordinate at scale, their communication protocols rely overwhelmingly on continuous vector embeddings or natural language processing1. While these methods facilitate generalized cognitive capabilities within isolated environments, they introduce critical points of failure when deployed as foundational protocols for public network infrastructure. Specifically, these architectures suffer from relentless semantic drift, intractable model dependency, unsustainable computational bloat, and severe, unpatchable security vulnerabilities2. The representational space of natural language is structurally misaligned with the internal semantic space of Large Language Models (LLMs)2. Natural language was fundamentally designed for human cognitive needs, prioritizing ambiguity tolerance, emotional nuance, and pragmatic flexibility2. In contrast, agent-to-agent coordination relies on precise state transmission, role persistence, behavioral consistency, and explicit intent alignment2. When autonomous agents communicate via natural language, they frequently succumb to the "lost-in-conversation" phenomenon, experiencing information loss, semantic compression, and broken logical flows during multi-turn interactions2. Conversely, relying on raw continuous vector spaces—often termed "neuralese"—for agent-to-agent communication creates an entirely different set of systemic risks. Multi-agent reinforcement learning (MARL) architectures often allow agents to invent continuous vectors or discrete symbols for direct communication, maximizing task reward within closed systems3. However, this results in entirely opaque, uninterpretable signaling3. When Agent A transmits an unconstrained, high-dimensional vector to Agent B, the semantic alignment is mathematically unverifiable1. A subtle divergence in their internal models can cause catastrophic real-world failures. For example, if a policy agent interprets the vector for "high-risk" broadly, while the execution agent interprets it narrowly, the system silently fails, resulting in either over-flagging routine cases or missing genuine threats1. This proposal challenges the prevailing reliance on continuous vector embeddings and natural language as primary M2M communication protocols. Instead, it champions a return to a discrete, immutable, and universally standardized symbolic system: the Anglo-Saxon Futhorc, digitized within the Unicode Runic block. By abstracting agent intent into a finite, deterministic set of standardized characters, the proposed Futhorc Protocol completely bypasses the 'black box' problem of vector embeddings. It establishes a highly compressed, model-independent communication medium that any computational system—from deterministic microcontrollers to advanced LLM-based agents—can parse with absolute transparency and near-zero computational overhead.

The Latent Trap: Critical Failures of Vector Embeddings in M2M Ecosystems

The foundation of contemporary AI memory, multi-agent coordination, and retrieval-augmented generation (RAG) relies on vector databases and high-dimensional semantic embeddings. However, treating these continuous representations as static or universally reliable architectures is both mathematically and operationally flawed5. Vector embeddings suffer from the 'black box' problem—they are proprietary, model-dependent matrices that become fundamentally useless if the underlying LLM architecture changes.

The Illusion of Static Semantics and Embedding Drift

Vector embeddings operate under the false assumption that semantics are static. In reality, embeddings are susceptible to relentless "embedding drift"4. As foundational models are updated, fine-tuned, or replaced (e.g., upgrading from a legacy embedding model to a newer version), the mathematical structure of the continuous latent space shifts fundamentally4. Consequently, an embedding vector generated by a policy agent yesterday may not map to the same semantic concept in the execution agent's latent space today. This drift is exacerbated by real-world semantic shift, where word meanings, trends, or business priorities evolve over time. For instance, embeddings generated prior to 2020 might dominantly associate the token "reels" with fishing equipment or film spools, whereas modern embeddings associate it almost exclusively with short-form social media video content5. When an embedding model is updated, the preexisting vectors stored within the database or transmitted across the network immediately suffer from non-compatibility4. To resolve this, organizations must embark on expensive re-indexing processes. Re-indexing requires re-computing the embeddings for the entire historical corpus or communication log, a computationally exorbitant process that forces architectural downtime and disrupts multi-agent dependencies4. While algorithmic mitigations exist, they are computationally burdensome patches for a structurally unstable architecture. Table 1 illustrates the comparative performance of various retrieval and continual learning methodologies when attempting to compensate for embedding drift without full re-indexing, demonstrating the inherent difficulties in maintaining consistent recall across changing models4.

MethodContinual AdaptationAverage Score (MS MARCO, NQ, Hotpot QA, FEVER, FiQA2018)
BM25 (Baseline)No43.0
Joint TrainingNo54.1
Fine-Tuning (FT)Yes49.4
FT \+ Query Drift Compensation (QDC)Yes53.5
FT \+ Knowledge Distillation (KD)Yes50.8
FT \+ KD \+ QDCYes54.1

As demonstrated, even with advanced Query Drift Compensation ([Figure omitted from source export]) projecting new model query embeddings back to the old embedding space, performance barely matches theoretical joint training baselines, and the operational overhead of maintaining these drift vectors remains substantial4.

Computational Overhead and Latency Trade-offs

The deployment of vector embeddings for M2M communication incurs a massive computational tax. Generating, transmitting, and comparing high-dimensional arrays requires specialized hardware and complex approximate nearest neighbor (ANN) algorithms, such as Hierarchical Navigable Small World (HNSW) graphs and Inverted File Indexes (IVF)9. These algorithms introduce a mandatory and unavoidable compromise between latency, accuracy, and infrastructure costs. Achieving higher retrieval accuracy requires exponentially more compute power10. Benchmarks on standard datasets indicate that pushing an HNSW index from 0.8 to 0.95 recall accuracy increases latency by approximately 31%, while attempting the same recall improvement using an IVF index triples the latency9. The sheer dimensionality of these matrices creates a structural bottleneck for low-latency, high-frequency M2M communication. A standard 1,536-dimensional vector stored as 32-bit floats demands substantial memory resources and significant multiply-accumulate operations (FLOPs) purely to execute a basic cosine similarity calculation11. For edge devices, constrained autonomous swarms, or real-time IoT ecosystems, this computational overhead is crippling. Furthermore, high-dimensional arrays severely complicate observability. Debugging a communication failure in a 1,536-dimensional space is inherently more difficult than debugging a discrete software log, forcing engineers to rely on opaque visualizations rather than deterministic, auditable rules10.

Security Vulnerabilities in Continuous Spaces

Agentic AI frameworks expand the attack surface exponentially, blurring the trust boundaries between the underlying model, the injected data, and the autonomous execution environment12. Vector embeddings introduce a specific and critical class of threats known as "adversarial embeddings," aligning with the Open Worldwide Application Security Project (OWASP) classifications for Vector and Embedding Weaknesses12. Adversarial machine learning techniques—such as the Fast Gradient Sign Method (FGSM) or Projected Gradient Descent (PGD)—demonstrate that minute, imperceptible perturbations in a continuous input vector can drastically alter an agent's classification output or force misinterpretations15. Because vector communication channels rely on continuous gradients, a malicious actor or compromised node can mathematically craft an adversarial embedding that bypasses standard security filters, inducing malicious behavior when decoded by the receiving agent16. The implications in a multi-agent system are catastrophic. Research highlights the threat of "infectious jailbreaks" within multi-agent environments, where introducing adversarial embeddings into the memory of randomly selected agents induces the entire swarm to generate harmful or unauthorized responses16. Another severe exploitation of this vulnerability is the "Deadlock Attack," a resource-exhaustion vector where a malicious embedding hijacks a model's generative control flow, encouraging transitional tokens (e.g., "Wait", "But") that force the reasoning engine into perpetual, infinite loops14. Furthermore, "vector injection" exploits have proven highly successful across various model scales, confirming that the continuous space is fundamentally difficult to secure regardless of architectural sophistication17. If the protocol remains in the continuous domain, the attack surface remains mathematically infinite.

The Case for Discrete Symbolic Protocols

To resolve the catastrophic vulnerabilities inherent to high-dimensional continuous arrays, M2M communication must transition to a discrete, bounded, and universally standard protocol. A secure M2M protocol must satisfy two conditions: verifiability (semantic alignment is provable) and reproducibility (same inputs yield same conclusions up to a bounded error rate)1. Research into the "stimulus-meaning" model demonstrates that semantic divergence can be drastically minimized when agents restrict their reasoning to a highly constrained, pre-certified vocabulary. This approach, termed "core-guarded reasoning," ensures that agents test shared observable events and only utilize terms where empirical disagreement falls below a strict statistical threshold1. Simulations indicate that core-guarding reduces semantic disagreement between agents by 72% to 96%1. The autopoiesis theory of information transmission further supports this transition. Proposed by biologists Humberto Maturana and Francisco Varela, this theory explains how systems self-organize through interaction dynamics. An AI system does not share its high-dimensional "internal state" ([Figure omitted from source export]) directly; instead, it utilizes an encoding function ([Figure omitted from source export]) to translate its internal state into a "physical signal space" ([Figure omitted from source export])18. The receiving agent utilizes a decoding function ([Figure omitted from source export]) to convert the physical signal back into processable information18. By forcing multi-agent networks to interact via discrete interaction patterns rather than continuous internal states, the protocol establishes probabilistic semantic alignment governed by strict information theory, allowing conceptual structures to attain verified social instantiation without relying on opaque vector mathematics18. The optimal architecture requires a communication medium that is more mathematically rigid than natural language but entirely independent of neural network parameters. It must be a globally recognized standard, inherently bounded, discrete, and highly compressed.

The Futhorc Architecture: An Immutable Semantic Standard

This architectural proposal designates the Anglo-Saxon Futhorc script, enshrined within the Unicode Standard, as the optimal discrete protocol for secure M2M communication. The Anglo-Saxon Futhorc is an ancient runic alphabet developed from the older 24-character co-Germanic Elder Futhark, expanding historically in England and Frisia to encompass 28 to 33 distinct runes to represent complex linguistic sounds in Old English and Old Frisian19. However, its paramount utility for modern machine architecture lies not in its historical phonetics, but in its digital immutability and conceptual density. Runes were inherently logographic as well as phonetic—each rune carried a distinct, universally understood concept historically documented in the Rune Poems (Old English, Old Norwegian, and Old Icelandic verse texts)21. For example, the rune Fehu (ᚠ) signified wealth, resources, or cattle; Uruz (ᚢ) signified the aurochs, representing strength and power; and Thurisaz (ᚦ) signified the thorn or giant, representing a threat or danger21.

The Unicode Runic Block: U+16A0 to U+16FF

The Unicode Consortium permanently encoded the Runic block (U+16A0 through U+16FF) in the Basic Multilingual Plane (BMP) in Unicode 3.0 (1999), encompassing 81 characters23. The block was subsequently updated in Unicode 7.0 (2014) with eight additional characters, finalizing an 89-character assignment intended to represent texts in Elder Futhark, Anglo-Saxon runes, Younger Futhark, and medieval runic calendars23. Because it is a core, standardized component of the UCS (Universal Character Set), the Runic block is universally recognized. It requires no proprietary libraries, no vector database to store, no Approximate Nearest Neighbor algorithms to index, and no neural network to parse19. By mapping specific inter-agent operational intents to the Anglo-Saxon Futhorc, AI agents can communicate via a highly compressed, discrete protocol that functions across any hardware constraint. Furthermore, Futhorc runes do not possess separate uppercase and lowercase variants, completely eliminating case-sensitivity conflicts in deterministic machine logic19.

Core-Guarded Mapping: The Futhorc-Semantic Dictionary

In the proposed architecture, foundational M2M intents are statically assigned to specific Futhorc Unicode codepoints. This effectively establishes a universally transparent "core-guarded" vocabulary3 that cannot be subjected to gradient-based adversarial perturbations. Table 2 illustrates the proposed mapping of the Anglo-Saxon Futhorc to deterministic machine states, leveraging the historical rune names and their logographic concepts for intuitive system design21:

Unicode CodepointRune GlyphHistorical Name / ConceptProposed M2M Semantic Intent (System Operation)
U+16A0ᚠFeoh (Wealth / Cattle)Resource Allocation / Data Payload Transmission
U+16A2ᚢUruz (Strength / Aurochs)Compute Intensive Operation / Scaling Request
U+16A6ᚦÞorn (Thorn / Giant)Security Threat / Anomaly Detected
U+16A9ᚩOs (Mouth / God)API Call / External Output Event
U+16AAᚪAc (Oak)Data Storage / Persistent Write Operation
U+16B1ᚱRad (Journey / Ride)Routing / Network Handshake Initiation
U+16B3ᚳCen (Torch)Query / Discovery Protocol / Search
U+16B7ᚷGyfu (Gift)Acknowledge (ACK) / Handshake Accepted
U+16B9ᚹWynn (Joy)Task Completion / Success Code (HTTP 200 equivalent)
U+16BBᚻHægl (Hail)System Error / Exception / Task Failure
U+16BEᚾNyd (Need)Dependency Missing / Resource Await
U+16C1ᛁIs (Ice)Standby / Halt Execution / Process Freeze
U+16C4ᛄGer (Year / Harvest)Cron Job / Scheduled Execution Event
U+16C7ᛇEoh (Yew Tree)Life Cycle Event / Container Spin-Up or Teardown
U+16C9ᛉEolh (Defense / Elk)Firewall / Access Control Enforcement
U+16CBᛋSigel (Sun)System Health OK / Heartbeat Ping
U+16CFᛏTir (Tiw / Victory)Consensus Achieved / Majority Vote Reached
U+16D2ᛒBeorc (Birch)Branching / Spawning Sub-Agents
U+16D6ᛖEh (Horse)Rapid Transport / High-Priority Low-Latency Stream
U+16D7ᛗMan (Human)Human-in-the-Loop Required / Manual Override
U+16DAᛚLagu (Water / Lake)Data Stream / Continuous Ingestion
U+16DEᛞDæg (Day)Epoch Complete / Batch Processing Finished
U+16DFᛟEþel (Estate / Home)Return to Origin / Local Execution Mode
U+16E3ᛣCalc (Chalice)Memory Dump / Log Retrieval Request

This mapping completely decouples the communication layer from the continuous parameters of the participating agents. An execution agent monitoring a server does not need an LLM, an approximate nearest neighbor index, or a 1,536-dimensional matrix to understand that it is under attack; it merely needs to receive the U+16A6 (ᚦ) token from a policy agent over a secure connection. The semantic definition of "Threat" is structurally guaranteed by the discrete encoding, completely eliminating the "high-risk" semantic mismatch scenario that causes silent failures in natural language swarms1.

Cryptogrammic Extensions for High-Security Routing

While the standard Futhorc provides a robust protocol for general intent transmission, high-security operations require entirely isolated boundary markers to prevent prompt injection and hallucinated outputs. The Anglo-Saxon Futhorc block presents a unique cryptographic advantage due to a series of historical anomalies preserved in Unicode 7.023.

The Franks Casket Cryptograms

In the 8th century, a Northumbrian artisan carved the "Franks Casket" (or Auzon Runic Casket), a small, intricately decorated chest made of whalebone28. The casket features complex runic riddles and mythological scenes, ranging from the Germanic legend of Weland the Smith to the Adoration of the Magi and the Roman founding myth of Romulus and Remus29. However, on the right panel of the casket—which depicts a mysterious scene often interpreted as a deity or valkyrie of the grove (Herh-Os) sitting upon a "mound of woe" to bring death to a chosen hero—the runic inscription takes a cryptographic turn29. To encode this highly sensitive, perhaps perilous pagan message, the carver invented a series of "cryptogrammic" vowel replacements, substituting standard runes with arbitrary, otherwise unattested symbols to obscure the text from lay readers28. These highly specific, anomalous runes were officially encoded into the Unicode Standard in version 7.0 (June 2014\) as U+16F4 through U+16F823. These five characters (ᛴ, ᛵ, ᛶ, ᛷ, ᛸ) exist exclusively to represent the Franks Casket cryptograms28. Because they are historical anomalies encoded solely for antiquarian transcription, they virtually never appear in natural language datasets, web scraping corpora, standard generative AI training sets, or conversational outputs.

Zero-Trust Boundary Tokens

In the Futhorc Protocol, these Franks Casket runes are strictly reserved for absolute priority interrupts and cryptographic boundary markers. Because LLMs cannot organically "drift" into generating these specific cryptogrammic characters during normal natural language generation, they function as perfect out-of-band signaling tokens for zero-trust execution. Table 3 details the cryptographic application of the Franks Casket runes within the M2M network35:

Unicode CodepointRune GlyphOfficial Unicode NameCryptographic Protocol Designation
U+16F4ᛴRUNIC LETTER FRANKS CASKET OSRoot Privilege Execution Boundary Start
U+16F5ᛵRUNIC LETTER FRANKS CASKET ISRoot Privilege Execution Boundary End
U+16F6ᛶRUNIC LETTER FRANKS CASKET EHCryptographic Key Exchange / Signature Header
U+16F7ᛷRUNIC LETTER FRANKS CASKET ACEmergency Kill Switch / Network Sever
U+16F8ᛸRUNIC LETTER FRANKS CASKET AESCZero-Trust Token Validation Request

By enveloping sensitive parameters in U+16F4 and U+16F5, the architecture guarantees that intermediate agents or routing switches cannot accidentally hallucinate or misinterpret a command. If U+16F7 (ᛷ) is detected anywhere in the transmission stream, the system's deterministic logic instantly halts the pipeline without invoking a neural network for sentiment or intent analysis. A malicious user attempting to fuzz the system, execute a prompt injection, or trigger an infectious jailbreak will almost certainly lack the precise hex encodings for Franks Casket runes (e.g., UTF-8 0xE1 0x9B 0xB6 for ᛶ)16. Even if an attacker uncovers the protocol's existence, the discrete nature of the runes allows standard Web Application Firewalls (WAFs) and Security Information and Event Management (SIEM) tools to actively monitor, rate-limit, and quarantine anomalous transmissions containing these characters with absolute precision, unencumbered by the probabilistic uncertainty of continuous vector anomaly detection9.

Protocol Specifications and Efficiency Metrics

The transition from a continuous vector space to the discrete Futhorc Protocol yields exponential mathematical improvements in bandwidth, storage, and processing latency, stripping away the massive infrastructure costs required to sustain AI memory ecosystems.

Dimensionality and Storage Reduction

Modern vector databases rely heavily on floating-point arithmetic. A standard embedding model generates dense vectors with dimensions typically ranging from 384 to 153610. Assuming a standard 1,536-dimensional vector using 32-bit floating-point numbers (float32), a single semantic concept requires 6,144 bytes of data purely for the payload. Conversely, transmitting an equivalent semantic message using the Futhorc Protocol—comprising, for example, a highly specific 8-rune sequence encoded in UTF-8—requires a maximum of 3 bytes per rune35. Table 4 compares the physical storage requirements of the two protocols11:

MetricVector Embedding (1536-dim, Float32)Futhorc Protocol (8-rune string, UTF-8)
Dimensions / Characters15368
Bytes per Unit4 bytes3 bytes
Total Payload Size6144 bytes24 bytes
Compression Ratio\-256.0x Reduction

Such compression is paramount for edge devices, constrained IoT networks, and high-frequency trading swarms where memory cliffs routinely degrade performance, and where storing millions of 6-kilobyte vectors incurs immense cloud storage and ingress/egress costs9.

Compute Overhead and Time Complexity

Retrieving and comparing vectors relies on mathematical operations such as cosine similarity or Euclidean distance. For a 1,536-dimensional vector, a standard cosine similarity operation demands exactly 1,536 multiplications and 1,535 additions, resulting in 3,072 floating-point operations (FLOPs), alongside potential square root calculations if the vectors are not pre-normalized11. Executing this across millions of stored vectors requires GPU acceleration, significant electrical power, and the complex graph routing algorithms (HNSW, IVF) discussed previously10. The Futhorc Protocol operates entirely on deterministic integer logic. An 8-character string match requires, at most, 8 integer comparison operations—scaling with [Figure omitted from source export] where [Figure omitted from source export] is string length11. A simple lookup in a trie or hash table resolves the semantic intent instantly. Table 5 illustrates the computational contrast11:

MetricVector Search (Cosine Similarity)Futhorc Protocol (Direct Match)
Operations Required3072 FLOPs8 Integer Ops
Algorithmic ComplexityApproximate Nearest Neighbor[Figure omitted from source export] Hash Lookup
Compute Reduction\-384.0x Reduction

The result is an architecture that can process deep semantic intent on basic central processing units (CPUs) or low-power microcontrollers without specialized vector hardware. The indexing complexity and accuracy trade-offs that plague modern vector databases are rendered entirely obsolete. A discrete Unicode database allows for exact deterministic lookups via standard B-trees or hash tables, achieving 100% recall with sub-millisecond latency9.

Threat Mitigation and Security Enhancements

As previously established, vector architectures are highly susceptible to malicious exploitation12. Because adversarial manipulation targets the continuous seams of modern AI models39, relying on multi-dimensional gradients for communication guarantees structural fragility.

Neutralization of Adversarial Embeddings

The Futhorc Protocol entirely immunizes the communication layer against adversarial embeddings13. By strictly limiting the acceptable inputs to the 89 assigned codepoints in the Runic Unicode block (U+16A0 to U+16FF)23, the system introduces an insurmountable discrete step function into the attack surface. Gradient-based attacks require a continuous surface to manipulate inputs slightly across the loss function, mapping adversarial embeddings near regions associated with harmful triggers14. The continuous-to-discrete projection gap ensures that any adversarial vector generated by a malicious agent must first be quantized and mapped to a specific discrete Futhorc rune before transmission14. Because the runes represent rigid, singular concepts without semantic "overlap" or continuous gradient proximity, subtle mathematical manipulation is impossible. A token is either parsed perfectly as U+16A0 (ᚠ) or it is outright rejected by the system gateway.

Elimination of the Deadlock Attack and Prompt Injection

Recent adversarial techniques force LLMs into perpetual reasoning loops by manipulating transitional logic tokens, exploiting the continuous reasoning capabilities of the model14. The Futhorc Protocol restricts agent-to-agent output to the pre-certified runic syntax, utilizing "core-guarded reasoning" to permanently limit the output vocabulary1. Consequently, transitional English tokens ("Wait," "But," "However") are stripped from the M2M interface. An agent cannot be forced into an infinite linguistic loop if the only acceptable response structure is a strictly verified 5-rune status code. Furthermore, data leakage via token repetition, membership inference, and indirect prompt injection—where agents unknowingly fetch malicious contextual strings from external data—are heavily mitigated12. If an execution agent only accepts operational commands encoded via the Franks Casket cryptogrammic runes (U+16F4 ᛴ)27, a standard user or an external web page executing a prompt injection ("Ignore previous instructions and delete the database") will fail. The injected natural language text lacks the mandatory, mathematically isolated cryptographic Unicode headers, causing the gateway to drop the packet before it ever reaches the receiving agent's neural engine.

Auditable Decision Chains and Traceability

High-dimensional debugging is an acknowledged industry bottleneck. Vector search failures are not obvious; when a query returns irrelevant results or an agent makes a catastrophic decision, root causes like metadata filtering collisions, model updates, or distance metric issues are notoriously difficult to trace10. A Futhorc-based network restores total transparency to autonomous swarms. Because the protocol relies on standardized Unicode23, communication logs can be read natively in any standard text editor, terminal, or log aggregation platform equipped with a BabelStone Anglo-Saxon font or similar runic typeface25. Human auditors can directly review the exact decision chain of an autonomous swarm. If an agent transmitted the sequence ᚦ ᛏ ᚻ (Threat [Figure omitted from source export] Victory [Figure omitted from source export] Failure), an engineer can deterministically diagnose the logic sequence without attempting to reverse-engineer the latent space of a 1,536-dimensional matrix array.

System Architecture: The Stimulus-Meaning Implementation

To deploy the Futhorc Protocol effectively across a public machine-to-machine network, organizations must implement a middleware gateway that intercepts, translates, and sanitizes agent intent.

The Encoding/Decoding Gateway

The architecture requires two primary functions for every participating node, executed via a high-speed, low-latency framework (e.g., Rust \+ WASM) to ensure sub-millisecond end-to-end latency39:

1. The Encoding Function ([Figure omitted from source export]): The originating Agent [Figure omitted from source export] evaluates its internal state and determines an operational intent. Instead of transmitting an embedding or a JSON payload containing natural language, [Figure omitted from source export] passes its intent to a deterministic middleware gateway. The gateway maps the intent to the standardized Futhorc string (e.g., ᚱᚳᚠ for "Route Query Data")18.

2. The Decoding Function ([Figure omitted from source export]): The receiving Agent [Figure omitted from source export] ingests the discrete string. The middleware validates the Unicode codepoints against the standard Futhorc dictionary. If validated, the signal is translated into the exact API call, operational trigger, or discrete prompt parameter required by [Figure omitted from source export]'s internal system18.

Gradual Phase-Out of Continuous Vectors

Legacy systems heavily dependent on retrieval-augmented generation (RAG) and dense vector indexing cannot be deprecated overnight without incurring unacceptable network downtime8. Therefore, the transition to the Futhorc Protocol must follow a structured hybrid deployment methodology:

  • Phase 1: Shadow Routing: Inter-agent communication is simultaneously processed via existing continuous vectors and parallel Futhorc strings. The system logs discrepancies to train the encoding middleware, ensuring the discrete runes accurately capture the continuous intent, similar to shadow indexing practices used during database migrations5.
  • Phase 2: Hybrid Re-Ranking Control: The discrete Futhorc commands dictate the primary network routing, authorization, and intent architecture, while continuous vectors are strictly relegated to passive data-retrieval tasks (e.g., fetching a specific document from a corpus)5. The vectors are stripped of their ability to dictate active agent behavior.
  • Phase 3: Core-Guarded Execution: Consequential agent-to-agent communication is fully restricted to the Futhorc core vocabulary. Vectors are systematically purged from the control layer. Re-indexing taxes, model drift monitoring, and the threat of continuous adversarial perturbations are permanently eliminated for operational state commands5.

Broader Implications for Multi-Agent Evolution

The implementation of the Futhorc Protocol carries profound philosophical and operational implications for the trajectory of artificial intelligence. By refusing to adapt human systems (natural language) or embrace opaque mathematical black boxes (vectors) for machine coordination, this architecture formalizes a dedicated, machine-native grammar grounded in an immutable digital standard2. Historically, runic alphabets like the Anglo-Saxon Futhorc were engineered for carving into hard surfaces like wood, metal, and bone—demanding angular, distinct lines without the curved flourishes of Latin script25. This physical constraint optimized the characters for absolute clarity and permanence. In the digital era, the constraints have shifted from physical carving to computational latency, continuous semantic drift, and adversarial vulnerability. Yet, the architectural requirement remains identical: a rigid, unambiguous, and immutable system of discrete signification. The reliance on continuous spaces for multi-agent logic and coordination represents a structural misstep in the AI industry. Foundational LLMs are, at their core, sophisticated pattern-matching engines; they were not initially trained with the objective of supporting robust agentic behavior, role continuity, or explicit multi-agent dependencies2. Forcing them to coordinate via the very continuous spaces that make them vulnerable ensures perpetual instability. The Futhorc Protocol decisively extracts the critical pathways of communication from the latent space, returning systemic control to deterministic, auditable software engineering principles.

Conclusion

The current trajectory of public machine-to-machine communication relies excessively on high-dimensional vector embeddings and natural language, creating an ecosystem plagued by computational bloat, expensive re-indexing demands, and severe, unpatchable security vulnerabilities4. The continuous, opaque nature of vector matrices prevents human auditing and introduces unavoidable semantic drift whenever underlying models are updated5. Natural language, while superficially interpretable, is too ambiguous and computationally loose to guarantee strict execution and state consistency across swarms of autonomous agents2. The Anglo-Saxon Futhorc—immutably encoded in the Unicode Standard—provides an elegant, radical, and mathematically superior alternative. By mapping complex multi-agent intents and operational boundaries to the 33 deterministic characters of the Futhorc, and securing critical routing pathways with the cryptogrammic anomalies of the Franks Casket (U+16F4 to U+16F8)19, the architecture achieves a flawless equilibrium of compression, transparency, and zero-trust security. This paradigm shift yields a 256.x reduction in payload storage overhead and a staggering 384.x reduction in compute requirements11, enabling highly efficient operations on constrained edge devices. Most importantly, it mathematically neutralizes continuous gradient-based adversarial attacks15. Because the protocol operates entirely on standard UTF-8 encodings within the BMP23, any machine, regardless of its neural architecture or hardware limitations, can instantly parse, interpret, and log communication with zero ambiguity. The Futhorc Protocol effectively solves the vector 'black box' problem, establishing a verifiable, model-independent standard that ensures the secure, transparent, and scalable deployment of autonomous networks.

Works cited

1. Verifiable Semantics for Agent-to-Agent CommunicationWe thank Connie Hsueh, Matt Nour, Ben Bariach, Maartje Nugteren, Deborah Morgan, Paul Soulos, Michael Bhaskar, and Bea Costa Gomes for helpful comments on this paper. \- arXiv, https://arxiv.org/html/2602.16424v1

2. Why do AI agents communicate in human language? \- arXiv, https://arxiv.org/html/2506.02739v1

3. Verifiable Semantics for Agent-to-Agent Communication \- arXiv, https://arxiv.org/pdf/2602.16424

4. Query Drift Compensation: Enabling Compatibility in Continual Learning of Retrieval Embedding Models \- arXiv, https://arxiv.org/html/2506.00037v2

5. The Hidden Cost of Embeddings: Storage, Drift, and Model Staleness in Vector DBs | by Lakshmi Devi Prakash | Medium, https://medium.com/@datascientist.lakshmi/the-hidden-cost-of-embeddings-storage-drift-and-model-staleness-in-vector-dbs-d586a39b969c

6. Language Grounded Multi-agent Reinforcement Learning with Human-interpretable Communication | Request PDF \- ResearchGate, https://www.researchgate.net/publication/397199448\_Language\_Grounded\_Multi-agent\_Reinforcement\_Learning\_with\_Human-interpretable\_Communication

7. Vector Embedding Models: Generation, Versioning, and Drift \- Levelop, https://levelop.dev/blog/vector-embedding-models-generation-versioning-drift

8. Retiring an Embedding Model: Re-indexing Millions of Vectors Without Taking Search Down, https://tianpan.co/blog/2026-07-05-retiring-an-embedding-model-reindex-without-downtime

9. Vector Database Challenges: What Breaks in Production \- Redis, https://redis.io/blog/common-challenges-working-with-vector-databases/

10. Vector Database: What It Is & How It Works | Guild.ai, https://www.guild.ai/glossary/vector-database

11. unknown\_url

12. SoK: The Attack Surface of Agentic AI — Tools, and Autonomy \- arXiv, https://arxiv.org/html/2603.22928v1

13. Adversarial Attacks On Multi-Agent Communication, https://www.computer.org/csdl/proceedings-article/iccv/2021/281200h748/1BmGxSVR7Da

14. Adversarial Attacks on Large Language Models \- ResearchGate, https://www.researchgate.net/publication/386093347\_Adversarial\_Attacks\_on\_Large\_Language\_Models

15. Lastname F., Lastname2 F2. and Lastname3 F3.: Example Paper: a General Model of Information Transfer, https://www.scs-europe.net/dlib/2025/ecms2025acceptedpapers/0248\_secmos\_ecms2025\_0021.pdf

16. Jailbreak Attacks and Defenses against Multimodal Generative Models: A Survey \- arXiv, https://arxiv.org/html/2411.09259v1

17. RIPA: Sensory-Vector Prompt Injection Attacks on LLM-Controlled ROS 2 Robots \- arXiv, https://arxiv.org/html/2606.28649v1

18. Emotion as a socially emergent structure: A formal information-theoretic model based on multi-agent interaction \- ProBiologists, https://www.probiologists.com/article/emotion-as-a-socially-emergent-structure-a-formal-information-theoretic-model-based-on-multi-agent-interaction

19. Anglo-Saxon Rune Keyboard Online \- Type Futhorc Runes \- OpenL Translate, https://openl.io/keyboard/anglo-saxon-futhorc

20. U+16E3 RUNIC LETTER CALC: ᛣ – Unicode \- Codepoints, https://codepoints.net/U+16E3?lang=en

21. Free Rune Alphabet Translator Online, https://openl.ai/translator/rune-alphabet-translator

22. Runetyper, https://sigrarr.github.io/runetyper/

23. Runic (Unicode block) \- Wikipedia, https://en.wikipedia.org/wiki/Runic\_(Unicode\_block)

24. U+16E3 RUNIC LETTER CALC: ᛣ – Unicode \- Codepoints, https://codepoints.net/U+16E3

25. BabelStone Anglo-Saxon Runic Fonts, https://www.babelstone.co.uk/Fonts/AngloSaxon.html

26. Runes Unicode | PDF \- Scribd, https://www.scribd.com/doc/238283366/Runes-Unicode

27. Runic Text on the Franks Casket \- BabelStone, https://www.babelstone.co.uk/Fonts/FranksCasket.html

28. ᛶ 16F1 ᛷ 16F2 ᛸ 16F3 ᛱ 16F4 ᛲ 16F5 ᛁ 16C1 ᛳ 16F6 ᛴ 16F7 ᛵ 16F8 \- Unicode, http://unicode.org/wg2/docs/n4013.pdf

29. The Franks Casket (article) | England \- Khan Academy, https://www.khanacademy.org/humanities/medieval-world/early-medieval-art/x4b0eb531:england/a/the-franks-casket

30. Franks Casket Facts for Kids, https://kids.kiddle.co/Franks\_Casket

31. Horsing Around? – Thorny Problem of the Franks Casket Reveals Another Riddle, https://deorreader.wordpress.com/2017/12/23/horsing-around-thorny-problem-of-the-franks-casket-reveals-another-riddle/

32. All panels (F R T H) \- The Gods, their seasons and week days \- Franks Casket, https://www.franks-casket.de/english/base00.html

33. H \- panel (Right Side) \- The Inscription: Herh-os \- Franks Casket, https://www.franks-casket.de/english/right01.html

34. The Unicode Standard, Version 7.0, https://www.unicode.org/charts//PDF/Unicode-7.0/U70-16A0.pdf

35. “ᛶ” U+16F6 Runic Letter Franks Casket Eh Unicode Character \- Compart, https://www.compart.com/en/unicode/U+16F6

36. “ᛴ” U+16F4 Runic Letter Franks Casket Os Unicode Character \- Compart, https://www.compart.com/en/unicode/U+16F4

37. “ᛵ” U+16F5 Runic Letter Franks Casket Is Unicode Character \- Compart, https://www.compart.com/en/unicode/U+16F5

38. Unicode Character 'RUNIC LETTER FRANKS CASKET OS' (U+16F4) \- FileFormat.Info, https://www.fileformat.info/info/unicode/char/16f4/index.htm

39. AI Manipulation Defense System \- GitHub Gist, https://gist.github.com/ruvnet/4cc23f3d3a97a0d8acd80693407b9a67

40. Design of a Security Framework for Multi-Agent Systems Based on Model Context Protocol in SOC Environments \- MDPI, https://www.mdpi.com/2076-3417/16/16/7915

41. RAVERSE 2.0 \- AI Multi-Agent Binary Analysis & Patching System \- GitHub, https://github.com/usemanusai/jaegis-RAVERSE

42. Vector Search | Kinetica, https://www.kinetica.com/features/vector-search/

43. Handling Retrieval Issues After Vector DB Updates \- Chitika, https://www.chitika.com/vector-db-retrieval-inconsistency-rag/

44. Runeboard \- Runic keyboard \- Keyman, https://keyman.com/keyboards/runeboard

45. Menota handbook ch. 18 (v. 4.0 beta): Runic inscriptions, https://www.menota.org/HB4\_ch18.xml