Context resolution

A model call may see only one RuntimeAgent’s perspective. That is the whole contract. Mesh’s control plane can know more than any one agent does, but prompt assembly is not allowed to turn operational knowledge into hidden cognition. See ../perspective.md for the perspective boundary, ../data-model.md for the entities it scopes, and work-graph.md for how bounded worker contexts are created inside one RuntimeAgent’s execution graph.

The invariant

Every context read starts with a RuntimeAgent and stays inside that agent’s perspective for its entire execution. A context resolver must never begin from a deployment-global Actor, Conversation, MessageEvent, or memory query and filter afterward. Perspective ownership is part of the key, not a presentation-layer predicate. Conceptually:

RuntimeAgent
    -> perspective
        -> actors
        -> conversations
        -> messages
        -> memory
        -> versioned agent state
    -> prompt snapshot
    -> model

Never:

global Mesh knowledge
    -> prompt

Eligible context

A resolver may include facts that belong to the current RuntimeAgent’s perspective:

the triggering messages and contributing actors
conversation history observed by this RuntimeAgent
actor history linked inside this RuntimeAgent’s perspective
cross-connector identity links established inside this perspective
memory written by this RuntimeAgent
the RuntimeAgent’s own profile, policy, and tool-grant state
connector-native facts available to this RuntimeAgent through its configured connector
WorkArtifacts produced by this RuntimeAgent’s current root Run and explicitly declared as inputs to the current WorkNode

Eligibility is still constrained by audience and conversation boundaries. “This agent knows it somewhere” does not automatically mean “this agent may say it here.”

Ineligible context

The following are control-plane or foreign-perspective facts and must not enter a prompt merely because Mesh can query them:

another RuntimeAgent’s memory
another RuntimeAgent’s private conversation history
another RuntimeAgent’s actor graph or identity links
another participant’s runtime_agent_id
the fact that another participant is hosted by this Mesh deployment
another RuntimeAgent’s model configuration, prompt, tools, grants, or private state
deployment-global identity correlations not independently established in the current perspective
sibling WorkNode private transcripts that were not declared as hand-off artifacts
WorkArtifacts from another RuntimeAgent’s root Run unless they arrived through an explicit authorized product surface and are then represented inside this perspective

If the current agent learned one of those facts through ordinary conversation, the conversationally learned fact may of course exist in its own memory. The prohibition is on the hidden control-plane source, not on knowledge that arrived legitimately.

Actor-centric retrieval

Actor-centric retrieval is perspective-scoped before it is actor-scoped. If Lyra and Daedalus both know Victor, each may have a different Actor row and different memory about him. A request for “what have I discussed with Victor?” reads only the Victor identity graph belonging to the current RuntimeAgent. No optimization may silently merge those histories because the control plane can correlate the external identities.

Conversation-centric retrieval

A Conversation is an observation inside one perspective. Two RuntimeAgents observing the same external Slack thread may therefore have separate Conversation and MessageEvent rows. Context resolution reads only the current perspective’s observation. This is what lets the same external message be engage for one agent and observe for another without introducing a deployment-global engagement truth.

WorkGraph worker context

A WorkGraph creates fresh execution contexts without creating fresh agent identities. The root Run owns the objective and the RuntimeAgent perspective. A model-backed agent_loop WorkNode may execute as a child Run with a fresh model context, but that context is assembled under the same RuntimeAgent key as the root. The child context should normally contain only:

the WorkNode objective
typed WorkArtifacts required by incoming WorkEdges
the minimum relevant slice of the root RuntimeAgent’s perspective
the child Run’s allowed tool subset and budget
any verification rubric or output schema declared by the node

It should not automatically contain:

every sibling worker’s transcript
every upstream worker’s model reasoning
the root Run’s entire prompt history
control-plane facts that the root agent itself could not see
tools or secrets outside the child Run’s delegated grant

This is the context-engineering half of graph execution. Parallelism is valuable partly because workers can approach independent subproblems with fresh bounded context. Broadcasting the full root context and every sibling transcript to every worker defeats that benefit and makes graph topology cosmetic.

Artifacts are the hand-off boundary

WorkGraph nodes normally communicate through durable WorkArtifacts, not through hidden shared chat state. An upstream node may produce a structured finding, patch, test report, citation set, or other typed artifact. A downstream node receives that artifact because an admitted WorkEdge declares the dependency. That gives context assembly an explicit question to answer:

Which admitted incoming edges authorize which artifacts to enter this worker’s context?

