Multi-Agent Spec Writing: Specialist Agents, Conflict Detection, and Human Escalation on AgentCore

In an earlier post I wrapped a single robot as a tool and let one agent drive it. One agent, one job, one loop. That is the easy shape of agentic AI, and most of what people call “multi-agent” is really that same shape run several times in parallel with the outputs stapled together at the end.

This post is about the harder shape: several specialist agents that each produce a piece of a single deliverable and then have to agree with each other. Not run in parallel and get concatenated. Agree. And when they cannot agree, the interesting question is what the system does next.

I built one of these to write construction specifications, and the part that turned out to matter was not the writing. It was the disagreement.

The Problem Is Not Writing, It Is Coherence

Take a construction specification for a mid-rise residential building. Break it down by trade and you get four fairly independent bodies of knowledge: the foundation, the walls, the floors, the roof. Each one has its own codes, its own materials, its own constraints. A specialist in one is rarely a specialist in all four.

So the naive design is obvious. Spin up four agents, one per trade, give each the project brief and its own knowledge base, and let each write its section. Foundation agent writes the foundation section. Roofing agent writes the roofing section. Staple the four sections into one document. Done.

That produces a document. It does not produce a specification, because a specification has to be internally consistent. The load the roof agent assumes is carried has to be a load the wall agent actually designed for, which has to be a load the foundation agent actually planned to bear. Each section can be individually correct and the assembled document still be structurally incoherent. The failure lives in the seams, not in the sections.

This is the thing a single-pass, run-in-parallel design cannot catch. Each agent is right within its own scope. Nobody owns the seam.

The Split: Specialists Write, an Orchestrator Reconciles

The design that works separates two responsibilities that the naive version conflates: producing content, and reconciling content.

Each specialist agent owns one trade. It reads the brief, queries its own knowledge sources, and produces its section plus, crucially, the assumptions it made about the other trades. The foundation agent does not just say “here is the foundation.” It says “here is the foundation, and I assumed a total building load of X.”

An orchestrator sits above them. Its job is not to write anything. Its job is to read every specialist’s output, extract the cross-trade assumptions, and check them against each other. The roof agent assumed the walls carry a certain load. Does the wall agent’s output actually support that load? If yes, the sections are coherent and the orchestrator assembles the specification. If no, the orchestrator has found a conflict, and that is where the design earns its complexity.

                    +--------------------+
                    |   Project Brief    |
                    +---------+----------+
                              |
                    +---------v----------+
                    |    Orchestrator    |
                    |  (fan out, then    |
                    |   reconcile)       |
                    +--+----+----+----+--+
                       |    |    |    |
        +--------------+    |    |    +--------------+
        |         +---------+    +--------+          |
        v         v                       v          v
  +----------+ +----------+        +----------+ +----------+
  |Foundation| | Walling  |        | Flooring | | Roofing  |
  | agent    | | agent    |        | agent    | | agent    |
  +----+-----+ +----+-----+        +----+-----+ +----+-----+
       |            |                   |            |
       | section +  | section +         | section +  | section +
       | assumptions| assumptions       | assumptions| assumptions
       +------------+---------+---------+------------+
                              |
                    +---------v----------+
                    |  Conflict Detector |
                    |  (compare cross-   |
                    |   trade assumptions)|
                    +---------+----------+
                              |
                  conflict?   |   no conflict
              +---------------+---------------+
              v                               v
       +-------------+                 +--------------+
       | Human       |                 | Assemble     |
       | arbitration |                 | specification|
       | (HITL)      |                 +--------------+
       +------+------+
              | decision
              v
       resume + re-reconcile

The specialists run on Bedrock AgentCore, each as its own agent with its own instructions and its own knowledge sources, built with the Strands Agents SDK. The orchestrator is itself an agent, but a differently-shaped one: its tools are the specialist agents, and its reasoning is about their outputs rather than about construction.

Conflict Detection Is a First-Class Step, Not a Side Effect

The temptation is to fold conflict detection into the assembly step: merge everything, and if something looks wrong, flag it. That is too late and too vague. By the time you are merging prose, the structured assumptions that would let you detect a contradiction have been flattened into sentences.

