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:

```python
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:

```python
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.