Agent Role Context Requirements Specification Prompt

This prompt is for integration engineers and multi-agent system architects who need to formally specify what context an agent requires before it can operate correctly. The core job-to-be-done is producing a context dependency manifest—a structured, machine-readable specification that lists every piece of state, intent signal, conversation artifact, and tool output the agent needs, along with explicit fallback behavior when context is missing or degraded. Use it when you are onboarding a new specialized agent into a multi-agent system, defining handoff contracts between agents, or debugging why an agent produces unreliable outputs that trace back to missing or stale context. The manifest this prompt generates becomes the contract that orchestrators, upstream agents, and context assembly pipelines must satisfy before invoking the agent.

The ideal user is someone who already understands the agent's role and capability boundaries but needs to make its context dependencies explicit and testable. You should have a completed agent role definition and capability boundary contract before using this prompt; those artifacts define what the agent does, while this prompt defines what it needs to know to do it. Required inputs include the agent's role specification, its input/output contracts, the available context sources in your system (session state stores, conversation history, tool output caches, user profile services), and any known failure modes from previous deployments. The prompt works best when you can enumerate the concrete data types and sources available in your agent platform—vague references to 'user context' or 'conversation history' will produce a vague manifest that doesn't prevent production failures.

Do not use this prompt for defining agent capabilities, tool access policies, or role boundaries. Those belong to sibling playbooks: the Agent Role Definition Prompt Template, Agent Capability Boundary Contract Prompt, and Agent Tool Access Policy Prompt respectively. This prompt also should not be used as a substitute for handoff protocol design—the Agent Handoff and Context Transfer Prompts content group covers how to package and transmit context between agents, while this prompt covers what context must be packaged. Finally, avoid using this prompt for agents that operate with purely stateless, self-contained requests where context dependencies are trivial; the overhead of a formal manifest isn't justified when the agent only needs the current user message and nothing else. If you find yourself writing 'no external context required' for every field, you're using the wrong tool for the job.

Use this template to generate a structured context requirements specification for any agent role. The prompt forces the model to enumerate every piece of context the agent depends on—session state, user intent, conversation history, tool outputs, and external data—along with the expected format, source, and degraded behavior when that context is missing or incomplete. Replace each square-bracket placeholder with your agent's specific details before use.

textCopy
You are a context requirements analyst for multi-agent systems. Your task is to produce a complete context dependency manifest for the agent described below.

## Agent Identity
- Agent Name: [AGENT_NAME]
- Agent Role: [AGENT_ROLE_DESCRIPTION]
- Agent Scope: [AGENT_SCOPE_BOUNDARY]
- Agent Capabilities: [AGENT_CAPABILITY_LIST]
- Agent Tools Available: [AGENT_TOOL_LIST]

## Task Description
[AGENT_TASK_DESCRIPTION]

## Output Schema
Produce a JSON object with the following structure:
{
  "agent_name": "string",
  "context_dependencies": [
    {
      "dependency_id": "string",
      "dependency_name": "string",
      "category": "session_state | user_intent | conversation_history | tool_output | external_data | configuration | memory | other",
      "description": "string explaining what this context provides",
      "source": "string describing where this context originates",
      "format": "string describing the expected data shape or schema",
      "required": true | false,
      "priority": "critical | high | medium | low",
      "freshness_requirement": "string describing staleness tolerance",
      "degraded_behavior": "string describing how the agent should behave when this context is missing, stale, or incomplete",
      "fallback_value": "string or null describing a safe default when unavailable",
      "validation_rule": "string describing how to verify this context is valid before use"
    }
  ],
  "context_assembly_order": ["dependency_id_1", "dependency_id_2"],
  "minimum_viable_context": ["dependency_id"],
  "context_conflict_rules": [
    {
      "conflict_description": "string",
      "resolution_strategy": "string"
    }
  ]
}

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

## Risk Level
[RISK_LEVEL]

Generate only the JSON manifest. Do not include explanatory text outside the JSON.

After copying the template, replace each placeholder with concrete details about your agent. The [CONSTRAINTS] field should include any domain-specific rules, compliance requirements, or operational limits. The [EXAMPLES] field should contain one or two worked examples of context dependencies to calibrate the model's output. Set [RISK_LEVEL] to low, medium, high, or critical to influence the thoroughness of degraded-behavior descriptions. For high-risk or critical agents, always require human review of the generated manifest before integrating it into an orchestration pipeline. Validate the output against the JSON schema programmatically, and re-prompt with the validation error if the model produces malformed JSON or omits required fields.

This prompt is designed to run as a pre-deployment gate in an agent registration pipeline, not as a runtime call. When a new agent role is defined, the integration engineer submits the role contract, capability declaration, and tool manifest. The prompt produces a structured context dependency manifest that downstream orchestrators use to decide what state to package before invoking the agent. The manifest should be stored alongside the agent's role definition in your agent registry (e.g., a versioned JSON artifact in a registry service or configuration repository). Do not run this prompt at inference time; the output is a build-time artifact that shapes how the orchestration layer assembles context for each agent invocation.

Integration pattern: Wire this prompt into a CI-style agent onboarding pipeline. When a team submits a new agent role definition, the pipeline runs this prompt against the role contract and produces a context-manifest.json artifact. A schema validator checks the output against the expected manifest schema (required fields: required_context, optional_context, degradation_policy, context_sources, staleness_tolerances). If validation fails, the pipeline rejects the submission and returns structured errors. If validation passes, the manifest is versioned and stored. The orchestrator reads this manifest at agent dispatch time to assemble the correct context payload. Retry logic: If the model returns malformed JSON or misses required fields, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt also fails, escalate to a human reviewer with the raw output and validation report. Do not auto-merge a manifest that failed validation twice.

Human review gates: For agents operating in regulated domains (finance, healthcare, legal) or agents with write-access to production systems, require human approval on the generated manifest before it becomes active. The review should confirm that required context fields are complete, degradation behavior is safe (e.g., the agent refuses rather than hallucinates when context is missing), and no sensitive data sources are inadvertently listed as required context. Model choice: Use a model with strong JSON schema adherence (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models for this task because schema precision and field completeness are critical. Logging: Log the prompt version, model, raw output, validation result, and reviewer identity for every manifest generation. This creates an audit trail for governance reviews. Tool use: This prompt does not require tool calling. It is a pure structured generation task. If your pipeline uses a RAG system to supply the agent's existing role documentation as [ROLE_CONTRACT], inject that context before the prompt rather than relying on the model's training data.

What to avoid: Do not treat the generated manifest as optional. Orchestrators that ignore the manifest will silently drop context, causing agents to operate with incomplete state and produce degraded outputs. Do not skip the degradation behavior tests described in the eval section—agents that fail gracefully when context is missing are safer than agents that guess. Finally, version your manifests alongside agent role definitions. When an agent's capabilities change, re-run this prompt to regenerate the manifest and flag any new context dependencies that the orchestrator must satisfy.