So I made conflict detection an explicit stage with structured input. Each specialist emits its cross-trade assumptions as data, not prose: what it assumed about loads, dimensions, interfaces, and tolerances that another trade is responsible for. The detector’s only job is to compare these structured claims pairwise and surface contradictions.

This matters because a contradiction between two agents is not an error in either agent. Both the roof agent and the wall agent did their jobs correctly given their inputs. The contradiction is an emergent property of their combination. If you treat it as a bug in one agent, you will “fix” it by overriding one of them, and you will silently ship an incoherent spec. If you treat it as a genuine conflict, you escalate it to someone who can decide which assumption should win.

That distinction, an agent error versus a genuine inter-agent conflict, is the whole reason this architecture exists.

Human-in-the-Loop as Resolution, Not Approval

Most HITL in agentic systems is an approval gate: the agent does its thing, a human clicks approve or reject, the agent proceeds or stops. That is a checkpoint. It treats the human as a brake.

The conflict case needs something different. When the detector finds that two trades disagree on a load-bearing assumption, no agent has the authority to resolve it, because resolving it means making a design trade-off that changes at least one section. That is a judgment call. The human is not approving the agents’ work; the human is supplying a decision the agents structurally cannot make on their own.

So the escalation carries the conflict, not the document. It says: the roof section assumes the walls carry load X; the wall section was designed for load Y; Y is less than X; here are the two options and their downstream effects. The human picks. The orchestrator then feeds that decision back to the affected specialists, they revise, and the orchestrator re-runs reconciliation to confirm the conflict is actually resolved and did not spawn a new one.

That feedback loop, escalate the conflict, get a decision, revise, re-reconcile, is the part that makes this a system rather than a demo. HITL here is a resolution mechanism wired into the control flow, not a modal dialog bolted onto the end.

Why AgentCore Earns Its Place Here

You could build all of this as one big prompt with four “personas” and a self-check. For a toy it would even work. It falls apart for a reason worth naming: shared context contaminates specialist reasoning. When all four trades live in one context window, the wall agent sees the roof agent’s reasoning and quietly conforms to it, which is exactly the coherence you are faking rather than earning. The conflict you most need to catch is the one the model smooths over because it saw both sides in the same breath.

Separate agents on AgentCore give each specialist an isolated runtime and its own knowledge scope. The foundation agent cannot see the roof agent’s chain of thought. It commits to its assumptions independently. That independence is what makes the downstream conflict detection meaningful: two agents that genuinely did not coordinate are the only ones whose agreement tells you anything.

The runtime isolation buys you the operational things too, per-agent scaling, per-agent instructions and knowledge bases, per-agent observability, but the reason that matters most is epistemic. Isolation is what keeps the specialists honest.

What I Would Watch Out For

Two failure modes showed up quickly.

The first is over-decomposition. Four trades is a natural, real boundary in this domain. If I had split into twelve micro-agents, most of the “conflicts” would have been artifacts of the split rather than real design tensions, and the human would drown in trivial arbitration requests. The decomposition has to follow genuine expertise boundaries, not an org chart and not an arbitrary desire for more agents.

The second is under-specified assumptions. Conflict detection is only as good as the assumptions the specialists surface. If an agent makes an implicit assumption and never emits it as structured data, the detector cannot catch the resulting contradiction, and it ships. Getting each specialist to be explicit about what it is assuming about everyone else turned out to be more of the work than getting it to write good content.

An Honest Recommendation

Reach for this pattern only when three things are all true: the work decomposes along real expertise boundaries, the pieces have to be mutually consistent, and the cost of a silent inconsistency is high. Construction specs qualify. So do things like multi-service architecture reviews, contract assembly across legal domains, and integrated financial models where one team’s assumption is another team’s input.

If your task is just “produce four independent things faster,” you do not need any of this. Run four agents in parallel, concatenate, done, and do not pay for an orchestrator and a conflict detector you will never exercise. The entire value of the multi-agent-with-reconciliation shape is in the seams. If your deliverable has no load-bearing seams, skip it.

And when you do build it, spend your effort where the leverage is. It is not in making each specialist write more eloquently. It is in making each specialist declare, out loud and as data, every assumption it is making about the others, and in treating the disagreements that surface as decisions for a human rather than bugs to be auto-resolved. The agents draft. The seams are where the judgment lives, and judgment is still the part worth escalating to a person.