> ## Documentation Index > Fetch the complete documentation index at: https://docs.mesh.texturehq.com/llms.txt > Use this file to discover all available pages before exploring further. # Context resolution # 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`](/perspective) for the perspective boundary, [`../data-model.md`](/data-model) for the entities it scopes, and [`work-graph.md`](/runtime/work-graph) 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: ```text theme={null} RuntimeAgent -> perspective -> actors -> conversations -> messages -> memory -> versioned agent state -> prompt snapshot -> model ``` Never: ```text theme={null} 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 `WorkArtifact`s, 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`](/runtime/memory-retrieval) 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: ```go theme={null} 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 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.