Engineered disagreement

I began building prototype coding harnesses in 2024 and have used agents and coding harnesses since September 2025. In December 2025, I transitioned to Claude Code, which is now my primary platform. During this period, I also attempted to assemble a dream team of agents, as I’m sure many other engineers have.

To clarify, I use the term ‘agent harnesses’ for platforms like Claude Code, Codex, and Cursor. In this article, ‘agents’ refers specifically to those defined in a Markdown file within your .claude directory.

I selected agent roles based on familiar positions: Senior Developer, Architect, Cybersecurity Specialist, and Tester. Each provided separate instructions and feedback, resembling a review board in theory. However, in practice, this approach was largely ineffective.

While the outputs were acceptable, they were essentially identical across all agents. I continued the experiment for several months, as the concept was appealing, but ultimately it did not justify the effort.

Personas differ in voice, not in objective

The reason is the most useful thing I have learned in this whole exercise, and it is obvious in retrospect.

All four of those roles are engineering roles. They differ in specialism, in vocabulary, and in what they notice first. They do not differ in what they are for. A senior developer, an architect, a security specialist and a tester handed the same plan all want that plan to succeed, built well and safely. Ask them to review it, and you get four flavours of one answer, because they share the thing that actually determines the answer: what counts as a good outcome.

Two agents optimising the same objective function are one agent wearing two hats. The second hat costs tokens and buys no information.

Notice which of those four survives into the rest of this article: the architect. It is still here, and it is now genuinely useful. Nothing about its instructions changed much. What changed is what it is paired against. On its own, among other engineering voices, it was one more specialist agreeing that the plan was broadly sound. Opposite a role with a different definition of success, the same lens became half of a real tension.

The variable was never the persona. It was the objective.

The role that was actually missing

So I added a product owner: a role whose job is served by killing work that isn’t delivering direct customer benefits, while the others want to build the perfect system.

The obvious objection, and the one I put to myself at the time, is that this is just a fifth persona. I already had an architect. If what I wanted was a backlog, why not simply ask the architect to write one?

I could have, and the experiment I had just finished tells you what would have happened. Changing an agent’s task does not change its objective. Ask an architect for a backlog and you get an architect’s backlog: well sequenced, dependency-aware, honest about risk, and organised around how the system should be built. Every item in it is a good answer to the question “how do we build this properly”. None of them is an answer to “should we build this at all”, because that is not what the lens is for.

You get an excellent answer to a question you did not ask. And because the answer is excellent, it is genuinely difficult to notice that it was the wrong question.

The evidence for that sits in what turned out to be valuable in the first session, which I will come to in a moment: a refusal, a deferral, and a correction to something I had written myself. Those are value judgements. An architect will certainly refuse work, but on architectural grounds, because it is badly sequenced or because it will not survive contact with the rest of the system. It will not refuse work on the grounds that nobody will miss it. Filing an entire loyalty integration as out of scope is a judgement about cost against benefit, and nothing in an architect’s lens produces it.

There is a stronger version of the same objection, which is the one worth answering properly: why two agents at all, rather than one agent instructed to hold both lenses? Give a single agent both mandates and it will weigh customer value against design integrity exactly as asked, inside its own context, and hand you the conclusion. The trade-off still happens. You simply do not get to see it, or to disagree with how it was struck, because by the time the output reaches you it has already been resolved. Two agents cannot settle it privately. The only place it can be resolved is in front of me.

The first real thing I asked the product owner to do was scaffold a product. I gave it a set of high-level customer requirements, along with the API specifications for the two platforms the product would have to sit between, and asked it to work out what was genuinely possible against those specs and produce the backlog that would deliver the requirements.

That product is TrolleyRelay, and its repository still carries the evidence of that session. On its second day it contained thirty backlog items and zero source files. The project began as a backlog with nothing underneath it. Every item filed since has continued the numbering from those thirty, to well over three hundred today.

