Krishna Esteva

6 months ago I installed Claude Code and every week since I've gotten pulled deeper down the rabbit hole. The deeper I got, the more I appreciated its power and the more I felt one fundamental limitation: terminals are the perfect interface for LLMs, but they're not the best one for humans. So I climbed the ladder of insanity (tools, plugins, IDEs) until I finally hit the point of building my own.

The deeper I got into orchestration, the more two fundamental constraints of working through a TUI started to bite:

computers are great at managing state, agents are pretty bad at it
a mostly-text interface makes it hard to figure out what actually needs your attention

Both meant I spent more time nudging the process along than building. So here's what I did about it:

Problem 1: building complex multi-agent workflows is hard

Workflows increase the quality and reliability of agent output but doing it through the TUI is clunky. Agents, skills, plugins, and now dynamic workflows all help, but designing and iterating on them is slow. And you burn your orchestrator's context window on process management.

But orchestration itself is easy, maybe a few hundred lines of code. Putting it into a nice UI is harder but also easy, which is where I started with Cyboflow:

Problem 2: monitoring is hard

Even if you get the workflow right, monitoring it means watching a wall of text + constantly tabbing through running agents. I wanted was a single central view: watch every agent run, see where they stand, and see which ones need my input.

That's the core of the human review queue. Monitor every agent, see which one need you, and every input gets categorized as a permission (e.g. a bash command), a decision (input required), or an action (e.g. an API key needed).

Problem 3: measuring performance

Great, you've built your multi-agent workflows and they're running. You're successfully tokenmaxxing, but are they actually working or are you just taking the long way to the same destination? To help, I added tracking to see which workflow steps burn the most tokens, plus observability to know whether the added steps are actually keeping issues out of production.

Problem 4: the more you ship, the more your problems compound

Even with a well-tuned system, the bigger your codebase the more issues creep in (whether humans or robots are writing the code). Asking agents to fix things along the way is a bad idea, they work best with focused objectives. The solution, which I learned from Every, is to give agents a place to park issues as they encounter them (missing docs, inefficient code, an opportunity for a shared utility) that I triage and resolve later

All of this is built on the Claude SDK, which created its own problem: it's included in subscription usage for now, but that's probably going away even with the temporary reprieve we got. So everything in Cyboflow can be run through the SDK or the PTY. You lose some functionality on a live interactive terminal, but most of it's still there, just a little slower.

Some more things that are far from unique but I found helpful for my own workflow:

built-in native task tracking
every session gets its own worktree
native ultracode support that automatically extracts dynamic workflow state

With lots more to come.

If that sounds interesting, give it a try: cyboflow.com

Or if you'd rather tweak it for your own workflow, it's fully open source: github.com/kesteva/cyboflow

Some caveats:

this is a very early beta, so it's for the tinkerers. If you want something reliable and stable, you should probably wait until we're at least out of the 0.1.[x] builds.
you probably need to be at least level 3 or 4 on the ladder of insanity for this to be useful. If you're still on level 1 or 2, it'll add more cruft than you need.

If that doesn't scare you, give it a try, and @ me if you run into anything or drop me a note hello@cyboflow.com