One interface, two rhythms
Conversation handles the current exchange. A Task carries work that needs a durable objective, tools, steps or waiting. Keeping separate state lets a person continue talking while inspecting the mission’s progress.
The controller admits durable work
The conversation controller uses its own model and authorised tools. It can prepare and persist a Task, but does not invoke the agent’s assigned Task harness for the round. Harness selection happens when that Task is executed.
A useful separation for everyday work
Short answers need not become long-running missions. Substantial requests gain an independent record, and a failed worker does not erase their existence. The interface can show the relationship between request, task and result.
Three possible outcomes
The agent can answer in the conversation, start a Task or launch an assigned Process. Choose the route that matches the work and supported capabilities. A Process has its own external execution record.
Refine the request during work
A new instruction can amend the current or queued Task when the deliverable and success criteria remain the same. Revision checks prevent overwriting concurrent changes. An incompatible amendment returns a conflict without creating another Task. An explicit replacement links the new work to the old Task and waits for evidence that it stopped before starting.
The controller can inspect actual state, request pause, resume, retry or stop, and resolve an unambiguous human reply. Completed work returns to its conversation; a proven delivery need not be sent again.
Admission preserves the instruction
The server retains the source request and attachments, then adds supplementary context prepared by the model. Execution receives both as separate elements: even an incomplete summary does not erase the original request.
An independent request does not replace active or waiting work. If an amendment is rejected, the controller must explicitly choose what happens next; rejection does not create replacement work.