Papers
Topics
Authors
Recent
Search
2000 character limit reached

Heterogeneous Scientific Foundation Model Collaboration

Published 30 Apr 2026 in cs.AI, cs.CL, and cs.LG | (2604.27351v1)

Abstract: Agentic LLM systems have demonstrated strong capabilities. However, their reliance on language as the universal interface fundamentally limits their applicability to many real-world problems, especially in scientific domains where domain-specific foundation models have been developed to address specialized tasks beyond natural language. In this work, we introduce Eywa, a heterogeneous agentic framework designed to extend language-centric systems to a broader class of scientific foundation models. The key idea of Eywa is to augment domain-specific foundation models with a language-model-based reasoning interface, enabling LLMs to guide inference over non-linguistic data modalities. This design allows predictive foundation models, which are typically optimized for specialized data and tasks, to participate in higher-level reasoning and decision-making processes within agentic systems. Eywa can serve as a drop-in replacement for a single-agent pipeline (EywaAgent) or be integrated into existing multi-agent systems by replacing traditional agents with specialized agents (EywaMAS). We further investigate a planning-based orchestration framework in which a planner dynamically coordinates traditional agents and Eywa agents to solve complex tasks across heterogeneous data modalities (EywaOrchestra). We evaluate Eywa across a diverse set of scientific domains spanning physical, life, and social sciences. Experimental results demonstrate that Eywa improves performance on tasks involving structured and domain-specific data, while reducing reliance on language-based reasoning through effective collaboration with specialized foundation models.

Summary

  • The paper introduces the Eywa framework that enables direct modality-native collaboration between language agents and domain-specific models, reducing information loss.
  • The paper demonstrates that adaptive orchestration and plug-and-play multi-agent systems yield lower population risk and higher utility across diverse scientific tasks.
  • The experimental evaluation confirms efficiency improvements with reduced token usage and latency across physical, life, and social science domains.

Heterogeneous Scientific Foundation Model Collaboration: An Authoritative Evaluation

Problem Motivation and Conceptual Framework

Agentic AI systems based on LLMs exhibit substantial generic reasoning and decision-making capabilities, but their exclusive reliance on natural language presents a fundamental bottleneck in scientific domains. Real-world scientific tasks frequently require reasoning over domain-specific inputs like time series, tabular datasets, molecular graphs, or structured data, which cannot be faithfully or efficiently encoded as text without information loss. This intrinsic limitation, rigorously motivated using information-theoretic arguments in the paper, implies that pure language-based interfaces are suboptimal for tasks demanding specialized computation. Meanwhile, scientific foundation models—pretrained over domain-specific data and optimized for modalities such as forecasting, classification, or sequence analysis—lack native linguistic interfaces but demonstrate strong predictive power. The core premise of the paper is to bridge this gap and permit direct, modality-native collaboration between heterogeneous foundation models and language-based agents.

Eywa introduces a modular framework encapsulating this paradigm shift. The FM-LLM Tsaheylu interface acts as a bidirectional communication and control layer, allowing LLMs to parse instructions, configure calls, and interpret outputs from foundation models. This framework is instantiated in three progressively complex architectures: EywaAgent (coupled FM-LLM unit for adaptive reasoning), EywaMAS (heterogeneous multi-agent system), and EywaOrchestra (dynamic orchestration via a central planner).

Theoretical Guarantees

A rigorous theoretical backbone supports the Eywa framework. The information-theoretic analysis demonstrates that any serialization of domain-specific inputs to text necessarily discards information, creating a Bayes risk gap that LLM-only agents cannot overcome. EywaAgent, by directly invoking the native modality computations of foundation models, strictly expands the function class and achieves strictly lower population risk on scientific tasks under reasonable assumptions (see Theorem 15). The containment property (Proposition 14) confirms that Eywa subsumes language-only agents as a strict special case, and the extension to multi-agent settings (Theorem 17) guarantees strict improvement of EywaMAS over pure LLM-based systems, contingent on communication topology. EywaOrchestra additionally leverages adaptivity: dynamic routing and configuration selection yield population risk strictly lower than any fixed system by exploiting task heterogeneity (Theorem 18).

System Design and Implementation

