Field Report · Generative AI · Architecture

The Architectural Toolbox for AI Engineers

Six patterns every generative AI engineer should be able to reach for — and know when to leave alone.

By Darren‑Michael Culbreath ~26 min read

Why a Toolbox and Not a Blueprint

Let me start with something most of us in this work already know but rarely say out loud. The hard part was never the model.

The models are extraordinary. They get better on a schedule you can almost set your watch to. The hard part is everything around the model: the retrieval, the routing, the governance, the plumbing that carries context from one place to another, and the operating model that decides who gets to build what. That is where projects live or die. That is where the proof-of-concept that dazzled everyone in the demo quietly fails to survive contact with production.

I have spent many years building systems on AWS, GCP, and Azure. The last several of those years have been specifically about generative AI. In that time, I have watched one pattern repeat itself so often it stopped surprising me. A team grabs a framework, wires up a model, gets a compelling demo, and declares victory. Then the questions start. How do we keep costs from spiraling? How do we swap the model when a better one ships next quarter, and one always ships next quarter? How do we show a regulator what the system actually did? How do we let six business units build on the same foundation without ending up with six stacks that hate each other? None of those questions get answered by the model. They get answered by architecture.

This is a toolbox. Not a blueprint. The difference matters more than it sounds. A blueprint tells you what to build. A toolbox tells you what is available and trusts you to frame your own problem well enough to choose. I kept this to six patterns on purpose, and the six I have seen earn their keep when the stakes were real. There are others. I expect to write about some of them later. But a good craftsperson doesn't carry every tool ever made. They carry the ones they trust.

Each pattern below gets the same treatment. Where it actually came from, because provenance matters and this field is full of confident misattribution. The shape of the problem it solves, because picking an architecture is really an exercise in framing the problem first. How it works, where it breaks, and the part most people skip: when you should not use it at all. Some of the most expensive decisions I have watched were not wrong tools. They were right tools reached for at the wrong time.

One note on method before we start. The most common mistake I see is what I have started calling the third-grade version of AI engineering. Grab something, run it, shout “look at it move.” The answers come back inconsistent, the outputs are unreliable, and the thing is stuck in POC forever. The eleventh-grade version is disciplined and structured, and it starts not with a tool but with a clearly framed problem. So before every pattern, we frame the problem. That is the whole game.

The State of Play

A little grounding first, because architecture choices only make sense against the backdrop of where the field actually sits.

The adoption numbers are big and, if you read them closely, a little sobering. Almost every large organization is doing something with generative AI now. The gap between doing something and getting real value from it remains stubbornly wide. McKinsey's ongoing work on the state of AI has shown that while adoption is close to universal, the share of companies capturing meaningful enterprise-level financial impact is much smaller.[1] Gartner put a number on the fallout. At least 30% of GenAI projects are abandoned after proof of concept, due to poor data quality, weak risk controls, runaway costs, or fuzzy business value.[2] Look one layer down, and it gets worse. On average, only about 48% of AI projects reach production, and the time from prototype to production is about 8 months.[3] Read those two numbers together, and the picture is clear. A lot of demos. Far fewer systems. And the ones that stall rarely stall on the model. They stall on integration. On cost. On governance. On the absence of the exact scaffolding this paper is about.

The center of gravity has also moved. We went from single-model applications to agentic systems, in which models plan, call tools, and coordinate with other models to complete multi-step tasks. The market forecasts for agentic AI are aggressive, and I want to be honest about how much they disagree. The analysts are not close to each other. Grand View, counting only the enterprise slice, puts it around $2.6 billion in 2024, growing to roughly $24 billion by 2030. Precedence and Market.us go much bigger, both landing near $200 billion by the mid-2030s. Fortune Business Insights sits in between, projecting about $139 billion by 2034.[4] Pick your source. That is a spread of nearly 10-to-1, which tells you these are educated guesses dressed up as decimals. The number I would not argue with is the direction. Whatever the true figure, agentic systems are where growth is pointing, and they raise the stakes because now you are not orchestrating a single call to a single model. You are orchestrating many actors, each of which can fail, cost money, and act on the world.

That is the environment. Near-universal adoption, painful production gaps, a fast march toward multi-agent complexity. This is the moment when knowing your patterns stops being academic and starts being the difference between something that ships and a science project.

Now, the toolbox.

Pattern 1

The Agentic Mesh

