---
title: 'Eywa: Architectural Mediation Across AI, Networking & Testing'
url: https://www.emergentmind.com/topics/eywa
type: topic
---

# Eywa: Architectural Mediation Across AI, Networking & Testing

Searching arXiv for the Eywa-related papers mentioned, to ground the article in the latest records.
Eywa is a recurrent system name in contemporary computer science and AI research, but it does not denote a single unified framework. In the arXiv record, the name has been used for at least four technically distinct systems: a provenance-grounded long-term memory architecture for AI agents [2605.30771], a heterogeneous agentic framework for collaboration between language models and domain-specific scientific foundation models [2604.27351], an oracle-based protocol-testing framework for black-box network protocol implementations [2312.06875], and an elastic load-balancing virtual network architecture for multi-tenant IaaS clouds [2604.09322]. Across these uses, the common motif is architectural mediation: each system inserts an explicit intermediate structure—provenance, a reasoning interface, a symbolic oracle, or a distributed hypervisor agent—to separate concerns that would otherwise be conflated.

## 1. Name, scope, and disambiguation

The most recent and most detailed use of the term is **Eywa: Provenance-Grounded Long-Term Memory for AI Agents**, which defines Eywa as “a provenance-grounded memory architecture built around evidence before belief” [2605.30771]. In that work, Eywa is a long-term memory substrate for agents that persist across sessions and need memory they can “retrieve, audit, update, and erase” [2605.30771].

A second 2026 paper, **"Heterogeneous Scientific Foundation Model Collaboration"** [2604.27351], uses Eywa for a heterogeneous agentic framework that lets language-model-based agents collaborate with domain-specific foundation models operating on non-linguistic modalities. That paper defines three variants—**EywaAgent**, **EywaMAS**, and **EywaOrchestra**—and motivates them by arguing that natural language is not a sufficient universal interface for many scientific tasks [2604.27351].

An earlier 2023 paper, **"Oracle-based Protocol Testing with Eywa"** [2312.06875], introduces Eywa as a Python framework for automatic black-box testing of network protocol implementations. Its defining move is to use an LLM to synthesize a compact executable behavioral oracle in C, then use **Klee** to derive systematic tests through symbolic execution [2312.06875].

A separate networking paper, **"EYWA: Elastic Load-Balancing and High-Availability Wired Virtual Network Architecture"** [2604.09322], expands the name as **Elastic load-balancing and high-availabilitY Wired virtual network Architecture**. There, EYWA is a distributed virtual networking design for multi-tenant IaaS clouds, centered on a per-hypervisor agent that enables many distributed virtual routers to share the same tenant gateway IP [2604.09322].

This multiplicity matters because otherwise claims about “Eywa” are easy to misattribute. In current literature, the name refers not to a lineage of one evolving system, but to several unrelated architectures in AI memory, scientific agents, software testing, and cloud networking.

## 2. Provenance-grounded memory architecture for AI agents

In **"Eywa: Provenance-Grounded Long-Term Memory for AI Agents"** [2605.30771], Eywa is defined by three separations: **evidence from belief**, **retrieval from answering**, and **answer policy from memory context**. The central thesis is “evidence before belief”: raw source evidence is stored first and preserved immutably, while extracted memories are treated as revisable derived beliefs linked back to supporting source evidence [2605.30771].

The architecture is motivated by diagnosability. The paper argues that many existing long-term memory systems collapse ingestion, extraction, storage, retrieval, context packing, and answering into “one opaque prompting pipeline,” making it difficult to localize failure causes [2605.30771]. Eywa instead separates several failure modes, including **coverage gap / missing evidence**, **grounding gap / unsupported extraction**, **revision gap / stale state**, **scope gap**, **temporal gap**, **retrieval gap / retrieval loss**, **synthesis gap / answer-model behavior**, and **measurement gap** [2605.30771]. This decomposition is not merely descriptive; the paper presents it as an engineering debugging framework, where each gap implies a different remediation target.

