Problem
#49 shipped the in-process abort (session.prompt(text, { signal }) / CallHandle.abort()), which works great when you hold the handle. But it also proposed an HTTP / remote abort — "expose a run id and provide an abort endpoint" — for streamed / SDK-driven callers. That half moved to discussion #91 ("Agent lifecycle control API") and closed without landing.
The result: apps that drive agents over @flue/sdk (agents.send / agents.stream) have no way to stop a running turn. Passing a signal to agents.send only cancels the client's wait — it does not stop the server-side run (the request-abort is a no-op server-side). For a headless app that wants a reliable "Stop" button, there's currently no supported mechanism.
Notably, the hard part already exists in the runtime: agent-submissions.ts holds the CallHandle and wires an incoming AbortSignal to handle.abort(reason) (today used for shutdown). So the cancellation machinery is in place — what's missing is an external trigger.
Proposal
Expose the existing cancellation over the transport:
- A
POST /agents/:name/:id/abort (or /runs/:runId/abort) endpoint that aborts that instance's in-flight submission via the existing signal → handle.abort() path, without deleting the session or losing conversation history.
- An
agents.abort(name, id) method on the SDK client.
This is the HTTP counterpart to the in-process API from #49, reusing the runtime's existing abort wiring.
Why
Stop / interrupt is the one piece of agent control that SDK / remote-driven apps can't do today, even though the runtime already supports it internally. It also provides a clean basis for "stop + resend" steering on top of the durable session store.
Happy to open a PR — the abort plumbing already exists, so this is largely a route + a small controller registry + the SDK method.
Problem
#49 shipped the in-process abort (
session.prompt(text, { signal })/CallHandle.abort()), which works great when you hold the handle. But it also proposed an HTTP / remote abort — "expose a run id and provide an abort endpoint" — for streamed / SDK-driven callers. That half moved to discussion #91 ("Agent lifecycle control API") and closed without landing.The result: apps that drive agents over
@flue/sdk(agents.send/agents.stream) have no way to stop a running turn. Passing asignaltoagents.sendonly cancels the client's wait — it does not stop the server-side run (the request-abort is a no-op server-side). For a headless app that wants a reliable "Stop" button, there's currently no supported mechanism.Notably, the hard part already exists in the runtime:
agent-submissions.tsholds theCallHandleand wires an incomingAbortSignaltohandle.abort(reason)(today used for shutdown). So the cancellation machinery is in place — what's missing is an external trigger.Proposal
Expose the existing cancellation over the transport:
POST /agents/:name/:id/abort(or/runs/:runId/abort) endpoint that aborts that instance's in-flight submission via the existing signal →handle.abort()path, without deleting the session or losing conversation history.agents.abort(name, id)method on the SDK client.This is the HTTP counterpart to the in-process API from #49, reusing the runtime's existing abort wiring.
Why
Stop / interrupt is the one piece of agent control that SDK / remote-driven apps can't do today, even though the runtime already supports it internally. It also provides a clean basis for "stop + resend" steering on top of the durable session store.
Happy to open a PR — the abort plumbing already exists, so this is largely a route + a small controller registry + the SDK method.