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 also risks scope drift, higher AI token consumption and costs, removes a creative human touch-point, and an opportunity for non-developers to learn more about development frameworks and CI/CD processes.

For my consulting business, I took a different approach. My architecture runs one accountable agent per workstream, 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. I have since added parallel agents and concurrent sessions to the environment, and I explain below how that differs from an org chart of role agents.

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 effectively collapses.

Human Domain Expertise and Creative Input

I've discovered along the way that during the design and development processes, my original vision changes. I'm a visual and experiential learner, and I'm making many changes during the AI-enabled design and implementation process. Anyone who has managed a project knows that scope always creeps as we move from hypothetical to reality. Things I didn't anticipate (and the AI design phase didn't anticipate) come up and have to be dealt with. Or the envisioned workflow can be improved and optimized through changes in the design scope.

One example: I used LucidChart to map an enterprise cross-functional sales process and customer lifecycle from MQL>SQL>Opportunity>Close>Delivery>Success. Laid out in a flow chart, there are 100 steps in the sales process. When i went to implement that in my CRM, I found that the process could be clustered and reduced by 20% around key customer interactions, with 47 automated Tasks split between Sales and Partner/Internal Professional Services, leaving 26 customer-driven decision points in the process - the sales-visible process is now 74% smaller.

During the design phase, I rationalized every step in the process interactively with Claude Code so that it could query my CRM directly to check the ability to implement each decision. If left to an automated agent-run process without me as a domain expert validating every decision, the final product would certainly have drifted from reality, and the optimization may never have happened.

Learning

One of my objectives when using Claude Code and CoWork for development was to learn and understand more about modern software development processes at the developer level. That will happen over time: I've set aside one hour a week to learn about the methods, processes, technologies, and architectural decisions that Claude Code has implemented for my environment.

I had enough experience over 44 years of work in the tech sector to know that I wanted

• Robust cybersecurity with a continuous loop of assessment during development and post-deployment
• An audit trail and rollback mechanism for changes that the AI makes to any environment it touches
• Git repositories for CI/CD, version control, code storage, documentation, changelogs, specifications, and an additional code review process outside of Claude Code
• Containerization to reduce the risks associated with running a local dev environment on my Mac laptop
• Secure access control (Apple Keychain, Microsoft Entra)
• Integration and orchestration between all of my business productivity tools, data analytics platforms, CRM, and my local Mac filesystem

The knowledge I've gained just by making decisions during the integration and development processes and staying involved in each step has been enormous. I feel that it is critical that I know what the AI is doing, and why.

Runaway Costs

An analysis by Claude of the last 30 days of my work showed that 12.6% of my prompts are "brakes": corrective or scope-limit language. The key question: "Do my low-supervision sessions (the closest thing I have to autonomous agent-managed activities) actually cost more per unit of delivered work?"

The autonomous stretch preceding a brake was 811K tokens: statistically indistinguishable from the 911K preceding an ordinary prompt. Drift doesn't announce itself. You don't catch it because it looks bad; you catch it because you look regularly. That suggests that that supervision frequency, not supervision quality, is what bounds scope.

The upside of agentic AI autonomous development

1. I'm paying each prompt for the AI to re-read caches, not for thinking. 97% of my 4.57B tokens are cache reads. Think of it as re-reading the entire case binder before answering each new question: the answer is cheap, the re-reads are costly.
2. Human gates have a measurable floor cost. My prompts and the turns answering them accounted for about 12% of the month, at a median of 324K tokens of context re-read per answer.
3. Agent work runs in far cheaper contexts. My subagent turns carry a median 54K context vs 280K on the main thread: 5.2× cheaper per prompt, because a subagent starts fresh instead of inheriting the whole session.

A turn late in a long session costs roughly 8× a turn early on, because it re-reads everything before it. That makes the total cost of a session grow with the square of its length, so anything that shortens the main thread pays off disproportionately, and the same holds for late-stage rework caused by agent drift. I measured that effect in detail in Part 2 of this series.

The upside of human-in-loop + AI assisted development

The human-in-loop and autonomous agent effects pull in opposite directions:

• Autonomy saves: Moving a 20-turn exploration block out of a mature main thread (~400K/turn ≈ 8M) into a subagent (~60K/turn ≈ 1.2M) is roughly 6× cheaper and it spares every later turn from carrying those 20 turns forever.
• Human-in-loop also saves: My manual QA gate costs ~324K tokens. A three-reviewer agent panel would cost ~1.5 to 2M (modelled, not observed: I have not run one). That autonomous agent review panel costs ~5× more expensive per gate, because I would then be paying tokens for judgment I currently supply for free.

But that doesn't factor in the cost of scope drift.

The Value of Continuous Creative Input

In the previous section, I described a 74% reduction in manually managed processes. These opportunities would not have surfaced without a domain expert in the loop. The deliverable on this project provided for a fully-integrated and automated sales process in Microsoft Dynamics 365 CRM that guides a company's revenue generating activities. The dollar value of the optimization is realized immediately and compounds over time.

The Argument for Human-in-Loop Arbitration

I'm not arguing to "keep a human in the loop for everything." The two things separate cleanly and the numbers are clear:

• Intent arbitration is cheap and only humans can do it. A brake costs ~324K tokens and one moment of my attention. It's the highest-leverage token I spend.
• Execution arbitration is expensive and agents do it fine. Delegating a work block to a subagent runs ~5.2× cheaper because it doesn't inherit your 280K-token main thread. But a human has to make the decision when this happens.
• The value of human creativity and domain expertise in the design and development cycle has a significant impact on the implementation of the AI-assisted work. A 74% reduction in manual touches in a sales process has far more value than any value that might be gained through autonomous agent-governed development.

The human-in-loop is a critical cost-control and business value mechanism in agentic AI development.

What I Run

The architectural diagram is somewhat complex. I provide a simpler explanation below in a prettified interactive diagram below. But the diagram I maintain in my Git repo is this:

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 and the outputs are identical in both worlds. The work does not change. What changes is the top and the bottom: how the work is divided, who directs it, and who is allowed to say no and when. Both tops now run work in parallel. On the left, the work is divided by scope and every lane ends at me. On the right, it is divided by role and passes from agent to agent. That difference is my whole argument.

Running agents in parallel did not require Roles

Since first publishing this piece, I have added two kinds of parallelism to my environment: several agents working inside one Claude Code session, and several sessions working at the same time. Neither one assigns roles, and that difference changes how errors travel.

A role-based framework divides work by function and runs it in series. The product agent's output becomes the developer agent's input, which becomes the QA agent's input, and each handoff is a hop with no human at the seam. That is the chain the pⁿ arithmetic above describes. My parallel work is divided by scope instead. Each lane covers its own slice of the work, no lane consumes another lane's output, and every lane returns to a single writer and then to me. Each lane is one hop long, so an error in one lane has no chain of later agents to compound through.

Inside a session: read-only agents and one writer

When a question can only be answered by sweeping a large set of records or files, and that set divides cleanly into separate parts, the session I am working in sends out several agents at once, each assigned one part to read. The rules are fixed:

• The agents only read. The main session is the only writer.
• Each agent gets a named scope that does not overlap the others.
• Each is briefed to try to refute the working assumption rather than confirm it, and to report how much it checked (1,290 of 1,290 workflows, for example) rather than an impression.
• No agent recommends a fix. Agents return findings, and decisions stay with me.

I have run this model three times, with eight agents in total. Containment held on every run: no agent wrote anything, and its findings could safely drive the main session's changes. The adversarial briefing earned its place on one occasion, when an agent disproved a count the main session had already recorded as a correction.

The more useful finding is what the agents did not catch. Across the two runs where I counted, the main session made seven substantive errors. The agents caught one, the session caught one of its own, and I caught five. Agents catch errors inside the question they are given. In three runs they have never caught a wrong premise, because each agent is briefed by the session that holds the premise and inherits its framing. When the question itself was wrong, a well executed agent returned a correct answer to it. Both times, the correction came from outside the system: once from asking to see the underlying records listed, and once from opening the email as it was actually received.

I have no baseline for what the same work would cost single threaded, so I make no claim that fanning out is cheaper or faster. What it provides is coverage: a large, known scope checked thoroughly. Deciding which scope to check remains my job.

Across sessions: ownership is settled by asking

On a typical working day several sessions run at once, each on its own workstream: one on the CRM sales process, one on the website, one on analysis. Each has one task, one handoff record and one branch of the code repository, in its own working copy. No orchestrator sits above them. When a session needs a shared resource that another session holds, such as a file, a status board or a CRM record, it has to message the holder and come away with one of two outcomes: ownership, or the holder's concurrence that it keeps ownership, which the session then reports to me by name. When two sessions have both changed the same artifact, the rule is to re-read, merge and republish, and never to overwrite.

A check at the start of a session describes the state at the start and nothing after it, so these rules hold for the whole session. Each session works in its own copy of the repository, so no other session can move its branch. It confirms what actually landed before reporting a commit, and it re-reads a record immediately before stating what it contains.

My role does not shrink as the number of sessions grows. I decide when a workstream forks into a session of its own, and no session merges its own changes: opening a pull request is where a session's work ends, and the merge waits for my direction.

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 per workstream plus my domain expertise and 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 while controlling each process. 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 now borrow two of them without the roles: parallel throughput, through read-only agents and concurrent sessions, and independent review, through agents briefed to refute the main session's work. The section above shows where the second one stops: independent agents catch errors within the question they are asked, and I still catch most of the rest.

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 still scales with my attention: I am the bottleneck by design. Parallel sessions and agents raised it, but every lane ends at my review, so the number of lanes I can run is the number I can review with care. Concurrency also adds overhead of its own: sessions have to look for one another, settle ownership of shared resources and confirm their own work landed before reporting it. Independent design and review is a habit I have to run, not a structure that runs itself. That is why every session now has to state at the start whether it will fan out. 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 domain expertise and human judgment where it can drive value, keeps a clean audit trail, and never mistakes activity for assurance.