Best for  scaling many agents across an enterprise without it turning into chaos.

Framing the problem

You reach for a mesh when you have stopped having an agent and started having agents, plural. Built by different teams. Running on different frameworks. Needing to find and work with one another. The problem shape is this: independent agents multiplying faster than any central team can coordinate them, each one its own little silo, each one reinventing identity, logging, and tool access from scratch. If that description makes you wince because it is already happening in your org, you have found a mesh-shaped problem.

The failure this pattern exists to prevent is the integration explosion. When every agent has to be wired directly to every other agent, your connection count grows quadratically with the number of agents, and governance becomes impossible because there is no consistent place to enforce it. A mesh swaps the tangle of point-to-point wiring for a shared fabric.

Provenance, and let's get this right

I want to be careful here, because the term gets thrown around loosely. “Agentic Mesh” is not a peer-reviewed pattern with a canonical paper behind it. The most substantive early write-up I have found is Eric Broda's, who developed a detailed Agentic Mesh concept across a series of widely read practitioner articles, describing the trust, discovery, and marketplace fabric that enable autonomous agents to find and safely work with each other.[5] Big consultancies, including McKinsey's QuantumBlack, have since written a lot about agentic operating models and the mesh-like fabric you need to scale them.[6] The phrase now appears throughout vendor and analyst writing.

So treat Agentic Mesh as an emergent, practitioner-led concept, not a settled standard. That is not a knock on it. Most of the useful patterns in this field started exactly this way. But a paper you are going to publish should say plainly what is established and what is still forming. This one is still forming. Worth knowing when you cite it.

How it works

Strip off the branding and a well-formed mesh has five load-bearing ideas. I use AGENT as the mnemonic because it actually maps:

What makes this newly practical in 2026 is real interoperability. Anthropic's Model Context Protocol gave the industry a common way for models to connect to tools and data,[7] and agent-to-agent protocols are doing the same for agent communication.[8] A mesh with no shared protocols is a slide. A mesh built on standard tool connectivity and standard agent messaging is something you can actually run.

Where it breaks

Meshes fail when teams build the fabric before they have the agents to justify it. I have watched companies stand up elaborate agent infrastructure to coordinate two agents that could have been a single function call. That is the “massive platform when a skill would do” mistake, and it is expensive. A mesh is a coordination technology. If you have nothing to coordinate, you have built overhead and called it architecture. The other failure is governance by good intentions. You called it a mesh, so you assumed the audit and identity story took care of itself. It did not. Those properties have to be engineered into the fabric on purpose, or the decentralization you were so proud of becomes a place where accountability disappears.

When to leave it alone

One to three agents, or a single orchestrator calling a handful of tools? You don't need a mesh. You need a clean, well-instrumented application. Reach for the mesh when the number of independently built agents exceeds the threshold at which central coordination no longer scales. Not one day before.

Pattern 2

Retrieval-Augmented Generation (RAG)

Best for  grounding a model in your own data without retraining it.

Framing the problem

RAG answers one very specific, very common problem: the model is brilliant and ignorant of your facts at the same time. It has never seen your product catalog, your policies, your patient records, your case files. Teaching it those facts through fine-tuning is expensive and slow, and it goes stale the moment your data changes. The problem shape RAG solves is “I need current, proprietary, or fast-moving knowledge in the answer, and I need to point at where it came from.” If your problem includes the words “and it has to trace back to a document,” you are looking at RAG.

Provenance, with one correction worth making

This is the one pattern in the toolbox with an airtight academic pedigree, so let's be exact. Retrieval-Augmented Generation showed up in the 2020 paper “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” led by Patrick Lewis with a large team, published at NeurIPS 2020.[9]

One small correction that trips people up. The work came out of Facebook AI Research (FAIR), together with University College London and NYU. People describe it today as coming from “Meta AI.” In 2020, there was no Meta. Facebook didn't rebrand until late 2021. Minor point. But if you are publishing, get it right, because someone will check. Worth knowing, too, that the retrieval machinery behind modern RAG leans heavily on Dense Passage Retrieval, from a companion line of FAIR work from the same year.[10] And the original paper actually described something tighter than what most people now call RAG. It trained the retriever and generator together. What the industry calls RAG today is usually a looser, inference-time pipeline. That drift is fine and useful. It just means the term has wandered from where it started, and a careful engineer knows the difference.

How it works

