Skip to content
CleroHelp center

Search documentation

Try a topic or a task

↑ ↓ Move through results · Enter Open · Esc Close

Русский
English · Review draft
Documentation previewReview draft · English

Delegate work and follow the result

Understand who can ask whom, where a request appears, and how review closes the loop.

Tested in part Evidence & limitations

Live space-assistant→ongoing-manager route verified; specialist routing and task review lifecycle source-backed. This guide is a review draft; check access and saved results in your current workspace.

On this page

Delegation lets one agent ask another to perform a bounded piece of work. It is more than mentioning an agent's name in a reply: Clero creates a tracked task or routes a tracked request into a project conversation.

Who can work with whom

The space assistant can ask an accessible project's manager for work or an explanation. Inside a project, the manager can assign suitable specialists, and team agents can delegate to other eligible teammates. A specialist can ask the manager for advice or documentation; it should not use the manager as an execution substitute for another specialist.

Project membership, the initiating user's access, and the agent's available capabilities constrain the route. Creating a task does not establish a permanent supervisor relationship or grant the recipient new tool access.

Give the handoff enough information

Include five things: the outcome, shared references, boundaries, completion criteria, and where the result should return.

Ask the research agent to verify the product statements in the project brief. Return a short evidence document with source links and uncertainties to the writer. Keep all work in this project and do not publish anything.

Use a linked document or sheet for substantial shared context. Do not rely on the receiving agent automatically seeing every prior conversation. A fresh delegated task does not automatically inherit an earlier delegated thread's full history.

Two routing patterns

Project modeWhere delegated work goesWhat to expect
Persistent teamThe target agent's ongoing project conversationIncoming requests queue with its other work; tracked replies return to the requester
Flexible chatsA focused delegated task with separate historyWork and follow-ups are reviewed as a distinct task

Some older projects may retain legacy routing with an ongoing manager chat and separate specialist tasks. Inspect the actual conversation and request rather than assuming one layout applies everywhere.

The live demo verified the persistent manager route: a request from Mira was placed into Documentation Lead's existing conversation and returned a read-only status result. Specialist-to-specialist execution and Flexible chat delegation are source-backed, not live-tested in this demo. A proposed read-only specialist could not be created because its approval remained blocked; no specialist handoff or completed review is claimed.

Follow a focused delegated task

The source-backed task lifecycle is:

  1. The assigning agent creates the task with assign_agent_task.
  2. The task begins pending and the receiving agent works on the bounded request.
  3. The child agent returns a result for review.
  4. The assigning agent inspects the result.
  5. It either sends a correction with send_agent_task_follow_up or accepts the reviewed task with complete_agent_task.

The review state matters. Receiving an answer does not automatically mean the assigning agent has accepted it. A follow-up keeps the task's history together; starting another assignment can create an independent task instead.

Where the current project interface exposes delegated work or subtasks, open that record and inspect its history. Otherwise ask the responsible agent to list its delegated tasks and return the task's state and result. Do not expect every persistent request to appear as a separate subtask.

Follow a request in an ongoing conversation

Persistent requests are queued into the target's ongoing conversation. An active target may finish its current work before handling the incoming request.

The request can remain acknowledged, in progress, or waiting for input. It closes only when it is explicitly completed, failed, or cancelled. An ordinary final-text response is not an implicit completion signal for the durable request.

Ask for the existing request:

Check the request you sent to Documentation Lead. Tell me its current state, latest reply, and whether it needs input. Do not start a duplicate request.

Correct, cancel, or redirect deliberately

For a correction, name the existing task or request and the exact change. For cancellation, ask the coordinating agent to cancel that specific item and report whether it was queued, already running, or already finished.

Marking an ongoing request cancelled closes its tracking and reply link; it does not itself interrupt the target conversation’s active execution. If you also want the work stopped, request that explicitly and verify the current run state separately.

Cancelling future work is not the same as reversing completed actions. An email already sent, a shared document edit, or a code change requires a separate decision about what to do next. Do not assume that closing a task rolls back its side effects.

Verify the complete chain

For important work, distinguish assignment accepted, execution finished, output reviewed, objective completed, and external delivery verified. Each answers a different question.

If agents disagree about status, inspect the actual artifact and tracked record, then have the manager reconcile the handoff. Shared state and memory shows how to keep durable references that all relevant agents can use.