Centaur or Minotaur: Who Is Deciding in Your Agent Stack?
Human brain on an AI body, or AI brain on a human body, and how one quietly becomes the other

Human brain on an AI body, or AI brain on a human body, and how one quietly becomes the other

"Who is driving whom"
Illustration by FLUX.2 Pro (fal.ai)
Feel free to send us a message with your thoughts, or learn more about us!
DCYFR Labs is one architect plus a private AI agent swarm. It is tempting to dress that up as a team: names, job titles, a bigger-than-it-is company. This is the honest version: the systems that let a solo studio operate like more than one person, why I say "I" and not "we," and where it stops scaling.
Every LLM provider keys its prompt cache on the prefix of the request. Mutate the system prompt, tool schema, or message history mid-conversation and you invalidate the cache for the rest of the session — a single slip can 10x the cost. The four forbidden mutations, the permitted ones, and how to enforce them statically.
A short, honest changelog: what shipped in the @dcyfr/ai v3.x line, what changed for people building on it, and what comes next — catching the blog up with work the package already produced.
Pair a human with an AI and you get one of two creatures.
A centaur has a human head on a tireless body. You decide what to do, and the machine does the running. A minotaur has the bull’s head on a human body. The machine decides, and a person carries it out.
People ask which one is more powerful as if it were a matchup. It’s more useful to treat it as a question about where the hard part of a task lives, and that answer changes over time. I run a studio on a centaur: one architect directing a swarm of agents and an autonomous daemon. Over the last year I watched pieces of it turn into a minotaur, one reasonable handoff at a time. This post is about how that happens and how to decide on purpose which way each decision faces.
The strongest evidence for the centaur comes from chess. In 2005 the PAL/CSS Freestyle tournament let anyone enter with any mix of humans and computers. Grandmasters entered with engines. So did dedicated chess machines. The winner was a team called ZackS: Steven Cramton and Zackary Stephen, two American amateurs rated under 1700, running three computers.
They didn’t out-calculate anyone. The engines did the calculating. What they had was a better process: they knew when to trust which engine, when the engines disagreed, and when a position needed a longer look. The humans contributed judgment about the machines, and that was enough to beat far stronger players who also had engines.
That result is why “centaur” became the optimistic word for human-AI teaming. Human judgment plus machine execution beat either one alone.
The part that gets told less often is what happened next. Engines kept improving. Every improvement shrank the set of positions where a human override helped, and grew the set where it hurt. The centaur’s advantage was real, and it came with an expiry date set by the machine’s rate of improvement.
Cory Doctorow has a name for the other shape: the reverse centaur, a person used as an appendage by a machine. I call it a minotaur because it reads more cleanly, and because in the myth the thing in the maze eats people.
You don’t have to imagine one. A warehouse picker whose route, pace, and next item come from an optimizer is a minotaur. So is a delivery driver dispatched turn by turn, and a support agent reading a script a model chose for this caller. The machine holds the decision. The person supplies hands, legs, a legal identity, and a face.
The minotaur has one decisive strength: it scales on the brain side. One model can direct ten thousand people at once. A centaur is capped by the attention of the human at the top, and human attention doesn’t parallelize.
It also has three structural weaknesses, and they are the ones that matter for anyone building agent systems.
The human executing a minotaur’s decision usually doesn’t know why it was made. That means they can’t tell a good instruction from a bad one. A centaur’s body can fail loudly (the code doesn’t compile, the test goes red). A minotaur’s body carries out a wrong decision faithfully and at full speed.
The party that decided can’t be held responsible, and the party that acted didn’t decide. Every incident review in a minotaur system ends in the same unsatisfying place: the model recommended it, and the person followed the process.
Treat people as actuators long enough and they stop exercising the judgment that was the only thing they offered over a robot. The minotaur makes itself more brittle over time, because it trains away its own error-correction.
It depends on what you mean by power, so here is the comparison laid out by dimension.
| Dimension | Centaur (human brain, AI body) | Minotaur (AI brain, human body) |
|---|---|---|
| Throughput | Capped by one human’s attention | Scales with the model |
| Ambiguous goals | Strong: a human can answer “should we?” | Weak: optimizes whatever it was pointed at |
| Physical and social work | Weak until robots and agents can do it | Strong: people are the body |
| Error correction | The human reviews what the AI produced | The human rarely has the context to object |
| Accountability | Clear: the decider answers for it | Split between decider and doer |
| Trend as models improve | Shrinks domain by domain | Grows domain by domain |
My answer:
The hybrid is fine. The danger is how you arrive at it.
DCYFR Labs started as a textbook centaur. I prompted an assistant, read what it produced, and decided what shipped. That’s the workflow I wrote up in AI Assistants as Development Partners.
Then came the daemon, described in Autonomous AI Agents. It runs on a schedule with nobody watching: it observes the workspace, triages what it sees, decides what’s worth doing, acts on a bounded slice, and records what happened. The moment it started choosing its own tasks, the direction of control flipped for that slice of work. I stopped setting the goal and started reviewing the output of a goal the daemon picked.
Every handoff after that was locally sensible:
None of those were bad calls. Each one removed toil I was glad to lose. Taken together, though, they describe a system where the machine increasingly decides and I increasingly approve. The morning review, where I read what the daemon did overnight and approve what it hands up, is the minotaur shape at small scale: the goal came from the machine, and the signature comes from me.
I don’t want to reverse the drift. The daemon is valuable exactly because it decides things I shouldn’t spend attention on. What I want is for every handoff to be a decision, made with evidence, that I can revisit.
Three rules came out of that.
Remediation playbooks in my stack don’t start with authority. A new playbook runs in shadow mode: it reports what it would have done, and a human does the real thing. It graduates to auto only after ten real successes. That is a decision handed from human to machine on a track record, with a paper trail. It’s the opposite of drift.
Every autonomous path honors a kill switch that I control and the machine can’t override, which I covered in Kill Switches for Autonomous Agents. A minotaur you can switch off is a tool. A minotaur you can’t switch off is in charge.
This is the rule that matters most. The daemon may pick which maintenance task to do next. It does not pick what the studio is for, what ships to customers, or what gets said in my name. Anything I will have to answer for, I decide.
Here’s the check I now run over my own stack. List the recurring decisions in your system (what gets built, what gets fixed, what gets merged, what gets sent) and answer four questions for each.
Then read the answers across:
The third row is common, and it’s easy to miss because it looks like human oversight. There’s a human in the loop. They approve every run. But they approve things they didn’t choose and can’t evaluate, which puts their name on the decision without giving them any real control over it.
For developers
Pick one automated workflow you rely on. Answer the four questions for each decision it makes. If the goal-setter and the accountable party are different, either move the goal back to a human or make the handoff explicit: shadow mode, a graduation threshold, and a kill switch.
The minotaur is more powerful in the sense that it scales, and it’s gaining ground every time a model gets better at judgment in some domain. The centaur is more powerful in the sense that it can be steered and held to account. Chess showed that the centaur’s edge doesn’t last forever. My bet is that it lasts longest in domains where “what should we want?” is the hard question.
The creature you end up with matters less than whether you chose it.
What does your stack look like when you run the audit? Tell me which row surprised you. The accidental minotaurs are where the interesting failures live.