The FM-LLM Tsaheylu interface is operationalized via Model Context Protocol (MCP) and implemented as a structured tool-call pattern in modern agentic platforms (e.g., LangChain agents and FastMCP servers). EywaAgent dynamically switches between generalized language reasoning and domain-specific acting based on a control policy C:S{invoke,skip}C: S \to \{\text{invoke}, \text{skip}\}, where skip reduces to pure language reasoning and invoke delegates computation to the appropriate foundation model.

EywaMAS accommodates plug-and-play composition with minimal architectural changes, permitting seamless replacement of language-only agents with EywaAgents in existing multi-agent workflows. EywaOrchestra introduces dynamic orchestration: a conductor (typically instantiated as an LLM) analyzes task modality and complexity, selects appropriate agent configurations, backbone models, foundation models, and communication topologies, and then executes the resultant system. The orchestration logic is highly modular, with configuration expressed as structured JSON objects and hard constraints to ensure robust, auditable execution.

Experimental Evaluation

EywaBench, a comprehensive multi-domain evaluation platform, is constructed to systematically assess the performance of heterogeneous agentic systems. EywaBench covers physical (material, energy, space), life (biology, clinic, drug), and social (economy, business, infrastructure) science domains, with balanced representation of modalities (natural language, time series, tabular). Evaluation metrics are modality-agnostic and normalized to facilitate rigorous comparison.

Numerical results are conclusive:

  • Utility: EywaAgent achieves a mean utility gain of ~6.6%6.6\% over backbone-matched single-LLM agents, EywaMAS outperforms all homogeneous multi-agent baselines (Refine, Debate, MoA, X-MAS) by up to 7.5%7.5\% with significantly less token consumption.
  • Efficiency: Token usage is reduced by ~30%, and inference latency drops by ~10% due to streamlined computation delegation. These results are robust across all domains and agentic settings.
  • Heterogeneity criticality: Heterogeneous LLM-only MAS methods (MoA, X-MAS) do not consistently surpass homogeneous baselines, confirming that cross-modality heterogeneity (not merely model heterogeneity) is central for scientific tasks.
  • Adaptive orchestration: EywaOrchestra achieves near-optimal utility at reduced cost and with zero expert configuration, demonstrating strong automation and dynamic adaptability. In several domains, EywaOrchestra surpasses expert-designed EywaMAS.

Eywa exhibits strong resilience to hyperparameter variations (LLM sampling temperature, FM temperature, prompt design) and backbone scaling, with diminishing returns beyond a certain LLM capability threshold—a finding that substantiates the value of domain-specific modeling over brute-force scaling of LLMs.

Qualitative Case Studies

Case studies empirically validate the theoretical claims:

  • LLM-only agents: Format adherence does not imply genuine domain computation; predictions on structured signals default to naive heuristics (e.g., persistence).
  • EywaAgent: Enables seamless integration—LLM parses task and configures FD call, FD delivers predictions, LLM verifies and formats output.
  • EywaOrchestra: Diagnoses task modality, selects minimal required agent system, avoids unnecessary debate or redundancy, maximizes efficiency.

The division of labor and adaptive orchestration are clearly executed, achieving optimal outcomes with minimal token usage and latency.

Implications and Future Directions

Eywa fundamentally advances the integration of domain-specialized foundation models with linguistic reasoning agents, enabling rigorous, scalable, and efficient scientific computation. The theoretical guarantees and empirical results highlight modality-native collaboration as necessary for agentic scientific workflows, especially as scientific tasks and expert models scale in diversity and complexity.

Practically, Eywa offers a blueprint for modular, extensible agentic ecosystems spanning multiple scientific domains. The framework’s plug-and-play architecture, standardization of computation interfaces, and orchestration policies form the foundation for scalable heterogeneous scientific model platforms. Future directions include expanding the pool of domain-specific models, developing advanced orchestration policies via supervised or reinforcement learning, tighter coupling (shared representation, differentiable interfaces), and expanding EywaBench for more comprehensive coverage and capability benchmarking.

Limitations

Eywa’s effectiveness hinges on the quality of both LLMs and scientific foundation models; poor or misaligned models limit achievable gains. While EywaBench is diverse, exhaustive domain coverage is unattainable; systematic expansion and domain-specific evaluation remain open problems. Computational cost, though mitigated via orchestration, may rise with ecosystem size and heterogeneity, necessitating more efficient agent selection and invocation strategies.

Conclusion

