Vision and direction

The problem

AI tools tend to sit at two extremes. On one side are chat interfaces: good at conversation, weak when you need something done, such as reading your code, running commands, working through many steps and delivering a result. On the other side are developer frameworks: powerful, but tied to a language and often a provider, and meant to be built with rather than deployed.

Between the two, something is missing: a runtime. A self-contained program that turns a model into a capable agent, with real tools, real permissions and real sessions, which you can call from your code, your terminal or your services. See What is an agent runtime?.

The idea

One runtime. Any model. Any language. Any deployment.

A runtime should behave like a database server: you deploy it, you connect to it, and it takes care of the hard parts. In practice:

• A Go developer embeds it with the SDK.
• A team in another language calls it through gRPC.
• Someone at a terminal uses it as a command-line agent, whatever the provider.
• A product team builds accounts, workspaces and billing on top, without touching the core. That is what SeshatOS and SeshatCloud do.

The runtime itself stays small: no users, no billing, no lock-in.

Principles

Local first. The runtime works on your machine, with your data. Models can be local (Ollama) or remote, per session. A runtime that works offline is easier to trust.

Provider agnostic. Sessions and skills are not tied to one company’s model. A failing provider can be replaced by another. See Tools and providers.

Safe by default. Permissions, sandboxing, compaction, retries and session recovery are part of the baseline, not add-ons. See Security and trust.

Extensible without forking. You add tools, skills and MCP servers, hooks and credential resolvers through interfaces, not by changing the core.

Written in Go on purpose. See Why Go?.

What Seshat is not

• Not a framework. You do not write your agent’s logic inside Seshat. You call it from your code, service or terminal.
• Not a product. It has no concept of users or organisations. Those belong to the layers above.
• Not a Python or TypeScript library. Other languages use it through gRPC.
• Not a chatbot. It is built for multi-step work where the model uses tools to reach a goal.
• Not finished. Some of what is described below is future work.

Three levels

The project grows one level at a time. A level must be solid before the next one starts.

1. Level 3: a teamSeveral persistent agents with roles, an inbox and a shared task board, coordinating over hours. Future work.
2. Level 2: delegationOne agent hands work to sub-agents, in parallel, with limits, and integrates their results. Partly available today.
3. Level 1: one agentA single agent a developer can use every day and trust with their codebase. The current focus.

Level 1 is what you can install and use now: the agent loop with tools, recovery, compaction and streaming, many providers, a permission engine, saved sessions, skills and MCP.

Level 2 starts to exist: an agent can delegate with the agent tool and the spawn_agent family, under depth and concurrency limits. What is still ahead is hardening: per-agent budgets, richer typed delegation and clearer progress from sub-agents. See Agents and delegation.

Level 3 is a direction. The building blocks for named agents with a mailbox exist in the repository, but they are internal and not exposed, so you cannot use them yet.