The canonical flow is five steps. Naming each one helps:

  1. Query. A user question enters the system.
  2. Retrieve. A search, usually vector similarity and ideally hybrid with keyword search, pulls the most relevant chunks from your knowledge store.
  3. Augment. Those chunks get injected into the model's prompt as context.
  4. Generate. The model answers from the supplied context instead of from its own parametric memory alone.
  5. Cite. The response carries source attribution back to the retrieved documents.

That fifth step is not decoration. Citation is what turns a plausible answer into a defensible one, and in regulated work, it is often the very reason RAG was chosen over fine-tuning in the first place.

Where it breaks

RAG fails in ways worth memorizing, because they are sneaky. The most common one: retrieval failure wearing generation failure's clothes. The model gives a wrong answer, everyone blames the LLM, and the real problem is that retrieval never surfaced the right chunk. Fix retrieval before you touch the prompt. Second most common is the lost-in-the-middle effect. Models pay the most reliable attention to the start and end of their context and can quietly skip relevant material buried in the middle of a long passage.[11] Stuffing more into the window is not the same as making it usable. And there is the ever-present risk of a confident hallucination when retrieval comes back empty and the model, rather than saying it doesn't know, fills the silence.

This is why evaluation is not optional. The RAG eval discipline, which has matured over the last two years or so, measures faithfulness (does the answer stay true to what was retrieved), context relevance (did we retrieve the right things), and answer relevance (did we actually answer the question). Open frameworks such as RAGAS made it more approachable.[12][13] Running RAG in production without measuring faithfulness is flying blind and calling it confidence.

One anti-pattern I will name directly, because it burns people: leaning on vector search alone for numerical or exact-match data. Embeddings are great for semantic similarity and terrible at “give me the exact figure from row 47.” Use a hybrid search that preserves exact values, and use real parsers to extract numbers rather than trusting the model to read them off a page.

When to leave it alone

If your knowledge is small, stable, and fits comfortably in the context window, you might not need retrieval at all. Just put it in the prompt. If the task is about reasoning or style rather than facts, RAG adds latency and moving parts for no gain. And if your knowledge base is a pile of contradictory documents, RAG will faithfully retrieve the contradictions. It grounds the model in your data. It does not clean your data for you.

Pattern 3

The LLM Router

Best for  keeping cost and latency under control across a portfolio of models.

Framing the problem

Here is a truth the frontier-model marketing doesn't dwell on. Most of your requests do not need your most expensive model. A large share of real production traffic is classification, formatting, extraction, and simple drafting. A small, cheap, fast model handles it fine. Sending all of it to a frontier model is like taking a helicopter to the corner store. The problem shape the router solves: “I have a spread of request difficulty and a spread of model cost, and right now I am paying frontier prices for grade-school work.” If your inference bill is climbing faster than your usage and you suspect you are over-buying intelligence, that is a routing-shaped problem.

Provenance: two things wearing one name

Be precise here, because two different things get collapsed together. Martian is a commercial model-routing company that sells routers. RouteLLM is an open-source framework and research contribution out of the LMSYS and UC Berkeley orbit, introduced in the 2024 paper “RouteLLM: Learning to Route LLMs with Preference Data.”[14] Related in spirit. Not the same thing. Citing them as one source is sloppy. And here is a detail that settles the point: the RouteLLM paper benchmarked its own routers against Martian directly and reported matching the commercial product's quality while running at over 40% lower cost.[14] They are not interchangeable. One is the research; the other is a product the research measured itself against.

The RouteLLM work is the one I'd put in front of a skeptical architect because it showed something concrete rather than a vibe. Route only the hard queries to the strong model, and you can hold quality while cutting cost hard. The headline result: over 85% cost reduction on MT Bench while keeping 95% of GPT-4's performance, with smaller but real savings on MMLU (about 45%) and GSM8K (about 35%).[14] Notice the spread across benchmarks. That is the honest part. How much you save depends on how much of your traffic is genuinely easy, which is exactly the judgment call routing exists to make. Not a marketing line. A measured result you can reproduce, on GitHub, today.

How it works

The mental model I use has four quadrants. SMFF keeps them straight:

The routing decision itself can be made a few ways, and they sit on a ladder. Simplest is rules: route by task type or a couple of heuristics. Next is semantic routing, where you embed the incoming request and match it against representative examples to pick the tier. The open-source semantic-router libraries put this within everyone's reach. Most sophisticated is a learned router of the RouteLLM kind, trained on preference data to predict which queries actually need the strong model. And under all of it, always, a fallback path for resilience.