Eywa offers a rigorously justified, empirically validated framework for heterogeneous agentic collaboration in scientific domains, substantially improving utility and efficiency, and showcasing modality-native computation as a necessary principle in AI for science. By enabling adaptive orchestration and flexible integration of domain-specific foundation models, Eywa transcends the limitations of language-centric systems and paves the way for scalable, ecosystem-level scientific AI (2604.27351).

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

A simple explanation of “Heterogeneous Scientific Foundation Model Collaboration (Eywa)”

1. What is this paper about?

This paper introduces Eywa, a system that helps different kinds of AI models work together to solve scientific problems. Today’s big LLMs are great at reading, planning, and explaining in words. But many science tasks aren’t just about words—they use special data like time series (numbers over time), tables, formulas, and more. Eywa connects LLMs with “specialist” models that are built for these non-language data types, so they can team up: the LLM does the planning and reasoning, and the specialist model does the precise calculations.

The authors use an Avatar-inspired idea: like the Na’vi linking with a banshee through a neural bond (“Tsaheylu”), Eywa creates a “bond” between a LLM (the planner) and a domain-specific model (the specialist).

2. What questions are they asking?

In simple terms, the paper asks:

  • Can we get better scientific results if LLMs collaborate with specialist models, instead of trying to do everything with language alone?
  • How do we let these very different models communicate smoothly, without forcing everything into words?
  • What’s the best way to organize many such models for different kinds of tasks?

3. How did they do it? (Approach)

Eywa builds a bridge so models can “talk” effectively, even if they use different kinds of data.

Key ideas you should know:

  • Modality: the type of data a model works with (e.g., text, tables, time series).
  • Domain-specific foundation model (FM): a model trained to be an “expert” for a certain data type or scientific area (like time-series forecasting or table-based prediction).
  • Tokens: chunks of text that LLMs read and write. Fewer tokens usually means lower cost and faster speed.

Here’s what Eywa provides:

  • EywaAgent: a single “paired” agent that combines an LLM (for reasoning) with a specialist FM (for acting on non-text data). The LLM decides when to call the specialist, sends it a well-structured request, and then uses the specialist’s result to continue reasoning. Think of the LLM as a coach and the FM as the athlete.
  • EywaMAS: a multi-agent setup where several agents (some pure LLMs, some EywaAgents) work together. This lets multiple specialists and planners collaborate on a bigger problem.
  • EywaOrchestra: a “conductor” that chooses the best team layout for each task. Depending on the job, it decides which agents to use, which models to connect, and how they should communicate—like choosing the best formation for a sports team before a match.

How the “bond” works (the Tsaheylu interface):

  • The LLM turns its plan into a clean, structured request the specialist understands (like filling out a well-designed form).
  • The specialist runs the calculation on its native data (like forecasting future values from a time series).
  • The result is converted back into a summary the LLM can read and reason about in natural language. This is implemented with standard “tool calling” infrastructure (so it’s plug-and-play with existing LLM tools).

They also created EywaBench, a benchmark that tests these systems across many science areas (physical, life, and social sciences), and across different data types (text, time series, tables).

4. What did they find, and why is it important?

Across many scientific tasks, Eywa:

  • Improves answer quality: Eywa’s agents performed better than language-only systems. In single-agent tests, utility (overall score) improved by roughly 6–7%.
  • Uses fewer tokens: By delegating heavy data work to specialist models, Eywa cut token usage by about 30%. This usually means lower cost.
  • Runs faster: Execution time dropped by around 10% in single-agent setups.
  • Works well in teams: In multi-agent settings, Eywa-based teams outperformed teams made only of LLMs.
  • Adapts smartly: EywaOrchestra (with the “conductor”) automatically picked good team configurations for each task, reaching strong performance with less cost and manual setup.
  • Robust across settings: It kept working well under different prompts, temperatures, and LLM backbones, showing that the gains aren’t fragile.

Why this matters:

  • Scientific data often isn’t text. Forcing all data through language can be clumsy and less accurate.
  • Letting an LLM plan while a specialist model calculates gives you the best of both worlds—clear reasoning plus precise, domain-native computation.
  • Lower tokens and faster runs mean more affordable and scalable systems.

5. What’s the bigger impact?

Eywa shows a practical path for AI to handle real scientific work:

  • Better science tools: Researchers and engineers can combine general reasoning (LLMs) with high-accuracy specialists (for time series, tables, climate, biology, materials, and more).
  • Flexible teamwork: For each problem, the system can pick the right set of experts and the right way for them to work together.
  • Lower cost, higher trust: Using specialists makes results more reliable on structured data, while saving tokens and time.

