Skip to main content

​
Agent perspective and epistemic isolation

Mesh hosts many agents in one control plane, but co-residency is an operational fact, not shared cognition.
Multi-agent hosting is operational multiplexing, not shared cognition.
Each RuntimeAgent experiences the world through its own perspective: its own actors, connector identities, conversations, messages, memory, and prompt history. Another participant may happen to be a RuntimeAgent hosted by the same Mesh deployment, an agent hosted somewhere else, a human, or a service. That distinction is not part of the participant’s conversational identity and must not be inferred from Mesh’s internal topology.

​
The portability test

The boundary is correct when this remains true:
Moving another participant from this Mesh deployment to a completely unrelated implementation must not change anything the current agent can observe, retrieve, remember, or infer about that participant, provided the participant’s external connector behavior remains the same.
If moving Daedalus out of the deployment changes Lyra’s prompt, memory, addressing behavior, or available context, Mesh has leaked control-plane knowledge across the perspective boundary.

​
Control plane versus perspective

The Mesh control plane necessarily knows facts that an agent must not receive as conversational context. For example, it may know that a Slack connector identity belongs to a RuntimeAgent it hosts. That knowledge is legitimate for:
  • routing inbound events to the correct runtime
  • recognizing an agent’s own connector identity
  • preventing self-echoes and pathological execution loops
  • enforcing authorization, budgets, and concurrency
  • auditing causal chains and operational behavior
  • administering agents and connectors
  • scheduling and supervising one RuntimeAgent’s internal WorkGraph
Those facts are not eligible context merely because Mesh knows them. Prompt assembly, memory retrieval, addressing classification, and tools operate inside the current RuntimeAgent’s perspective. They must not receive another participant’s runtime_agent_id, private state, tool grants, model configuration, memory, or the fact that the participant is hosted by Mesh unless that fact was learned through the external conversation like any other fact.

​
Actor is intentionally opaque

An Actor means: a participant as known within one RuntimeAgent’s perspective. Mesh does not classify an Actor as human, agent, or service. The graph records identity and behavior that the current perspective actually observed, not an ontological claim about what sits behind a connector account. This means Actor.kind does not belong in the model. Self-recognition is the one deliberate exception. A RuntimeAgent may use its own connector credentials and connector identity to recognize itself. That privileged recognition does not extend to peers. For Lyra:
  • Lyra’s own Slack identity -> self
  • Daedalus’s Slack identity -> Actor
  • an externally hosted bot -> Actor
  • Victor -> Actor
The fact that Daedalus may also be hosted by this Mesh process changes none of those semantics.

​
Perspectives do not share actors

Actor identity is stable across connectors only within one RuntimeAgent’s perspective. If Lyra and Daedalus both interact with Victor, Mesh must allow these to be distinct graph identities:
The control plane may know that the external identities correspond to the same real-world person for operational purposes, but that fact must not silently merge the two perspectives or their memory. Cross-connector identity linking is therefore perspective-scoped. A linkage learned by Lyra does not bootstrap Daedalus’s identity graph, and vice versa. This is enforced by the schema rather than by convention. actors and connector_identities carry the owning runtime_agent_id, connectors is unique per perspective, and composite foreign keys require an identity’s Actor and Connector to belong to the same RuntimeAgent — so a cross-perspective link is not storable. See data-model.md. In particular this holds when two RuntimeAgents share external connector topology: the same Slack workspace, the same conversation namespace, even the same external user id. Nothing about the boundary depends on their installs having been configured with different values. An earlier implementation carried the boundary in the conversation namespace alone, which meant an ordinary configuration choice — leaving a second install’s namespace unset — silently merged both agents’ actors and history.

​
Conversations and messages are observations

The same external event may legitimately exist once in each RuntimeAgent’s perspective that observed it. For example:
Those are not accidental duplicate canonical rows. They are two observations with different conversational meaning. This is why engagement may remain a property of the message event in a perspective-scoped graph: the message row already belongs to one agent’s view of the conversation. A future storage optimization may deduplicate raw connector payload bytes underneath these observations, but it must not collapse the perspective-level semantics above them.

​
Memory and context isolation

Memory belongs to the RuntimeAgent that learned it. The context resolver must begin with a RuntimeAgent/perspective and remain inside that boundary for the entire read. It may retrieve:
  • actors known to this perspective
  • conversations observed by this perspective
  • messages observed by this perspective
  • memory written by this RuntimeAgent
  • versioned profile/tool state belonging to this RuntimeAgent
It may not use another RuntimeAgent’s graph or memory as a retrieval source simply because both runtimes are hosted by Mesh. This is a correctness boundary as much as a privacy boundary. Shared hidden context would let one agent behave differently toward a participant because of facts the participant never exposed to it.

​
WorkGraph workers stay inside the perspective

runtime/work-graph.md lets one RuntimeAgent decompose a complex objective into bounded worker executions. Those workers are not additional RuntimeAgents. If Lyra creates three parallel research nodes, Mesh has not created three new coworkers. It has created three temporary execution contexts owned by Lyra’s root Run. A worker:
  • uses Lyra’s perspective as its only eligible knowledge source
  • receives a deliberately bounded subset of Lyra’s context
  • may receive only a subset of Lyra’s tools and authority
  • has no connector identity of its own
  • does not appear as an Actor
  • does not own separate long-term memory
  • does not gain privileged knowledge about other co-resident RuntimeAgents
Fresh worker context is execution isolation, not epistemic independence. This distinction prevents an internal implementation technique like “subagent” from quietly creating a second product-level identity system underneath RuntimeAgent.

​
Agent-to-agent interaction

Mesh-hosted agents communicate through connectors exactly as unrelated participants do. If Lyra speaks to Daedalus in Slack, Daedalus receives a Slack-authored participant message. There is no private Mesh side channel that gives either runtime a richer conversational representation of the other. The control plane may retain hidden causal provenance for safety and auditability. For example, it may know that an effectful Lyra run was triggered by a message emitted by a Daedalus run. That provenance may constrain authorization, cycle depth, budgets, or loop prevention, but it must not become prompt context unless the same fact is externally observable. WorkGraph workers are different because they are not peers. They are internal execution children of one RuntimeAgent. Their parent/child relationship is legitimate control-plane context for scheduling, budget, authorization, artifact routing, and auditability. It still does not create new conversational actors.

​
Guardrails

  • do not classify Actors as human, agent, or service
  • do not expose RuntimeAgent identity through the conversation graph
  • do not share Actors, memory, or conversation state between RuntimeAgent perspectives
  • do not let co-residency change an agent’s observable world
  • do not use control-plane identity mappings as model context
  • do not bootstrap one agent’s cross-connector identity links from another’s
  • do not treat a per-install configuration value (namespace, workspace id) as the isolation boundary; ownership is an explicit key
  • self-recognition is privileged; peer-recognition is not
  • do not optimize duplicated external observations by collapsing their perspective-specific semantics
  • do not model WorkGraph workers as RuntimeAgents or Actors
  • do not give a child worker a broader perspective, tool set, or authority than its parent RuntimeAgent

​
Design consequence

Mesh has two intentionally different views of reality:
The control plane can see both RuntimeAgent branches because it must operate them. Each RuntimeAgent can see only its own perspective. WorkGraph workers live underneath one branch; they do not create a bridge between branches. That wall is a product invariant, not a prompt convention.