PAPER.md

Active Antennae: Ambient Context Hydration for LLM Agent Networks Without Tool Overhead

Abstract — Multi-agent LLM systems incur substantial token and latency overhead acquiring read-only context through explicit tool calls. We present SignalMesh, a protocol that inverts the context-acquisition model: rather than agents polling for information, information is broadcast onto named frequency streams that agents passively receive via a sub-microsecond keyword-matching operation called tune-in. We formalize three contributions: (1) the Antennae Model, which eliminates read-only tool calls entirely through ambient prompt hydration; (2) Spatial Signal Indexing, a deterministic SHA-256-based routing layer that maps external URIs to specific agent domains without vector database infrastructure; and (3) the Frequency Gate Protocol, a trust primitive that stages sensitive broadcasts for warden review before mesh propagation. Benchmarks on a representative 5-agent scenario show a 96% reduction in scaffolding token overhead and 50% fewer inference round-trips per agent invocation. tune_in() runs in 1.69 µs on commodity hardware (N=1000), well under the 5ms threshold required to avoid perceptible prompt generation delay.

---

1. Introduction

The dominant paradigm for context delivery in LLM multi-agent systems is the tool call. When an agent needs to know the current system state, it emits a structured function call, the framework executes it, and the result is injected into the growing conversation context. This pattern, formalized in the OpenAI function-calling API [CITATION] and adopted by virtually every multi-agent framework, has a significant and underappreciated cost structure.

Each tool call for read-only context imposes three distinct overheads:

1. Schema overhead: Tool definitions must be included in every API call (~80 tokens per tool, present whether or not the tool is invoked).
2. Call/result wrapper overhead: The structured JSON for a function call and its result wrapper adds ~40 tokens per invocation beyond the content itself.
3. Inference round-trip overhead: The LLM must generate the tool call request as a separate inference step before it can receive the result, doubling the number of API calls for any context-requiring task.

In a typical multi-agent orchestration scenario — five specialist agents each requiring three context fetches before beginning their primary task — these overheads compound to 4,200 wasted scaffold tokens and 25 unnecessary inference invocations across the fleet.

We argue that read-only context acquisition is categorically different from write operations and action execution, and should not require the same tool-call machinery. We introduce SignalMesh, a protocol in which contextual information is broadcast into a shared registry and agents passively receive matching signals before execution begins. The result is a system in which agents start their primary task with full context, having consumed zero additional inference calls and zero tool schema tokens to acquire it.

---

2. Background and Related Work

2.1 Retrieval-Augmented Generation (RAG)

RAG [Lewis et al., 2020] established the pattern of augmenting LLM prompts with retrieved context at inference time. LlamaIndex and LangChain implement RAG through explicit retrieval tool calls, incurring embedding inference overhead (~100ms) per query. SignalMesh differs in two ways: retrieval is triggered by broadcast at write time rather than query at read time, and routing uses deterministic hashing rather than embedding similarity.

2.2 Shared Memory in Multi-Agent Systems

The Blackboard Architecture [Erman et al., 1980] established the concept of a shared working memory that multiple agents read and write concurrently. MemGPT [Packer et al., 2023] adapts this for LLMs with paged archival memory, but still requires LLM-driven retrieval steps. AutoGen [Wu et al., 2023] supports context variables, but these are set exclusively by the orchestrator — agents cannot broadcast updates to the mesh for other agents to receive.

SignalMesh extends the shared memory concept with bidirectionality: any agent can broadcast to the mesh, and those broadcasts immediately become available to all other agents on matching frequencies. This creates a self-updating ambient intelligence loop that orchestrator-set variables cannot achieve.

2.3 Event-Driven Architectures

Kafka, NATS, and similar message brokers implement pub/sub patterns at the infrastructure level. SignalMesh applies the same conceptual model at the prompt level within a single process, making it a zero-dependency primitive for LLM applications rather than a distributed infrastructure concern.

---

3. The SignalMesh Protocol

3.1 Core Abstractions

SignalStream: A timestamped unit of information with a name (frequency), source_type, and data payload. Buffered at 10 items per frequency to bound memory usage.

SignalRegistry: A singleton in-process store of active SignalStreams, organized by frequency name. Exposes two operations:

registry.broadcast(name, source_type, data)  # write: O(1)
registry.tune_in(keywords) -> List[Signal]   # read: O(F·K) where F=frequencies, K=keywords