In short, Eywa helps AI move beyond “only text” and into “the right tool for the right job,” which could speed up insights in fields like energy, medicine, economics, and space science.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a consolidated list of unresolved issues that are either missing, uncertain, or left unexplored in the paper, written to be concrete and actionable for future work.

  • Limited foundation model (FM) coverage: evaluations use only two FMs (Chronos for time series, TabPFN for tabular); integration and testing with other scientific FMs (e.g., weather/climate models like GraphCast, materials potentials like MACE/CHGNet, protein models like ESM/AlphaFold, geospatial rasters, graph-based models) are absent.
  • Modality scope: EywaBench focuses on natural language, time series, and tabular data; no experiments on vision, audio, graphs, PDE/simulator outputs, or multi-modal fusion tasks that require combining heterogeneous representations.
  • Single-FM-per-agent design: the framework does not demonstrate composing multiple FMs within the same task (e.g., combining climate forecasts with economic indicators); mechanisms for cross-FM aggregation and conflict resolution are not provided.
  • Orchestration policy learning: the conductor in EywaOrchestra is an LLM that selects from a finite, expert-curated topology pool; there is no learning-based, cost-aware policy that optimizes over a larger or continuous design space (e.g., RL/meta-learning, neural architecture search for agent topologies).
  • Lack of theoretical guarantees for orchestration: no bounds on regret or performance relative to an oracle for dynamic configuration selection; no analysis of conductor misselection impact or convergence properties.
  • Invocation control policy C: the invoke/skip decision is induced by the LLM without explicit learning or cost–utility optimization; no methods to learn C that jointly minimizes utility loss and end-to-end compute/latency cost.
  • Query compiler and response adapter engineering: (+, γ) are hand-crafted and not learned; there is no method to induce schemas, units, and format conversions automatically, nor to validate semantic correctness (e.g., unit consistency checks).
  • Error handling and robustness: the system assumes structured FM outputs and allows limited retries; there is no systematic handling of malformed FM outputs, timeouts, partial data, or noisy/missing inputs, nor robust fallback strategies.
  • Uncertainty quantification: FM predictive uncertainty is not captured or propagated into LLM planning; no calibration, confidence-aware decision-making, or risk-sensitive orchestration is implemented.
  • Assumption 1 (Domain Advantage) untested: the assumption that FMs strictly outperform language-only models on domain inputs is not empirically validated across tasks; conditions where improved serialization or code-based tools close the gap are not explored.
  • Theorem robustness: theoretical results hinge on Assumption 1 and do not model adapter/compiler noise or error propagation; no analysis of sensitivity to imperfect interfaces or distribution shift in xₖ.
  • Baseline fairness: LLM-only baselines rely on textualization of structured data; stronger baselines (LLM+code execution over dataframes, domain toolkits like statsmodels/Prophet, specialized prompt schemas) are not compared, potentially conflating interface with capability.
  • Compute cost accounting: results report token usage and wall-clock time but do not quantify FM-side compute (FLOPs, GPU utilization, energy, dollar cost), making cost–benefit comparisons incomplete.
  • Scalability and throughput: experiments run on a single CPU machine with local MCP servers; no evaluation of distributed deployments, network latency, queuing effects, or throughput under concurrent requests and larger agent/FMs counts.
  • Communication overhead and topology scaling: there is no study of communication costs, deadlocks, or synchronization strategies (synchronous vs asynchronous) as the number of agents grows or topologies become denser.
  • State and memory management: the growth of agent state S and context is not characterized; mechanisms for summarization, memory pruning, and long-horizon task execution are unspecified.
  • Security and trust boundaries: risks from untrusted MCP endpoints, prompt-injection into tool schemas, model hijacking, or data exfiltration are not addressed; no sandboxing, access control, or output validation policies are described.
  • Privacy and compliance: handling of sensitive scientific/clinical data (e.g., HIPAA/GDPR), data minimization, and auditability are not considered in the MCP-based design or experiments.
  • Interpretability and attribution: there is no method for tracing how FM outputs influence LLM reasoning, attributing errors to LLM vs FM vs adapters, or generating faithful explanations suitable for scientific auditing.
  • Data provenance and leakage: EywaBench construction may overlap with FM pretraining data (e.g., TabPFN, Chronos), risking leakage; provenance audits and leakage tests are not reported.
  • Benchmark scope and representativeness: EywaBench emphasizes prediction; tasks involving optimization, control, simulation loops, experiment planning, or closed-loop lab settings are absent.
  • Statistical rigor: variance, confidence intervals, and statistical significance tests over multiple runs are not reported; robustness claims (beyond limited ablations) lack formal statistical support.
  • Cross-lingual and domain transfer: the system is evaluated with English prompts; generalization to non-English instructions, domain shifts, and low-resource languages is unassessed.
  • Interface standardization: MCP schemas for diverse FMs, versioning, unit conventions, and ontology alignment across domains are not formalized; no guidelines for adding new FMs with complex I/O.
  • Continuous integration and versioning: strategies to update FMs/LLMs without breaking compilers/adapters, manage model version drift, or ensure reproducibility across updates are not provided.
  • Real-world deployment: no user studies or field trials assess human-in-the-loop workflows, trust calibration, error recovery, and the practical utility of Eywa in operational scientific pipelines.
  • Ethical and societal impacts: for social science tasks, there is no analysis of bias, fairness, or disparate impact when delegating decisions to FM-guided agents; mitigation strategies are not discussed.
  • Alternative orchestration approaches: comparisons with program-synthesis-based planners, symbolic planners, or hybrid classical schedulers are missing, leaving open which orchestration paradigm is most effective.
  • Multi-objective optimization: orchestration and agent policies do not explicitly trade off utility, latency, tokens, FM compute cost, and energy; no Pareto-front analysis including FM costs is performed.
  • Data engineering and ETL: the framework does not include automated data validation, schema matching, or cleaning for structured inputs—critical for real-world scientific data integration.
  • Failure recovery and resilience: system behavior under FM server crashes, degraded connectivity, or partial pipeline failures is not evaluated; no checkpointing or graceful degradation strategies are presented.
  • Open-source reproducibility: reliance on proprietary LLMs (e.g., GPT-5 family) hinders reproducibility; full replication with open-weight models and openly available FMs is not demonstrated.

