OpenStation runs agents against real work. You give an agent a workspace, a charter, and a set of tools; OpenStation makes it reachable on Slack, Telegram, Email, or a local REPL, keeps its conversations continuous, enforces what it's allowed to touch, and records everything it did as git history.
The framework stays thin on purpose. It resolves which agent, which session, and what's permitted — then hands off to Claude Code, which materializes the context and does the thinking. Almost everything you write to shape an agent is a Claude-native file.
Core topics
| Page | Start here when you need to |
|---|---|
| Agents | Define a charter, profile, runtime, and gate |
| Integrations | Connect channels, CLI tools, MCP servers, and skills |
| Permissions | Control tool access, approvals, and spending |
| Roles and people | Configure caller admission and agent authority |
| Automations | Schedule work or react to workspace events |
| Project status | Understand current capabilities and limits |
Start here
New? Getting started — install, scaffold a workspace, and have a conversation with an agent in about five minutes.
Then pick your path:
I want to run an agent
- Getting started —
init,create,dev, and your first turn - End to end — the whole configuration in one pass: two connectors,
a people roster, per-space gates, automation, and
serve - Connectors — per-channel app setup: Slack · Telegram · Email
- Deploying — running
serveas a long-lived service - Sharing secrets with dotenvx — commit an encrypted
.env; only the private key stays out
I want to author an agent
- Your first agent — build a working agent file by file
- Giving agents tools — CLI tools in any language, MCP servers, skills
- Permissions — what the agent may do, and how that's enforced
- Subagents — handing work to a second agent mid-turn
loops add— scaffold the eval → learn → improve loop into a workspace, from the template bundle the CLI ships
Concepts
What you need to model to configure OpenStation correctly — not the full design.
| Page | Answers |
|---|---|
| Architecture at a glance | what happens between a message and a reply |
| Agents and profiles | which file holds what, and why behavior isn't in openstation.yaml |
| Spaces and channels | which conversations an agent answers in, and why the axes are separate |
| Workspaces and git | where the agent's work lives and how to undo it |
| Sessions and turns | how a conversation stays continuous |
Reference
| Page | Contents |
|---|---|
| CLI | every command and flag |
openstation.yaml |
every field, every load-time error |
people.yaml |
mapping channel handles to roles |
roles.yaml |
which roles exist and what they grant; the compiled gate |
| Events | the event types and how to read the log |
| Environment variables | auth, connector credentials, what serve detects |
Example
examples/notes-agent is a complete, runnable OpenStation: an agent
that keeps a written record under okf/issues/, commits every change, reaches a Python tool from
the TypeScript platform, and refuses to read .env. It needs Claude auth and nothing else.
Before you build on this
OpenStation is pre-v1 and honest about it. Notably: one agent serves one process (per-message
channel routing isn't wired), nothing sums spend across turns (budget: caps each turn, and
that is the only ceiling there is), and the Telegram and Email transports are verified against
fakes only. The full list is in internal/roadmap.md under "Known gaps
to v1".
Design and process docs — architecture, roadmap, milestone logs — live in
internal/.