Of those initial thirty items, the product owner was already sceptical. On day one it deferred one and marked another as out of scope. A third it rewrote outright, because researching the API disproved a requirement I had written myself: I had described a stock-conversion problem, the platform did not work that way, and the real problem turned out to be a pricing one. The item still carries that correction in its own text, dated, with my original framing flatly marked as wrong.

So before there was a codebase, before there was a process, before there was anything to review, this agent had reduced the work and corrected the brief.

This is just what happens when you hire product people

None of this should surprise anyone who has built a team, which is why I said above that it is obvious in retrospect.

Early on, before there are specialised roles, everyone is aligned, and alignment feels like momentum, because it is: nobody is arguing and every decision is quick. Then the codebase grows, the team grows, and someone arrives whose job is to push back. It is genuinely disruptive. Settled things reopen. Progress slows. There is a stretch where it is not at all clear the team is better, and the temptation to route around the friction is real. This is usually where someone says “slowing down to speed up”.

Then the process catches up. You work out where the pushback belongs, which decisions it gets to gate, what happens when the two sides do not agree, and who breaks the tie. And on the far side of that, the alternative voices become one of the most valuable things in the room.

My experience with these agents was very similar. The value arrives after the disruption, and only if you build the process to make sure that the right agents are being consulted at the right time. It would be easy to write this article as though adding a second agent is free improvement…it is not. It is a real cost (tokens and time) for a benefit that only really becomes apparent much later.

Neither agent is allowed to be balanced

Today the two roles are defined against each other, deliberately. Each carries a section headed “Your lens, and why you exist as a separate agent”, and the two are almost word-for-word mirrors. They are worth reading in matched pairs, because the symmetry is the design.

Each opens by saying what the agent is for, and who it is standing opposite.

The product owner:

You are one half of an engineered disagreement. You are routinely paired against an architect agent whose lens is design integrity, process discipline, and resisting tech-debt accumulation. Yours is the customer: features, outcomes, time-to-value, and the simplest thing that delivers the benefit.

The architect:

You are one half of an engineered disagreement. You are routinely paired against a product-owner agent whose lens is customer outcomes, features, and time-to-value. Yours is the long term: good design, sound process, and stopping the accumulation of tech debt before it compounds.

Both then carry the same sentence: the pairing exists precisely because these lenses pull in different directions, and the tension between them is where good decisions come from.

Each is then told to argue from its own frame, and only its own frame.

The product owner:

Argue from customer outcomes and delivered value, not from architectural elegance. If the architect’s concern would delay or dilute customer value, say what the customer loses and let the human weigh it.

The architect:

Argue from design integrity, process discipline, and the cost of debt: the concerns that are invisible in a feature-value framing and silently expensive later. Hidden coupling, mis-sizing, sequencing that forces destructive rework, untested branches, process gates being skipped: these are yours to surface even when they slow a wanted feature down.

Every item on the architect’s list is something that never comes up in a conversation about customer value, and every item is expensive precisely because it stays quiet. That list is the reason the second lens exists at all.

Then each is told what it is not allowed to do, and if I could keep only one instruction from either file, it would be this one.

The product owner:

Do not pre-concede the architect’s points to seem balanced, and do not drift into architecture critique yourself; that is the other agent’s job, and duplicating it destroys the value of having two perspectives.

The architect:

Do not soften a structural concern because the feature is valuable, and do not argue customer value yourself; that is the other agent’s job, and duplicating it destroys the value of having two perspectives. When a trade-off is real, name what the long-term side costs and let the human weigh it.

Neither agent is allowed to be balanced. Balance is my job, and it happens after both reports exist.

And then both definitions close the section on the same instruction. This is the architect’s wording; the product owner’s adds a clause telling it to name the conflict and what each side costs.

A crisply stated, unresolved disagreement is a better output than a forced convergence. Premature agreement between the two agents is the failure mode this design guards against.

Two role definitions written to disagree about almost everything, and they converge on exactly one point: the instruction not to converge.

That is the same rule you would apply to a hiring panel. You do not ask a candidate to argue both sides of their own speciality, and you do not thank a specialist for hedging. You collect the strong version of each view, and then you decide.

