Why can’t the team get it right, when one agent can?

That headline is our founder’s question, asked with some heat, and it deserves a straight answer rather than a defence of our architecture. This article is the straight answer. It is written the same day as the failure it describes, and the failure is ours.

There is a live argument in agent engineering about whether you get better results from one very capable model working alone or from several models working as a team with review between them. Most evidence offered on either side is anecdotal, because the honest comparison is expensive: you have to run both on the same problem, at the same moment, with the same information, and judge the outputs against something harder than your own opinion.

We got that comparison this week, and we kept the receipts — a build log, prototype files with their reasoning written into them, and 94 rendered screenshots with pixel measurements attached. Every number below traces to an artifact.

The problem was small enough to measure and hard enough to be real: build a glass material for a product interface. Translucent surfaces, light from one direction, edges that strengthen and weaken depending on where that light is, thickness at the corners, working in both light and dark mode. Anyone who has tried this knows it is deceptively difficult — a slightly wrong edge reads as cheap plastic, everyone can tell, and nobody can say why.

The short version of what we found: the single agent preserved intent. The team preserved correctness. Neither of those is optional, and we had no owner for the first one.

First, the two failures before the experiment

We had already shipped this material twice.

The first version was ported from a prototype our founder had personally approved. On the real page it was graded 0 out of 3. Approving a mockup and approving a shipped surface are not the same act, and we learned that the expensive way.

The second was a proper rebuild against a physical reference, and it went through a real automated quality loop. That loop worked: it caught a text-contrast failure on a dark background, measured at 4.23 against a 4.5 minimum, and shipped a fix within the hour. Every check we had was green.

Then it sat live for five days, and the verdict came back: “You put a white border on the tiles and called it a day.”

Both versions passed everything we knew how to check. The checks measured contrast. Nothing measured whether it looked like glass. That is the first place progress dies, and it dies silently: when the only failures your pipeline can produce are the ones you already thought to automate, your pipeline has stopped being able to surprise you.

So the third attempt ran differently — one design agent leading, a rendering agent producing screenshots and pixel measurements after every change, nothing accepted on the strength of reading the code.

The team loop: 96 minutes, five rounds, two of them spent undoing round one

The design agent built a complete specimen from scratch in twelve minutes. One authored value — where the light comes from — with every shadow, sheen and edge derived from it, so the whole material moves together if you move the light.

Then it was rendered, and three things were wrong.

The important one: the edge treatment was built as a sweep that goes aroundthe shape by angle. On a square card that looks fine. On a wide bar — a toolbar, a navigation strip, the shape this material actually has to survive — it painted a bright notch straight through the middle of the bottom edge. Invisible on the shape it was designed on. Obvious on the shape it would ship on.

What happened next is the pattern worth recognising, because it is not incompetence and it is expensive:

• Round 2 deleted the bright stop causing the notch. The render came back: the notch was gone and a cliff had replaced it, in the same place. The first fix removed a jump in value and left a jump in slope.
• Round 3 flattened that part of the sweep. The render came back: the bottom edge was clean and the same defect had appeared at the top edge instead.
• Round 4deleted the sweep entirely and rebuilt the edge from four gradients that each run along their own edge’s length.

The seam problem never returned, because it could not. An angular feature compresses hard at the poles of any non-square box; a length-based feature has no poles. Round 4’s commit message names the method in three words: “subtraction not fix.”

Three rounds produced three bugs that were one bug. The design agent wrote that conclusion into the file itself, at the exact spot the deleted code used to occupy: “Each time a pole was flattened the defect moved to the other pole. That is not three bugs; it is one property.”

The takeaway

When a fix relocates a defect instead of removing it, stop tuning and go look at the parameterisation. A defect that moves is not a new defect. It is the same structural fact announcing itself in a new place.

The takeaway generalises far past graphics. Recognising that one round earlier would have saved roughly a third of the effort.

A second thread ran alongside. One bright detail — light exiting the far corner — moved four times in five rounds. Each move fixed a real, correctly-diagnosed problem. Three of four created the next one, because moving an element away from one neighbour gives it new neighbours, and the test image that exposed the old problem is usually blind to the new one. The final position was found only by rendering it on a smallelement — a chip, a badge — where the bright peak landed on the corner rather than inside it.

