RFD: Client-Provided System Prompt - #1237
Conversation
b93753b to
68a1067
Compare
68a1067 to
3cf1268
Compare
|
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:
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. |
3cf1268 to
4e4a566
Compare
|
@alexhancock thanks for the feedback! I agree with both and just pushed an update with these changes:
|
4e4a566 to
2331a57
Compare
It seems wrong to have the session created if the |
2331a57 to
cb74b20
Compare
@aleclarson good call, that's a much cleaner design. I just pushed an update that drops |
|
We've built a working implementation of this RFD in block/sprout#981 — a Rust ACP agent ( Key implementation details:
|
cb74b20 to
526537e
Compare
There was a problem hiding this comment.
Pull request overview
This PR adds a new RFD documenting a proposal to let clients provide system-level instructions at session creation time, so agents can place them into the LLM’s system prompt slot in a consistent, interoperable way.
Changes:
- Introduces an RFD describing
systemPromptsupport forsession/new, including capability advertisement and validation rules. - Specifies append vs. override delivery modes (with
overridegated behind a sub-capability). - Documents backward-compatibility and client/agent MUST-level behaviors, plus rationale and alternatives.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
526537e to
c2189e4
Compare
…ppend/override modes Addresses maintainer review: an optional field without a capability is a de facto breaking change (old agents may silently ignore or reject unknown params, and protocolVersion is major-only so it cannot signal additive features). Adds a systemPrompt capability under sessionCapabilities, switches the field type to ContentBlock[] with a text-only baseline, and specs both append (default, universal baseline) and override (sub-capability-gated) delivery modes since shipping harnesses already support both. Co-authored-by: Will Pfleger <wpfleger@block.xyz> Signed-off-by: Will Pfleger <wpfleger@block.xyz>
c2189e4 to
4969bbb
Compare
| title: "Client-Provided System Prompt" | ||
| --- | ||
|
|
||
| Author(s): [@wpfleger96](https://github.com/wpfleger96) (Block — contributor to [Buzz](https://github.com/block/buzz) and [Goose](https://github.com/aaif-goose/goose)) |
Proposes a standard way for clients to provide system-level instructions at session creation, so agents can deliver them to the LLM's system prompt slot.
ACP is currently the only major agent protocol without a dedicated system prompt mechanism. MCP, OpenAI, and Anthropic's Messages API all have one. Every ACP implementation has independently implemented non-standard workarounds:
_metaextensions, user-message injection, filesystem indirection. This RFD proposes a single interoperable solution:systemPromptcapability undersessionCapabilities, advertised atinitialize, so clients have reliable feature detection before sending the fieldsystemPromptfield onsession/new, typed asContentBlock[]for consistency withsession/prompt, with text as the universal baselinesystemPromptModefield:append(default and universal baseline) andoverride(double opt-in, gated behind anoverridesub-capability)session/load/session/resumeand inherited bysession/forkMotivated by Discussion #414.