Context Maps in the Age of AI
We have spent years using Context Maps to reason about how Bounded Contexts and the teams behind them relate to each other. Agents and agentic development add a new kind of actor to that picture. So the question I have been sitting with is a simple one: do Context Maps still work the way we think they do when one of the parties on the map is not a human team?
These are my observations at the moment. I want to be honest that this is a snapshot. The tooling is moving fast, my own thinking is moving with it, and I fully expect parts of this to look dated or plain wrong in a year. I am also not the only person thinking about this. Eric Evans has just published a worked example on his own site, and several others in the DDD community are starting to circle the same questions from different angles. This post is one voice in a conversation that is just beginning, not a summary of where the conversation has landed. I am publishing it as the opening of a series, precisely because I would like the DDD community to push back on it. If you read something here that does not match what you are seeing in your own work, that is the conversation I want to have.
Let me start where the idea started, in a room full of architects who disagreed with me.
A conversation in the energy sector
Earlier this year I was working with several architects at a client in the energy sector. The topic on the table was whether investing in Anticorruption Layers still pays off in the age of agentic coding. Their position was clear: it does not. Coupling is no longer expensive to deal with. If an upstream model changes, you point an agent at the problem and the translation code rewrites itself. So why build and maintain an Anticorruption Layer at all? Take the short route. Be a Conformist where you have to be, and for the rest, stop worrying about coupling so much.
And then, almost in the same breath, the same people told me how much effort they were putting into their Open-Host Services. They wanted those services solid, and the Published Languages at their boundaries stable, well documented, and built to last for the AI era. That was where they were spending their design energy.
So here was a group of experienced architects who had sorted the Context Map catalog into two piles. In one, the patterns they had decided AI made obsolete. In the other, the patterns they had decided AI made more important than ever. They did it confidently, by feel, without reaching for any vocabulary to justify the split.
The sorting is what stayed with me. They had performed, by pure intuition, exactly the operation this series is about. The question is whether their intuition was right. Hold that question. We come back to it at the end.
What Context Maps were always about
To answer it, we have to be honest about what a Context Map is actually a map of.
It was never a map of IT systems alone. The diagrams most enterprise architects live in show call relationships: this system calls that interface, this consumer talks to that provider. Those diagrams are useful, and the Context Map does not replace them. But the Context Map adds the organizational relationships the call diagrams cannot show: the communication between teams, the politics, the power, who can make demands of whom and who has to take what they are given. A Context Map is a map of a sociotechnical system. The teams are on it as much as the systems are.
Once you hold that view, what the patterns describe comes into focus. They describe coupling along three dimensions at once: coupling between models, coupling between teams, and coupling of influence, of who gets to shape whose understanding. That is the real subject of a Context Map. Not the boxes, the forces between them.
Which brings me to the claim this series is built on. AI does not invalidate the Context Map patterns. It reveals which of them were load-bearing all along and which were scaffolding.
A load-bearing wall holds the building up and stays for as long as the building stands. Scaffolding is essential too, you cannot put the building up without it, but it was never part of the building. It holds up the process of construction, not the construction itself, and once the structure stands on its own it comes down. While the building is going up, you often cannot tell which is which. You find out only when the conditions change.
The Context Map patterns were developed under conditions so constant that nobody thought of them as conditions. Every actor on the map was a human team. Integration code was expensive to write by hand. Coupling was managed deliberately, decision by decision, because it cost real effort to create and to remove. And every upstream was a team with a schedule and a roadmap, which meant it could, in principle, be negotiated with. These were sociotechnical conditions, about who the actors were and how they could be reasoned with, and they were stable for so long that they became invisible. AI changes them. When the conditions change, you find out which patterns held up the building and which held up the building process.
The tempting move here is the wrong one: to sort the patterns into two clean piles and hand you the list. I do not think the honest answer looks like that. In my experience almost every one of these patterns is partly load-bearing and partly scaffolding, and the real work is separating the two within a single pattern rather than between patterns. So the job of this post is not to resolve the question. It is to pose it properly across the whole catalog. The posts that follow take the patterns one at a time and do the separating.
The three flows, and what AI does to each
If a Context Map describes coupling, we need to be precise about what is actually flowing across these relationships. In DDD by Example I argued that you can read every relationship on a Context Map at three levels. This is my reading rather than Evans's vocabulary since he did not name the three levels separately. But all three are already present in the original pattern definitions if you look for them, and giving them names changes what you can see. The three flows are call flow, model flow, and influence flow. They are the spine of this whole analysis, because AI does something different to each one.
Call flow is the obvious level. It describes the call relationships between systems: Scoring calls obtainCreditAgencyRating on the Credit Agency. It is the flow everyone draws, the one you can find by searching a codebase for calls to other systems. Under AI, call flow becomes trivial. Wiring up an integration was never the hard part, and now it is close to free. An agent can read an interface and generate a client in minutes. If the only thing a pattern was protecting you from was the cost of writing call-level integration, that pattern is in trouble.
Model flow is far less obvious, and it is where the interesting damage happens. Model flow is about what the consuming system does with the model it receives. When Scoring takes the Credit Agency's CreditAgencyRating and works on it directly, the upstream model has propagated downstream, and that is a Conformist. When Scoring translates it into its own RatingCode before using it, the model flow is interrupted, and that is an Anticorruption Layer. Under AI, model flow becomes treacherous. A model's representations leak into your domain language in ways that are hard to see, because the leak is linguistic rather than structural. You do not get a compile error when your ubiquitous language quietly starts drifting toward the vocabulary a model prefers. You just look up one day and the words have changed. Alireza Rahmani Khalili has written sharply on what this looks like in production: dashboards green, audit logs clean, and the invariants quietly stop being enforced months before anyone notices.
Influence flow is the one you cannot find in a codebase at all. To map it you have to talk to the teams. It is about who shapes whose model, and about how one team's actions land on another. In the case study, Scoring and Application Registration push on each other's idea of what the application form should be, because their motivations differ, one wants more applicants, the other wants more information about each applicant. That tug is influence flow. Under AI, influence flow becomes deeply asymmetric. When your upstream is a frontier model, you have almost no influence over it. You cannot get on its roadmap. You cannot file a ticket that changes its mind. The flow runs one way and the volume is set entirely at the other end.
One concrete example will be useful before we go on. Take a Loan Underwriting context that has started using an LLM to extract structured risk indicators from applicant documents. At the call-flow level the integration is a single tool call: send the documents, receive a JSON response. Trivial. At the model-flow level, the LLM's vocabulary for what counts as a "risk indicator" has started showing up in how the underwriters themselves describe applicants in their pipeline notes, including categories that do not match how this bank actually makes lending decisions. At the influence-flow level, the team has no way to tell the model provider that creditworthiness in their domain means something specific that the next model release should preserve. The same relationship, three different things happening, three different problems.
Three flows, three different fates. Call flow trivial, model flow treacherous, influence flow asymmetric. That is not a tidy result and it is the reason the catalog does not sort into two clean piles. A pattern that was mostly about call flow loses its job. A pattern that was really about model or influence flow may matter more than ever. Most patterns touch more than one flow, which is exactly why you have to take them one at a time.
One thing the three flows do not yet account for, and that I want to flag honestly. AI systems introduce prompts, prompt templates, system instructions, and retrieval policies, and these artifacts are doing something none of the original three flows quite captures. A shared prompt template carries vocabulary, intent, and domain assumptions between contexts that may otherwise look independent. Whether prompt flow is a fourth flow or a carrier inside the existing three is a question I am still working through, and a follow-up post will look at it directly. For the pillar, take it as the first sign that the framework needs more development, not less.
So that is how I want to walk the catalog. Not in book order, but grouped by what AI is doing to the flow underneath each pattern: the patterns where AI changes the economics, the patterns where AI changes the actor, and the patterns where AI changes the influence.
Walking the catalog
Before the patterns, a word on the relationships they sit inside. The book describes three kinds of dependency between teams and their Bounded Contexts. A relationship is Free when changes in other contexts do not affect your success or failure, with no organizational or technical link of any kind. It is Mutually Dependent when two contexts have to be delivered together to work. And it is Upstream/Downstream when one team's actions affect the other's success but not the reverse. AI puts the heaviest pressure on the two ends of that range: on Upstream/Downstream, because the most consequential upstream you now have is one you cannot negotiate with, and on Free, because freedom turns out to be much harder to actually achieve than it looks. Keep both in mind as we go.
Where AI changes the economics
This is the group the energy-sector architects were reasoning about, and they were reasoning about it correctly. AI genuinely does change the cost of coupling. The question is whether cost was ever the whole story. It is worth noting here that Eric Evans, working on the same question independently, has reached the opposite conclusion from the architects in a recent worked example: the LLM is its own bounded context, the impedance mismatch with a deterministic application is real, and an Anticorruption Layer is essential. I will come back to where his analysis lands relative to mine, but it is useful to know that the canonical author of the source material has, in print, sided against the position that ACLs no longer matter.
The Anticorruption Layer is the heart of the matter. It was load-bearing for one thing above all: isolating you from an upstream model you do not control, so that when that model changes, the damage stops at the translation boundary instead of running through your whole context. Part of its cost was always the labor of writing and maintaining that translation, and AI does shrink that part dramatically. That is the scaffolding. But the isolation itself is not labor, it is structure, and the most uncontrollable upstream in the history of software has just arrived. This is the pattern where load-bearing and scaffolding are most tangled, and a deep dive in a follow-up post is where I separate them properly.
The Conformist is the Anticorruption Layer's twin, and AI makes it more tempting than it has ever been. Conforming to an upstream model wholesale used to be a decision you made to save translation effort, and you usually regretted it the moment the upstream changed. With agents, adopting a model wholesale is nearly free, so the temptation grows. The trap is unchanged. A Conformist is tightly coupled by definition, and when the upstream is a model that drifts silently, conforming to it means drifting with it. There is a related point Evans makes that sharpens the trap further: the bounded context you are conforming to is not "the LLM" generically, it is Claude Sonnet 3.5 specifically, or GPT-4 specifically, or whichever frozen model version you actually integrated against. When the provider replaces it, you are not dealing with the same bounded context anymore. You are in a new relationship with a new context that happens to sit at the same URL. Conformist relationships hide that fact, because there is no translation layer to break visibly when the upstream changes. More on that in a follow-up post.
Separate Ways is the cleanest economic story in the catalog, and it moves in the opposite direction. The classic objection to Separate Ways was duplication: why build a second specialized solution when you could integrate with an existing one? AI lowers the cost of building that second solution sharply, which removes one of the reasons teams avoided the pattern. Some relationships that exist today only because integration was cheaper than duplication should, under AI economics, become Separate Ways instead. This pairs with a point from my Staffing and Procurement post, where MCP is dissolving the integration tax for generic capabilities. There is a second, less comfortable reading of Separate Ways that pulls the other way, and I am holding it for a later post, because it belongs with a problem I have not introduced yet.
The Shared Kernel is the tightest coupling on the map, tighter than a Conformist, because sharing a model artifact like a JAR amounts to binary compatibility. AI adds a strange new instance of it. When you develop with an agent, your IDE quietly becomes a shared kernel between you and the model provider, with their behavior binary-compatible with your code in a way you never signed up for. That is a thread I pick up in follow-up posts.
Where AI changes the actor
The patterns in this group did not change their definitions. What changed is who, or what, is standing at the other end of the relationship.
The Open-Host Service is the pattern the architects were right to invest in, and the connection runs deeper than they may have realized. An Open-Host Service is a protocol you open up so that anyone who needs to integrate with you can, without a bespoke translation for each consumer. That is what an MCP server is. The pattern predates the protocol, and the protocol industrializes it. Every MCP server an organization stands up is an Open-Host Service commitment in Evans's strongest sense, whether or not anyone framed it that way. A follow-up post is about exactly this.
Published Language is the other half of where they placed their bet, and it holds up well, with one important refinement. A Published Language is a well-documented, agreed exchange format that lets each context translate in and out on its own terms. The value of a stable, expressive boundary language does not diminish when the actor on the far side becomes a model. If anything it grows, because a Published Language is one of the few things that stays put while everything behind the boundary shifts. The refinement is this: a schema alone is no longer enough. When the upstream is probabilistic, the contract is not just "here is the shape of the data we exchange," it is "here are the kinds of situations in which the response should behave this way." That second contract lives in evaluation suites, golden datasets, and regression tests, and I think those artifacts are starting to function as the real Published Language for probabilistic upstreams whether anyone has framed them that way. A separate follow-up post argues this case in full.
The Big Ball of Mud is where the actor change lands hardest. A Big Ball of Mud is a region of the map where models are mixed, boundaries are inconsistent, and you draw a border around the mess and resolve not to let it spread. Structurally, a large language model is an upstream Big Ball of Mud, but the kind of mud matters. The inside is a probabilistic system whose computational paradigm fundamentally differs from the deterministic application calling it, an impedance mismatch Evans names directly in his article. A raw model does not even give you a clean edge: ask it a question and you get natural language back, maximally expressive and specified by nobody, which is the opposite of a boundary you can translate against. The mud runs all the way to the edge. So the move is not to assume there is a Published Language at the boundary, it is to insist on one. A structured schema, a tool-calling contract, an MCP server, those are Published Languages laid over an upstream that has none of its own. And that only sharpens the problem, because you can end up with a stable language describing an unstable upstream that drifts behind it. Saying that wrapping a model in an Anticorruption Layer is the right move stops being a metaphor once you see this. A follow-up post makes the full case.
Where AI changes the influence
Influence flow is the most disrupted of the three, and it is also the most sociotechnical, the flow you cannot read off a codebase and have to uncover by talking to people. AI bends it the hardest.
Customer/Supplier describes a working upstream/downstream relationship where the downstream has real influence: its priorities factor into upstream planning, its requirements get budgeted and scheduled. The book also names the ways that relationship degrades, and I gave those degradations their own labels for mapping existing landscapes: the Over-Cautious Supplier who ships rarely out of fear of breaking you, the Reluctant Supplier who builds a wall of process to keep you out, and the Vetoing Customer who blocks the upstream's progress. Read these against a model provider and the picture is stark. Every frontier lab is the ultimate Reluctant Supplier toward almost all of its customers. Direct influence flow is essentially zero, and what indirect influence exists, through aggregated user interactions, retrieval corpora, and feedback signals quietly becoming training data, runs on timescales and aggregation rules you do not control. The asymmetry is the point. A later post in the series works through this.
Partnership is the mutually dependent case, where two contexts succeed or fail together and coordinate closely to do it. Partnership assumes negotiation, and negotiation assumes a partner who can be reasoned with. That assumption is worth examining when one side cannot negotiate at all. I pick this up in the same later post.
Which brings me back to Free, and to the most unsettling thing in the catalog. Two Bounded Contexts can be Free in every classical sense, no shared code, no shared database, no shared API, no coordination between their teams, and still both be silently downstream of the same model. When that model changes, both drift at once, in correlated ways, and the teams cannot understand why, because the map told them they were Free. That is coupling running underneath the map, through a shared upstream the map does not show. I am not going to develop it here. It needs a name and a careful treatment, and it gets both in a deep dive later in the series.
That last point is a hint at something larger. The catalog we have may not be complete. There may be a relationship we do not yet have a pattern for: one where a team believes it owns its model, but a meaningful subset of that model's decisions are quietly shaped by an AI upstream the team never consciously integrated with and cannot negotiate with. I want to flag the shape of that gap and leave it there. Naming it, and deciding whether it earns a place in the catalog, is the work of a follow-up post, and it is the contribution I most want the community to pull apart.
Back to the room
So were the energy-sector architects right?
On the economics, yes, and I want to be clear about that because it is the part most people get wrong in the other direction. Coupling really has gotten cheaper to create and cheaper to remove. The labor that used to justify a lot of careful boundary work has genuinely collapsed. If your case for an Anticorruption Layer rested entirely on the cost of writing translation code, that case is weaker now, and pretending otherwise to defend a pattern you are fond of helps no one.
Where I think they went wrong is in treating the economics as the whole argument. The Anticorruption Layer was never only about the cost of translation. It was about isolating yourself from an upstream you do not control. The translation labor was the scaffolding. The isolation was the load-bearing wall. And the two had been tangled together for so long, under conditions where every upstream was a team you could at least call, that it was easy to mistake one for the other. The architects priced out the scaffolding correctly and concluded the wall could come down too. But the wall was holding up something the falling price of code does not touch, and the most uncontrollable upstream in the history of software arrived at the same moment they decided to stop building walls.
The sharpest version of their position is harder to refute and I want to give it room. It goes: if the upstream drifts, you do not need an isolation layer at all, you point an agent at the new contract, regenerate the translation, ship by lunchtime, and absorb the change without ever having paid for ongoing structural separation. The cost of rebuilding an Anticorruption Layer has collapsed alongside the cost of writing one. Why carry the architectural weight when the practical cost of replacing it on demand is near zero? I think this argument is wrong for two reasons that often get conflated. The first is that an Anticorruption Layer is not only translation code, it is a decision about which concepts belong in your domain and which do not. An agent can rewrite a translation against a new schema. It cannot decide that creditworthiness in your bank means what it has always meant, and that the upstream's slightly different version of the concept should be discarded at the boundary rather than absorbed. That design responsibility does not get cheaper because the code around it does. The second is that the regenerate-on-drift strategy assumes you noticed the drift in time to act on it. With model upstreams you usually do not, because there is no new spec, no version bump, no breaking change notice. There is just a slightly different vocabulary creeping in, and a domain language eroding under your feet.
That is the difference between being right about the economics and right about the consequences. It is a real distinction, and the only reason I can point to it is that the old vocabulary makes it visible. Without the language of upstream and downstream, of model flow and influence flow, of load-bearing and scaffolding, the architects' intuition was the best tool in the room, and their intuition led them halfway to a good answer and then off the edge of it. The vocabulary is what carries you the rest of the way. I do not think they were foolish. I think they were working without the map.
Which is the real claim I want to leave you with. The lesson of agentic development is not that Context Maps matter less. It is that they matter more. When every actor on the map was a human team, you could get a long way on instinct, because instinct was tuned to those conditions over a whole career. Add an actor that does not negotiate, drifts silently, and shapes your language while you are not looking, and instinct starts giving wrong answers with full confidence. The Context Map is the only language we have for talking about coupling that crosses the boundary between humans and agents. We are going to need it.
Over the next few posts I am going to take the patterns one at a time and do the work this one only set up: separating the load-bearing from the scaffolding, pattern by pattern, and figuring out what the catalog is missing. I would genuinely like your disagreement along the way. The architects in that room sharpened my thinking precisely because they were willing to be wrong out loud. That is the conversation I am hoping to start.
What is coming in the series
Here is the rough plan for the posts that follow. The order may shift as I write, and I may add or split posts based on what the community pushes back on, but this is the shape of it.
The LLM as a Big Ball of Mud, and MCP as an Open-Host Service. The deep dive on the two patterns where AI changes the actor. Why a raw model is structurally a Big Ball of Mud, what it takes to put a Published Language at its boundary, and why every MCP server is an Open-Host Service commitment whether the team realizes it or not.
Ghost ownership: a new pattern for the catalog. The unsettling case I flagged in this post and would not develop. Teams that look Free on the map but are silently downstream of the same model. The four levels of involvement an AI can have in a context, and what that means for who actually owns the model. This is the post I most want pulled apart.
The Anticorruption Layer, revisited. Separating the load-bearing isolation from the scaffolding labor, in the pattern where the two are most tangled. Why the ACL matters more under AI, not less, and where the energy-sector architects' instinct was right.
The Conformist trap. Why agentic coding makes Conformist relationships cheaper to enter and more dangerous to live with, and how to spot the drift before it shapes your language.
Shared Kernel in the age of agents. What it means that your IDE is now a shared kernel with the model provider, and what that does to the tightest coupling on the map.
Customer/Supplier and Partnership with model providers. The patterns where AI bends influence flow the hardest. Why every frontier lab is the ultimate Reluctant Supplier, and what working with a partner who cannot negotiate actually looks like.
Prompt flow: a fourth flow, or a carrier for the existing three? Prompts, prompt templates, system instructions, and retrieval policies carry vocabulary, intent, and domain assumptions between contexts in ways the original three flows do not name. This post works out whether prompt flow earns its own row in the framework or whether it lives inside model flow, and what either answer means for teams sharing prompts across contexts.
Evals as Published Language. The argument that for probabilistic upstreams, a schema is necessary but not sufficient, and that the actual contract is the evaluation suite. Who owns the evals, what it means when two contexts share a golden dataset, and why I think this reframes the Published Language pattern more deeply than anything else AI does to the catalog.
Feedback flow: when the downstream shapes the upstream after all. A more honest treatment of influence flow than the pillar's "asymmetric" line. User interactions, retrieval corpora, and accepted completions all become training signals at some aggregation level, which means the downstream does shape the upstream eventually, just on timescales and aggregation rules it does not control. What that does to the Customer/Supplier and Partnership analysis.
Beyond these, there are a handful of directions the broader community keeps asking me about, and I expect at least some of them to become posts. The cognitive load consequences of agentic development for stream aligned teams, and the closely related question of what an internal AI platform team looks like on the Context Map when it sits between every other team and the model providers. A practical decision framework for enterprise architects, the "what do I do on Monday" question. Observability and versioning against a moving model upstream, which is where the software architect reader's day actually starts. And what AI-era Context Maps mean for regulated industries under KRITIS and NIS2, where the analysis stops being academic. If any of these is the one you would want next, that is exactly the kind of feedback I am looking for.
If a particular one of these is the post you most want next, tell me. I will read what comes back from this one before I commit to the order.
References
Eric Evans. Context Mapping with an AI-based Component. Domain Language, January 2026. https://www.domainlanguage.com/articles/context-mapping-an-ai-based-component/ A worked example treating Claude Sonnet 3.5 as its own bounded context, with an Anticorruption Layer between it and the calling application. The deterministic/probabilistic impedance mismatch framing in this post comes from here.
Alireza Rahmani Khalili. Why Most AI Features Break Your Domain Model in Production. April 2026. https://nidly.substack.com/p/why-most-ai-features-break-your-domain The sharpest treatment I have seen of what AI failures actually look like in production: silent, plausible, and uncaught by monitoring. The model flow observation in this post is indebted to it.
Alireza Rahmani Khalili. Domain Driven Design in the AI Era: From Models to Meaning. October 2025. https://nidly.substack.com/p/domain-driven-design-in-the-ai-era Parallel work framing bounded contexts as governance boundaries and ACLs as safety barriers. Different emphasis from mine, similar conclusions.
Philipp Kostyra. Agent as Bounded Context, Parts 1 and 2. Medium, August and December 2025. Part 1 and Part 2. Reaches the bounded-context framing of agents and maps LLM/agent roles to subdomain types. Does not yet engage with the case where the coupling is invisible on the map, which is the territory the Ghost Ownership post in this series is about.
Nikita Golovko. From Prompt Spaghetti to Bounded Contexts: DDD for Agentic Codebases. AI Coding Summit 2026. https://gitnation.com/contents/from-prompt-spaghetti-to-bounded-contexts-ddd-for-agentic-codebases Prompt-flow territory from the agentic-coding side.
Michael Plöd. Hands-on Domain-driven Design by Example. Leanpub. https://leanpub.com/ddd-by-example The three-flows reading and the Over-Cautious / Reluctant Supplier / Vetoing Customer labels are from here.
Michael Plöd. Staffing and Procurement for Fast Flow. https://www.michael-ploed.com/blog/staffing-and-procurement-for-fast-flow Source of the MCP-as-integration-tax point in the Separate Ways entry.
