In my last note I let a language model loose among our bounded contexts and watched it trample the borders we had drawn. One might think I am against the thing. I am not. I am against giving it the wrong part. So, this plot is the companion to that one: not what AI does to our models, but which role we should hand it in the work itself.
As usual, let me begin with a borrowed framing one I came across recently and liked enough to argue with. It ran, roughly, like this. There are three ways to put AI to work in solution architecture. You can have it design the architecture for you. You can have it help the architect document the design. Or you can have it help the review board judge the design. And stacked on top of that, a second question: should the agent be a rules engine, rigid and deterministic, or a free generator, given loose guidance and left to improvise?
Review Board is a loan concept which is not necessarily valid in all the organizations but based on TOGAF the need for that is crystal clear. It can be a one man show!
Plot 1 - The Question We Asked Last
My first objection is about order, not content. The framing lists the three tools first, and arrives (almost as an afterthought, at the very end) at the only question that truly matters: what problem are you actually trying to solve?
That is backwards. Naming the tool before naming the wound is choosing a costume before you know the play.
So let me name the wound, because in most shops it is one wound wearing three masks:
- The architecture documents arriving at review are uneven.
- The reviewers are stretched thin.
- And the whole review cycle takes too long.
Three complaints but pull the thread and they are mostly one. A weak document is what makes the review slow; the reviewer burns their hours catching what the author should have caught. Repair what arrives, and reviewer load and cycle time fall out of the same fix. Once you see that, the question is no longer "which of the three tools," but "where do I intervene to move all three at once." Hold that thought; we will need it shortly.
Plot 2 - Three Parts, Ranked by How Much Can Go Wrong
Now, the three roles. The borrowed framing listed them boldest first (the machine that designs). I want to list them the other way, by how much damage each can do if it misbehaves, because that, and not ambition, is how you should choose where to begin.
The Critic
An agent that helps the review board review. Lowest risk, clearest ground truth. The board still decides; the machine only surfaces, flags, and drafts. If it is wrong, a human catches it in the room. This is the safest part in the house.
The Scribe
An agent that helps the architect write the document. A little more exposure (it shapes the artifact itself) but the architect remains the author and the editor. A good scribe produces better documents; that is the entire point.
The Playwright
An agent that designs the architecture outright. The most thrilling option on the page, and the wrong place to start. The original framing said the quiet part aloud: with such a tool "you wouldn't need architects, except to add judgement." Read that again. It treats judgement as the leftover ; the scrap remaining after the machine does the real work. It is exactly the reverse. The compressible part of architecture, the part a machine handles well, is the easy fifth: does it follow the template, does it cite the standards. The value lives in the judgement about trade-offs, about context, about the things nobody wrote down. A tool that frames judgement as the residue sets the wrong ambition before a single line of code is written.
So far this looks like a simple ranking: start with the Critic, then the Scribe, leave the Playwright for a braver year. But there is a better move hiding here, and it is the reason I bothered with Plot 1.
Build the Scribe so that it holds up the Critic's lens. Take the very criteria the board reviews against and put them in front of the architect while the document is being written, not after it is filed. The author gets the review before the review. By the time the document reaches the board, it has already been held to the standard the board would have held it to. One intervention. All three wounds. The Scribe and the Critic turn out to be the same tool, pointed upstream.
Plot 3 - Script or Improv?
That leaves the second question: rigid rules, or free generation? The framing offered them as a fork in the road. They are not a fork. They are two layers of the same stage direction.
Underneath, a fixed script. Is every mandatory section present? Is the data classification declared? Are the required standards cited? These are pass or fail, and no model should be deciding whether a mandatory section may be skipped. That layer is a gate, and gates do not improvise.
On top, improvisation. Is this the right pattern for this context? Are the trade-offs argued, or merely asserted? Have the quiet requirements been addressed, or dropped where no one would look? Here the machine reasons and suggests. It hands the architect a sharper question, not a verdict.
A small aside while we are here, since the borrowed framing leaned on the word. It spoke of "training" the agent on the template, the standards, the house rules. In practice you rarely train the actor at all. You hand it the script and the standards and let it read from them in the moment. The distinction is not pedantic: a team that goes hunting for a training problem will spend months solving one that was never there.
Plot 4 - The One Line It Can Never Speak
Whatever part we give the machine, there is a single line it can never speak: its own name on the playbill.
The architect stays the author. The board stays the decision. The agent signs nothing and owns no outcome. The morning a tool writes the design, and a person merely rubber stamps it, we have not saved any effort, we have quietly moved an accountable decision onto a thing that cannot be accountable and dressed the move up as efficiency.
Two traps sit close to this line.
- The first: if the same machine that writes the design is also the one that reviews it, the two will always agree, because they share a mind, and the human reviewer will slowly stop looking. The same lens shifted upstream for the author is good design. The same lens closing a loop with no human inside it is a quiet disaster.
- The second trap is gentler. How do you even know your Critic is any good? Its ground truth sits in plain sight; the board's own record of what passed and what did not. If you cannot point the agent at that record, you are not measuring it. You are trusting it.
The Denouement
So, which part for the machine? Give it the Critic's eye and the Scribe's hand, fused and pointed upstream, and keep the lead role (and the signature) human. Earn the Playwright later, if ever, by proving the smaller parts first. That is not timidity. It is the same discipline we apply to any actor we do not yet trust with the closing scene.
Business before architecture, still. And judgement before automation because the moment we forget which of those is the residue of the other, we have miscast the whole production.
I will leave the harder question "how you actually evaluate one of these agents over time and keep it honest as the standards drift beneath it?" for another plot. Another story for another day.
Let's Summarize
- Name the problem before the tool. Weak documents, tired reviewers and slow cycles are usually one wound, not three.
- Rank the roles by blast radius, not ambition: the Critic and the Scribe first, the autonomous Playwright last.
- The best move fuses Critic and Scribe, put the review lens in front of the author, before submission. One intervention moves all three.
- Rules versus generation is a false choice. A deterministic gate underneath, generative judgement on top.
- The machine never signs the playbill. Keep accountability human, avoid the closed review loop, and measure the agent against the board's own history.
...and some references
Written across a couple of sittings, as ever; correct me if I have misremembered a debt.
The borrowed three-part framing that set this note in motion (paraphrased; Gideon Slifkin)
Martin Fowler - architecture as the business of decisions, and eliminating irreversibility
Gregor Hohpe - The Software Architect Elevator
My companion plot, The Stranger Who Speaks Every Language, on what the same machines do to our bounded contexts
Cheers,
Mohammad Malekmakan
Disclaimer:
All opinions and content published in my blog and my social networks are solely my own, not those of my employer(s) and the communities I am contributing in.