← Writing · 610 words · Essay

omni: an agent orchestrator for my GitHub workflow

Overview

In March 2026 I let an autonomous agent system run my GitHub workflow overnight for the first time. By the time I woke up, it had completed 686 cycles, opened and merged 11 pull requests, and self-healed 8 stalls without me touching the keyboard.

That system is omni, a CLI orchestrator I use as a personal operating system for AI agents.

What omni does

omni runs on three layers. The master layer decides which workspace or project needs attention next. The workspace layer understands a specific codebase, its open issues, and its local tools. The project layer runs Claude Code agents against a single GitHub issue until it is implemented, tested, and ready to merge.

Instead of treating AI as a one-off assistant, omni treats agents as long-running workers with a backlog. It reads GitHub issues and turns them into concrete tasks. It spins up short-lived Claude Code agents to implement changes in local repos. It commits and pushes branches, opens pull requests, and responds to CI feedback. And it logs failures and friction points back into a vault, so the next run starts a step ahead of the last one.

The goal isn't to replace engineers. It's to give one engineer a set of workers that don't need to be re-explained the codebase every morning.

Why I built it this way

Most "AI coding" setups stop at: open the editor, ask the model to change a file, copy the diff in. That's fine for small changes. It breaks down once you want a queue of issues that get worked automatically, agents that can run commands and keep state between steps, and a feedback loop where a failure this week changes what happens next week.

omni treats GitHub issues as the source of truth, uses Claude Code agents as workers rather than a chat window, and stores context and run history in a vault so an agent can see what a previous attempt already tried. The result sits between my repos, GitHub, and Claude Code, and does the coordination I used to do by hand.

The first overnight run

The first real test for omni was simple: run all night and close as many issues as you can. Over one night it ran 686 orchestration cycles across multiple projects, opened and merged 11 pull requests, and hit 8 stalls (flaky tests, ambiguous specs) that it recovered from without me stepping in.

The interesting part wasn't the numbers. It was the failure modes: the agent getting stuck in tool loops, lint rules or tests that should have existed and didn't, and GitHub issues written loosely enough that a human would have rewritten them without thinking twice. Each of those became a new constraint for the system. The next night, omni knew a little more about what "done" actually looks like.

How it fits into my work

omni isn't a product, at least not yet. It's a tool I run locally as part of a bigger stack: context-vault gives agents a persistent memory layer, this site is hand-edited HTML deployed via Cloudflare Pages that agents can safely touch, and omni runs on top of that environment, spinning up agents that edit repos like this one.

If your work looks like a lot of small issues spread across repos, or refactors and migrations that repeat the same shape, or documentation that needs updating faster than a human gets to it, that's the kind of problem omni was built for.

Work with me

I build agent orchestration systems like omni, MCP-based tools like context-vault, and production Webflow and HubSpot CMS setups that integrate with AI workflows. I work full-time as Technical Lead at Stormfors and take on a small number of projects through my independent practice. If that overlaps with something you're building, get in touch.

Related

Browse by tag →