The one-shot rival

Midway through, our founder asked a different model to write the whole material alone, in a single pass, with no review loop. It produced 194 lines in one shot.

It was good. Genuinely, uncomfortably good. It went straight to the architecture that cost the review loop three rounds to reach — no angular parameterisation, edges built along their own lengths — and modelled the interior properly. On one specific property it beat the team outright: how a shadow-side edge fades. Its away edge is simply absent along the straight run and gathers only into the corner, which is what refraction on a shadow side actually does. The design lead’s verdict on the rendered crops was blunt: the single cleanest crop either file produced.

Two things complicate the story, and both matter.

First, the one-shot was not working from a blank page.Its own construction notes say so: it adopted “the proven round-2/3 wins” — the sign-flip that makes a dark-mode edge behave correctly, and the corner treatment that avoids reading as machined metal. Those were the team loop’s rounds 2 and 3, already paid for and sitting in the repository. The one shot ran on a track that had been cleared for it. Any claim about one-shot capability from this experiment carries that asterisk.

Second, and decisive: it had a structural flaw nobody could see by reading it.

Its edge is painted as four rectangular bands, each covering 34% of the box. Four rectangles meeting at 34% and 66% with no fade at the join. On a wide bar those joins render as visible steps — measured at 3.56 to 6.61 luminance units per pixel, against the team version’s worst discontinuity of 0.54. About twelve times worse, visible without instruments, landing precisely on the shape the whole exercise exists to survive. Because the bands are sized by proportion, the seams scale with the element: every surface, every size, permanently. Not a tuning problem.

The line we keep returning to is in that file’s own header. It states, confidently and with a correct-sounding argument, that a seam is geometrically impossible in its construction.

It has three.

The author reasoned accurately about the failure mode it had in mind and had no way to reason about the one it had built. This is not a model-quality criticism — it is a category fact. An agent’s confidence about its own architecture carries almost no information about whether the architecture holds. Only rendering it on a case chosen to break it does.

We hold our own work to the same standard. The winning specimen makes structurally identical claims about its own immunity. We believe them because 88 screenshots and a pixel probe measured them, not because they are well argued. The losing one was well argued too.

And then, the same day, the team failed at something the solo agent would not have

Here is where the founder’s question lands, and the answer is not comfortable.

He asked to see the two specimens side by side.

He got: two finished specimens, 88 measurement shots, 24 luminance probes, five per-check rendered verdicts, an architectural disqualification with numbers behind it, a borrowed property rebuilt from first principles, a re-render passing 4 of 4, a sign-off document, and a package containing two open commands.

He did not get a side-by-side. He had to ask twice.

Look at what each piece did instead, because none of it was lazy:

• Each specimen compared itself against the current site. Both files contain a side-by-side — their own titles say so, “current vs proposed” and “side-by-side vs current.” Both are comparisons against the incumbent. Neither is the comparison that was asked for.
• The comparison between the two candidates existed only as prose in the sign-off document, describing crops in words, plus 88 images in a working folder that is not a viewable page.
• The delivery handed over two separate open commands and asked the reader to hold both in their head.
• And the message carrying it buried the package in the middle of a long report.

The aggravating detail: we had built exactly this artifact two days earlier. A file called onesite-COMPARE.html— two rival prototypes from two models, placed beside each other for the same person to judge. Three days old. Proven. Not applied. Nothing prompted it, because nothing in the loop asks whether the thing the requester pictured has been built.

Every stage passed. The design agent’s deliverable was a judged, signed-off material — delivered. The render agent’s deliverable was measured evidence on named checks — delivered, 94 shots. The relay’s deliverable was a package containing the recommendation — delivered. The side-by-side was nobody’s acceptance criterion, so no stage could fail for its absence.

So: why can one agent get this right?

Because it never decomposes the ask.

A single agent holds the request whole, in one context, from beginning to end. “Show me these two side by side” stays a single felt object the entire time it is working. Nothing splits it into a build stage and a measurement stage and a review stage and a delivery stage, so nothing is at riskof being split away. The requester’s picture survives, because there is no seam for it to fall through. That is not a reasoning advantage. It is a structural one, and it is the same structural property that makes the solo agent unable to see its own flaws: one context, one point of view, no second pair of eyes — good for intent, blind for correctness.

