---
title: Build to operate
description: The verified journey from building an agent with AgentsKit to running it with governance, audit, cost, and HITL on AgentsKit OS.
---

AgentsKit OS is the production destination in the AgentsKit ecosystem. Use this journey when you already know how to build an agent and need to run it with real controls.

## Journey

1. **Build** with [AgentsKit](https://www.agentskit.io/docs) — define tools, adapters, and agent behavior on the foundation library.
2. **Start faster** from the [Registry](https://registry.agentskit.io) when a ready agent matches the problem, then own and adapt the source.
3. **Ship the experience** with [AgentsChat](https://github.com/AgentsKit-io/agentskit-chat) when users need a conversational interface across clients.
4. **Guide ownership** with [Doc Bridge](https://agentskit-io.github.io/doc-bridge/) so agents and contributors land on the correct edit roots and checks.
5. **Apply discipline** with the [Playbook](https://playbook.agentskit.io) before merging agent-produced changes.
6. **Operate** on AgentsKit OS — permissions, egress, audit ledger, cost budgets, HITL approvals, and deployment modes (managed cloud, self-hosted desktop, terminal/CLI).

## Clean quickstart proof

```bash
# 1) Read the public docs entry point
open https://akos.agentskit.io/docs/getting-started

# 2) Install the CLI (see the CLI guide for the current package name and channel)
akos --help

# 3) Confirm the authentication and health commands are available
# The verified help surface lists both `auth status` and `status`.
akos --help
```

## What “operate” means here

| Control | Why it matters |
|---|---|
| Identity + RBAC | Only authorized principals run or approve agent actions |
| Egress allowlists | Agents only call approved tools and destinations |
| HITL gates | Risky steps pause for a human decision |
| Signed audit | Every material action is reconstructible later |
| Cost budgets | Spend is visible and policy-bound |
| Deployment modes | Same contracts for managed cloud and self-hosted |

## Maturity honesty

- Released public docs and CLI surfaces are what this journey covers.
- Experimental package APIs may change; treat them as internal operator knowledge unless a release notes them as stable.
- If a capability is planned or unavailable, the assistant and docs must say so rather than inventing a path.

## Next steps

- [Getting Started](/docs/getting-started) — web, desktop, and CLI entry.
- [How a run works](/docs/how-it-works/run-lifecycle) — trigger to signed audit ledger.
- [CLI command reference](/docs/cli/command-reference) — verbs and capabilities.
- [Using the app](/docs/using-the-app) — screen-by-screen operator guide.