Where it breaks

The router's real risk is that it becomes a single point of failure and a source of silent quality regressions. Misclassify a hard query as easy, and you have quietly degraded an answer, and nobody may notice until a customer does. So routing needs its own evaluation and its own observability. Measure the quality of the routing decisions, not just the money saved. The other trap is over-engineering: building a learned router with a training pipeline and a preference dataset to save money on a system that serves a thousand requests a day. At that volume, a few sensible rules will do, and the fancy router costs more in engineering time than it ever saves in inference.

When to leave it alone

One kind of request, or volume low enough that inference cost is a rounding error? Skip the router. It earns its complexity at scale, across a genuine spread of difficulty. Below that line it is a solution shopping for a problem.

Pattern 4

Hub-and-Spoke for Enterprise AI

Best for  centralizing governance while still letting business units move.

Framing the problem

This one is less a software architecture than an operating-model architecture, and it solves an organizational problem: the tension between control and speed. Centralize AI completely, and the central team becomes a bottleneck every business unit resents and works around. Decentralize it completely, and you get twelve incompatible stacks, twelve security postures, and no way to enforce policy or capture reuse. The problem shape hub-and-spoke solves: “I need consistent governance, security, and cost control across the company, and I need domain teams to move fast on their own use cases.” Feel that tension? Every enterprise of any size eventually does. That is a hub-and-spoke-shaped problem.

Provenance

Hub-and-spoke is not an AI invention. It is a classic topology borrowed from transportation and telecom networks and has been used in enterprise operating models for decades. What is current is applying it to AI operating models, and the major consultancies have landed on it with striking agreement: a central platform-and-governance hub, federated spokes in the business units, and a coordinating function that sets the standards.[1][6] This is the least novel pattern in the toolbox, in the sense that the topology is old. It is also one of the most reliable, precisely because it has been tested for decades. Not everything valuable has to be new.

How it works

The structure I recommend has five clear roles:

Where it breaks

The signature failure is the hub becoming a bottleneck rather than an enabler. A gatekeeper the spokes have to beg for access, which drives shadow AI as frustrated teams route around it. The fix is a mindset. The hub exists to enable the spokes, not to police them. Judge it by how much good work the spokes ship, not by how many requests it denied. The opposite failure is a hub with no teeth. A center of excellence that publishes standards nobody has to follow, which rots into a center of good intentions. The balance is real, and holding it takes executive air cover.

When to leave it alone

A small company with one AI team does not need this. Hub-and-spoke answers scale and federation: multiple business units, multiple domains, real governance obligations. If you are a startup with fifteen engineers, imposing this is cargo-cult enterprise architecture. Grow into it.

Pattern 5

Event-Driven Agents

Best for  real-time, asynchronous agent workflows at scale.

Framing the problem

Most agent tutorials wire agents together with direct calls. Agent A calls Agent B calls Agent C. Works beautifully in a demo. Falls apart in production because direct calls are tight coupling, and tight coupling is brittle. When B is slow, A blocks. When you want to add D, you have to change everyone who should talk to it. When something goes wrong, you cannot reconstruct what happened. The problem shape event-driven architecture solves: “I have many agents that need to react to things happening across the system, in real time, without being wired directly to one another, and I need to replay exactly what occurred.” If your agents need to be decoupled, resilient, and auditable, that is an event-shaped problem.

Provenance

Event-Driven Architecture is a foundational, long-established pattern. Gartner popularized the term years ago, and the related concepts of event sourcing and event notification have been discussed at length by Martin Fowler and others.[15] What is current is applying EDA to agentic systems, and here the Kafka ecosystem, Confluent in particular, has done the most substantive advocacy. The argument is that agentic AI genuinely needs an event-driven backbone rather than a web of point-to-point calls.[16] So, as with several patterns here, the foundation is old and solid, and the AI application is new. That is a strength. You are standing on infrastructure that has run the world's transaction systems for a decade.

How it works

Five ideas carry it:

That replay property deserves a second. In a direct-call setup, when an agent does something surprising, you are often reduced to guessing. In an event-sourced setup, you have the tape. For anyone running agents in regulated or high-stakes work, that audit trail is not a nice-to-have. It is frequently the thing that makes the system deployable at all.

Where it breaks

