Mono-Run Explained
Mono-run means the runtime owns the whole agent turn lifecycle inside one coherent execution model. It is not merely a single binary story. It is an architectural rule: do not split sessions, prompts, tools, permissions, providers, memory, and runtime events into separate competing owners before you absolutely have to.
Overview
The term mono-run can sound like branding if it is not explained precisely. In Seshat it means something concrete: one runtime boundary should own the live work of the agent turn end to end. Different surfaces can call into that runtime, but they should not each reinterpret what a session, tool, permission, provider fallback, or memory boundary means.
What Mono-Run Actually Means
Mono-run does not mean that everything forever lives in one file, one package, or one process topology. It means there is one authoritative execution model. Internal packages can still be modular. External surfaces can still be multiple. What should not multiply is the meaning of the runtime contract.
Session creation, prompt assembly, model calls, tool execution, permission checks, memory injection, compaction, and event emission remain inside one coherent execution owner instead of being scattered across thin wrappers.
Why This Helps In Practice
Resume, compaction, metadata, eventing, and permission semantics stay stable across entry surfaces.
Tools do not escape the same permission engine and hook system that govern the loop.
Fallback routing, streaming, auth handoff, and normalized outputs do not splinter by host application.
Skills, MCP, custom tools, and future multi-agent layers attach to the same core instead of targeting many incompatible wrappers.
What Breaks When You Split Too Early
Many agent systems become hard to trust because the ownership model is blurry. The host owns some memory semantics, the framework owns some orchestration semantics, tools live elsewhere, and provider behavior differs by surface. Mono-run is a way to resist that fragmentation.
| Split Too Early | What Tends To Break | Why Mono-Run Helps |
|---|---|---|
| Prompt system separate from execution loop | Prompts drift away from the real tool surface, session state, and runtime mode decisions. | Prompt assembly happens close to the session that will actually execute, so tools, memory, permissions, and stage overlays stay aligned. |
| Tool daemon separate from runtime semantics | Tool execution may become detached from session-level permissions, eventing, and recovery logic. | The runtime can treat tools as first-class parts of the same execution contract rather than as blind remote side effects. |
| Provider routing as host-side glue | Fallbacks, retries, streaming, and provider normalization differ by surface and become impossible to reason about globally. | One provider layer serves CLI, SDK, gRPC, and platform surfaces consistently. |
| Memory bolted on after the fact | Retrieval and compaction become optional decorations instead of execution-time behavior with clear boundaries. | Memory, retrieval, prompt shaping, and compaction remain part of the same turn lifecycle. |
| Surface-specific event systems | Desktop, CLI, API, and SDK each invent incompatible progress and trace semantics. | A shared runtime event stream can feed every surface from one source of truth. |
How Mono-Run Expands Without Collapsing
Mono-run is not anti-platform. It is what makes platform growth sane. Seshat can still expose a CLI app, a Go SDK, gRPC, a multi-user backend, and a desktop environment because those surfaces all sit above the same runtime contract instead of replacing it.
For the architectural map, continue with Mono-Run Architecture. For the engineering rationale behind the language choice, continue with Why Go for AI Agents?.