Eywa: Architectural Mediation Across AI, Networking & Testing

• Eywa is a designation for distinct, domain-specific systems that use explicit architectural mediation to disentangle complex interfaces in AI memory, scientific collaboration, protocol testing, and cloud networking.
• Each implementation leverages a structured intermediate layer—such as provenance, FM-LLM interfaces, executable oracles, or hypervisor agents—to improve diagnosability, modularity, and performance.
• Eywa systems demonstrate practical gains including higher utility scores, reduced token usage in agent collaborations, and effective bug discovery in protocol testing and network performance.

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 (Joshi, 29 May 2026), a heterogeneous agentic framework for collaboration between LLMs and domain-specific scientific foundation models (Li et al., 30 Apr 2026), an oracle-based protocol-testing framework for black-box network protocol implementations (Kakarla et al., 2023), and an elastic load-balancing virtual network architecture for multi-tenant IaaS clouds (Jeong et al., 10 Apr 2026). 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” (Joshi, 29 May 2026). 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” (Joshi, 29 May 2026).

A second 2026 paper, "Heterogeneous Scientific Foundation Model Collaboration" (Li et al., 30 Apr 2026), 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 (Li et al., 30 Apr 2026).

An earlier 2023 paper, "Oracle-based Protocol Testing with Eywa" (Kakarla et al., 2023), 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 (Kakarla et al., 2023).

A separate networking paper, "EYWA: Elastic Load-Balancing and High-Availability Wired Virtual Network Architecture" (Jeong et al., 10 Apr 2026), 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 (Jeong et al., 10 Apr 2026).

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" (Joshi, 29 May 2026), 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 (Joshi, 29 May 2026).

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 (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026). 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” (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026).

Eywa’s memory representation explicitly distinguishes Evidence, Signals, Candidates, Beliefs, and Links (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026). 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$ (Joshi, 29 May 2026). The pipeline then applies deterministic filters, including a person demotion rule with $\delta_p = 0.05$ and a preservation floor with $r_{\min} = 25$ (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026).

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 $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})}.$0 (Joshi, 29 May 2026). 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 (Joshi, 29 May 2026). 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" (Li et al., 30 Apr 2026), 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 (Li et al., 30 Apr 2026).

The formal setup factorizes inputs as

$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})}.$1

where $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})}.$2 is language-observable context and each $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})}.$3 is a domain-specific component (Li et al., 30 Apr 2026). The paper uses the data processing inequality,

$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})}.$4

to argue that serializing domain-native inputs into language can discard target-relevant information (Li et al., 30 Apr 2026). Under squared loss, it gives the Bayes risk gap

$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})}.$5

as the formal reason why language is not a sufficient universal medium for scientific agentic systems (Li et al., 30 Apr 2026).

The framework augments a domain-specific foundation model $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})}.$6 with an FM-LLM interface pair: a query compiler $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})}.$7 and a response adapter $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})}.$8 (Li et al., 30 Apr 2026). The core EywaAgent abstraction is

$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})}.$9

where $s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$0 is a control policy (Li et al., 30 Apr 2026). If the policy skips invocation, the agent reduces to a standard LLM step,

$s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$1

If invocation occurs, the coupled pipeline is

$s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$2

followed by state update $s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$3 (Li et al., 30 Apr 2026). 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

$s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$4

where each $s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$5 is either an LLM agent or an EywaAgent, and $s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$6 is the communication topology (Li et al., 30 Apr 2026). EywaOrchestra is a planning-based orchestration framework

$s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$7

where $s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$8 is a configuration space induced by candidate LLMs, candidate FMs, and a topology pool, and $s_v(q, f) = \cos(\mathbf{e}_q, \mathbf{e}_f),$9 is a conductor that selects a configuration per task (Li et al., 30 Apr 2026). The paper defines the fixed-configuration risk

$$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$0

and oracle adaptive risk

$$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$1

with the stated theorem that $$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$2, and strictly less when no single configuration is optimal for all tasks (Li et al., 30 Apr 2026).