Event-driven systems trade one kind of complexity for another. You gain decoupling and auditability. You pay in eventual consistency and harder end-to-end reasoning. Debugging a purely event-driven flow can be genuinely hard, precisely because everything is decoupled. The property that makes it resilient makes it tough to see the whole story without good tooling. Teams new to EDA also tend to skimp on event schema design, and a bad event contract hurts as much as a bad API. Design your events with the same care you'd give a public interface, because that is exactly what they are.

When to leave it alone

Simple, synchronous, linear workflow? Do this, then that, then return? An event bus is overkill and will slow you down. The pattern earns its complexity when you have real concurrency, real-time reactivity, many independent actors, or hard audit obligations. A three-step pipeline does not need Kafka. Say so, and move on.

Pattern 6

Hexagonal Architecture for AI

Best for  keeping your system swappable as models and vendors change.

Framing the problem

Ask any engineer who built a serious LLM application in 2023 how many times they have swapped the underlying model since. The answer is “several.” And each swap was either trivial or miserable, depending entirely on one decision: whether the vendor's SDK was threaded throughout the whole codebase or isolated behind a boundary. The problem shape hexagonal architecture solves: “the pieces of my stack, the model, the vector store, the tools, the interface, are all changing faster than my core logic, and I refuse to rewrite my application every time one of them does.” In a field where the best model changes roughly every quarter, this is not hypothetical. It is the defining operational reality.

Provenance

This pattern has a clean, honest origin. Hexagonal Architecture, also called Ports and Adapters, was created by Alistair Cockburn, who worked it out and wrote it up in the early-to-mid 2000s.[17] The core idea is timeless. Isolate your application's core logic from the outside world by having the core talk only through ports (abstract interfaces), with adapters handling the messy specifics of any particular external technology. Swap the adapter, keep the core.

The AI version applies that decades-old idea to the new set of volatile externals AI systems depend on. I want to be clear about credit. “Hexagonal Architecture for AI” is an adaptation, not a new pattern. The intellectual credit is Cockburn's, and the AI framing is a faithful application of his idea to our particular problem. That is exactly how good patterns are supposed to age. The principle outlives the technology to which it was first applied.

How it works

The AI version defines a port for each volatile external. LVTUO covers them:

The frameworks most teams already use, the provider-agnostic abstraction layers in the big orchestration libraries, are an informal version of this pattern whether their users realize it or not. Hexagonal architecture just makes the discipline deliberate rather than accidental.

Where it breaks

The cost is upfront abstraction, and abstraction has its own failure mode: building ports for things that will never change. If you are certain you will only ever use one vector store, a port around it is ceremony. The judgment is in predicting which externals are genuinely volatile. In AI right now, the model is unquestionably volatile, which is why the LLM port earns its keep even for people who dislike abstraction. The other risk is leaky abstractions. A port that pretends all models are interchangeable when prompts, token limits, and tool-calling formats differ in real ways between providers. A good adapter absorbs those differences. A lazy one lets them leak into the core, and you get the worst of both worlds.

When to leave it alone

Throwaway prototype whose whole purpose is to be discarded? Skip the abstraction, move fast. Hexagonal architecture is an investment in longevity and changeability. If your system won't live long or change much, you are paying for insurance you'll never claim. But the moment a system is headed for production and expected to outlast one model generation, build the ports. You will thank yourself at the next model release, which is roughly ninety days out. Always.

The Patterns Are Not Rivals

Here is what separates the third-grade version of this material from the eleventh-grade version. These six patterns are not competitors. They are layers. A serious production system does not pick one. It composes several, and the real skill is in how they lock together.

Let me paint a realistic picture. Picture an assistant serving a large financial-services firm, not far off from the advisor-facing assistant Morgan Stanley built on a frontier model to put decades of internal research at its advisors' fingertips, a well-documented case of RAG at real scale.[18] Now lay the toolbox on top of a system like that.