Practical Applications

Immediate Applications

The following applications can be deployed with today’s tooling, leveraging Eywa’s FM–LLM “Tsaheylu” interface, EywaAgent (single agent), EywaMAS (multi-agent), and EywaOrchestra (planner), plus readily available foundation models such as Chronos (time series) and TabPFN (tabular). Reported benefits from the paper include higher task utility with ~30% lower token usage and ~10% faster runtime versus language-only agents.

  • Energy sector: grid and DER operations co-pilot
    • What it does: Forecast short- to medium-term load, renewable generation, and price signals; detect anomalies; generate operator-facing recommendations combining forecasts with policy/constraint reasoning.
    • How it’s built: EywaAgent with Chronos for forecasting; LLM for constraint-aware reasoning; MCP-based connectors into SCADA/EMS dashboards.
    • Tools/products/workflows: “Forecast + Plan” panel embedded in control-room UIs; API that returns forecast and ranked actions.
    • Assumptions/dependencies: Access to historical and streaming telemetry; robust time-series FM calibration for local conditions; cybersecurity and NERC/CIP compliance; human-in-the-loop for critical actions.
  • Finance and business: demand, risk, and revenue forecasting assistant
    • What it does: Produce SKU-level demand forecasts, churn/propensity scoring, cashflow projections, and dashboard-ready narratives; explain model drivers and uncertainties.
    • How it’s built: EywaAgent with Chronos (time series) and TabPFN (tabular risk/propensity); LLM converts outputs into plans and reports.
    • Tools/products/workflows: Planning co-pilot embedded in BI stacks (e.g., via MCP + LangChain plugins for Snowflake/BigQuery); “explainable forecast” reports.
    • Assumptions/dependencies: Clean tabular/time-series data; data governance and PII protections; clear guardrails to avoid autonomous trading/credit decisions without oversight.
  • Infrastructure and manufacturing: predictive maintenance and anomaly triage
    • What it does: Analyze sensor streams for early fault signatures; triage alerts with recommended checks/spares; produce maintenance work orders.
    • How it’s built: EywaAgent with Chronos; optional EywaMAS where one agent specializes in detection and another in logistics planning.
    • Tools/products/workflows: MCP connector to CMMS/EAM; auto-generated work orders with evidence snippets.
    • Assumptions/dependencies: Sufficient historical failure labels or proxy signals; integration to asset registries; safety review of recommendations.
  • Healthcare operations (non-diagnostic): capacity and throughput planning
    • What it does: Forecast ED arrivals, bed occupancy, OR utilization; suggest staffing templates and patient-flow interventions; summarize rationale.
    • How it’s built: EywaAgent with Chronos (arrivals/occupancy) + TabPFN (tabular operational KPIs); LLM for policy/shift rules.
    • Tools/products/workflows: “Ops foresight” module in hospital analytics; schedule drafts and what-if analyses.
    • Assumptions/dependencies: HIPAA/GDPR-compliant data pipelines; strict non-diagnostic use; institutional oversight.
  • Public sector/economy: macro nowcasting and policy briefing
    • What it does: Forecast key indicators (inflation, employment claims, energy prices); synthesize briefings that connect forecasts to policy options.
    • How it’s built: EywaAgent with Chronos over public time series; LLM for policy-aware synthesis; EywaOrchestra to choose single vs multi-agent setups per task.
    • Tools/products/workflows: “Nowcast + Brief” service for analysts; reproducible memo generation with provenance.
    • Assumptions/dependencies: Data timeliness and revisions handling; transparency/audit trails for public accountability.
  • Cross-domain research assistant for structured data
    • What it does: Run tabular classification/regression (e.g., small-sample studies), time-series analyses, and produce method-aware interpretations with citations.
    • How it’s built: EywaAgent with TabPFN/Chronos; prompt templates (ReAct/CoT) for robust tool invocation.
    • Tools/products/workflows: Lab notebook add-on; “method card” attached to each result (dataset, FM version, settings).
    • Assumptions/dependencies: Faculty/IRB data policies; reproducibility logs; awareness of TabPFN’s scope and failure modes.
  • Developer tooling: LLM–FM integration SDK and service endpoints
    • What it does: Provide plug-and-play adapters (query compilers, response adapters) and MCP servers to wrap domain FMs as agent tools.
    • How it’s built: Eywa’s Tsaheylu components via FastMCP + LangChain; templates for time series/tabular models; CI tests for schema stability.
    • Tools/products/workflows: “EywaAdapter” SDK, FM registry with input/output schemas, conductor service for dynamic orchestration.
    • Assumptions/dependencies: FM licensing/redistribution terms; schema/version management; observability and error recovery.
  • Cost-optimized analytics services
    • What it does: Reduce token usage and latency for structured-data analytics by delegating computation to FMs and limiting free-text reasoning.
    • How it’s built: EywaOrchestra selects minimal-topology configurations for each query; caching and memoization of FM outputs.
    • Tools/products/workflows: Pay-as-you-go inference with usage dashboards; per-task router policies.
    • Assumptions/dependencies: Reliable performance monitoring; fallback strategies if FM endpoints are unavailable.

