Agentic AI & MCP — Goal 3¶
Goal 3 delivers agentic AI orchestration that lets researchers drive MESA through natural-language conversation with an AI assistant. The orchestration layer is built on the Model Context Protocol (MCP) and self-hosted LLM inference on Jetstream-2 GPUs.
Stack¶
| Layer | Technology |
|---|---|
| LLM serving | vLLM on Jetstream-2 GPUs (and commercial API egress as buffer) |
| RAG | LiteLLM router; project-specific retrieval over docs + Lakehouse catalog |
| Agent protocol | Model Context Protocol (MCP) — stdio, SSE, and Streamable-HTTP transports |
| Sandbox | Container-based per-request sandboxes for tool execution |
| Multi-agent | Multi-agent orchestration patterns (specialist agents per domain) |
MCP servers in the MESA ecosystem¶
MESA bundles five MCP servers. Each one wraps an existing CyVerse capability as a set of agent-callable tools:
| Server | Wraps | Repo |
|---|---|---|
mesa-mcp |
iRODS Data Store + AVU + OBO/OLS ontology lookup + DuckLake | cyverse/mesa-mcp |
mesa-ducklake |
AVU-history Lakehouse | cyverse/mesa-ducklake |
irods-mcp-server |
Generic iRODS access | cyverse/irods-mcp-server |
formation-mcp |
CyVerse Formation API — DE job orchestration | cyverse-de/formation-mcp |
terrain-mcp |
CyVerse Terrain API | cyverse/terrain-mcp |
See the MCP servers overview for a comparison matrix.
Agent ergonomics¶
MCP servers are designed to be composable so that one prompt may invoke tools from several servers. For example, a discovery → annotate → launch workflow could call:
sequenceDiagram
actor U as Researcher
participant Cl as MCP client
participant Me as mesa-mcp
participant Mu as mesa-ducklake
participant Fo as formation-mcp
U->>Cl: "Find sandy-desert soil samples from 2024 and launch QIIME2 on them"
Cl->>Me: ds_search_files_by_avu (ENVO:00000446 + date)
Me-->>Cl: 47 matching files
Cl->>Mu: mesa_ducklake_get_avu_history (sample of 5)
Mu-->>Cl: history summary
Cl->>Fo: launch_app (QIIME2, inputs=47 files)
Fo-->>Cl: analysis ID + monitor URL
Cl-->>U: "Launched QIIME2 — track at <URL>"
Sandbox security¶
Tool calls execute inside per-request container sandboxes so that:
- A malformed or adversarial prompt cannot escape the agent runtime to reach the host or sibling user sessions.
- iRODS credentials never leave the MESA service boundary.
- Network egress is constrained to the configured set of MCP transports.
The sandbox model is reviewed during the TrustedCI prototype security review in WBS 6.5 (Phase 2).
Performance targets¶
| Metric | Target |
|---|---|
| MCP / RAG median latency | < 5 s on Jetstream-2 GPUs |
| Simultaneous LLM requests | 8–12 sustained on the leveraged Jetstream-2 GPU allocation |
| Service availability | ≥ 95% business hours |
The prototype performance ceiling is set by the leveraged infrastructure (Jetstream-2). Larger simultaneous-request scale on a dedicated GPU cluster is deferred to the follow-on operations proposal.
Multi-agent orchestration patterns¶
MESA does not commit to a single multi-agent framework. The prototype investigates:
- Specialist agents — one agent per domain (data discovery, analysis, reporting), each backed by a different MCP server.
- Tool-use scaling — using LLMs that can plan multi-step workflows across MCP tools without explicit orchestration code.
- Human-in-the-loop checkpoints — for any operation that writes data or launches paid compute, the agent pauses for confirmation.