At the base, a hexagonal architecture isolates the core assistant logic from the model, the vector store, and the tools. When a better model ships next quarter, that is an adapter swap, not a rewrite. Inside the hexagon, the knowledge problem gets solved by RAG, grounding every answer in the firm's own vetted documents and citing them for compliance. In front of the model port sits an LLM router, sending routine formatting and classification to a cheap model and saving the frontier model for genuinely hard reasoning, which keeps the inference bill sane at enterprise volume. As the system grows from one assistant into many specialized agents, a research agent, a compliance agent, a client-communication agent, those agents coordinate over an event-driven backbone. They publish and subscribe rather than call each other directly, which hands the firm the replayable audit trail its regulators will absolutely ask for. As those agents multiply across teams and start needing to find and trust each other, the whole thing takes on the character of an agentic mesh, with shared identity, governance, and a tool registry running through the fabric. And governing all of it, the standards, the guardrails, the FinOps, the upskilling, is a hub-and-spoke operating model that lets wealth management, investment banking, and research each build their own use cases on one safe, shared foundation.

That is not six architectures fighting for one slot. That is one coherent system with six patterns doing six different jobs. The framing question is never “which pattern should I use.” It is “which problems do I actually have, and which pattern handles each one.” Frame the problems honestly, and the architecture mostly assembles itself, because each pattern announces its own fit the moment you describe your situation without kidding yourself.

I want to be honest about one thing, though, because the picture above reads a little too clean. Patterns compose in the diagram. They fight at the seams. That is where the real work goes. Identity is the classic one. Your mesh wants a single, consistent notion of who an agent is and what it is allowed to do, and your hub-and-spoke operating model wants each spoke to manage its own access. Those two goals pull in opposite directions, and reconciling them is a project, not a checkbox. The event bus has its own version of this. Decouple your agents through events, and you gain resilience; then you discover that a schema change in one agent's event silently breaks three subscribers you forgot existed. And the router sitting in front of your LLM port can quietly undermine your RAG evals, because a query that scored well on the frontier model now gets a different answer from the cheap one, and your faithfulness metric drifts without anyone touching the retrieval code. None of this is a reason to avoid composing the patterns. It is a reason to expect the integration work to be real, to budget for it, and to instrument the boundaries between patterns as carefully as you instrument the patterns themselves. The seams are where production systems actually break.

A last note on why this composition is newly buildable in 2026. Interoperability standards. The Model Context Protocol provided a common way to connect models to tools and data,[7] and agent-to-agent protocols are standardizing how agents communicate.[8] Before these, composing patterns across vendors meant custom glue everywhere. Increasingly, the glue is standard, which means the system above is not an architecture-astronaut fantasy. You can build it today.

What Order to Reach For These

People ask me where to start. Fair question, because the composition picture can make it look like you need all six on day one. You do not. There is a rough order that most systems follow, and it tracks maturity rather than ambition.

Start with RAG. Almost every useful generative AI system begins as a grounding problem. Get retrieval right, measure faithfulness, ship something that cites its sources. That alone clears a lot of value, and it teaches you where your data is actually messy, which you need to know before anything else.

Add the hexagonal boundary early, not late. This is the one I see teams skip and regret. The moment your RAG system is headed for production, put the model behind a port. It costs a little now and saves you a rewrite at the next model release. I have watched the same swap take an afternoon for one team and three weeks for another, and the only difference was whether the boundary existed before they needed it.

Bring in the router when the bill starts to hurt. Not before. You will know. When your inference cost curve bends up faster than your usage, you have earned a router, and by then you have enough traffic data to route intelligently instead of guessing.

Reach for event-driven and the mesh when you cross from one agent to many. These two travel together. The day you have a second and third agent built by different people, needing to communicate with each other without direct calls, is the day the event backbone and the mesh fabric stop being overhead and become necessary. Not one agent sooner.

Hub-and-spoke shows up when the org, not the code, becomes the bottleneck. This is the least technical of the six and often the last to matter. When three business units are each building their own thing and stepping on each other, when governance is a series of one-off conversations, when nobody can tell you what the total AI spend is, that is the signal. The operating model has become the constraint, and hub-and-spoke is the answer.

That order is not a law. Some systems need the mesh early because they are agent-first from the start. Some never need hub-and-spoke because they live inside one team. But if you are staring at all six and wondering where to put your first month, put it in RAG and the hexagonal boundary. Earn the rest.

By the Numbers

A few figures worth carrying around as you make these calls, drawn from the research cited throughout:

None of these tell you what to build. All of them tell you why architecture is where the value tends to leak out, and why the toolbox is worth carrying.

Frame First, Reach Second

I opened by saying the hard part was never the model. Everything since has been an argument for that one claim. Six patterns, six problem shapes, and the same discipline repeated: frame the problem before you reach for the tool.