Long-Term Applications

These opportunities require further research, broader FM coverage, integration with specialized systems, scaling, or regulatory clearance.

  • Materials and chemistry discovery platforms
    • What it could do: Orchestrate materials FMs (e.g., MACE-MP-0, CHGNet) with LLM-driven hypothesis generation to propose synthesizable compounds and assess stability/performance.
    • How it’s built: EywaMAS with specialized EywaAgents bound to materials FMs, simulators, and literature mining; EywaOrchestra selects pipelines per task.
    • Tools/products/workflows: “Discovery agent” that moves from literature → candidate generation → simulation → lab handoff.
    • Assumptions/dependencies: High-fidelity FMs for the target property space; simulation–experiment gap; lab automation interfaces; IP and safety controls.
  • Climate and weather-informed decision support
    • What it could do: Fuse weather FMs (e.g., GraphCast, Pangu-Weather) with sectoral models to plan grid dispatch, agriculture schedules, and disaster response.
    • How it’s built: EywaOrchestra connecting meteorology FMs, hydrology/crop models, and policy agents; multi-agent coordination across agencies.
    • Tools/products/workflows: “Impact-aware forecast” dashboards; scenario planning with constraints and resource allocation.
    • Assumptions/dependencies: Licensing and compute for large weather FMs; local calibration; inter-agency data sharing and governance.
  • Regulated clinical decision support and drug development
    • What it could do: Combine structure/sequence FMs (e.g., AlphaFold/ESM) and tabular clinical models within an orchestrated agent to inform target selection, trial design, or companion diagnostics.
    • How it’s built: EywaMAS linking bioinformatics FMs, pharmacometrics tools, and protocol-design agents; rigorous validation pipelines.
    • Tools/products/workflows: “Translational pipeline assistant” with audit trails; integration with EHRs and eTMF systems.
    • Assumptions/dependencies: Regulatory approval (FDA/EMA), clinical validation and bias assessments, protected data environments, model traceability.
  • Automated scientific workflows and robotic labs
    • What it could do: End-to-end closed-loop experimentation where agents plan, call simulators/domain FMs, analyze results, and dispatch robotic execution.
    • How it’s built: EywaOrchestra spanning experiment planners, simulators, and lab-automation controllers; safety constraints enforced by specialized agents.
    • Tools/products/workflows: “Experiment conductor” that maintains provenance from hypothesis to results; self-updating lab notebooks.
    • Assumptions/dependencies: Robust lab automation APIs; failure-safe policies; dataset/model provenance; physical resource scheduling.
  • Smart-city digital twins and infrastructure governance
    • What it could do: Integrate traffic, energy, water, and public safety data streams with specialized FMs to simulate interventions and optimize resource allocation.
    • How it’s built: Hierarchical EywaMAS with domain-specific EywaAgents and a city-level conductor; geospatial/temporal model fusion.
    • Tools/products/workflows: Policy sandboxes, citizen-impact reports, and budget-constrained planning tools.
    • Assumptions/dependencies: Cross-department data interoperability; privacy-by-design; governance and public transparency.
  • Sector-agnostic orchestration marketplaces and standards
    • What it could do: Offer a marketplace of FM-backed EywaAgents with standardized schemas, SLAs, and compliance certifications; conductors select best-in-class tools on demand.
    • How it’s built: MCP-based registries, benchmarking via EywaBench-like suites, and contract-level observability.
    • Tools/products/workflows: “Conductor-as-a-Service,” FM certification programs, and pluggable governance policies.
    • Assumptions/dependencies: Broad adoption of interface standards; liability frameworks; sustainable cost models.
  • Privacy-preserving, on-prem and edge deployments
    • What it could do: Run Eywa stacks entirely within enterprise/on-device environments for low latency and data custody, especially in healthcare, finance, and defense.
    • How it’s built: Compact LLM backbones, on-prem FM serving, and hardware acceleration; offline-capable conductors.
    • Tools/products/workflows: Secure MPCP/MCP variants, device attestation, and policy-driven routing.
    • Assumptions/dependencies: Hardware availability; model compression/quantization; security certification.