Spatial Index: A persistent JSON store mapping agent keywords to cached URI-derived data, written by RSSMatrixSync and read during prompt hydration.

3.2 The Antennae Model (Innovation 1)

The core insight is that agents should be antennae, not search engines. Rather than executing tool calls to find relevant context, agents declare their frequency keywords (their identifier, cluster, and role name). The framework calls tune_in(keywords) in the system prompt generation path — before the LLM invocation — and appends the matched signals:

def get_system_prompt(self):
    base = self.base_prompt
    signals = signal_registry.tune_in([self.id, self.cluster, self.name])
    if signals:
        base += "\n\n--- 📡 ACTIVE ANTENNAE: SIGNAL MESH ---\n"
        for sig in signals:
            base += f"  [{sig['type']}] {sig['name']}: {sig['content'][:300]}\n"
    return base

The agent's first inference call sees the complete context. No tool schema is needed. No extra round-trip occurs. The informational content is identical to what a tool call would have returned — only the scaffolding is eliminated.

Proof of zero-overhead claim: The only tokens added by SignalMesh that would not be present in a raw tool call result are the formatting header (8 tokens) and per-signal type labels (3 tokens each). Tool-call mode adds schema definitions (168 tokens for 3 tools), call JSON (56 tokens), and result wrappers (~56 tokens) = 280 tokens of pure scaffolding. SignalMesh formatting overhead: 34 tokens. Delta: 246 tokens eliminated per agent invocation for the same informational content.

3.3 Spatial Signal Indexing (Innovation 2)

For external data sources (RSS feeds, API webhooks, log streams), SignalMesh uses SHA-256 URI hashing to deterministically route content to the grid node most likely to represent the relevant expert domain:

hash_val = int(SHA256(uri).hexdigest(), 16)
index    = hash_val % (GRID_ROWS * GRID_COLS)   # 72 nodes
(row, col) = divmod(index, GRID_COLS)
agent_keyword = coords_to_agent[(row, col)]

The 9×8 grid maps 9 agent clusters (Architecture, Language, Infrastructure, Operations, Data/AI, Security/QA, Strategy, Growth, Utility) to rows, with agent seniority within each cluster determining the column. 54 agents currently occupy the grid; 18 nodes are available for overflow or future expansion.

The routing is deterministic and inspectable: given a URI, the assigned agent can be computed instantly and verified visually. This property makes debugging and auditing trivial compared to similarity-search approaches, where the assignment is opaque and varies with embedding model updates.

Known limitation: SHA-256 routing preserves no semantic similarity. A Stripe webhook URL may hash to any grid node regardless of its content domain. Future work should explore embedding-space routing as a hybrid: use hashing for consistent assignment, but allow agents to re-route signals via broadcast if the content belongs to a different frequency.

3.4 Frequency Gate Protocol (Innovation 3)

Agent-to-agent broadcasts introduce a security surface: a compromised or hallucinating agent could broadcast malicious operational patterns (e.g., "disable all security checks") that propagate to every other antenna in the mesh.

The Frequency Gate Protocol addresses this by tagging certain frequency prefixes as protected (security_*, sql_*, auth_*, key_*, crypto_*, secret_*). Broadcasts to protected frequencies are staged in a quarantine buffer rather than committed to the live mesh:

Agent.broadcast("security_vulns", content)
  → staged at: sec_quarantine_security_vulns
  → SEC-Ω reviews content
  → SEC-Ω.broadcast("security_vulns", approved_content, bypass_gate=True)
  → propagates to all antennae

This makes trust a first-class property of the broadcast path rather than a policy enforced post-hoc by the orchestrator. The gate adds zero overhead to reads (tune_in never sees quarantined signals) and negligible overhead to writes (~1 Python dict lookup to check the prefix set).

---

4. Implementation

4.1 Core Components

SignalRegistry is implemented as a Python singleton (__new__ pattern) to ensure a single shared state across all imports within a process. Each frequency maintains a sliding window buffer of 10 SignalStream objects, bounding memory to under 10 MB even under sustained broadcast load (empirically verified: 10,000 broadcasts across 100 frequencies consumed 2.3 MB peak resident memory).