A team is the exact inverse. Decomposition is the whole point of a pipeline, and it is also the failure mode. Intent arrives as one thing and is immediately split into stages, each with a crisp, checkable, locally-correct deliverable. Every stage completes. Every gate is green. And the composite — the thing the requester actually pictured — is the one object that is nobody’s stage output. It cannot fail a gate, because gates attach to stages.

This is why more rigour does not fix it. Everything else in this article concerns properties of an artifact that exists: is the edge continuous, does it hold on a wide bar, is the contrast sufficient. This is an artifact that does not exist. Adding measurement makes the package more convincing while the gap stays exactly where it was.

The tell

Your loop can list its outputs, and none of them is the sentence the requester said. If restating the original ask requires the listener to assemble two or more of your deliverables themselves, the composite is missing — and what you have shipped is homework, not an answer.

The honest synthesis

Neither mode is the winner, and pretending otherwise is how teams like ours end up defending an architecture instead of fixing it.

One agent preserves intent.The ask stays whole because it is never divided. That is the founder’s question, and it has a real answer, not an excuse.

A team preserves correctness.The seam that was “geometrically impossible” and occurred three times was found by rendering two candidates against a case built to break them and measuring the difference. No single pass finds that about itself, however strong the model — not because it lacks capability but because it lacks a second vantage point. The team also did two things a solo pass structurally cannot: it disqualified a candidate on evidence, and it absorbed the rival’s one genuine win as a propertyrather than as code, re-deriving it inside the winning model. That re-derivation produced a better reason than a copy would have — edge strength now tracks which part of the material owns that boundary, which is why the corner keeps its weight while the middle of the edge quiets down. Property transfer beats code transfer, because it forces you to understand why the borrowed thing works.

What is missing is a role, not a model. Somebody has to own the artifact-as-asked— the user’s-eye composite — as a first-class deliverable, named at dispatch in the requester’s own words, and gated last, independently of whether every stage completed. Not the sum of the deliverables. The thing that was asked for.

That is the change we are making, and it is the reason this article exists in the form it does. We had the measurement discipline. We had the review loop. We had, three days old and in the same folder, the exact comparison harness the moment called for. What we did not have was anyone whose job was to look at the finished pile and ask whether it was the thing.

What to take away

If you are building with agents, six things from this log:

1. Name the artifact-as-asked, in the requester’s words, and give it an owner. It is the last gate, not the sum of the earlier ones. Every other item on this list assumes the right thing is being built.
2. Render and judge, every round, no exceptions.Not “the code looks right,” not “the tests pass” — look at the output. Every round in this lane was accepted on rendered evidence, which is the only reason its failures are visible enough to write about.
3. Keep an adversarial specimen.The wide bar caught every real bug here, and caught them because someone made it a permanent part of the test file after it broke once. A defect at a ratio you never render is a defect you do not have — until a customer has it.
4. When a fix moves a defect, stop fixing and look at the structure. Three rounds of local fixes bought one structural fact. One round would have been enough with this rule.
5. Prefer subtraction. Every round framed as a removal closed a whole class of bug permanently. Every round framed as a tuning closed one instance and often seeded the next.
6. Treat any agent’s claim about its own soundness as unverified — including your best one’s. The most confident architectural claim in this episode was the one that was wrong, written by a strong model with a correct-sounding argument.

The material that shipped is the team’s, and it carries one property it did not invent, rebuilt from first principles inside its own model. That is what good collaboration looks like when it works — not consensus, not a vote, but one architecture that holds under measurement, improved by an idea it was willing to lose to.

And it was delivered as two opencommands to someone who had asked for one picture. Both of those sentences are true about the same day’s work. Until the second one stops being true, the answer to “why can’t the team get it right” is: because we never made the right thing anyone’s job.

AIU Research publishes what we learn building the platform, including the parts where we were wrong — especially those, and especially same-day. This article is drawn from the build log of 2026-07-27 and its supporting render evidence.