HN Explorer

Show HN: Optio – Orchestrate AI coding agents in K8s to go from ticket to PR (github.com)

88 points by jawiggins ↗ HN
I think like many of you, I've been jumping between many claude code/codex sessions at a time, managing multiple lines of work and worktrees in multiple repos. I wanted a way to easily manage multiple lines of work and reduce the amount of input I need to give, allowing the agents to remove me as a bottleneck from as much of the process as I can. So I built an orchestration tool for AI coding agents:

Optio is an open-source orchestration system that turns tickets into merged pull requests using AI coding agents. You point it at your repos, and it handles the full lifecycle:

- Intake — pull tasks from GitHub Issues, Linear, or create them manually

- Execution — spin up isolated K8s pods per repo, run Claude Code or Codex in git worktrees

- PR monitoring — watch CI checks, review status, and merge readiness every 30s

- Self-healing — auto-resume the agent on CI failures, merge conflicts, or reviewer change requests

- Completion — squash-merge the PR and close the linked issue

The key idea is the feedback loop. Optio doesn't just run an agent and walk away — when CI breaks, it feeds the failure back to the agent. When a reviewer requests changes, the comments become the agent's next prompt. It keeps going until the PR merges or you tell it to stop.

Built with Fastify, Next.js, BullMQ, and Drizzle on Postgres. Ships with a Helm chart for production deployment.

34 comments

[ 4.6 ms ] story [ 68.9 ms ] thread
MrDarcy
Looks cool, congrats on the launch. Is there any sandbox isolation from the k8s platform layer? Wondering if this is suitable for multiple tenants or customers.
antihero
And what stops it making total garbage that wrecks your codebase?
conception
What’s the most complicated, finished project you’ve done with this?
hmokiguess
the misaligned columns in the claude made ASCII diagrams on the README really throw me off, why not fix them?

| | | |

denysvitali
FWIW, a "cheaper" version of this is triggering Claude via GitHub Actions and `@claude`ing your agents like that. If you run your CI on Kubernets (ARC), it sounds pretty much the same
naultic
I'm working on something a little similar but mines more a dev tool vs process automation but I love where yours is headed. The biggest issue I've run into is handling retries with agents. My current solution is I have them set checkpoints so they can revert easily and when they can't make an edit or they can't get a test passing, they just restart from earlier state. Problem is this uses up lots of tokens on retries how did you handle this issue in your app?
pianopatrick
I wonder, based on your experience, how hard would it be to improve your system to have an AI agent review the software and suggest tickets?

Like, can an AI agent use a browser, attempt to use the software, find bugs and create a ticket? Can an AI agent use a browser, try to use the software and suggest new features?

vidarh
Yes, they can, and they do a reasonably good job at it. Hand them playwright or similar, and point them at it. The caveat is that they're often "lazy", and it takes some practice to coax them into being thorough (hot tip: have one write a list of things to probe and test, and tell it to use sub agents to address each; otherwise they tend to decide very quickly it's too tedious and start taking shortcuts)
verdverm
I love k8s, but having it as a requirement for my agent setup is a non-starter. Kubernetes is one method for running, not the center piece.
raised_hand
Why K6? Is there a way I could run it without
stingraycharles
I’ve come to the realization that these kind of systems don’t work, and that a human in the loop is crucial for task planning; the LLM’s role being to identify issues, communicate the design / architecture, etc before it’s handed off, otherwise the LLM always ends up doing not entirely the correct thing.

How is this part tackled when all that you have is GH issues? Doesn’t this work only for the most trivial issues?

jawiggins
Maybe - I do think as the model get better they'll be able to handle more and more difficult tasks. And yet, even if they can only solve the simplest issues now, why not let them so you can focus on the more important things?
vidarh
I've come to the opposite conclusions: The big limitation of systems like this is starting and ending with human involvement at the same level, instead of directing at a higher level. You end up quibbling over detail the agents can handle themselves with sufficient guardrails and process, instead of setting higher level requirements and reviewing higher level decisions and outcomes, and dealing with exceptions.

You can afford a lot of extra guardrails and process to ensure sufficient quality when the result is a system that gets improved autonomously 24/7.

I'm on my way home from a client, and meanwhile another project has spent the last 10 hours improving with no involvement from me. I spent a few minutes reviewing things this morning, after it's spent the whole night improving unattended.

tim-projects
I don't believe comments like this. Sure it did work for ten hours but if you didn't review it you will sooner or later when it breaks. And it will. I run the agents all day and that's what happens - they do stuff that is unwanted but that you aren't aware of.
Ryand1234
I kind of agree. For features, we need human in the loop to verify what agent needs to build but for bugs and all, I feel these systems can work.
saltpath
The parallel execution model makes sense for independent tickets but I'm wondering what happens when agent A is halfway through a PR touching shared/utils.py and agent B gets assigned a ticket that needs the same file. Does the orchestrator do any upfront dependency analysis to detect that, or do you just let them both run and deal with the conflict at merge time?
vidarh
It's generally not worth it worrying about it too much other than at a very high level vs. letting them fight it out, as long as your test suite is good enough and your orchestrator is even moderately prepared to handle retries.
maxdo
Is the pod per repo or per task ?
jawiggins
One pod is an instance of a repo, you can set the number of instances of each agent/task that can be running on a pod at a time. For >1, each agent should be using it's own worktree.
fhouser
Hot take: You should want to review your agents' output and progress.
olegbk
The feedback loop is what most people miss when they build these systems. You spin up the agent, it submits a PR, CI goes red, and suddenly you're back to being the bottleneck you were trying to eliminate.

One thing I ran into building something similar, agents are surprisingly good at fixing the exact error message they're given, but terrible at recognizing when they're going in circles. After the third retry on the same failing test, you're not getting a fix, you're getting increasingly creative excuses for why the test is wrong.

How deep does the self-healing go? Is there a retry limit before it escalates, or does it just keep going until you manually intervene?