Sample of the middleware in progress
Architecture Diagram

MinionWare

A user centric agentic AI middleware that combines orchestration, human agent interaction, and test driven development.

Inspiration

Coding agents are powerful, but their output is hard to trust and harder to predict. Most of the time the problem isn't the model. It's the specification. To get a desirable outcome from an agent, a user has to explain exactly what they want, and humans are notoriously bad at articulating everything they have in mind in a single prompt.

Today's baseline coding agents paper over that gap by guessing. They produce output based on their own interpretation of an ambiguous request, and the result looks confident even when it's wrong. The user only finds out several hundred lines later.

We wanted something that treats the specification as a primary artifact rather than an afterthought, a system that pins down intent before it starts burning tokens on implementation. That's MinionWare.

What it does

MinionWare sits between the user and the coding agents as a middleware layer. It:

Orchestrates a hierarchy of models rather than throwing one large model at the whole problem.
Keeps the human in the loop at the points where ambiguity actually matters, so intent is captured up front instead of being reverse engineered from broken code.
Drives development with tests, so "done" is a condition the system can check rather than a judgement call the model makes about its own work.

The result is better alignment with what the user actually asked for, and meaningfully more efficient use of expensive model calls.

How we built it

MinionWare runs on two tiers of models.

The driver. A larger, more sophisticated thinking model owns the project. It holds the user's intent, decomposes the work, and writes the test cases that define what each unit of work has to satisfy.

The minions. Smaller, cheaper models take those goals and do the actual build and test cycle. Small models are generally quite capable of writing correct code when the end goal is unambiguous, and an AI generated test suite is about as unambiguous as a goal gets. Each minion iterates until its tests pass.

The key property here is context economy. The expensive model never has to read every failed attempt, every stack trace, and every intermediate diff. If a task takes $n$ build and test iterations, the naive single agent approach accumulates all $n$ iterations in one context window:

$$C_{\text{naive}} = \sum_{i=1}^{n} c_i$$

Under MinionWare, that noise is absorbed by the minions, and the driver's context grows only by the goal and its result:

$$C_{\text{driver}} = c_{\text{spec}} + c_{\text{result}}$$

Keeping the driver's context clean is what keeps it focused on the user's original intent, instead of drifting as its window fills with debugging noise.

Challenges we ran into

Most of our pain was in implementation, and it was pain of exactly the kind MinionWare exists to solve.

We repeatedly shipped things that didn't match our vision. Our own development was driven partly by agents, and those agents kept writing code that behaved very differently from what we had in our heads. It was plausible, well structured, and not what we meant. Debugging a misunderstanding is much harder than debugging a bug, because nothing looks broken.

We also hit the coordination version of the same problem. We split the work, went off to build, and came back to find that our pieces overlapped severely. Two separate layers of unclear communication had compounded: first in how we divided the work between ourselves, and then again in how each of us described our segment to our own agent. Ambiguity at the top of the chain doesn't stay small. It multiplies.

What we learned

The core lesson is that getting an agent, or any capable engineer, to produce code that matches your vision requires two things: clear communication of intent, and a willingness to go through multiple rounds of building and testing. Neither is optional, and no amount of model capability substitutes for either.

Living through our own overlapping implementations problem was the strongest possible argument for the thing we were building. A single, authoritative holder of project intent isn't optional. It's the difference between parallel work and duplicated work.

What's next

MinionWare's real advantage is the centralization of project intent in a large driver model, which makes AI workflows look a lot like corporate ones: managers who hold context and engineers who execute against clear specs. That analogy suggests the next steps.

Manager to manager communication, so multiple drivers can negotiate interfaces and split large projects the way teams of teams do.
Multiple users to a single manager, so a whole team can collaborate against one shared, coherent specification rather than each person maintaining their own private version of the plan.
Security and sandboxing around minion execution, so untrusted generated code stays contained.