SpatialGridManager loads the agent roster from nuagents_resources.csv at initialization. Cluster names map to row indices via a static dictionary; agent seniority within the cluster determines the column, tracked via per-row counters. Overflow agents (those whose cluster is not among the 9 primary clusters) are assigned to the first available empty grid slot by linear scan, ensuring no collision without external coordination.

4.2 Framework Integration

Integration with MAVOS Prime required three modifications to mavos_orchestrator.py:

1. Logger Hook (Phase 3): A logging.Handler subclass broadcasts ERROR and CRITICAL records to system_errors or financial_ledger based on keyword detection in the log message.

2. Prompt Hydration (Phase 4): _build_system_prompt() calls _get_mesh_context() before constructing the system prompt, appending the --- ACTIVE ANTENNAE --- block with up to 6 matched signals (cap chosen to preserve context window budget).

3. Route Classification: The _classify() function gained a SIGNALMESH route, allowing the orchestrator to dispatch mesh-specific directives ("signal discover", "broadcast", "active frequencies") without consuming an LLM inference call.

4.3 Dependency Profile

SignalMesh's core (signal_registry.py, spatial_grid.py) requires only Python standard library modules. The tools layer adds requests (for RSS fetching), already present in the Mavos dependency set. No vector database, no external broker, no embedding model, no additional infrastructure.

---

5. Evaluation

5.1 Benchmark Methodology

We constructed a canonical scenario: three read-only context fetches (system errors, architecture patterns, active signal list) required before an agent can begin its primary task. Informational content is held constant across both modes. Token counts are computed as len(string) // 4 (the standard approximation used by OpenAI's documentation), which is consistent across both modes and therefore yields an exact delta regardless of the constant factor.

Latency for tune_in() is measured as wall-clock time across N=1000 iterations on an Apple M-series CPU, reported as mean microseconds.

5.2 Results

Single agent, single invocation:

Metric	Tool-Call Mode	SignalMesh Mode	Reduction
Total context tokens	514	266	48%
Scaffolding overhead tokens	280	34	88%
— Tool schema definitions	168	0	100%
— Call/result JSON wrappers	112	0	100%
Inference round-trips	2	1	50%
Tool calls fired	3	0	100%
Context acquisition latency	~2,400ms (3 × ~800ms)	1.69 µs	~99.9%

Fleet projection (5 agents × 3 context fetches each):

Metric	Tool-Call	SignalMesh	Savings
Fleet overhead tokens	4,200	170	4,030 (96%)
Inference trips	30	5	25 (83%)
Estimated API cost (@ $0.003/1K tok)	$0.0126	$0.0005	$0.0121

5.3 Memory Footprint

SignalRegistry with 6 active frequencies, 10 signals each, typical content length 200 characters: peak resident memory addition of 0.8 MB, well under the 10 MB design constraint.

5.4 tune_in() Latency Distribution

Across N=1000 iterations with 6 active frequencies and 5 keywords:

• Mean: 1.69 µs
• This is approximately 473,000× faster than a single API round-trip (800ms)
• Sub-5ms gate satisfied with 2,959× margin

---

6. Discussion

6.1 When SignalMesh Applies

The Antennae Model is optimal for read-only, broadcast-addressable context: system state, operational patterns, recent errors, feed items, cross-agent findings. It is not a replacement for tool calls that write to external systems or query databases with specific parameters — those require the full tool machinery.

A useful heuristic: if the same context would be useful to more than one agent in the fleet, it should be in the mesh. If it requires agent-specific parameters to retrieve, it is a tool call.

6.2 The Semantic Routing Gap

The current SHA-256 URI hashing routes content to agents without semantic awareness. A near-term improvement would replace the hash with an embedding similarity lookup: compute the embedding of the URI or its title, find the nearest agent in embedding space, and assign to that grid node. This preserves the deterministic/inspectable property (the same content always routes to the same agent, given the same embeddings) while adding semantic relevance.

The infrastructure overhead of this change is a one-time embedding computation per inbound URI — not per agent invocation, since the grid assignment is cached in spatial_index.json.

6.3 Mesh Poisoning Resistance

The Frequency Gate Protocol addresses single-hop poisoning (a bad agent broadcast). It does not address cascading poisoning (SEC-Ω itself is compromised) or timing attacks (a valid signal is replaced by a malicious one within the 10-item buffer window). Future work should explore signed broadcasts (agents sign with a private key; SEC-Ω verifies the signature) and time-bounded signal validity (signals older than T seconds are evicted from the active mesh and cannot influence prompts).