The practical implementation uses the Model Context Protocol (MCP), LangChain agents, FastMCP servers, and one MCP backend per foundation model (Li et al., 30 Apr 2026). 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 (Li et al., 30 Apr 2026). 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 (Li et al., 30 Apr 2026). EywaMAS achieves 0.6761 overall utility, outperforming Refine MAS (0.6294), Debate MAS (0.6460), MoA (0.6273), and X-MAS (0.6188) (Li et al., 30 Apr 2026). EywaOrchestra reaches 0.6746 utility with 48.16 overall time, compared with 72.11 for EywaMAS (Li et al., 30 Apr 2026). 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" (Kakarla et al., 2023) 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 (Kakarla et al., 2023).

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(...) (Kakarla et al., 2023). 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(...) (Kakarla et al., 2023). It then compiles the model plus harness to LLVM bitcode, invokes Klee, and translates the resulting test cases back into Python values (Kakarla et al., 2023). 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 (Kakarla et al., 2023).

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 $$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$3 and number of implementations $$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$4 (Kakarla et al., 2023). In experiments the authors use $$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$5 and $$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$6, compiling each generated model, symbolically executing successful ones, and taking the union of resulting tests (Kakarla et al., 2023). The generated models are interpreted as partial executable specifications: imperfect, but sufficiently semantically rich to expose corner cases (Kakarla et al., 2023).

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 (Kakarla et al., 2023). 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 (Kakarla et al., 2023). Across models Eywa generated roughly 100K tests (Kakarla et al., 2023).

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 (Kakarla et al., 2023). The paper emphasizes that this exceeded SCALE, which found 22 unique bugs, while Eywa missed 7 unique bugs found by SCALE (Kakarla et al., 2023). 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 (Kakarla et al., 2023).

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 (Kakarla et al., 2023). 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" (Jeong et al., 10 Apr 2026), 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 (Jeong et al., 10 Apr 2026).

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 (Jeong et al., 10 Apr 2026). 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 (Jeong et al., 10 Apr 2026).

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

$$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$7

virtual networks, contrasted with about 4,094 VLAN IDs (Jeong et al., 10 Apr 2026). 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 (Jeong et al., 10 Apr 2026). 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 (Jeong et al., 10 Apr 2026).

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 (Jeong et al., 10 Apr 2026). The agent performs three main functions: VR monitoring, ARP caching, and ARP filtering and proxy ARP (Jeong et al., 10 Apr 2026). 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 (Jeong et al., 10 Apr 2026). Inbound discovery requests to an overloaded local VR can be filtered so that orphan VMs avoid selecting it (Jeong et al., 10 Apr 2026).

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 (Jeong et al., 10 Apr 2026). 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 (Jeong et al., 10 Apr 2026). 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-$$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$8 throughput tracking the physical capacities of active communicating pairs (Jeong et al., 10 Apr 2026). 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 (Jeong et al., 10 Apr 2026).

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 (Jeong et al., 10 Apr 2026). Even so, the design is presented as a deployable alternative that avoids centralized bottlenecks without requiring host kernel, physical switch, or software switch modifications (Jeong et al., 10 Apr 2026).

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 $$\text{RRF}(f) = \sum_{c \in \mathcal{C}} \frac{w_c}{k + \text{rank}_c(f)},$$9 and by the separation of retrieval outputs from answer policy (Joshi, 29 May 2026). In the scientific-agent Eywa, the key mediation layer is the FM-LLM interface $k = 20$0 and the control policy $k = 20$1, which let non-linguistic foundation models participate in agentic reasoning without being forced into purely textual I/O (Li et al., 30 Apr 2026). 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 (Kakarla et al., 2023). 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 (Jeong et al., 10 Apr 2026).

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” (Joshi, 29 May 2026). The scientific-agent framework formalizes invocation through structured FM schemas and MCP-backed service interfaces (Li et al., 30 Apr 2026). The protocol-testing system uses typed function models, generated C, symbolic harnesses, and explicit path conditions (Kakarla et al., 2023). The cloud-networking architecture relies on explicit ARP packet-control rules rather than centralized SDN-style control (Jeong et al., 10 Apr 2026). 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 (Joshi, 29 May 2026). The scientific-agent Eywa similarly treats the LLM, domain-specific FM, and planner as separable components that can be recombined into different agentic topologies (Li et al., 30 Apr 2026). The protocol-testing Eywa separates behavioral-oracle construction from downstream implementation testing (Kakarla et al., 2023). 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 (Joshi, 29 May 2026, Li et al., 30 Apr 2026, Kakarla et al., 2023, Jeong et al., 10 Apr 2026).

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 (Joshi, 29 May 2026). 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 (Li et al., 30 Apr 2026). 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 (Kakarla et al., 2023). 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 (Jeong et al., 10 Apr 2026).

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.