Cross-cutting assumptions and dependencies

  • Model availability and coverage: Immediate wins rely on time-series/tabular FMs (Chronos, TabPFN); broader domains need mature, well-calibrated FMs.
  • Interface standardization: Stability of MCP schemas and robust query compilers/response adapters; versioning and backward compatibility.
  • Data quality and access: Clean, timely, governed data streams; integration with existing data warehouses and operational systems.
  • Human-in-the-loop and safety: Oversight for high-stakes decisions; clear separation of advisory vs. autonomous actions; auditability and provenance.
  • Compliance and security: Sector-specific regulations (HIPAA, GDPR, SOX, NERC/CIP) and organizational risk controls.
  • Operational resilience and cost: FM/LLM serving reliability, latency budgets, rate limits, and token/compute economics.
  • Generalization limits: Assumption 1 (domain advantage of FMs) must hold for target tasks; performance may degrade if domain inputs are out-of-distribution or poorly represented in the chosen FM.

Glossary

  • agentic AI systems: AI systems composed of autonomous agents that plan, reason, and act to solve tasks. Example: "agentic AI systems that spark paradigm shifts across numerous industries"
  • bidirectional communication interface: A two-way protocol that enables information to flow from an LLM to a specialist model and back. Example: "we formalize the FM-LLM Tsaheylu as a bidirectional communication interface between the LLM and the specialist."
  • Chain-of-Thought: A prompting strategy that asks models to reason step-by-step in natural language. Example: "Chain-of-Thought [59] encourages the model to reason step by step"
  • communication topology: The structured pattern of message passing among agents in a multi-agent system. Example: "G denotes the communication topology."
  • conductor: A component that plans and instantiates the agent configuration and topology for a given task. Example: "the conductor automatically selects the foundation model and topology"
  • debate topology: A multi-agent communication pattern where agents argue or deliberate before producing an answer. Example: "EywaMAS uses debate topology by default."
  • Domain Advantage of Foundation Models: An assumption that domain-specific foundation models outperform language-only models on their native domain inputs. Example: "Assumption 1. (Domain Advantage of Foundation Models)."
  • domain-grounded prediction: Predictions produced by operating directly on native, non-linguistic domain representations. Example: "different mixtures of language-only reasoning, domain-grounded prediction, and inter-agent collaboration patterns."
  • domain-specific foundation model (FM): A pretrained model optimized for specialized data/modalities (e.g., time series, tabular) rather than open-ended language. Example: "Domain-Specific Foundation Model (\"FM\")."
  • EywaAgent: A coupled LLM–foundation model agent with a reasoning interface that decides when to invoke the specialist. Example: "EywaAgent improves utility by ~ 7% across physical, life, and social science tasks"
  • EywaMAS: A heterogeneous multi-agent system that composes LLM agents and EywaAgents in a plug-and-play fashion. Example: "Similarly, EywaMAS improves utility while reducing token and time usage in multi-agent settings."
  • EywaOrchestra: A dynamic orchestration framework that constructs heterogeneous multi-agent systems per task. Example: "EywaOrchestra dynamically orchestrates heterogeneous models"
  • FM-LLM "Tsaheylu": The interface that binds an LLM with a domain-specific foundation model for coordinated reasoning and acting. Example: "The objective of the FM-LLM \"Tsaheylu\" is to establish a robust and stable communication channel"
  • function classes: Sets of functions that a given agent architecture can realize, used to compare representational capacity. Example: "Let FLLM and FEywa denote the function classes induced by language-only agents and EywaAgent, respectively."
  • in-context-learning: Performing new tasks by conditioning on examples in the input without gradient updates. Example: "uses in-context-learning to solve tabular prediction problems in a forward pass."
  • LLM agent: An agent whose policy is implemented by a LLM acting over messages, tools, or actions. Example: "An LLM agent [33, 34] is a policy ALLM : S -> A(M)"
  • Model Context Protocol (MCP): A standard for structured interaction between language agents and external computational resources/services. Example: "Model Context Protocol (MCP) [35]"
  • modality-native collaboration: Coordination across agents and models that each operate in their native data modalities without forcing translation to text. Example: "Eywa enables modality-native collaboration"
  • multi-agent system (MAS): A set of interacting agents connected by a communication graph that collectively solves tasks. Example: "A multi-agent system is defined as a tuple M = (A,G)"
  • oracle adaptive risk: The expected loss achieved by an oracle that can choose the best configuration for each task instance. Example: "and the oracle adaptive risk as"
  • Pareto frontier: The set of trade-off-optimal solutions where improving one objective (e.g., utility) would worsen another (e.g., tokens). Example: "Pareto frontier"
  • planning-based orchestration: A control mechanism that plans which agents, models, and topologies to use for each task. Example: "a planning-based orchestration framework"
  • query compiler: A component that converts the LLM’s task state into a structured invocation for the foundation model. Example: "Dk : S -> Uk is a query compiler that translates the task state into a structured FM invocation."
  • response adapter: A component that converts the foundation model’s outputs into representations consumable by the LLM planner. Example: "Yk : Ok > Zk is a response adapter that converts the specialist output into a planner-consumable representation"
  • serialize: To convert structured, non-linguistic inputs into language tokens for LLM consumption. Example: "where serialize(.) maps domain inputs into language tokens"
  • soft-match score: A fuzzy matching metric for evaluating natural-language predictions against references. Example: "utility is computed with a soft-match score between predictions and references"
  • softmax temperature: A scaling parameter that adjusts the confidence/entropy of a model’s softmax output distribution. Example: "the TabPFN softmax temperature"
  • structured tool call: A schema-defined invocation from an LLM to an external tool or service with typed inputs/outputs. Example: "implemented as a structured tool call"
  • topology pool: A predefined set of candidate communication structures from which the conductor selects. Example: "a topology pool II"
  • utility score: A normalized performance metric in [0,1] used across tasks and modalities for comparability. Example: "Eywabench uses a unified utility score u € [0,1]"
  • wall-clock latency: The real elapsed time for end-to-end execution measured on the system clock. Example: "we record wall-clock latency"
  • zero-shot forecasting: Making predictions on new time series without task-specific training, relying on pretrained knowledge. Example: "can achieve competitive zero-shot forecasting without task-specific training"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 4 tweets with 44 likes about this paper.