My AI architecture is deliberately simple. Four decades of technology commercialization domain experience is the reason it works.

There is a dubious pattern making the rounds among AI “vibe coders”: stand up a team of autonomous agents, assign each one a role – a product manager, a developer, a DevSecOps engineer, a QA lead – and let them hand work back and forth like a software organization in miniature. It is an impressive thing to watch. It is also, in most cases, an elaborate answer to the wrong question.

For my consulting business, I took a different approach. My architecture runs on a single capable agent, with me accountable at every gate, implementing a durable trail of artifacts:

• An append-only change log
• A curated backlog
• Explicit permission tiers
• Reviewed drafts that reach production only through a controlled pipeline

No simulated committee. No agents role-playing. No compounded scope drift.Here I'll explain why that choice is deliberate, what it costs me, and why domain expertise is the reason it holds.

Multi-Agent Scope Drift

Large Language Models (LLMs) are not deterministic: they are probabilistic. This means that they have a probability of being correct, but not a certainty of being correct.

In this way, a multi-agent framework is fragile as each small error in judgement that is not corrected by a human can compound over time, and increase exponentially with the size of the project.

Every handoff between agents carries a small loss: a requirement slightly misread, an assumption quietly added, a corner interpreted rather than confirmed. Because no human sits at the seam to catch it, those small losses compound. The dev agent optimizes against the product agent's not-quite-right output; the QA agent signs off against the dev agent's; and with each pass the work drifts a little further from the brief that started it.

There is no single moment where it visibly breaks. It simply accumulates errors the way a game of telephone does, until what ships is a confident, internally consistent answer to a question no one actually asked. In a system with one accountable operator, that drift gets caught at the gate. In an org chart of agents, the drift becomes the product.

When each agent treats the previous agent's output as ground truth (no re-grounding to the brief, no human gate), errors stop adding and start multiplying.

The cleanest way to see it: if each hop stays on-brief with probability p, the whole chain is correct with probability pⁿ. That's geometric decay. At p = 0.95 per hop, ten hops is 0.95¹⁰ ≈ 60%; twenty hops ≈ 36%. Confidence doesn't decline: it collapses.

What I Run

My system is simple by design:

A set of scheduled automations does the recurring work: a federal-grant monitor tracking nine programs for a Smart City client, a weekly SEO report, daily analytics, a monthly site-health audit, a sales-intelligence pipeline that maps enrichment data into my CRM. A handful of live-data connectors let me query my own analytics and search performance in plain language. My documents live cloud-native, secured within my Microsoft Entra environment, controlled by governance documents in GitHub, mirrored to Microsoft OneDrive, and not trapped on my local machine.

What matters is not the parts. It is the disciplines wrapped around them:

Every consequential action passes a permission gate: allow, ask, or deny. Every change lands in a log I can audit and roll back. Nothing publishes to my website because an agent decided it was ready; it publishes because I reviewed the draft and released it. The architecture externalizes artifacts and controls – not roles.

Here is my environment on one page, and beside it, the same environment translated into the multi-agent org popular with vibe coders. I had it diagrammed both ways so the comparison is easy to understand.

Look at the band in the middle.

The connectors, the scheduled automations, the state repositories, the outputs – identical in both worlds. The work does not change. What changes is only the top and the bottom: who directs the work, and who is allowed to say no and when. That single difference is my whole argument.

Why the simple design works – for me

A multi-agent “org chart” is an attempt to simulate the cross-functional judgment of a seasoned operating team: the product instinct, the security reflex, the QA skepticism, the deployment caution. I spent a quarter-century being that judgment.

For 25 years as a VP of Sales and CRO, I have often been a human check-point across product management, development, DevSecOps, and professional services: the person accountable for turning what those teams built into revenue and keeping it defensible. In one case, I was one of five senior managers on the cybersecurity response team that handled repeated public disclosures against our platform: mitigation, customer messaging, DMCA enforcement, all at once, all under fire. I have sat at that table, with revenue and reputation genuinely on the line. I don't need an agent to play the "skeptic in the room" because I have been in the room helping solve these problems and representing customers' interests.

That is why one disciplined agent plus my oversight outperforms four agents pretending to be a team. The scarce ingredient in this work was never more agents. It was judgment about which output to trust, challenge, or kill. This architecture is built to give my judgment clean leverage, not to replace it.

The honest trade-offs

Where the multi-agent framework genuinely wins: It buys parallel throughput. You can fan work across many agents at once. It forces separation-of-concerns artifacts to exist. And an agent reviewing work it did not write catches more than an author grading its own paper. Those are real benefits, and I borrow the last one deliberately: I run an independent review pass on anything that matters.

Where it quietly fails: Four agents built on the same underlying model are not a cross-functional team; they are one mind wearing four hats.

When that mind is confidently wrong, all four hats are wrong together, and the pipeline hands you five approvals that cleared, in truth, zero independent gates.

That is not rigor. It is the theater of rigor, and it is most dangerous precisely for a builder who lacks the domain experience to notice when the “team” has talked itself into a mistake. It also provides no real control: a single agent orchestrator drives every agent, so there is no independent actor who cannot be overruled until significant drift has already occurred.

Separation of duties that no one can enforce is not a control. It is set dressing. The shared band in the diagram is the tell: the work is identical in both worlds, so the only thing the org chart can add is governance: and its governance cannot enforce a "No".

Where my design pays for its simplicity. My model has costs too, and I will name them.

Throughput scales with my attention: I am the bottleneck by design. Independent design and review is a habit I have to run, not a structure that runs itself. And my compute still leans on controlled hosts rather than a fully redundant always-on fabric. Those are real limitations. They are also the right limitations for a practice where being auditable, accountable, and correct matters more than being fast.

The part the tooling can't supply

I am an enthusiastic adopter of agentic AI. It is woven through how I and my clients work now, and it makes me faster than teams several times my size. But I have watched enough technology cycles to know the difference between a tool that amplifies judgment and a tool that masks its absence.

The org-chart-of-agents is often the second thing: a way to look like a disciplined operating team without having led one.

My architecture makes the opposite bet – that the durable advantage is the judgment you bring to the system, and the best design is the one that puts that judgment where it counts, keeps a clean audit trail, and never mistakes activity for assurance. That is the same balance I have always managed toward: rigorous, data-driven controls, paired with the human accountability that decides what is actually true.

You cannot prompt your way to that.