The answer is inspectable from runtime state rather than reconstructed from worker transcripts.

Fresh context is not a new perspective

A verifier node should often use a fresh context so it is not anchored to the producer’s reasoning. A parallel research worker should often use a fresh context so sibling framing does not contaminate it. Those are execution isolation choices inside one RuntimeAgent perspective. They do not create new Actors, new long-term memory owners, or new conversational identities.

Audience boundary

Perspective isolation answers whose knowledge is this? It does not by itself answer is this knowledge appropriate in this conversation? Context selection must also preserve audience/provenance information well enough to avoid leaking private conversation facts into a broader room. At minimum, every durable memory or retrieved event must retain enough provenance to answer:

where was this learned?
who could observe it then?
which actor or conversation did it concern?
is the current conversation allowed to reuse it?

The exact audience policy can evolve, but the provenance needed to enforce one cannot be retrofitted after memory has lost its source. memory-retrieval.md owns the next step: hard audience eligibility before relevance ranking, and the separation between subject, source, and visibility. In short, subject changes relevance, visibility changes eligibility, and source explains provenance. WorkArtifacts inherit the audience/authority constraints of the root Run plus their source provenance. A worker producing a summary does not magically widen who is allowed to receive the underlying facts.

Prompt snapshots

Every model-visible prompt should eventually have a durable snapshot tied to:

RuntimeAgent id
turn/root Run id
optional WorkGraph revision, WorkNode, and WorkNodeAttempt ids
profile revision
memory revisions used
source MessageEvent ids
WorkArtifact ids used
model role and resolved model
context-compaction revision, if any

A prompt snapshot is the audit record of what this RuntimeAgent actually knew for that model call. It must contain references from one perspective only, even when the call belongs to a graph worker.

Compaction and summaries

Summaries are derived context and inherit the perspective and provenance of their inputs. A busy Slack channel may eventually be compacted instead of replayed as raw history, but the summary belongs to the RuntimeAgent that observed it. It does not become a shared channel summary available to every co-resident agent unless each perspective independently produced or imported it through an explicit product feature that preserves the isolation contract. A WorkGraph join or synthesis artifact follows the same rule. It is execution state owned by the root RuntimeAgent; it does not become cross-agent shared memory merely because several worker contexts contributed to it.

API shape

The intended shape is an API that makes an unscoped read difficult or impossible:

type Resolver interface {
    Resolve(ctx context.Context, agentID uuid.UUID, turnID uuid.UUID) (Context, error)
    ResolveWorkNode(ctx context.Context, agentID uuid.UUID, rootRunID uuid.UUID, nodeID uuid.UUID) (Context, error)
}

The exact types may change. The invariant should not: there is no context-resolution entry point without a RuntimeAgent/perspective key, and a WorkNode context additionally requires explicit graph/node scope.

Guardrails

do not query global actor history and filter by agent afterward
do not use control-plane RuntimeAgent mappings as prompt context
do not share memory between perspectives as an optimization
do not let cross-connector identity links cross perspective ownership
do not compact multiple perspectives into one shared summary
do not lose source/audience provenance when creating memory
do not assemble a model prompt without recording which perspective supplied it
do not broadcast every WorkGraph worker transcript to every other worker
do not let a child worker receive tools, secrets, or context beyond its delegated scope
do not confuse fresh worker context with a new RuntimeAgent perspective
do not pass graph artifacts between workers without an admitted dependency or explicit authorized input contract

Overview

Runtime

Data & State

Connectors

Operations

Context resolution

Context resolution

The invariant

Eligible context

Ineligible context

Actor-centric retrieval

Conversation-centric retrieval

WorkGraph worker context

Artifacts are the hand-off boundary

Fresh context is not a new perspective

Audience boundary

Prompt snapshots

Compaction and summaries

API shape

Guardrails

​Context resolution

​The invariant

​Eligible context

​Ineligible context

​Actor-centric retrieval

​Conversation-centric retrieval

​WorkGraph worker context

​Artifacts are the hand-off boundary

​Fresh context is not a new perspective

​Audience boundary

​Prompt snapshots

​Compaction and summaries

​API shape

​Guardrails

Context resolution

The invariant

Eligible context

Ineligible context

Actor-centric retrieval

Conversation-centric retrieval

WorkGraph worker context

Artifacts are the hand-off boundary

Fresh context is not a new perspective

Audience boundary

Prompt snapshots

Compaction and summaries

API shape

Guardrails