Not built yet. This page describes what is planned. Today, agents reach an environment’s tools through the agent contract — a function Silo calls with
callTool.What it would unlock
Drive a simulated world from an existing MCP client. Point a client that already speaks MCP at a Silo environment and its 42 CRM tools become available as ordinary tools — no adapter, no glue. Try an environment by hand. Ask for a stalled deal, reassign it, see what the tools say, before writing any agent code. Today the fastest way to explore a tool surface is a scripted agent and a trace. Evaluate agents you did not write. Anything that speaks MCP could be pointed at an environment, which widens what Silo can measure beyond agents you can wrap in a function.The open question
Silo’s value comes from a rollout being a bounded, graded unit: one fresh world, one task, one verdict, one set of artifacts. An MCP session is the opposite shape — a long-lived connection with no natural start or end. So the design question is not how to expose the tools. It is what a rollout means over a session:- When does the world get created, and when is it graded?
- Does one connection map to one task, or can a client switch tasks?
- What does a trace look like when the client, not Silo, decides when work is finished?
state-diff.json and result.json still mean anything. Getting it wrong would make MCP a way to poke at an environment without ever producing an evaluation — interesting, but not what Silo is for.
What works today
Write an agent function. It is a small contract, and a model loop in any framework fits it in a few lines:Bring Your Own Agent
The full contract, tool errors as values, and where a model loop plugs in.
trace.jsonl gives you the same information today — see Debug a Failed Run.
Silo