The sharp claim in Domain-Driven Agents isn’t that DDD helps agents — it’s the diagnosis of why they fail. In a greenfield repo an agent ships a clean “job offer status” field on the first try. In a four-year-old system it invents a fourth spelling of a concept that already exists three times, writes an adapter where a plain call was fine, or calls straight through where the adapter was the whole point. The failure isn’t the model’s reasoning. It’s that the codebase never decided which spelling was real, so there’s no shared meaning for the model to ground on.
That reframes a lot of agent-reliability work. Teams reach for a bigger model, a longer context window, more tools — when the actual gap is a missing ubiquitous language. An agent dropped into strong coupling and a tech-debt backlog is guessing at intent the code itself encodes nowhere. No amount of model capability resolves an ambiguity the system refuses to resolve for it.
What makes the proposal worth stealing is that it’s incremental: each repo registers a small domain block it owns, and a context map is generated by walking the portfolio and unioning those blocks. That’s context engineering pointed at the codebase instead of the prompt — you build the retrieval surface an agent needs before you ever call it. In production that’s the difference between an agent that reasons over a real domain model and one that pattern-matches on whatever tokens happen to be nearby.
If you’ve fought an agent through a legacy monolith, the HN discussion is where to compare notes. My bet: the next useful layer of agent tooling won’t be smarter models — it’ll be linters for missing meaning that flag the three-spellings-of-one-concept problem before an agent ever trips on it.