The write path has two tiers. **Tier 0: immutable capture** stores each routed user turn as an evidence record with metadata such as user or tenant scope, speaker role, timestamp, and session, then runs deterministic signal detectors with no LLM call [2605.30771]. The typed signals include people, organizations, places, dates, version numbers, monetary values, identifiers, URLs, IP addresses, percentages, quoted strings, and decisions, corrections, approvals, rejections, and other “memory acts” [2605.30771]. **Tier 1: validated extraction** then asks an LLM to propose candidate facts
$$
\hat{F} = \{\hat{f}_1, \dots, \hat{f}_n\},
$$
which are validated against evidence and signals through
$$
V(\hat{f}, \mathcal{E}, \mathcal{S}) = V_{\text{support}(\hat{f}, \mathcal{E}) \wedge V_{\text{hard}(\hat{f}, \mathcal{S}) \wedge V_{\text{subject}(\hat{f}, \mathcal{E}) \wedge V_{\text{act}(\hat{f}, \mathcal{S})}.
$$
The reported two-tier audit found that **67.4% of candidate facts had no hard anchor**, and **11 of 132 candidate facts were rejected**, mostly for insufficient source overlap or invented hard values [2605.30771].

Eywa’s memory representation explicitly distinguishes **Evidence**, **Signals**, **Candidates**, **Beliefs**, and **Links** [2605.30771]. The implementation uses **SQLite as authoritative store for evidence, facts, lifecycle status, and provenance metadata**, **LanceDB vector indexes**, **SQLite full-text keyword indexes**, and **graph relations / RustworkX graph state** [2605.30771]. A crucial implementation claim is that vector and graph layers are treated as **idempotent projections**, not authoritative stores; if they drift, they are to be rebuilt or reconciled from SQLite [2605.30771]. This suggests a design principle closer to database systems than to prompt-centric memory caches.

The read path is described as **deterministic multi-route retrieval with zero LLM calls inside retrieval** [2605.30771]. The planner classifies question shape—such as exact, recommendation, inference, count, interval, boolean, list, and factoid—and activates weighted retrieval routes including **Vector**,
$$
s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),
$$
**Keyword**, **Temporal**, **Entity/graph**, and support channels such as **raw-episode rescue** and **inference support** [2605.30771]. Route outputs are merged by weighted reciprocal rank fusion,
$$
\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},
$$
with default $k = 20$ [2605.30771]. The pipeline then applies deterministic filters, including a person demotion rule with $\delta_p = 0.05$ and a preservation floor with $r_{\min} = 25$ [2605.30771]. Final context is packed under token budget $B$ as
$$
\mathcal{C}_q = \text{Pack}\!\left(\text{top-}K\!\left(\{f \mid s'(f) > 0\}\right),\; B\right).
$$

A defining feature is the separation of retrieved context from answer instructions. Eywa returns a `ReadResult` with separate `context` and `answer_instructions` fields, permitting the same memory substrate to be evaluated across different answer models and answer policies—**strict**, **balanced**, and **advanced** [2605.30771]. The formal summary is
$$
ReadResult(q) = \bigl(\mathcal{C}_q,\; \mathcal{I}_\pi,\; F_q,\; D_q,\; t_{\text{ms}}\bigr),
$$
where the result includes packed context, answer instructions, fact identifiers, diagnostics, and retrieval latency [2605.30771].

Empirically, under a frozen, artifact-recorded retrieval configuration, Eywa reports **90.19% judge accuracy on LoCoMo C1–C4** with **Claude Sonnet 4.6** write and QA roles, **88.2% retrieval-sufficiency accuracy** on **LongMemEval-S**, and on **BEAM** a **81.45% mean nugget score** with **85.29% pass@score $\geq 0.5$** [2605.30771]. On a stress store with **6,320 facts**, **250 episodes**, and **14,585 fact-entity links**, the default interactive retrieval profile returns assembled context in roughly **150–200 ms**, excluding answer generation and judging [2605.30771]. The paper frames these results as support for a memory architecture whose failures can be localized to explicit pipeline stages rather than collapsed into generic “forgetting.”

## 3. Scientific agentic collaboration across heterogeneous modalities

In **"Heterogeneous Scientific Foundation Model Collaboration"** [2604.27351], Eywa addresses a different problem: the limitation of language-centric agentic systems in scientific settings where relevant inputs are time series, tabular data, symbolic structures, and other domain-native modalities. The paper’s core claim is that specialized foundation models often outperform language-only systems on such inputs, but lack natural-language interfaces and therefore cannot directly participate in higher-level agentic reasoning [2604.27351].

The formal setup factorizes inputs as
$$
X = X_{\mathrm{lng}} \times X_1 \times \cdots \times X_m,
$$
where $X_{\mathrm{lng}}$ is language-observable context and each $X_k$ is a domain-specific component [2604.27351]. The paper uses the data processing inequality,
$$
I(Y;T(X)) \le I(Y;X),
$$
to argue that serializing domain-native inputs into language can discard target-relevant information [2604.27351]. Under squared loss, it gives the Bayes risk gap
$$
R_T - R_X = \mathbb{E}\left[\left\|\mathbb{E}[Y\mid X] - \mathbb{E}[Y\mid T(X)]\right\|^2\right] \ge 0,
$$
as the formal reason why language is not a sufficient universal medium for scientific agentic systems [2604.27351].

The framework augments a domain-specific foundation model $F_k : X_k \times U_k \to O_k$ with an FM-LLM interface pair: a **query compiler** $\phi_k : S \to U_k$ and a **response adapter** $\psi_k : O_k \to Z_k$ [2604.27351]. The core **EywaAgent** abstraction is
$$
A_{\mathrm{eywa}} = (A_{\mathrm{LLM}}, F, \phi, \psi, C),
$$
where $C : S \to \{\texttt{invoke}, \texttt{skip}\}$ is a control policy [2604.27351]. If the policy skips invocation, the agent reduces to a standard LLM step,
$$
z^{(t)} = A_{\mathrm{LLM}}(s^{(t)}).
$$
If invocation occurs, the coupled pipeline is
$$
u = \phi(s^{(t)}), \qquad o = F(x, u), \qquad z^{(t)} = \psi(o),
$$
followed by state update $s^{(t+1)} = s^{(t)} \cup \{z^{(t)}\}$ [2604.27351]. This makes the LLM a controller and integrator over specialist computation rather than the sole reasoning engine.

The paper generalizes this primitive in two directions. **EywaMAS** is a heterogeneous multi-agent system
$$
M_{\mathrm{Eywa}} = (A, G),
$$
where each $A_i$ is either an LLM agent or an EywaAgent, and $G$ is the communication topology [2604.27351]. **EywaOrchestra** is a planning-based orchestration framework
$$
O = (C, P),
$$
where $C$ is a configuration space induced by candidate LLMs, candidate FMs, and a topology pool, and $P$ is a conductor that selects a configuration per task [2604.27351]. The paper defines the fixed-configuration risk
$$
R_{\mathrm{fixed}} = \min_{c \in C} \mathbb{E}_{T\sim\mathcal{T}}[\ell(F_c(q,x), y^*)]
$$
and oracle adaptive risk
$$
R_{\mathrm{oracle}} = \mathbb{E}_{T\sim\mathcal{T}} \left[ \min_{c\in C} \ell(F_c(q,x), y^*) \right],
$$
with the stated theorem that $R_{\mathrm{oracle}} \le R_{\mathrm{fixed}}$, and strictly less when no single configuration is optimal for all tasks [2604.27351].

The practical implementation uses the **Model Context Protocol (MCP)**, **LangChain agents**, **FastMCP servers**, and one MCP backend per foundation model [2604.27351]. The benchmark, **EywaBench**, spans physical, life, and social sciences, mixes natural language, time series, and tabular tasks, and uses **Chronos** for time series and **TabPFN** for tabular prediction [2604.27351]. The main results report that **EywaAgent** improves over **Single-LLM-Agent** from **0.6154** to **0.6558** utility, while reducing time from **25.22** to **22.78**, summarized as **~6.6% average utility improvement**, **nearly 30% token reduction**, and **~10% lower execution time** [2604.27351]. **EywaMAS** achieves **0.6761** overall utility, outperforming **Refine MAS** (**0.6294**), **Debate MAS** (**0.6460**), **MoA** (**0.6273**), and **X-MAS** (**0.6188**) [2604.27351]. **EywaOrchestra** reaches **0.6746** utility with **48.16** overall time, compared with **72.11** for EywaMAS [2604.27351]. The paper interprets these results as evidence that cross-modality heterogeneity matters more in these tasks than simply composing multiple LLMs.

## 4. Oracle-based protocol testing

The 2023 paper **"Oracle-based Protocol Testing with Eywa"** [2312.06875] uses the name for a framework in network protocol testing. Its defining methodology is **oracle-based testing**, which combines LLM-synthesized protocol models with symbolic execution to automate black-box testing without requiring humans to hand-build formal protocol models [2312.06875].

The workflow is function-centric. A user defines a protocol component as a typed Python function using Eywa library abstractions such as `eywa.Bool()`, `eywa.String(maxsize=5)`, `eywa.Struct(...)`, `eywa.Arg(...)`, and `eywa.Func(...)` [2312.06875]. Eywa converts that description into a prompt for an LLM to implement the function in C and into a symbolic harness in C that creates symbolic inputs and enforces preconditions with `klee_assume(...)` [2312.06875]. It then compiles the model plus harness to LLVM bitcode, invokes **Klee**, and translates the resulting test cases back into Python values [2312.06875]. The key conceptual distinction is that Eywa does not ask the LLM to output tests directly; it asks the LLM to produce a behavioral program model from which systematic tests can be derived [2312.06875].

The implementation details are unusually concrete. Eywa is about **2K lines of Python** plus **200 lines of C**, uses **GPT-4 on Azure OpenAI Service**, and supports multiple model samples by choosing temperature $\tau \in [0.0, 1.0]$ and number of implementations $k$ [2312.06875]. In experiments the authors use **$k = 10$** and **$\tau = 0.6$**, compiling each generated model, symbolically executing successful ones, and taking the union of resulting tests [2312.06875]. The generated models are interpreted as **partial executable specifications**: imperfect, but sufficiently semantically rich to expose corner cases [2312.06875].

The main case study concerns DNS. Eywa was evaluated against **ten widely used DNS implementations**—**bind**, **coredns**, **gdnsd**, **hickory**, **knot**, **nsd**, **powerdns**, **technitium**, **yadifa**, and **twisted names**—using differential testing across implementation/version pairs in Docker containers [2312.06875]. The authors built eight Eywa models, including `cname`, `dname`, `wildcard`, `ipv4`, `fulllookup`, `rcode`, `auth`, and `loop`, with **19–40 lines of Python** per model and generated C models of a few hundred lines [2312.06875]. Across models Eywa generated roughly **100K** tests [2312.06875].

The headline result is the discovery of **38 bugs total** across ten implementations, corresponding to **26 unique bugs** after deduplicating root causes, of which **15** were also found by SCALE and **11** were new [2312.06875]. The paper emphasizes that this exceeded **SCALE**, which found **22 unique bugs**, while Eywa missed **7 unique bugs** found by SCALE [2312.06875]. Runtime measurements report that each LLM query took **under roughly 20 seconds**, simple models typically required **5–10 seconds** of Klee time, larger models hit the **5-minute timeout**, and each test across the **17 implementation/version pairs** took about **10 seconds**, leading to testing over several days despite parallelization [2312.06875].

A notable interpretive claim in the paper is that imperfect LLM-generated models can still be useful. An example involving DNAME semantics shows that even a semantically wrong branch in the generated oracle can provoke Klee to explore corner-case inputs that reveal real implementation bugs [2312.06875]. This suggests a broader methodological point: executable approximations derived from natural-language knowledge may be valuable not despite their incompleteness, but partly because they perturb the search space in bug-finding-relevant ways.

## 5. Virtual network architecture for multi-tenant IaaS clouds

In **"EYWA: Elastic Load-Balancing and High-Availability Wired Virtual Network Architecture"** [2604.09322], the term designates a distributed virtual networking architecture for multi-tenant clouds. The central problem is that conventional overlay network architectures centralize too much functionality around special network nodes or virtual routers, creating bottlenecks, single points of failure, inflexible failover, and poor scaling of tenant isolation [2604.09322].

The architecture’s main conceptual move is to place an **agent on every hypervisor host** and allow multiple distributed virtual routers for a tenant to share the same private gateway IP address, such as `10.0.0.1`, while the agent controls which physical VR is visible to each VM [2604.09322]. The paper stresses that the per-hypervisor agent is EYWA’s **only component**, and that the full set of agents collectively acts as a distributed controller without any centralized controller, external state database, or mandatory gateway appliance [2604.09322].

The design aims to solve three problems simultaneously. First, it supports a very large number of tenants by using **VxLAN** rather than VLANs, with a **24-bit virtual network identifier** allowing approximately
$$
2^{24} = 16{,}777{,}216
$$
virtual networks, contrasted with about **4,094** VLAN IDs [2604.09322]. Second, it provides per-tenant public network services—especially **SNAT/DNAT** and integrated **Layer-4 load balancing**—without the usual single-router throughput bottleneck or single point of failure [2604.09322]. Third, it seeks to provide a **single large IP subnet with extended Layer-2 semantics** while suppressing ARP and broadcast pathologies that normally make large L2 domains difficult to scale [2604.09322].

The paper defines two operating modes: **Normal Mode**, when a tenant VM shares a hypervisor with a local VR and should use it as default gateway, and **Orphan Mode**, when no local VR exists and the VM must bind to a remote VR [2604.09322]. The agent performs three main functions: **VR monitoring**, **ARP caching**, and **ARP filtering and proxy ARP** [2604.09322]. The mechanism is especially centered on ARP/GARP control at the VTEP boundary. In Orphan Mode, if a local orphan VM ARPs for the gateway, the request is passed; multiple remote VRs may respond because they share the same gateway IP, and EYWA resolves the resulting ARP flux problem by accepting only the **fastest reply** and filtering the rest [2604.09322]. Inbound discovery requests to an overloaded local VR can be filtered so that orphan VMs avoid selecting it [2604.09322].

The implementation is a proof of concept on a **10-server testbed** connected through a **single commodity switch** in a **single rack**. The switch has **2 × 10 Gbps ports** and **24 × 1 Gbps ports**, each server connects at **1 Gbps**, each hypervisor can run at most one VR and one or two VMs depending on the experiment, and the VR’s L4 load balancer is implemented with **HAProxy** [2604.09322]. Evaluation emphasizes bandwidth-saturation workloads rather than latency or failover timing.

The main finding is that aggregate throughput scales with the number of active VRs and VMs. In Normal Mode, when every hypervisor hosts both a VR and a VM of the same tenant, each VM can use its full physical link bandwidth to external servers, and aggregate north-south throughput equals the sum of individual link capacities [2604.09322]. Auto-scaling experiments show throughput increasing and decreasing proportionally with active instances, and inter-tenant east-west experiments show one-to-one and one-to-$N$ throughput tracking the physical capacities of active communicating pairs [2604.09322]. The paper contrasts this with a conventional **single-router environment**, where aggregate throughput would be capped by the bandwidth of only two VMs’ links regardless of the number of communicating VMs [2604.09322].

The limitations are explicit: the evaluation is small, there is no direct apples-to-apples comparison against systems such as OpenStack Neutron or MidoNet, failover time and packet loss are not reported, and the control logic remains heuristic, particularly the “fastest ARP reply wins” policy [2604.09322]. Even so, the design is presented as a deployable alternative that avoids centralized bottlenecks without requiring host kernel, physical switch, or software switch modifications [2604.09322].

## 6. Cross-cutting architectural themes and technical significance

Although the four Eywa systems are unrelated in application domain, they share a recognizable architectural style. Each is motivated by the claim that an existing end-to-end pipeline obscures important structure, and each inserts an explicit intermediate representation to recover controllability.

In the long-term memory Eywa, the crucial separation is between **source evidence** and **derived belief**, reinforced by explicit provenance links $\ell(f) \to e$ and by the separation of retrieval outputs from answer policy [2605.30771]. In the scientific-agent Eywa, the key mediation layer is the FM-LLM interface $(\phi, \psi)$ and the control policy $C$, which let non-linguistic foundation models participate in agentic reasoning without being forced into purely textual I/O [2604.27351]. In the protocol-testing Eywa, the LLM does not directly generate tests; instead it synthesizes a compact executable oracle whose paths can be explored by symbolic execution [2312.06875]. In the virtual-network EYWA, a per-hypervisor agent mediates ARP visibility and gateway identity so that many distributed VRs can present a single logical gateway to VMs [2604.09322].

A second commonality is the preference for structured, inspectable subsystems over opaque learned monoliths. The memory architecture emphasizes deterministic read-time routing and “zero LLM calls inside retrieval” [2605.30771]. The scientific-agent framework formalizes invocation through structured FM schemas and MCP-backed service interfaces [2604.27351]. The protocol-testing system uses typed function models, generated C, symbolic harnesses, and explicit path conditions [2312.06875]. The cloud-networking architecture relies on explicit ARP packet-control rules rather than centralized SDN-style control [2604.09322]. This suggests a broader research trend in which LLMs or distributed components are embedded within typed, auditable scaffolds rather than allowed to subsume the entire system boundary.

A third theme is model separability. The memory Eywa explicitly argues that the same memory substrate should be testable across frontier, budget, and local answer models [2605.30771]. The scientific-agent Eywa similarly treats the LLM, domain-specific FM, and planner as separable components that can be recombined into different agentic topologies [2604.27351]. The protocol-testing Eywa separates behavioral-oracle construction from downstream implementation testing [2312.06875]. This modularity is not identical across papers, but it consistently serves the same purpose: reducing confounding when diagnosing system behavior.

These convergences do not imply a shared lineage, but they do make the reuse of the name intelligible. In all four cases, Eywa denotes an architectural connective tissue rather than a single model: a substrate that binds heterogeneous components while preserving some form of traceability, locality, or controllable delegation.

## 7. Limitations, misconceptions, and prospective interpretation

A common misconception would be to treat “Eywa” as a single platform spanning AI memory, scientific agents, protocol testing, and cloud networking. The literature does not support that interpretation. The four systems are independent proposals with distinct authorship, technical stacks, benchmarks, and problem formulations [2605.30771][2604.27351][2312.06875][2604.09322].

Within each work, the main limitations are also domain-specific. The provenance-grounded memory Eywa depends partly on extraction model quality, uses hand-coded route weights and thresholds, relies on write-time supersession invariants for stale-state handling, and does not report confidence intervals or significance tests [2605.30771]. The scientific-agent Eywa depends on the quality of both the LLM and the domain-specific FMs, is limited by planner quality in EywaOrchestra, and does not provide planner calibration, uncertainty modeling, or a detailed error taxonomy for failed FM invocations [2604.27351]. The protocol-testing Eywa assumes that the target protocol is sufficiently represented in public natural-language sources and that bounded symbolic search spaces still cover meaningful bug-triggering behaviors [2312.06875]. The virtual-network EYWA demonstrates feasibility rather than hyperscale validation, and many of its HA and load-balancing claims are supported more by architectural reasoning than by detailed timing measurements [2604.09322].

A plausible implication is that the name’s reuse reflects a wider methodological convergence across systems research and AI engineering. Each Eywa instantiation addresses a brittle interface—memory vs. evidence, language vs. modality-native prediction, natural-language protocol descriptions vs. executable test models, and logical gateway identity vs. distributed forwarding—by making the interface explicit and operationally manipulable. From that perspective, the significance of the Eywa papers lies less in the lexical coincidence than in a shared systems ideal: replace hidden coupling with structured mediation.

Source: https://www.emergentmind.com/topics/eywa