Skip to content

docs(rfd): prompt queueing RFD #484

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
SteffenDE wants to merge 1 commit into
base: main
Choose a base branch
from
+57 −0
Draft

docs(rfd): prompt queueing RFD #484

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 57 additions & 0 deletions docs/rfds/prompt-queueing.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
title: "Prompt Queueing"
---

Author(s): [SteffenDE](https://github.com/SteffenDE)

## Elevator pitch

> What are you proposing to change?

Add a new `promptQueueing` session capability, that tells client if the agent supports sending prompts while another prompt is already being processed for that session.
The Claude Code CLI supports writing a user message while the agent is working and injects that message at the next opportunity (i.e. after the current turn is finished).

Since ACP prompts can consist of many agent turns, having an officially supported way to adjust running prompts is very useful.

## Status quo

> How do things work today and what problems does this cause? Why would we change things?

Today, the specification does not mention what should happen when sending a concurrent prompt request.
Clients cannot assume that this is supported, so running prompts need to be canceled when a client wants to allow users to send a new prompt while an existing one is running.

## What we propose to do about it

> What are you proposing to improve the situation?

Add a capability that tells clients if parallel prompt requests are supported.

## Shiny future

> How will things will play out once this feature exists?

If an agent supports prompt queuing, clients can send parallel prompt requests and be sure that the agent will handle them properly.

## Implementation details and plan

> Tell me more about your implementation. What is your detailed implementation plan?

The idea is to use whatever mechanism the agent has to queue incoming prompts and if a new prompt arrives and is processed at the next opportunity,
the existing is finished early `end_turn` (or optionally a new stop reason). This allows the client to inject the new user message at the correct place
in the conversation, since session updates are not tied to a particular prompt request.

## Frequently asked questions

> What questions have arisen over the course of authoring this document or during subsequent discussions?

None so far.

### What alternative approaches did you consider, and why did you settle on this one?

I was thinking that maybe clients could first send a `session/cancel` with a new parameter `afterCurrentTurn: true` to indicate that the current turn should be finished.
Right now, the protocol tells clients to immediately mark tool calls as canceled when sending `session/cancel`, but for queued prompts, currently running tool calls
should be able to finish.

## Revision history

<!-- If there have been major updates to this RFD, you can include the git revisions and a summary of the changes. -->