You already built this. Stop maintaining it.
An agent stack needs compute, storage, task coordination, retrieval, and access control. sys9 offers focused services for parts of that stack. Adopt a service where its current contract fits your workload, and keep the application logic and authorization your system needs.
What you wired together → one service.
Compare the responsibilities each service can take on. Validate behavior, quotas, data migration, and access control before replacing an existing component.
| What you wired together | The sys9 service | What changes |
|---|---|---|
| Sandbox service or self-managed microVMs | run9 | Fork a filesystem Snap and create a Box from it. Root and persistent Volumes have separate lifecycles; retained storage and provisioned Host capacity contribute to usage. |
| Object storage (e.g. S3) + glue | db9 + drive9 | File storage built into the database, no bucket wiring — plus a shared FUSE filesystem across sandboxes with semantic grep. |
| A queue / job runner | task9 + tape9 | Atomic work-claim and append-only logs. Configure owner-liveness explicitly and follow tapes when streaming output is needed; your application still schedules and retries work. |
| A vector DB / search service | drive9 + mem9 | Semantic grep (vector + BM25 in parallel) over your files, and one persistent memory shared across every agent. |
| Agent-to-agent messaging glue | inbox9 + pulse9 | Mailboxes ordered by ingestion sequence, explicit read marks, and a liveness registry. Consumers handle idempotency and retries within the message retention window. |
| Homegrown auth | auth9 · planned | A planned identity service. Today, retain your application authorization and configure each product credential separately; drive9 vault grants do not replace tenant identity. |
| DIY logging / tracing | owl9 | Install and configure a supported runtime integration, then capture native sessions and linked sub-sessions with owl9. This is not a service-wide audit log. |
Move service responsibilities deliberately.
A DIY stack
Service responsibilities and integration code your team maintains.
- Separate bills, dashboards, and operational responsibilities
- Integration code between the services you use
- Idle compute often still costs you
- Auth and isolation are yours to get right
- SDK and API integration with your agent runtime
sys9
Atomic services that compose, driven by APIs and CLIs.
- One agent-native suite; opt into only what you use
- APIs and CLIs for explicit integration between services
- Track Host Compute and retained storage separately
- Separate tenant resources and enforce application authorization
- Product-specific setup — agents use scoped CLI credentials
Migrate a row at a time.
You don’t have to rip out the stack. Replace the piece that hurts most, keep the rest, and compose from there.
Start with the sharp edge
Swap the one service that pages you most — usually compute. Verify run9 image, Snap, networking, and lifecycle behavior against your workload before cutover.
Compose outward
Add storage, a database, coordination, or traces as you go. Each is independent; nothing forces a big-bang cutover.
Retire the glue
Remove obsolete integration code only after the replacement path passes your acceptance checks. Keep the scheduling, retries, and authorization your application owns.
Replace the stack one service at a time.
Tell us what your DIY stack looks like, or sign in to run9 and validate one workload with its quickstart.