---
title: "Designing agents with boundaries, not just personas"
type: note
description: "A product-design principle for multi-agent systems: persona is only one layer. Role, environment, authority, context, relationship, and handoff need separate boundaries."
summary: "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."
ai_summary: "Principle note: multi-agent design should model role, environment, authority, context, relationship, and handoff separately. Uses Mina/Miro and Hedwig/Haechi as public examples of related identity without shared authority or runtime permission."
status: public
visibility: public
language: en
topics: [agentic-ai, agent-ux, system-design]
tags: [boundaries, multi-agent, authority, context, handoff]
audience: [product-managers, ai-practitioners, builders]
publishedAt: 2026-09-03
updatedAt: 2026-09-03
featured: true
related: [projects/personal-agent-society, labs/from-canonical-profile-to-essence]
sourceStatus: original
sourceSensitivity: public
monetization: free
noteType: principle
confidence: high
canonicalUrl: "https://wbeen-personal-kb.vercel.app/notes/designing-agents-with-boundaries-not-just-personas"
---

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:

1. define the role
2. define its environment
3. bound authority
4. decide what context is needed
5. model relationships separately
6. define the handoff contract
7. 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.

## Related

- [Personal Agent Society project](/projects/personal-agent-society)
- [Agent Society showcase](/agents)
- [From Canonical Profile to Essence](/labs/from-canonical-profile-to-essence)

---

Canonical page: https://wbeen-personal-kb.vercel.app/notes/designing-agents-with-boundaries-not-just-personas
This is the AI-readable Markdown mirror. Public, curated content only.