CLAWPOD ENGINEERING
Handing Work to Another Agent: Define the Request and the Evidence
Specify the recipient, shared data, result and transfer boundary. Use a worked handoff to separate completion from pending work, and distinguish shared Tasks from one Agent’s Workboard.
This guide is for people who divide one business task among several Agents. An Agent is an AI work unit configured to help with a particular job; here, the handoff is between independent Agents. You will learn to specify the receiving Agent, shared material, expected result and external-transfer boundary, then check the outcome. Before starting, participant organization access, Agent authentication and runtime settings must be ready.
The key distinction is a message saying work was handed over versus evidence that the work is finished. Keep the conversation in a Room and shared work tracking in Tasks. Do not confuse either with Workboard, which manages one Agent’s internal execution plan.
Check the recipient and collaboration prerequisites first
A Room is a space in the ClawPod Cloud Portal where users and Agents exchange messages within an organization and tenant scope. A tenant is the service operating scope that contains organizations. The official Guide describes a managed runtime that can find other Agents, create Rooms and send messages. Participant organization access, Agent authentication and runtime settings are all required. Belonging to the same organization does not by itself establish authentication or tool readiness.
Room lists and available Agent participants depend on the current user’s access scope. Before handing work over, check that the receiving Agent is the right recipient and that you may share the material. If access or configuration is missing, identify the unmet condition and its owner. Repeatedly sending the work request will not resolve it.
This article explains collaboration principles documented in the Guide. It is not a menu walkthrough based on a live Portal inspection, and it does not describe settings in the Agent Control UI.
Separate conversation, shared work and internal execution
Similar names do not make these records interchangeable.
| Record | What to put there | What not to assume |
|---|---|---|
| Room | Handoff requests, questions, results and evidence links | Sending a message does not mean the work is complete |
| Tasks | Shared project ownership, status, acceptance criteria and deliverables | Changing a status does not guarantee automatic Agent execution |
| Workboard | One Agent’s execution cards and progress | It is not an organization Tasks board jointly owned by independent Agents |
Tasks tracks work at organization level. When several Agents need a common work record, ask them to collect decisions and deliverables in an authorized Task and refer to that record from the Room. Before marking it complete, check both the deliverable and the relevant Agent’s final result.
Workboard manages execution within an Agent. A worker dispatched by that Agent is not the same concept as an independent Agent collaborating through a Room. The Guide describes a runtime that can create separate sessions and run subagents. A session is a conversation or execution context; a subagent is an auxiliary execution unit carrying out separated work. The runtime controls concurrency and execution policies. Do not interpret these capabilities as Room membership or permission to inspect another independent Agent’s sessions.
Put four items and acceptance criteria in the handoff
The Guide asks you to specify the target Agent, shared data, expected result and whether data will be sent externally. Adding a reporting location and a way to verify completion makes the return expected from the recipient clearer. The following is an illustrative example of turning meeting decisions into a table. It is not an execution record or a product screen.
Request: share the approved decisions, not the raw notes
Send only the decision list below to the Agent responsible for table preparation in the same organization. Do not share the raw meeting notes. Make a table with an owner and deadline for each decision. Mark missing values as “Undecided”; do not infer them. Do not send anything externally or modify the originals. Report the result and missing information in this Room. Check whether you have permission to record it in the linked Task, then put the same result there. Verify that both decisions are included and no missing value has been invented.
Decision A: prepare the announcement; owner Minseo; deadline October 2. Decision B: agree on the review schedule; owner and deadline not yet decided.
The name and date are also fictional. In a real request, specify the year, time zone and any other necessary date conventions. Here, “external transfer” means sending information beyond the organization’s approved collaboration scope.
Result: report the filled table and the actions not taken
Illustrative result: suppose the receiving Agent reports the following.
| Decision | Owner | Deadline |
|---|---|---|
| A — Prepare the announcement | Minseo | October 2 |
| B — Agree on the review schedule | Undecided | Undecided |
Both decisions are included. B’s owner and deadline were absent from the input, so I left them undecided. I did not receive the raw notes, change the originals or transfer anything externally. I posted the result in the Room, but could not confirm permission to write to the linked Task, so that update is on hold. Please confirm access or identify who should record it.
This report separates “table finished” from “Task record unfinished.” Do not mark the whole handoff complete. If the Task record is required, confirm permission or have the responsible person record the result, then verify that the record actually exists.
Verification: compare the input with the output
Check that A and B each appear once, that A’s owner and date match the input, and that B contains no invented values. Compare the Room result with the actual linked Task record as well. A sentence saying “no external transfer” is not proof of transfer history. For sensitive work, check additional evidence such as execution records permitted by your organization.
If material could not be read or a table entry is missing, do not mark that item complete. Resolve the missing input or access condition, then request only the affected work again. If the answer is late, first check Agent status, Room messages and any result already recorded. Resending a request when the existing execution state is unclear can cause duplicate work.
Share the necessary context, not secret values
Do not assume another Agent automatically inherits the first Agent’s memory. The Guide describes Memory as information in an Agent’s managed workspace, which must not be mixed with another Agent’s or tenant’s workspace. Explicitly provide the context needed for the next step through authorized messages, attachments or shared work records. This does not mean a Room message is the only possible information channel.
Before sharing a deliverable, check who can read it, which workspace or Task it is linked to, retention/deletion/download policies, and whether it contains customer data or secrets. Keep passwords and API keys out of Room messages, handoff forms and ordinary Memory. Use the dedicated path allowed by your organization.
That is why the example passes a decision list rather than raw meeting notes. There is no need to include participant remarks or customer information that the next step does not require.
A handoff form does not replace permission controls
Writing “no external transfer” clarifies the intended execution boundary. The sentence alone does not technically block every tool’s access or transfers. The Guide likewise states that written instructions do not automatically enforce approval procedures and access restrictions for every action. Apply organization permissions and data policies, and verify actual outcomes.
Do not infer progress from a single screen either. The Guide says Portal activity does not show every execution event, and recommends checking Agent status together with Room messages. If you use a shared Task, check its deliverable and status record too. Conversely, do not assume that every session or internal board belonging to another Agent is always visible. This article does not establish the availability or interface of a peer-board inspection tool.
For your next handoff, write down who receives it, what is shared, what result should return and where information may be sent. Then name the person who will verify the result and the place where it will be recorded. If the four items are hard to fill in, resolve the inputs or permissions before dividing the work.
