Seshat is an open-source Go agent runtime designed for real agentic work, not just prompt-response chat. It is the execution layer behind persistent sessions, tool use, permissions, memory, MCP, skills, provider routing, retrieval, and long-running work. On top of that runtime, seshat-ai is the broader platform direction: desktop app, API layer, workspaces, governance, automation, education, and eventually a much wider environment for organized agentic work.
seshat is the runtime. seshat-ai is the product layer. The runtime executes and governs agent sessions. The platform turns that core into a desktop and API environment for users, teams, workspaces, knowledge, scheduling, automation, and future domain-specific apps.
AI tooling usually falls into two weak extremes. On one side, you have chat interfaces: useful for asking, explaining, and summarizing, but weak when real work needs continuity, tool use, permissions, persistence, and recoverability. On the other side, you have frameworks: powerful for developers, but still something you must assemble, host, govern, and adapt yourself.
Seshat exists in the middle as a runtime. The idea is simple: an agent runtime should behave more like infrastructure than like a demo. You deploy it, call it from a CLI app, an SDK, gRPC, or a product surface, and it handles the hard parts of agent execution consistently.
The open-source Go runtime. This is where the execution model lives: sessions, tools, permissions, compaction, memory, MCP, skills, retrieval, provider fallback, CLI app, gRPC, and the core agent loop.
The platform layer built on top of the runtime. This is where desktop UX, multi-user APIs, auth, workspaces, knowledge systems, scheduling, governance, and future specialized surfaces can evolve.
Keeping those layers separate is important. The runtime should stay clean, embeddable, and useful on its own. The platform should be free to become a richer environment for organizations and domain-specific workflows without polluting the engine with product concerns like billing, user management, or UI-specific logic.
The deeper thesis is not just that agents need tools. It is that AI should stop being trapped in the chatbot format and become a real work system. Real work is not a single answer. It has goals, time, memory, permissions, reports, handoffs, revisions, and durable decisions.
Seshat starts from the belief that the next important jump in value is not merely the individual agent. It is the organization of work between agents and humans in a coherent environment. That is why the project keeps returning to ideas like missions, explicit coordination, memory boundaries, observability, and traceable execution instead of treating orchestration as a black box.
One of the most important ideas in the vision is that the core unit is the complete agent session, not the disposable sub-agent. A full agent has identity, tools, permissions, history, working memory, and operational responsibility. A sub-agent is still useful, but it is only an execution mechanism inside a larger system.
Seshat is not only about assistance. It is meant to become infrastructure for automating digital work wherever that work can be observed, structured, delegated, and governed. That includes software delivery, research, reporting, support, operations, communication, knowledge work, marketing, documentation, finance workflows, and other professional tasks that can be translated into missions, tools, approvals, and outputs.
The important point is not a vague promise to automate everything magically. The stronger claim is that Seshat aims to progressively automate any digital workflow that can be made legible enough for agents to execute safely and usefully.
Another important direction is education. The same runtime can support agents that teach, explain, quiz, adapt to a learner's level, and keep continuity over time. In that model, Seshat is not just a tool for developers or enterprises. It can also become an environment for learning, training, revision, guided exploration, and domain teaching grounded in sources and structured explanations.
Persistent, resumable work instead of disposable terminal output or one-off chat history.
Agents can read, write, browse, search, and execute, but inside explicit permission boundaries.
Context is preserved across long sessions and compacted automatically when the window fills up.
External servers and reusable skill packs extend the agent without forking the runtime.
Multi-provider support, fallback routing, and model switching are part of the core design.
The same engine can power a CLI app, a Go SDK, a gRPC service, and the larger desktop platform.
Seshat is intentionally built as a deployable Go runtime rather than as a Python-first framework. That choice is about infrastructure qualities: single-binary deployment, fast startup, clean embedding, easier self-hosting, and a stable execution core that other languages can call through interfaces instead of re-implementing.
Seshat is not meant to be defined only by a central product roadmap. It is meant to reflect an open-source worldview for agentic systems: transparent, self-hostable, extensible, provider-agnostic, and affordable enough to matter beyond a handful of very large companies.
In practice, that means the long-term shape of the platform should be influenced by the people who actually know their domains well: developers, educators, operators, researchers, designers, marketers, analysts, and other specialists who want to build serious agentic systems without surrendering control of the foundation.
The project is intentionally staged. Today, the priority is making the single-agent runtime strong enough for daily real use. That means one capable agent, one solid session model, one trustworthy execution core.
Mono-run is not the end state. It is the trustworthy base layer that makes delegation, teams, and higher-order orchestration coherent.
One session owner handles prompt assembly, model calls, tools, permissions, and persistence inside one execution boundary.
One orchestrator session can spawn isolated sub-sessions, collect progress, and re-ingest their outputs as tool results.
Specialized agents coordinate via task boards, mailboxes, and explicit responsibilities while still relying on the same trusted inner runtime.
The CLI app is currently the fastest place to prove the runtime under real pressure. It lets developers and vibecoders use the engine directly, test new capabilities early, and contribute feedback before features become polished platform surfaces. In that sense, the CLI is not separate from the vision. It is the proving ground that helps the runtime mature.
Once the runtime itself is clear, the next useful step is understanding why the single-binary design matters and how one executable can own the execution surface without collapsing into chaos.