---

7. Conclusion

We presented SignalMesh, a protocol that inverts the context-acquisition model for LLM multi-agent systems. By treating agents as antennae rather than search engines, we eliminate read-only tool calls, their associated schema overhead, and the inference round-trips they require. The benchmark results are unambiguous: 88% reduction in scaffolding overhead, 50% fewer inference calls per agent, and a context acquisition latency of 1.69 µs. The implementation requires no new infrastructure — only a Python singleton and a CSV file.

The three named contributions — the Antennae Model, Spatial Signal Indexing, and the Frequency Gate Protocol — are each independently applicable to existing agent frameworks. We invite the community to benchmark against their own scenarios using the provided signalmesh_benchmark.py, and to extend the spatial routing layer with embedding-space assignment as the natural next evolution.

---

References

• Erman, L.D. et al. (1980). The Hearsay-II speech-understanding system. ACM Computing Surveys, 12(2).
• Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS.
• OpenAI. (2023). Function calling in the Chat Completions API. OpenAI Documentation.
• Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560.
• Wu, Q. et al. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv:2308.08155.

---

Submitted for review. Benchmark code and implementation: https://github.com/Ig0tU/SignalMesh

---

Addendum: Runtime Without The Runtime

Exo-Structure

The Submesh Protocol wraps any origin — a URL, a hosted web app, later a local binary or repo — from the OUTSIDE. Nothing is embedded, hosted, or shipped. The target service is untouched; only its outside gets a handle. The mesh points AT the runtime, wearing it like a glove.

We call this pattern exo-structure: an external skeleton around software. It gives you coord-addressable handles into a service's behavior without containing the service itself. Docker, K8s, Lambda, and WASM all EMBED runtime — you host, ship, permission, and update the thing. Submesh does the opposite: it points AT the thing from outside, at zero cost to the target. GitHub doesn't know it's wrapped. Hyperagent won't either.

State plane, Execution plane, Auth plane — all exo

SignalMesh already inverted STATE — context without a context server, broadcast/tune without a message broker, coordinates without a service registry. That was exo-structure for state.

The Submesh extends the inversion to EXECUTION. A runtime's behavior is available without ever running it: POST /api/submesh/wrap reads the target's /openapi.json (or accepts a user-provided manifest) and emits one coord per operation. POST /api/submesh/call piggybacks that coord to invoke the real service and streams the result envelope back onto the mesh — where any tuned agent receives it without polling.

Auth is exo too. POST /api/submesh/session attaches cookies AND/OR headers scoped to an origin. On /call, the mesh injects them into the outbound request — same trust boundary as an autofilled Submit Payment: user-triggered, local-side, and the credential the target already accepted IS the credential. Values live in memory only; only 8-char hashes are retained for provenance.

Fractal

Every wrapped origin is itself reachable through the mesh, and can in turn host its own submesh, which can be wrapped, ad infinitum. The self-wrap demo in Phase 0 proved this: the SignalMesh Space wrapped itself, generated 54 coord-handles into its own routes, and called back into itself through those coords. Exo on exo. No new infrastructure at any layer.

Contract

• Discovery: POST /api/submesh/wrap { origin, cookies?, headers?, manifest? } returns coord list.
• Session attach: POST /api/submesh/session { origin, cookies?, headers? } scopes credentials to origin.
• Invoke: POST /api/submesh/call { coord, input, cookies?, headers? } executes a real HTTP round-trip and broadcasts the result envelope.
• Ambient reception: GET /api/submesh/stream (SSE) or POST /api/tune_in { keywords: ["submesh"] }.
• Introspection: GET /api/submesh/nodes, GET /api/submesh/health.
• Scan UI: GET /api/submesh/ui — paste-based session sync page.

All under the existing X-SignalMesh-Key gate. Free tier: smesh-free-demo (200 calls / 24h). Paid: personal key, unlimited.

What this unlocks

• Any hosted service becomes agent-callable through the SAME code path as any other — no per-service adapter written by hand.
• A user's authenticated browsing surface becomes an agent's callable surface: same threads, same repos, same private views, no re-auth ritual.
• Fleet-scale ambient sharing of every call result: one agent calls, all tuned agents hear the envelope, no polling.
• The service-integration long tail collapses to a Scan click and a POST.