Why DDD Will Come Back for AI Agents?

DDD will come back because agents need a model of the domain they are operating in.

What are we doing when we are creating different skills for different process and giving access to the agent? We are passing business context - the context for the domain your business operates in.

Payment should happen in 30 days, else charge 10% extra - this is a business invariant you need to pass to the agent, as a skill, prompt, static logic, or whatever the case may be.

When people talk about context, the deeper point is not just “give the agent more context.”

The real point is: the agent needs a structured model of the business.

Not just files, docs, embeddings, or tool descriptions. It needs to understand how the domain is shaped ?

For example:

• What is a customer?

• What is a user?

• Are they the same thing?

• When are they different?

• What is an account?

• What state can an invoice move through?

• Which actions are allowed before approval?

• Which events matter?

• Which policy applies in which context?

That is why DDD will come back.

DDD gave us language for:

• ubiquitous language

• entities

• value objects

• aggregates

• bounded contexts

• domain events

• invariants

Because when an agent operates inside a business, it cannot rely only on code syntax or generic reasoning.

It has to know the meaning of the system.

If the agent collapses these concepts incorrectly, it will make bad decisions.

This is where context graphs (Domain Model represented as graph ) and DDD meet.

A context graph is not just a retrieval graph.

It becomes a living domain model:

Customer
  -> belongs to Account
  -> has Users
  -> has Contracts
  -> receives Invoices
  -> opens Support Tickets

But the graph also needs boundaries:

Billing.Customer != CRM.Customer
Auth.User != Workspace.Member
Finance.Account != Product.Account

That is bounded context.

Without bounded context, the agent will over-generalize.

It will see the same word in two places and assume it means the same thing.

Or it will see two different words and miss that they refer to the same business concept.

So the real job is not just “stuff more context into the model.”

The job is to help the agent build and evolve a correct domain model.

And this model will not be perfect on day one.

You start with a baseline:

• existing code

• docs

• database schemas

• API contracts

• workflows

• product language

• support docs

• analytics events

• tribal knowledge

If you are building a one-off agent, you may not see the need. But if you are automating a business process or making a function autonomous, then you need to understand the shape of the domain and design your multi-agent system around these bounded contexts.

Once the domain model exists, evals also need to operate against that model.

Right now, evals are more focused on prompts, tool calling, and whether the model gave the correct output. That is true to a certain extent.

But what we really want to validate is:

Did the agent complete the business process as expected?

Eval traces should also contain domain events. Traces containing domain events that agents emit when they complete certain tasks. This Event Source becomes evidence of how the agent understood and acted inside the domain.

A trace should not only say:

Tool called: update_invoice

It should say:

{
  "actor": "agent",
  "action": "approve",
  "entity": {
    "type": "invoice",
    "id": "INV-123",
    "attributes": {
      "bounded_context": "finance",
      "state": "validated",
      "amount": "1200"
    }
  },
  "outcome": {
    "result": "blocked",
    "reason": "approval_required"
  }
}

Then every run teaches the system more:

• this term was ambiguous

• this workflow had a hidden gate

• this entity was misclassified

• this repo owns this concept

• this policy applies only in this context

• this event means something different in another service

That learning should update the domain model.

Context graph -> domain model -> domain events -> eval traces -> learning loop

The context helps the agent reason.

The domain model gives meaning to the context.

The trace records how the agent acted against that model.

The eval checks whether the action was valid.

The learning loop updates the model when the trace reveals ambiguity or drift.

DDD will come back as the practical operating system for AI agents inside real businesses.

Because the bottleneck will not be whether the model can write code.

The bottleneck will be whether the system understands business concepts well enough to act safely.

In the old world, DDD helped humans align around software.

In the agentic world, DDD helps humans and agents align around the business.