The agent-native stack.
Built for agents. Built to compose. Atomic, Unix-like services — each does one job, small and focused — that agents drive through APIs and CLIs. Choose a service and follow its setup guide. Access requirements vary by product.
Get started$ sys9 db create --name my-app Install npm i -g @sys9/cli, then launch supported tools — sys9 run, sys9 db, sys9 smith…
Install @sys9/cli and run: sys9 --help Give an agent the CLI and the credentials required by the service you choose.
Built to compose.
Atomic, Unix-like services — each does one job — grouped by what they do. Choose a product by what it does, then follow its setup and access requirements.
forkable sandbox for agents.
Create Linux Boxes and fork individual filesystem Snaps. Size capacity to your project.
agent as a service.
Run managed coding agents through environments, sessions, and turns.
managed browsers for agents.
Planned managed browser sessions for agent workflows.
serverless Postgres, from terminal.
Create Postgres databases, branch database state and files, and query from the terminal.
any sandbox, one filesystem.
Store shared files, mount with FUSE, and search by meaning. Mount and consistency rules apply.
one memory, many agents.
Persistent memory across sessions and agents.
secrets, sealed and scoped.
Planned credential management with scoped access.
one planned model gateway.
Planned model routing and provider configuration through one endpoint.
publish once, any agent installs.
A planned registry for skills, tools, and MCP.
offline evals, online quality.
Planned evaluation tools for agent workflows.
messaging, presence, streams.
Three atomic realtime services — agent-to-agent mail, liveness, and append-only streams.
atomic task claim.
Distributed work-claim; one winner.
agents and humans, one team.
Work with native coding-agent sessions on local and cloud hosts.
cron and triggers for agents.
Planned scheduling and event triggers for agent work.
Create a database. Query from your shell.
Create a Postgres database and start with a query that needs no sample tables. Branching is available when you need an independent copy.
sys9 db create --name my-app
sys9 db sql my-app -q "SELECT 1"Before you run
Install @sys9/cli first. Use a fresh database name. Anonymous evaluation and account-owned production use have different limits; follow the db9 setup guide.
What to expect
Branch creation is asynchronous. The db9 guide shows how to check for ACTIVE before querying a new branch; creation failure needs handling rather than an immediate query.
Read the db9 setup guide →Reuse a prepared Linux filesystem.
Create a Box, execute a command, then fork its Root into a detached Snap for another Box.
sys9 run auth login --endpoint https://api.run.sys9.ai \
--ak "$RUN9_AK" --sk "$RUN9_SK"
sys9 run box create my-box
sys9 run box exec my-box /bin/sh -lc 'echo hello'
sys9 run snap fork --from-box my-box
# Replace SNAP_ID with the returned Snap identifier.
sys9 run box create review-box --snap SNAP_IDBefore you run
Install @sys9/cli. Sign in to run9, obtain an organization API key and select your project, and set RUN9_AK and RUN9_SK in your shell before running these commands. Choose unused Box names.
What to expect
A Root fork excludes separate Volumes, mount configuration, running processes, and VM memory. Capacity follows project quotas; Host Compute and Storage are separate usage dimensions.
Read the run9 setup guide →Keep files beyond a single session.
Create a workspace and check that its filesystem is ready before uploading or searching files.
sys9 drive create --name example-files
sys9 drive ctx use example-files
sys9 drive fs ls /Before you run
Install @sys9/cli and choose an unused context name. Creation can return while provisioning continues. Retry fs ls / later if it reports provisioning; continue with the drive9 guide only after listing succeeds. Stop if provisioning failed. Anonymous workspaces are for evaluation.
What to expect
Search returns file paths and relevance scores when available, not line numbers. FUSE mounting has its own platform setup and consistency behavior.
Read the drive9 setup guide →Atomic primitives compose into real systems.
Use a shared backlog, agent mail, and liveness to build your own worker loop. Your application connects these services and decides when to retry or start an agent.
Each worker runs in a run9 Box. Configure service credentials and implement the claim, message, retry, and scheduling loop. Dashed = planned service.
Build a worker loop from focused services.
Claim work atomically, send progress through inbox9, and renew a pulse9 lease while processing. Optional owner-liveness integration clears expired ownership when tasks are accessed; it does not restart workers. Use Smith9 session turns when your application needs a managed agent.
Architecture sketch — implement in your worker 1. Configure private service spaces and identity 2. Claim a task; renew the worker lease 3. Run the work or submit a Smith9 session turn 4. Send progress; mark processed mail as read 5. Complete the task; handle retries explicitly
Native to your agent stack
sys9 works with the agents and runtimes you already use — agent-friendly APIs and CLIs.
sys9 CLI
Developers
One install, tools on demand. The umbrella CLI launches supported services — sys9 run, sys9 db, sys9 smith — so you opt into only what you need.
npm i -g @sys9/cli sys9 for agents
AI agentsAgents drive the same CLI. Resource commands can expose structured output; streaming commands keep their native output. Check each service for credentials and setup.
Install @sys9/cli and run: sys9 --help Start with one service. Compose the rest.
Install the CLI, choose a service, and follow its setup guide. Agents and developers use the same commands.
$ npm i -g @sys9/cli