Seshat is not just a project to consume. It is an open runtime, a CLI app, and a growing desktop platform that we want to build with the community. This page explains the vision, how the ecosystem is split, and where contributors can help whether they care about the Go engine, the CLI app, the future Python SDK, the desktop experience, or specialized domain workflows.
The long-term vision for Seshat is not a slightly better assistant and not another orchestration framework. It is an environment where AI agents can pursue missions over time, where multiple agent teams can coordinate, where work is observable and governable, and where the same core can support everything from coding and research to automation, education, media production, design, 3D, knowledge work, voice, and external communication. The runtime executes. The platform organizes. The community helps define what this becomes in practice.
The desktop is not meant to be a thin shell around chat. The ambition is to make it the main entry point into an OS for agentic services: a unified environment where specialized surfaces for development, enterprise operations, automation, education, research, design, communication, finance, knowledge work, media, and even 3D generation can live on top of the same runtime foundation.
The CLI app is where developers and vibecoders can use Seshat today, test features early, and push the runtime in real projects instead of shallow demos.
The point is not another wrapper around a model. The point is a real execution environment with tools, permissions, sessions, MCP, skills, memory, mission continuity, and eventually structured multi-agent coordination.
The long-term platform is meant to host real work: enterprise automation, research, data science, knowledge systems, education, media generation, design, communication, and any domain experts can help shape.
One of the strongest ideas behind Seshat is unification. Today these activities are fragmented across many products, contexts, and memory silos. The platform aims to let them converge in one coherent environment instead of scattering work across disconnected tools.
Coding, code review, testing, planning, architecture exploration, documentation, and real repo workflows are already core ground for the runtime and CLI app.
Retrieval, synthesis, long-form analysis, knowledge bases, document workflows, study assistants, and deep research surfaces belong naturally inside the same platform core.
Organizations need governance, audit, roles, quotas, workspaces, scheduling, SLAs, and integrations. That is why the platform layer matters as much as the raw engine.
Text, image, audio, video, branding, visual design, 3D generation, and creative pipelines can become specialized surfaces powered by the same underlying agent system.
Email, social platforms, community workflows, publishing, outreach, support, and voice interaction should eventually connect to the same operational environment instead of living in isolated tools.
The platform should not be defined only by a central roadmap. Teachers, analysts, accountants, lawyers, operators, researchers, and domain experts can help define what useful agent systems really look like in their field.
The work is intentionally split so contributors can go exactly where they are most useful. One repository advances the runtime and CLI app. The other turns that runtime into the broader desktop and API platform.
This is the open-source Go runtime and CLI app foundation: agent loop, tool execution, permissions, sessions, MCP, skills, memory, RAG, providers, SDK primitives, and the core execution model.
This is the product and platform layer built on top of the runtime: desktop app, multi-user backend, REST API, workspaces, auth, scheduler, governance, knowledge, and product-facing experiences.
We want more than passive feedback. We want contributors who help define what a strong open-source agent runtime, a serious CLI app, and a real platform for agentic services should become over time.
Improve the engine, terminal workflows, performance, providers, local model support, MCP, skills, and agent execution quality.
Help turn the platform into the main entry point for agentic work with stronger UX, workspace design, domain surfaces, and better product coherence.
We want Seshat to reach beyond Go. Python SDK, JS or TS SDK, examples, bindings, API ergonomics, and client libraries are high-value ecosystem work.
A strong open-source project needs better guides, examples, tutorials, architecture explanations, and onboarding paths for technical and non-technical users.
If you understand a specific field well enough to know what an agent system should actually do there, your contribution is strategic, not peripheral.
Naming, information architecture, docs UX, product positioning, onboarding, interface quality, and community communication all shape adoption.
Today the SDK story starts in Go because the runtime itself is written in Go. That is not the end state. We want a Python SDK, a JS or TS SDK, better examples, cleaner client ergonomics, and a broader set of entry points so Seshat can attract contributors from multiple ecosystems instead of staying locked inside one language community.