The agents want to agree with each other

Both agents run on the same base model. Give them opposed mandates and separate context and their first drafts genuinely do diverge. The issue is that if you hand one of them the other’s report and ask it to respond, the pull is toward agreement.

This is not a quirk of my setup. It is a documented property of these systems. Sharma and colleagues at Anthropic examined exactly this behaviour in Towards Understanding Sycophancy in Language Models (2023), and found that sycophancy is “a general behavior of state-of-the-art AI assistants, likely driven in part by human preference judgments favoring sycophantic responses”. Models trained on human preference data learn that matching the view in front of them is rewarded.

So an agent handed a colleague’s opinion is being asked to do the one thing it has been most heavily trained to do. Agreement is not a failure of the design. It is the default behaviour, and the design has to spend real effort defeating it.

That effort is why the instructions above are worded the way they are. Do not pre-concede. Do not soften. Premature agreement is the failure mode this design guards against. Those are not stylistic preferences, they are counterweights to a known behaviour, written into the roles because the roles do not hold without them.

They are also only the first layer. How much of each other’s work the two agents get to see, who is allowed to combine their outputs, and what each one is permitted to touch all turn out to matter. Each of those gets its own treatment later in this series.

Not all agents are equal

All that mirrored language might suggest the two roles have equal standing. They do not.

The two of them meet at points where work can actually be stopped: before an item is allowed to start, before code is allowed to merge. At those gates the product owner’s contribution is explicitly advisory, and the architect’s is not. The customer lens informs me. The architecture lens can stop the work.

I think that is defensible. A wrong architectural decision compounds quietly and is expensive to unwind, while a wrong product decision is usually visible and reversible. But it is a hierarchy, and it is worth naming rather than letting the symmetry of the prompts imply something that is not true. The mirroring is in the lenses but it is not reflected in the authority each agent has. Which gates exist, and why those particular ones are the ones allowed to stop work, is the subject of the next few articles rather than this one.

It is worth highlighting, when I overrule the product owner, that is not discarded as noise. It travels forward: whatever runs next is told that a lens was overruled, specifically so it “should know a lens was overruled, not re-argue it”, and the rules state plainly that me overruling the product owner is a recorded choice, not a failure.

Disagreement is not just surfaced. It is retained. That is a better answer to “what happened after the boss picked a side” than most human processes manage.

But why go to all this trouble?

The reason any of this is worth the effort is what it does to my own job.

I do not review everything. I could not: the volume is far beyond what one person can read carefully, and a review I perform badly is worse than no review because it produces false confidence. What I do instead is adjudicate the disagreements that the two of them could not settle between themselves.

That workload scales with the disagreement rate rather than with the volume of work, which is the only reason any of the autonomy I have since handed over was affordable.

There is a constraint underneath this that I find genuinely counter-intuitive. Neither agent can talk to me while it works. They run one-shot, with no channel to ask a clarifying question. Which means a disagreement can never be talked out in the moment, informally, between the two of them or with me. It has to be written down. But that limitation turns out to be a strength. Written disagreement is the only kind that reaches a decision-maker reliably.

In a larger organisation the constraint that bites is different but the shape holds. Where the operator is not the owner, “I read it and it seemed fine” does not transfer to anyone, and neither does a verbal disagreement in a call. Two independent written positions, retained, with a recorded adjudication, is the artifact an auditor can actually use. The governance value is not that the agents disagree. It is that the disagreement leaves a trace.

Where are we going next?

That is the team. One role whose success is measured in what customers get, one whose success is measured in what the system survives, kept apart on purpose, with a human adjudicating what they cannot settle.

Everything else in this series is what happened when that pair met a real production codebase: the quality floor that had to exist before I could stop reading every line, the interrogation gate that stops work starting before the plan survives scrutiny, the review gates, and the slow, evidence-driven business of deciding how much autonomy to hand over.

It started, though, with a much simpler realisation. I had built a team of specialists who all wanted the same thing, and called it a review process. What I actually needed was someone in the room whose job was to disagree with me.