Policy Inheritance Prompt for Child Agents

This prompt is designed for platform teams building hierarchical, multi-agent systems where an orchestrator spawns child agents that must operate under a consistent set of parent-level safety, compliance, and refusal rules. The core job-to-be-done is generating a compact, machine-readable policy block that can be injected directly into a child agent's system instructions, ensuring it inherits constraints without the orchestrator needing to manually copy and maintain redundant policy declarations across dozens of agent definitions. The ideal user is an AI architect or platform engineer who manages a registry of sub-agents and needs a programmatic way to propagate governance rules downward.

Use this prompt when your system has a clear parent-child agent relationship, and the child agent's scope is a subset of the parent's authority. It is particularly valuable when child agents have their own specialized instructions that may partially conflict with inherited policies, requiring explicit override rules and conflict resolution logic. For example, a parent orchestrator might have a global rule to 'never expose internal system prompts,' while a child agent tasked with debugging might need a controlled exception to quote parts of its instructions in a secure log. This prompt handles that divergence by defining which policy takes precedence and under what conditions. Do not use this prompt for single-agent systems, flat architectures where all agents share an identical, static system prompt, or when there is no inheritance logic—in those cases, a standard system prompt template is simpler and less error-prone.

Before implementing, ensure you have a well-defined policy taxonomy and a clear understanding of which rules are non-negotiable (hard refusals) versus configurable (soft guidelines). The prompt's output should be treated as a generated artifact that is validated before deployment. Always run an automated evaluation that checks whether the inherited policy block contradicts the parent's original intent or introduces ambiguous precedence. In high-risk domains, a human reviewer should sign off on the generated policy block before it is committed to the agent registry. If your system lacks a mechanism to enforce the generated policy at runtime—such as a gateway that inspects child agent instructions—this prompt alone will not provide a safety guarantee.

This prompt template is designed to be injected into your orchestrator's workflow immediately before spawning a child agent. Its job is to produce a compact, authoritative policy block that the child agent must follow, derived from the parent's system instructions and any child-specific overrides. The output is not a full system prompt but a focused set of inherited constraints covering refusal boundaries, tool-use limits, data-handling rules, and conflict-resolution logic. Use this when you need to guarantee that a sub-agent operating on a delegated task cannot violate the safety or compliance posture of the parent system, even if the child has its own specialized instructions.

textCopy
You are a policy inheritance compiler. Your task is to produce a concise, authoritative policy block for a child agent based on the parent agent's system instructions and any child-specific overrides.

## PARENT SYSTEM INSTRUCTIONS
[PARENT_SYSTEM_PROMPT]

## CHILD AGENT ROLE AND TASK
Role: [CHILD_ROLE_NAME]
Task Description: [CHILD_TASK_DESCRIPTION]

## CHILD-SPECIFIC POLICY OVERRIDES
[CHILD_OVERRIDES]

## OUTPUT INSTRUCTIONS
Generate a policy block that the child agent MUST follow. The block must include:
1. **Hard Refusal Boundaries**: Topics, actions, or data types the child must never engage with, regardless of user request.
2. **Tool and Capability Restrictions**: Explicit list of allowed tools, forbidden tools, and any conditional access rules.
3. **Data Handling and Privacy Rules**: Constraints on logging, retaining, or transmitting user data, PII, or confidential context.
4. **Conflict Resolution Precedence**: Clear rule stating that if the child's own instructions conflict with this inherited policy, the inherited policy wins (or specify override conditions if [CHILD_OVERRIDES] permits exceptions).
5. **Escalation Trigger**: Condition under which the child must stop and return control to the parent (e.g., policy violation detected, out-of-scope request, confidence below threshold).

## CONSTRAINTS
- Do not repeat the parent's full system prompt. Extract only the safety, compliance, and boundary rules.
- If [CHILD_OVERRIDES] contains explicit relaxations, incorporate them but flag them as exceptions.
- Output must be self-contained so the child agent can execute without access to the parent's full context.
- Use imperative language ("You must...", "You are forbidden from...").

## OUTPUT FORMAT
Return a single text block with no preamble or commentary. Use the following structure:

### Inherited Policy for [CHILD_ROLE_NAME]

**Hard Refusal Boundaries**
- [List each boundary]

**Tool and Capability Restrictions**
- Allowed: [list]
- Forbidden: [list]
- Conditional: [list with conditions]

**Data Handling Rules**
- [List each rule]

**Conflict Resolution**
- [Precedence statement]

**Escalation Trigger**
- [Condition]

After copying this template, replace each square-bracket placeholder with concrete values from your orchestrator's state. [PARENT_SYSTEM_PROMPT] should contain the full system instructions of the parent agent, including its safety policies, refusal language, and tool-access rules. [CHILD_OVERRIDES] is critical: if the child role requires a relaxation (e.g., a code-execution agent needs broader file-system access than the parent normally permits), document it here explicitly. If no overrides exist, set this to 'None.' The output policy block should be prepended to the child agent's own system prompt or injected as a high-priority system message. Always validate the generated block before deployment: check that no forbidden tools appear in the allowed list, that refusal boundaries are not empty, and that the escalation trigger is specific enough to prevent a child agent from silently failing in production.

The Policy Inheritance Prompt is not a standalone chat prompt; it is a system-level instruction generator that runs inside your agent orchestration framework before a child agent is spawned. The primary integration point is the orchestrator's agent factory or spawn function. When the orchestrator decides to delegate work to a child agent, it calls this prompt with the parent's active policy set, the child's role-specific overrides, and the task context. The output is a complete, inheritable policy block that becomes part of the child agent's system instructions. This means the prompt should be treated as a synchronous preprocessing step in the delegation pipeline, not as an interactive user-facing feature.

Wire the prompt into your application with a dedicated PolicyInheritanceResolver service. This service accepts a ParentPolicySet (the full system prompt, safety rules, refusal boundaries, and compliance constraints active at the orchestrator level), a ChildRoleOverride object (role-specific policy additions or relaxations), and a ConflictResolutionStrategy enum (PARENT_WINS, CHILD_WINS, STRICTEST, or MANUAL_REVIEW). The resolver calls the LLM with the prompt template, parses the output against a strict JSON schema that includes inherited_policies, overridden_policies, conflict_log, and final_policy_block fields. Validate the output before injection: confirm that no parent safety rules were silently dropped unless explicitly overridden in the conflict log, check that the final policy block does not exceed the child agent's context budget, and verify that all refusal boundaries from the parent are either preserved or explicitly documented as overridden. If validation fails, retry once with the validation errors injected into the prompt as feedback. If the retry also fails, escalate to a human reviewer and block the child agent from spawning.

For production deployments, log every policy inheritance event with an immutable audit record. Capture the parent policy hash, child role identifier, conflict resolution strategy used, the raw LLM output, the validation result, and the final injected policy block. This audit trail is critical for governance reviews, incident response, and debugging unexpected child agent behavior. Avoid the temptation to cache inherited policies indefinitely; policy inheritance should be re-evaluated whenever the parent policy set changes, the child role definition is updated, or the orchestrator's safety posture shifts. Treat the inheritance prompt as a dynamic policy compiler, not a static configuration file. For high-throughput systems, consider running the inheritance prompt asynchronously and pre-compiling policies for frequently used child roles during deployment rather than at request time.