Your Agent's Skills Are Bounded Contexts (Design Them Like It)
written by Stefan Christoph
TL;DR: My AWS colleague Dennis Traub made the case that Domain-Driven Design’s Ubiquitous Language is now critical infrastructure for AI agents. I want to take that one layer up, into architecture. After building a stack of agent skills to run my own work, I keep landing on the same rule: a skill that works is a bounded context. One consistent vocabulary inside one boundary. The skills that break are the ones that try to know everything and end up speaking three domains’ languages at once.
Start With Dennis’s Point, Then Go Up a Level
A couple of weeks ago Dennis Traub wrote a sharp piece on why coding agents amplify vocabulary ambiguity, and why DDD’s Ubiquitous Language, the discipline of agreeing on precise domain terms, turns out to be exactly what agents need [1]. If you haven’t read it, start there. He covers the why better than I will repeat it here: agents take your words literally, never ask “what do you mean?”, and amplify whatever vocabulary you give them.
I want to pick up where that leaves off and ask an architecture question. If Ubiquitous Language is the answer at the level of individual terms, what is the answer at the level of system structure? Because in a real agent setup you are not handing the agent one glossary. You are handing it a collection of skills, tools, and instructions, and they are not all speaking the same language.
This is the part I learned the hard way, by building.
What I Keep Relearning About Skills
I run most of my work through an agent driven by skills: small, self-contained workflow definitions the agent loads when a task matches. I wrote about the general approach in The Coding Agent That Doesn’t Code. What I did not appreciate at first is how much the boundaries between skills matter, and how those boundaries are really about language.
The failure mode is seductive. You have a skill that prepares customer meetings. It works. So you grow it: now it also logs activities, drafts follow-ups, and updates the CRM. Each addition is reasonable on its own. But “meeting” in the prep context, “activity” in the logging context, and “opportunity” in the CRM context are not the same concepts, and now one skill is trying to hold all three vocabularies at once. The agent starts blurring them. Quality drops in a way that is hard to pin on any single instruction.
The fix was never a better prompt. It was drawing a boundary.
A Skill Is a Bounded Context
Eric Evans’s Domain-Driven Design (2003) gave us the term Bounded Context [2]: a boundary inside which a model, and its language, is consistent. “Customer” means one thing in billing and a different thing in shipping, and rather than forcing a single universal definition, you draw a line and keep each side internally coherent.
That maps almost exactly onto a well-designed agent skill. A skill is a boundary. Inside it, the vocabulary should be consistent and complete. Across skills, the same word is allowed to mean different things, because they are different contexts.
The god-skill holds three vocabularies in one boundary. Split when a word needs two meanings.
The practical signal is simple: the moment a term needs two definitions inside one skill, that is your boundary, and your cue to split. Not when the file gets long. When the language stops being consistent.
Splitting doesn’t make the shared concepts vanish. A completed meeting still has to become an activity somewhere. The trick is to write that handoff explicitly at the seam, one clear line about how a term in one skill maps to a term in another, instead of letting a single skill quietly hold both meanings. DDD has a name for this too: the Anti-Corruption Layer. In an agent setup it is usually just a sentence, but it is the difference between a deliberate translation and an accidental blur.
The Skill’s Instructions Are Its Ubiquitous Language
Here is the reframe that changed how I write skills. A skill’s instruction file is not just a how-to. It is the Ubiquitous Language of that bounded context. It is where you pin down what each term means for this skill, so the agent stops guessing.
So I now write a short vocabulary section into a skill, the same way I would brief a new teammate joining only that one workstream:
## Language (this skill only)
- "activity": a logged interaction with a customer. NOT a calendar meeting.
- "meeting": a calendar event. Becomes an "activity" only after it happens.
- "opportunity": a CRM deal record. NOT a meeting and NOT an activity.
It is a few lines. It costs almost nothing. And it removes the exact class of error where the agent confidently does the wrong thing because two of my words looked like synonyms to it but are not.
Naming Is the Boundary Contract
The other place language lives is in names, tool names, skill names, parameter names. I argued in CLI vs MCP: The Wrong Debate that the interface names are part of how the agent thinks, not packaging around it. Bounded contexts sharpen that: a tool name should belong to one context and speak that context’s language. A skill called “handle-customer” invites the god-skill problem. A skill called “log-activity” already tells the agent which boundary it is in before it reads a word of the body.
Name the boundary, and half the ambiguity never arises.
If You’re Running This on AWS
The pattern is tool-agnostic, but here is where it lands if you build on AWS.
| Where | Bounded context shows up as |
|---|---|
| Kiro specs | One spec per context; the requirements file pins that context’s terms before code generation. |
| Agent skills / steering | One skill per bounded context, each carrying its own short vocabulary section. Resist the god-skill. |
| Amazon Bedrock AgentCore — tool schemas | Group tools by context and name them in that context’s language; the names are vocabulary the model reasons over. |
| MCP servers | One server per context where you can. The tool name is the contract the agent reads first. |
The Question Worth Sitting With
Dennis’s piece will make you fix your vocabulary. This is the structural follow-on: your skills, tools, and servers are already bounded contexts, whether you drew the boundaries on purpose or let them happen by accident.
So the question I would ask of your own setup: which of your skills is quietly speaking three languages at once? That one is your next refactor.
Sources
[1] Dennis Traub, “Your Agent Keeps Using That Word,” dev.to, May 2026. https://dev.to/aws/your-agent-keeps-using-that-word--4g36 — the piece this one builds on; the case for Ubiquitous Language as agent infrastructure, plus a survey of practitioners converging on the pattern.
[2] Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003 — origin of Ubiquitous Language and Bounded Contexts.
About the Author
Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.
This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.