Tools & Providers
In Seshat, tools and providers are different runtime layers. Tools define what the agent is allowed to do. Providers define which model-backed transport answers the turn. The runtime keeps those concerns separate, then joins them inside one governed mono-run execution loop.
The Core Design Problem
A serious agent runtime cannot treat every external dependency as one vague bag of capabilities. A tool call is executable surface area with permissions, side effects, and local state. A provider is a model transport and normalization layer. When those two concerns are fused too early, routing, safety, multimodal backends, and prompt exposure all become harder to govern.
Built-in tools, aliases, MCP entries, deferred tools, and runtime metadata live in one canonical inventory.
Anthropic, OpenAI, Ollama, Bedrock, Gemini, OpenRouter, Codex, and others are normalized into one message contract.
Read-only flags, destructive checks, permission mode, tool-search deferral, and surface profiles filter the visible tool set.
Image generation, speech-to-text, and text-to-speech can use dedicated providers instead of sharing the reasoning model path.
Seshat first builds a governed tool surface, then routes the turn through the chosen provider adapter, then executes tool calls back through the runtime owner. That late join is why tools, permissions, MCP, memory, and providers can evolve independently without turning the runtime into framework glue.
The runtime can hold back lower-priority or MCP-derived tools and expose them only through tool discovery when needed.
Vendor routing, retries, transport quirks, and model normalization stay on the provider side rather than leaking into the tool layer.
Why The Separation Exists
Filesystem access, shell execution, browser control, planning, memory, RAG, notebooks, agent delegation, and MCP are runtime-owned actions with permissions and side effects.
Anthropic, OpenAI, Ollama, Bedrock, Gemini, OpenRouter, Codex, and the other provider ids are network and normalization layers that produce model responses.
Image generation, speech-to-text, and text-to-speech do not have to share the same provider as the main reasoning model.
The model does not automatically inherit every tool. The visible surface is filtered by runtime rules, permission mode, destructive checks, categories, and session context.
How The Runtime Joins Them
The mono-run loop assembles prompt context, builds the model-visible tool surface, chooses the provider adapter, executes tool calls through the orchestrator, persists state, and applies permission policy. That late join is what lets Seshat change vendors, add new tools, or harden permissions without redesigning the whole runtime contract.
Built-ins, MCP entries, and metadata exist before a turn starts.
Permission rules, destructive checks, read-only flags, and profiles decide exposure.
The selected provider normalizes the request and returns the model response stream.
Tool calls come back through the orchestrator, not around it.
Image, audio, and other specialized paths do not have to share the core reasoning vendor.
Messages, permission context, tool results, and memory stay under one runtime owner.
- The registry defines built-in tools, aliases, MCP extensions, and metadata.
- The surface builder filters what the model can actually see for the active session.
- The provider client normalizes the chosen provider into the runtime message contract.
- The loop routes reasoning and tool execution back through one runtime owner.
- Capability-specific backends can remain separate from the reasoning model path.
What This Unlocks Architecturally
The model sees the filtered tool surface, not the entire raw inventory.
Provider fallback and vendor quirks stay in the transport layer rather than leaking into tool execution.
Image and audio paths can evolve independently of the main reasoning model.
MCP and deferred tools can extend the runtime without turning every integration into framework glue.
What Belongs In Concepts And What Does Not
Concepts should explain the architecture, not duplicate the integration reference. Exact provider setup tables, environment variables, credential injection patterns, capability wiring, and Codex auth details belong in SDK and API.
If you want the implementation reference, continue with Go SDK and then Providers & Auth. If you want the SDK-side tool inventory and per-session shaping APIs, continue with Tools & Surface.
Related Pages
Continue with Agent Teams and Mailboxes for persistent multi-agent coordination, or Skills and MCP for extensibility.