Optio
Self-hosted AI engineering platform — your cluster, your agents, your code.
Optio organizes agent work into three tiers, all driven by the same trigger types, prompt-template engine, log streaming, and /api/tasks HTTP surface:
- Tasks (Repo Tasks) — turn tickets into merged pull requests. Submit a task (manually, from a GitHub Issue, Linear, Jira, or Notion), and Optio provisions an isolated environment, runs an AI agent, opens a PR, monitors CI, triggers code review, auto-fixes failures, and merges when everything passes.
- Jobs (Standalone Tasks) — reusable, parameterized agent runs with no repo checkout. Generate reports, triage alerts, audit dependencies, query a database, post to Slack — anything that doesn't need to land as a PR.
- Agents (Persistent Agents) — long-lived, named, message-driven agent processes. Each has a stable slug, an inbox, and a cyclic state machine. Wake on user messages, agent messages, webhooks, cron ticks, or ticket events. Three pod lifecycle modes (
always-on/sticky/on-demand). Address each other via an inter-agent HTTP API. See the four-agent Forge demo and the Mars Mission Control example. - Connections — give your agents access to external services. Connect Notion, Slack, Linear, GitHub, PostgreSQL, Sentry, or any MCP-compatible server, and Optio injects them into agent pods at runtime.
Tasks and Jobs are the job model — one-shot runs whose identity is the run itself. Persistent Agents are the service model — a turn is an input to the long-lived process, not the unit of work. Pick the tier by what shape your work has; see examples/ for runnable starting points and docs/tasks.md for the full breakdown.
The feedback loop is what makes Tasks different. When CI fails, the agent is automatically resumed with the failure context. When a reviewer requests changes, the agent picks up the review comments and pushes a fix. When everything passes, the PR is squash-merged and the issue is closed. You describe the work; Optio drives it to completion.
Under the hood, all task and pod state changes flow through a Kubernetes-style reconciliation control plane — a pure-decision-plus-CAS-executor loop with periodic resync that keeps runs from getting stuck on lost events.
Dashboard — real-time overview of running agents, pod status, costs, and recent activity
Task detail — live-streamed agent output with pipeline progress, PR tracking, and cost breakdown
Why Optio?
The AI coding agent space is crowded — Devin, Charlie Labs, Cursor background agents, Sweep, and others all promise ticket-to-PR automation. Optio's wedge is different: it runs in your infrastructure, behind whichever agent vendor you trust, against whichever Kubernetes cluster you already operate.
| Optio | Hosted alternatives |
|---|---|
| Self-hosted — runs entirely in your Kubernetes cluster (GKE, EKS, AKS, or any conformant K8s). Code, secrets, and agent logs never leave your network. | Hosted SaaS — your code goes to their cloud. |
| Multi-vendor agents — Claude Code, OpenAI Codex, GitHub Copilot, Google Gemini, OpenCode, and Cursor behind one interface. Switch per repo, or A/B agents on the same task. | Locked to a single model family or in-house agent. |
| Open source (MIT) — read the code, fork it, audit it. No black box, no vendor lock-in. | Closed source. |
| Enterprise-ready primitives out of the box — workspaces, encrypted secrets at rest (AES-256-GCM), OIDC/OAuth, Kubernetes RBAC, audit-friendly task history, and a reconciliation control plane that keeps runs from getting stuck on lost events. | Vary by vendor; often gated to enterprise tiers. |
| Standalone Tasks — not just ticket-to-PR. Reusable, parameterized agent work for ops, on-call triage, scheduled reports, and webhook-driven automation, with no repo checkout. | PR-centric; ops/automation use cases are out of scope. |
If you'd ship to a hosted agent without thinking twice, the hosted options are simpler. If shipping your repo to someone else's cloud is a non-starter — or if you want to keep your model choice open — Optio is built for you.
Who is this for?
- Security-conscious organizations — teams that can't (or won't) ship source code, secrets, or production data to a third-party AI service.
- Regulated industries — finance, healthcare, government, defense, and others where data residency, auditability, and tenancy isolation are non-negotiable.
- Teams already running Kubernetes — drop-in Helm install, BYO Postgres/Redis, integrates with your existing observability, ingress, and identity stack.
- Multi-agent shops — engineering teams evaluating multiple agent vendors and unwilling to commit to a single platform's roadmap.
- Platform teams building internal AI tooling — Optio is the orchestration layer. You bring the prompts, policies, connections, and review standards.
If none of the above describes you, a hosted product like Devin or Cursor background agents will get you to value faster. We're not trying to be everything to everyone.
How It Works
Tasks — ticket to merged PR
You create a task Optio runs the agent Optio closes the loop
───────────────── ────────────────────── ──────────────────────
GitHub Issue Provision repo pod CI fails?
Manual task ──→ Create git worktree ──→ → Resume agent with failure context
Linear / Jira / Notion Run Claude / Codex / Copilot Review requests changes?
Open a PR → Resume agent with feedback
CI passes + approved?
→ Squash-merge + close issue
- Intake — tasks come from the web UI, GitHub Issues (one-click assign), Linear, Jira, or Notion
- Provisioning — Optio finds or creates a Kubernetes pod for the repo, creates a git worktree for isolation
- Execution — the AI agent (Claude Code, OpenAI Codex, or GitHub Copilot) runs with your configured prompt, model, and settings
- PR lifecycle — Optio polls the PR every 30s for CI status, review state, and merge readiness
- Feedback loop — CI failures, merge conflicts, and review feedback automatically resume the agent with context
- Completion — PR is squash-merged, linked issues are closed, costs are recorded
Jobs — reusable agent work without a repo
You define a job Optio triggers it Optio runs & tracks
──────────────────── ───────────────── ───────────────────
Prompt template Manual (UI / API) Provision isolated pod
{{PARAM}} variables ──→ Cron schedule