RAG, Swarms and Staying in the Loop — An Architect's Honest Take

Last week I got a comment on my post about AI-assisted development that I’ve been thinking about since. The question was about tooling to enforce architectural process — specifically swarms and smart RAG for surfacing relevant architectural decision records at the right moment.

It’s a sophisticated question from someone who clearly knows the space. And it deserves a genuine answer rather than a theoretical one.

Where I actually am

My process is human-led. Before any building starts, I’m clear on the outcome I want. I have opinions on options and tradeoffs — strong opinions, loosely held — and I use Claude to pressure-test my thinking rather than replace it. When the AI suggests an approach I haven’t considered, I ask it to explain the reasoning before I agree. Once direction is set, Claude Code works autonomously within clearly defined boundaries, tests its own work against criteria agreed in advance, and proves the results before we move on.

That’s not a stepping stone to something more automated. It’s a considered architectural pattern — one where the judgment stays with the architect and the execution is delegated with clear constraints.

On RAG

Retrieval Augmented Generation is the pattern of giving an AI access to a curated knowledge base — documents, decision records, guidelines — and having it retrieve the relevant pieces at the right moment to inform its response, rather than relying solely on what it already knows.

My current document approach is already a manual version of this. CLAUDE.md, architecture documents, data models — these are all context I provide upfront at the start of every session. The AI reads them, orients itself, and works within them. Smart RAG would automate the retrieval of that context selectively, surfacing only what’s relevant to the current task rather than loading everything at once.

The idea of documents that capture architectural taste — preferred patterns, past decisions, rationale — available for retrieval when the AI isn’t certain on a path makes intuitive sense to me. And the escalation pattern the commenter hinted at — surfacing a human when retrieval confidence is low rather than letting the AI guess — isn’t a fallback. It’s good system design. Confidence thresholds and human escalation are patterns that belong in any well-designed agentic system.

Where it gets interesting at enterprise scale

At the scale I’m currently working — focused products, clear scope, one architect in the loop — manual context management is practical and appropriate. The documents are manageable. The decisions are mine to make explicitly.

Where the calculus changes is at enterprise scale. When the system you’re building with AI needs to operate across a mixed landscape — legacy and modern, in-house and vendor, bought and built — the knowledge base becomes too large and too varied to manage manually. The number of relevant ADRs, integration patterns, and architectural constraints across a heterogeneous environment is exactly the kind of complexity that makes automated retrieval necessary rather than optional.

Enterprise architects have always had to manage this. Knowing which decisions, patterns and constraints are relevant in a given context — across a landscape that spans decades of technology choices — is the job. Smart RAG is attempting to replicate that capability automatically. The pattern maps directly onto skills the EA community already has.

On swarms

Swarms — where multiple specialised AI agents collaborate on a task in parallel — I’m watching rather than using. At my current scale they feel like a solution looking for a problem. The overhead of orchestrating agents adds complexity that a single well-briefed AI with clear constraints doesn’t need.

At enterprise scale — where parallel workstreams, specialised domain knowledge, and complex coordination problems are the norm — the case gets stronger. But it’s worth being clear-eyed here: the majority of enterprise multi-agent deployments currently fail, largely because agents lack the architectural context to coordinate effectively. They can coordinate perfectly around incomplete understanding — and that’s worse than no coordination at all.

Which, perhaps unsurprisingly, brings us back to the same problem: context first, coordination second. That’s where my clients may be heading, and it’s why the EA community has a more important role to play in this space than most people currently recognise.

Context engineering

There’s a term emerging for all of this: context engineering. It’s the discipline of deliberately managing what an AI has access to, when, and in what form — and it’s becoming as important as the code itself. It’s not the same as what enterprise architects do, but it draws on the same instincts: knowing which information matters in a given context, defining boundaries, making decisions explicit. The skills transfer. The application is genuinely new.

This series started with a simple observation: that my EA background turned out to be an unexpected advantage in AI-assisted development. The more I explore the space, the more that holds true — and the more I think the EA community has a more important role to play in how organisations adopt agentic AI than most people currently recognise.

More on that in future posts. And thank you to everyone engaging with this series — the comments are genuinely shaping where it goes.