The mesh coordinates many agents. RAG grounds answers in your data. The router spends intelligence wisely. Hub-and-spoke governs at scale without strangling speed. Event-driven agents give you real-time, auditable, decoupled workflows. Hexagonal architecture keeps you alive in a world where everything you depend on is shifting underneath you. Learn the shape of each problem well enough to spot it in the wild, and the right pattern tends to show up on its own. Reach for a pattern before you have framed the problem, and you will build something impressive that solves nothing.

This is a toolbox, not a blueprint, and it is deliberately incomplete. There are patterns I left out, and I expect to come back to them. Master these six, though, to the point where you can explain not just how each one works but exactly when each one is wrong, and you are ready for most of the generative AI systems worth building right now.

The models will keep getting better on their reliable schedule. The architecture is the part that is up to us. Build it with discipline.

Darren-Michael Culbreath
Darren M. Culbreath

A full-stack technologist, entrepreneur, and patent holder with over 20 years of experience in technology, and the author of the Responsible AI Developer Framework. He writes about generative AI, cloud, and the discipline of building systems that survive production contact.

References

  1. [1] McKinsey & Company, “The State of AI: Global Survey,” QuantumBlack, McKinsey & Company, 2024–2025. mckinsey.com
  2. [2] Gartner, “Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept,” Press Release, Jul. 30, 2024. gartner.com
  3. [3] Gartner, “Gartner Survey Finds Generative AI Is Now the Most Frequently Deployed AI Solution in Organizations,” Press Release, May 7, 2024. gartner.com
  4. [4] Agentic AI market forecasts (ranges vary by analyst): Fortune Business Insights, “Agentic AI Market Size, Share & Forecast, 2034,” 2025, fortunebusinessinsights.com; Precedence Research, “Agentic AI Market Size,” 2025, precedenceresearch.com; Grand View Research, “Enterprise Agentic AI Market Size,” 2025, grandviewresearch.com
  5. [5] E. Broda, “Agentic Mesh: The Future of Generative AI-Enabled Autonomous Agent Ecosystems,” Towards Data Science, 2024. towardsdatascience.com
  6. [6] McKinsey & Company (QuantumBlack), writing on agentic AI operating models and the fabric required to scale agents, 2024–2025. mckinsey.com
  7. [7] Anthropic, “Introducing the Model Context Protocol,” Nov. 2024. anthropic.com
  8. [8] Google, “Announcing the Agent2Agent (A2A) Protocol,” Google Developers Blog, 2025. developers.googleblog.com
  9. [9] P. Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” NeurIPS 2020. arXiv:2005.11401. arxiv.org/abs/2005.11401
  10. [10] V. Karpukhin et al., “Dense Passage Retrieval for Open-Domain Question Answering,” EMNLP 2020. arXiv:2004.04906. arxiv.org/abs/2004.04906
  11. [11] N. F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” TACL 2024. arXiv:2307.03172. arxiv.org/abs/2307.03172
  12. [12] S. Es et al., “RAGAS: Automated Evaluation of Retrieval Augmented Generation,” 2023. arXiv:2309.15217. arxiv.org/abs/2309.15217
  13. [13] Y. Gao et al., “Retrieval-Augmented Generation for Large Language Models: A Survey,” 2023. arXiv:2312.10997. arxiv.org/abs/2312.10997
  14. [14] I. Ong et al., “RouteLLM: Learning to Route LLMs with Preference Data,” 2024. arXiv:2406.18665. arxiv.org/abs/2406.18665. See also LMSYS Org, “RouteLLM,” Jul. 1, 2024, lmsys.org, and github.com/lm-sys/RouteLLM
  15. [15] M. Fowler, “What do you mean by ‘Event-Driven’?,” 2017. martinfowler.com
  16. [16] Confluent, “Event-Driven Multi-Agent Systems” and related writing on agentic AI and Apache Kafka, 2024–2025. confluent.io/blog
  17. [17] A. Cockburn, “Hexagonal Architecture (Ports and Adapters),” c. 2005. alistair.cockburn.us
  18. [18] Morgan Stanley, “Morgan Stanley Wealth Management Deploys GPT-4 to Assist Financial Advisors,” 2023. morganstanley.com
  19. [19] E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.
  20. [20] Apache Software Foundation, “Apache Kafka Documentation.” kafka.apache.org
  21. [21] Deloitte AI Institute, “State of Generative AI in the Enterprise,” 2024. deloitte.com