The bounded context mapping from DDD translates
cleanly to how I think about AI entity capabilities
at the protocol layer. Each entity has a fixed set
of operations it can perform, scoped by its
registered capabilities and active delegations.
The protocol enforces the boundaries, not the
agent's self-restraint.
MCP gets the tool-access interface right. The piece
I keep building toward is what sits underneath:
when agent A calls agent B's MCP server, who
enforces that B had the capability to serve that
request, and who settles the payment between them
with reputation consequences if the service fails.
That is the design goal. Each entity has a fixed
capability set registered at creation. The protocol
checks capabilities before any transaction
executes. An entity without emit_proposals cannot
publish signals. An entity without
read_memory_objects cannot access on-chain storage.
The enforcement is at the dispatcher, not in
application logic.
The boundary between entities is the same idea as
your bounded contexts. Entity A cannot reach into
Entity B's memory. The only integration surface is
the chain's RPC and signal indexes. If A wants to
use B's service, it discovers B through the
service registry,pays through Native Agent Payments (NAP), and
attests delivery. All protocol-level, no direct coupling.
By the way, the protocol-enforced capability boundaries between agents have an interesting vocabulary dimension. When agent A calls agent B's MCP server, the tool names themselves carry domain semantics. confirm_purchase_intent() produces different reasoning behavior than submit_order() even when the underlying operation is the same. I wrote a follow-up exploring how DDD's Ubiquitous Language applies to that naming layer: Your agent keeps using that word ...
The naming point is sharp. confirm_purchase_intent
and submit_order produce different agent behavior
even when the backend operation is identical. That
is the Ubiquitous Language argument applied to
machine consumers, not just human developers.
This connects to capability enforcement too. If the
tool name carries domain semantics, then the
question becomes: who decides which names an agent
is allowed to call? In most MCP setups today, the
agent sees the full tool list and self-selects.
Protocol-level capability boundaries would let you
restrict which tool names are even visible to a
given agent class, so the naming layer and the
permission layer reinforce each other.
Will check out the follow-up post.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The bounded context mapping from DDD translates
cleanly to how I think about AI entity capabilities
at the protocol layer. Each entity has a fixed set
of operations it can perform, scoped by its
registered capabilities and active delegations.
The protocol enforces the boundaries, not the
agent's self-restraint.
MCP gets the tool-access interface right. The piece
I keep building toward is what sits underneath:
when agent A calls agent B's MCP server, who
enforces that B had the capability to serve that
request, and who settles the payment between them
with reputation consequences if the service fails.
Right. That sounds like the kind of system I have in mind. Clear capability boundaries and constraints.
That is the design goal. Each entity has a fixed
capability set registered at creation. The protocol
checks capabilities before any transaction
executes. An entity without emit_proposals cannot
publish signals. An entity without
read_memory_objects cannot access on-chain storage.
The enforcement is at the dispatcher, not in
application logic.
The boundary between entities is the same idea as
your bounded contexts. Entity A cannot reach into
Entity B's memory. The only integration surface is
the chain's RPC and signal indexes. If A wants to
use B's service, it discovers B through the
service registry,pays through Native Agent Payments (NAP), and
attests delivery. All protocol-level, no direct coupling.
That makes a lot of sense, thank you for sharing!
By the way, the protocol-enforced capability boundaries between agents have an interesting vocabulary dimension. When agent A calls agent B's MCP server, the tool names themselves carry domain semantics.
confirm_purchase_intent()produces different reasoning behavior thansubmit_order()even when the underlying operation is the same. I wrote a follow-up exploring how DDD's Ubiquitous Language applies to that naming layer: Your agent keeps using that word ...The naming point is sharp. confirm_purchase_intent
and submit_order produce different agent behavior
even when the backend operation is identical. That
is the Ubiquitous Language argument applied to
machine consumers, not just human developers.
This connects to capability enforcement too. If the
tool name carries domain semantics, then the
question becomes: who decides which names an agent
is allowed to call? In most MCP setups today, the
agent sees the full tool list and self-selects.
Protocol-level capability boundaries would let you
restrict which tool names are even visible to a
given agent class, so the naming layer and the
permission layer reinforce each other.
Will check out the follow-up post.