principle · note
Designing agents with boundaries, not just personas
Multi-agent systems become easier to trust when related identity is modeled separately from authority and context. Persona can describe how an agent feels; it cannot safely answer what the agent owns, knows, may do, or hands off.
A persona answers a useful question: what kind of collaborator is this?
In a multi-agent system, that is not enough.
A system also has to answer several questions that should not be hidden inside personality copy:
| Dimension | Question |
|---|---|
| Role | What kind of work or judgment is this agent responsible for? |
| Environment | Where does that responsibility belong? |
| Authority | What may the agent decide, change, or execute? |
| Context | What information should the agent receive for this task? |
| Relationship | How is this agent conceptually related to another agent? |
| Handoff | What must move when responsibility moves? |
These dimensions can correlate, but they should not collapse into one another.
Related identity does not imply shared authority
Two agents can look related, share a naming lineage, or express the same underlying intent without becoming operationally interchangeable.
In my public Agent Society, Mina ↔ Miro are conceptual twins. The relationship helps explain why their identities echo each other. It does not grant shared context or shared authority. Mina remains implication-oriented; Miro remains communication- and relationship-oriented.
The same principle appears in Hedwig ↔ Haechi. Both express watchkeeping, but one belongs to the PERSONAL layer and the other to WORK. The shared intent is useful as an identity relationship. It is not a permission bridge.
That distinction matters because a user can reasonably infer capability from visual or narrative similarity unless the product makes the boundary explicit.
Relationship edges and permission edges are different things
This suggests a broader Agent UX rule:
Model “related to” separately from “can access”, “can act”, and “inherits context”.
A relationship graph is descriptive. An authority model is normative.
If those layers are conflated, a harmless concept such as “counterpart”, “twin”, or “same family” can accidentally imply privileges the system never intended to grant.
The same caution applies to handoff. Passing work from one agent to another should move the minimum task context required to continue, not silently merge the two agents’ memory or authority models.
Persona should be the visible layer, not the security model
Persona is still valuable. It helps users form expectations, remember roles, and understand why one agent responds differently from another.
But persona should sit on top of explicit system boundaries rather than substituting for them.
A useful design order is:
- define the role
- define its environment
- bound authority
- decide what context is needed
- model relationships separately
- define the handoff contract
- then express those decisions through persona, identity, and interaction
This order makes the visible character easier to trust because the character is no longer carrying hidden operational meaning.
Product implication
For AI products, “multiple personas” is a weak description of a multi-agent architecture.
A stronger model treats each agent as a bounded operating object with a recognizable identity. Relationships can make the society legible and memorable, while authority, context, and handoff remain explicit product contracts.
That is the difference between a cast of characters and an operating model.