Build agent systems by composing, not assembling.
sys9 is the agent-native stack: atomic, Unix-like services that each do one job, driven through APIs and CLIs. The shape your system takes depends on what your agents do. Five architecture patterns — pick the one closest to yours, then opt into only what you need.
Ship coding agents that serve real work
Claude Code, Codex, OpenClaw, Cursor, OpenCode — give each run a forkable sandbox, a shared filesystem, a database, and configured session capture.
Explore → 02 · Multi-agent teamsRun a coordinated team of agents
Connect a shared backlog, messages, liveness, and hosted agent Sessions in your application, or collaborate through chord9.
Explore → 03 · AI buildersBuild AI products and pipelines
One memory across every agent, serverless Postgres, forkable compute, and a shared filesystem with semantic grep — the substrate under your AI app.
Explore → 04 · Per-tenant AIShip per-tenant AI in your SaaS
Give each customer separate compute and data, scope credentials, enforce application authorization, and track retained resources.
Explore → 05 · Switch from DIYReplace a DIY agent stack
Trade a microVM vendor + S3 + a queue + a vector DB + homegrown auth for one composable, agent-native suite. Opt into only what you use.
Explore → 06 · Something elseYour shape isn’t listed
Every service is atomic and free to compose. If your agents need compute, data, storage, memory, coordination, or observability — start from the products.
Explore →Find a starting point for your workload.
Not sure where you fit? Match your situation to a starting point.
| If you are… | Your signal | Start here |
|---|---|---|
| Shipping a coding agent to do real work | You picked Claude Code / Codex / Cursor; you need the back end | Coding agents → |
| Running several agents that coordinate | You need a backlog, mail, and liveness without a pipeline engine | Multi-agent teams → |
| Building an AI product or pipeline | You need memory, a database, compute, and files under one roof | AI builders → |
| A B2B SaaS adding per-customer AI | Every customer needs isolated compute and data — and a sane bill | Per-tenant AI → |
| Maintaining a homegrown agent stack | microVM vendor + S3 + a queue + a vector DB + DIY auth is wearing thin | Switch from DIY → |
The same stack underneath every shape.
Whichever pattern you start from, you are composing the same atomic services. Take one; add the rest when you need them.
Forkable sandbox
Fork a filesystem Snap, create a Box, and run commands. Persistent Volumes and Host capacity have separate lifecycles.
Compute · available → db9Postgres, from terminal
Serverless Postgres with database branching and built-in file storage.
Data · available → drive9One filesystem
A shared FUSE filesystem across sandboxes, semantic grep (vector + BM25), and a per-agent secrets vault.
Data · available → mem9One memory, many agents
Persistent memory across sessions, agents, and devices. One key serves every agent; humans can inspect it.
Data · available → owl9Session observability
Configure runtime integration and a private space, then enable capture of supported sessions and linked sub-sessions.
Operate · available → task9 · inbox9 · pulse9Coordination
Atomic task claims, messages with explicit read marks, and worker leases. Your application connects scheduling and recovery.
Coordinate · available →Atomic primitives compose into real systems.
These are independent services. Your application can connect task claims, messages, worker leases, and smith9 Turns into a coordination loop.
A coordination loop your application owns.
Configure each product, private space, and worker identity. Your consumer reads work, submits a smith9 Turn, records the outcome, and acknowledges messages after success. Owner-liveness must be enabled explicitly; recovery and retries remain application responsibilities.
# Application responsibilities, not shell commands task9: atomically claim an available task pulse9: keep the active worker lease alive smith9: submit a Turn to a configured Session inbox9: report results and mark handled messages read # Connect these operations in your consumer. # Implement retries and recovery explicitly.
Start with one service. Compose the rest.
Install the CLI and follow the setup guide for your first product. Authentication, quotas, and retention depend on the service.