The substrate under your AI product.
Whether you’re shipping an AI feature or running a data pipeline, you need the same four things: memory that persists, a database, compute that scales out, and files your steps can share. sys9 gives you each as an atomic service — compose them, don’t assemble a stack.
Four services, one AI product.
Take memory on its own, or compose all four into a full pipeline. Opt into only what your product needs.
One memory, many agents
Persistent memory that outlives resets, restarts, and devices. One key serves every agent; humans can inspect, import, and export it. Integrates with Claude Code, Codex, OpenCode, OpenClaw, Hermes, and Dify.
mem9 → db9Postgres + storage
Serverless Postgres with database branching and built-in file storage. Create an isolated review database for a migration or prompt experiment, with access appropriate to the data.
db9 → run9Compute that forks
Create Boxes from a prepared Root Snap and execute a shard explicitly in each Box. Your application schedules work and combines results within project quotas; persistent Volumes and running processes are not copied with the Root.
run9 → drive9Files + semantic grep
A shared filesystem across every step and session, with semantic grep (vector + BM25 in parallel) for retrieval and a per-agent secrets vault for the keys your pipeline needs.
drive9 →Shard the work, share the memory.
Fork compute for the parallel parts, read and write a real database, recall one memory across every agent, and retrieve context semantically — all from the terminal — by you or by an agent.
Parallel where it pays. Persistent where it counts.
mem9 keeps one memory across every agent and session, so context isn’t re-derived on each run. db9 holds the structured state. Your scheduler creates run9 Boxes for parallel stages and assigns work to each one. drive9 carries the files between them. The example creates a small Box and a database; connect your own pipeline and configure mem9 through its documented API or runtime integration.
Prepare a drive using the drive9 setup guide, wait for its filesystem to become ready, and upload your input files before this example. Replace pipeline-files with that saved context name.
# Install sys9 and complete run9 login first sys9 run box create batch-7 --image public.ecr.aws/docker/library/alpine:3.20 sys9 run box exec batch-7 /bin/sh -lc 'echo "pipeline worker ready"' sys9 db create --name pipeline sys9 db sql pipeline -q "SELECT 1" # Search only if the prepared workspace is accessible sys9 drive ctx use pipeline-files && sys9 drive fs ls / && sys9 drive fs grep "Q3 pricing" / # Remove compute after exporting your results sys9 run box rm batch-7
Compose the services your pipeline needs.
Atomic & composable
Each service does one job. Start with one, add the rest when you need them — there’s no bundle to buy or framework to adopt.
Configure each service
Install the CLI, complete each service’s login or workspace setup, and give agents scoped credentials. run9 requires an authenticated project.
Works with your agents
mem9 plugs into the runtimes you already use, so memory and retrieval aren’t tied to one agent framework.
The services behind this shape.
One memory
Persistent cross-agent, cross-session memory; humans can inspect it.
mem9 → db9Postgres + storage
Serverless Postgres, database branching, and built-in file storage.
db9 → run9Forkable compute
Fork filesystem Snaps and execute each scheduled shard in its own Box.
run9 → drive9One filesystem
Shared FUSE filesystem, semantic grep, per-agent secrets vault.
drive9 →Build your AI product on composable parts.
Start with a product quickstart, then add the services your pipeline needs.