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.

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, and OpenCode 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

1. Intake — tasks come from the web UI, GitHub Issues (one-click assign), Linear, Jira, or Notion
2. Provisioning — Optio finds or creates a Kubernetes pod for the repo, creates a git worktree for isolation
3. Execution — the AI agent (Claude Code, OpenAI Codex, or GitHub Copilot) runs with your configured prompt, model, and settings
4. PR lifecycle — Optio polls the PR every 30s for CI status, review state, and merge readiness
5. Feedback loop — CI failures, merge conflicts, and review feedback automatically resume the agent with context
6. 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          ──→     Execute agent with params
  Agent + model config      Webhook from external          Stream logs in real time
  Budget & retry limits     Ticket events                  Track cost & token usage
                                                           Auto-retry on failure

Jobs (Standalone Tasks) run an agent in an isolated pod with no git checkout. Define a prompt template with {{PARAM}} placeholders, configure triggers (manual, cron schedule, webhook, or ticket), and let Optio handle execution, retries, and cost tracking. Tasks can also be saved as blueprints with the same trigger types — see docs/tasks.md.

Agents — long-lived, message-driven

You create an agent         Wake sources                   Per turn
──────────────────────      ─────────────────              ──────────────────────

  System prompt             User chat message              Drain pending messages
  agents.md operator   ──→  Inter-agent message    ──→