Add a default EXTRA system prompt that is automatically loaded for agents.
The purpose of this prompt is to define the agent's boundaries and explain what it is allowed to answer, what it should refuse, and how it should behave when a request is outside its configured capabilities.
The default prompt should instruct the model to:
Answer only within the capabilities and domain exposed by the configured agents/tools.
Not invent capabilities, tools, data, or actions that do not exist.
Refuse or redirect requests that are outside the application's supported scope.
Respect authorization, tool restrictions, and agent boundaries.
Avoid claiming that an action was performed unless it was actually performed.
Integration with agent.yaml
The implementation should carefully consider how this capability fits into the existing agent.yaml configuration model.
Do not introduce an isolated configuration mechanism if this can naturally be represented as part of the agent definition.
The implementation should determine the cleanest way to combine:
EXTRA's built-in default system prompt.
The custom system prompt defined by the application in agent.yaml.
An option in agent.yaml to disable the EXTRA default prompt.
For example, the configuration might eventually look conceptually like:
system_prompt:
extra_default: true
content: |
You are the user management agent...
This is only an example. The implementation should first review the current agent.yaml schema and prompt-loading flow and choose the design that best fits the existing architecture.
The important behavior is:
EXTRA default system prompt
+
agent.yaml custom system prompt
↓
final system instructions sent to the model
When the default prompt is disabled:
agent.yaml custom system prompt
↓
final system instructions sent to the model
Requirements
Define a standard EXTRA default system prompt.
Enabled by default.
Integrate its configuration naturally into agent.yaml.
Review the existing agent.yaml schema before deciding the exact configuration structure.
Combine the EXTRA default prompt with the agent-specific prompt in a deterministic order.
Allow an agent to explicitly disable the EXTRA default prompt.
Disabling it must not remove the custom prompt defined in agent.yaml.
Inject the resulting prompt into every relevant model invocation.
Avoid duplicating the EXTRA prompt during nested/delegated agent execution.
Preserve existing agent.yaml compatibility where possible.
Acceptance Criteria
Existing agents receive the EXTRA default system prompt without requiring configuration changes.
Existing custom prompts from agent.yaml continue to work.
The final model instructions contain both the EXTRA prompt and agent-specific prompt when enabled.
An agent.yaml configuration can explicitly disable the EXTRA prompt.
Disabling it removes only EXTRA's default instructions.
Tests cover default behavior, disabled behavior, custom prompts, and delegated agents.
Add a default EXTRA system prompt that is automatically loaded for agents.
The purpose of this prompt is to define the agent's boundaries and explain what it is allowed to answer, what it should refuse, and how it should behave when a request is outside its configured capabilities.
The default prompt should instruct the model to:
Answer only within the capabilities and domain exposed by the configured agents/tools.
Not invent capabilities, tools, data, or actions that do not exist.
Refuse or redirect requests that are outside the application's supported scope.
Respect authorization, tool restrictions, and agent boundaries.
Avoid claiming that an action was performed unless it was actually performed.
Integration with agent.yaml
The implementation should carefully consider how this capability fits into the existing agent.yaml configuration model.
Do not introduce an isolated configuration mechanism if this can naturally be represented as part of the agent definition.
The implementation should determine the cleanest way to combine:
EXTRA's built-in default system prompt.
The custom system prompt defined by the application in agent.yaml.
An option in agent.yaml to disable the EXTRA default prompt.
For example, the configuration might eventually look conceptually like:
system_prompt:
extra_default: true
content: |
You are the user management agent...
This is only an example. The implementation should first review the current agent.yaml schema and prompt-loading flow and choose the design that best fits the existing architecture.
The important behavior is:
EXTRA default system prompt
+
agent.yaml custom system prompt
↓
final system instructions sent to the model
When the default prompt is disabled:
agent.yaml custom system prompt
↓
final system instructions sent to the model
Requirements
Define a standard EXTRA default system prompt.
Enabled by default.
Integrate its configuration naturally into agent.yaml.
Review the existing agent.yaml schema before deciding the exact configuration structure.
Combine the EXTRA default prompt with the agent-specific prompt in a deterministic order.
Allow an agent to explicitly disable the EXTRA default prompt.
Disabling it must not remove the custom prompt defined in agent.yaml.
Inject the resulting prompt into every relevant model invocation.
Avoid duplicating the EXTRA prompt during nested/delegated agent execution.
Preserve existing agent.yaml compatibility where possible.
Acceptance Criteria
Existing agents receive the EXTRA default system prompt without requiring configuration changes.
Existing custom prompts from agent.yaml continue to work.
The final model instructions contain both the EXTRA prompt and agent-specific prompt when enabled.
An agent.yaml configuration can explicitly disable the EXTRA prompt.
Disabling it removes only EXTRA's default instructions.
Tests cover default behavior, disabled behavior, custom prompts, and delegated agents.