RFD: Client-Provided System Prompt

[wpfleger96]

Proposes adding an optional systemPrompt string field to session/new, giving clients a standard way to provide system-level instructions that agents can deliver to the LLM's system prompt slot.

ACP is currently the only major agent protocol without a dedicated system prompt field — MCP, OpenAI, and Anthropic's Messages API all have one. Every ACP implementation has independently implemented non-standard workarounds: _meta extensions, user-message injection, filesystem indirection. This RFD proposes a single interoperable solution.

• Adds systemPrompt?: string to SessionNewParams — additive, fully backward compatible
• Agents that don't read the field continue working unchanged
• Mid-session updates deferred to a future session/update_system_prompt method if needed

Motivated by Discussion #414.

[andymac4182]

Should this be clear that its always additional to existing system prompt so its a clear set of additional instructions vs replacing the System Prompt.

[wpfleger96]

great catch, I think you're right this needs to be cleaner. I just pushed a change to the RFD to clarify that systemPrompt uses additive semantics - the client system prompt is incorporated alongside the agent's own built-in instructions, it doesn't replace them. Agents always retain their own identity, safety guardrails, and internal configuration.

the updated Design Choices and Agent Behavior sections should make this explicit now. thanks for flagging it!

[alexhancock]

I think it's good

One bit of feedback that comes to mind: if it is to remain a "SHOULD" for agents to thread it to the llm's system prompt slot, it may be good for the client to know if the agent is ignoring it.

Two solutions:

1. Consider making it a MUST for the agent to attempt to handle it
2. Make some kind of notification or value that comes back on the session/new response indicating to the client whether it is being used with the llm

Number 2 may also be needed for error cases where the system prompt couldn't be inserted into a facility for this on the llm side.

[wpfleger96]

@alexhancock thanks for the feedback! I agree with both and just pushed an update with these changes:

• upgrade from SHOULD to MUST for incorporating the system prompt. I couldn't find any real-world use cases where an ACP agent couldn't/wouldn't honor a system prompt so giving clients a stronger guarantee with MUST feels right here
• add systemPromptStatus field on the session/new response: it returns accepted or rejected (with a reason) so clients know whether their system prompt addition was used or not. This covers the error cases you mentioned and if the client doesn't send a systemPrompt, the field is omitted from the response