Delegate Work to a Colleague and Keep the Owner in Control

This recipe shows one pattern end to end: a manager AI employee takes a request, plans it, asks the owner to confirm, and delegates to a specialist employee. The specialist drafts, then stops at an owner approval. The owner can send the draft back for changes or approve it, and only an approval produces the final file.

The example is a General Manager asking a Proposal Writer for a one-page proposal. The same shape fits any “draft, review, finish” job.

Engine in production, the demo on staging

The engine pieces are in production since 2026-11-05: the awaiting_approval status, publishing an approval workflow that a sub_agent targets, and request changes through the API. The General Manager and Proposal Writer employees and the workspace app screens (request-changes button, hire panel) are a demo on the staging-backed app, in Wetel-prepared workspaces, and are not hired into production workspaces. You cannot assemble the whole pattern yourself through the API today (see Honest limits). Read it as a description of how the demo works. The status page carries the current status.

What the owner sees

1. The owner tells the General Manager: “Draft a proposal for a small clinic.”
2. The General Manager answers with a short plan and asks the owner to confirm. Nothing is delegated yet.
3. The owner confirms. The General Manager hands the task to the Proposal Writer.
4. The Proposal Writer drafts the proposal text. Its workflow then stops at an owner approval. The General Manager tells the owner the draft is waiting in Approvals, with the request id, and that nothing has been sent.
5. In Approvals the owner reads the draft and either requests changes (with a note), rejects, or approves.
6. On a request for changes, the Proposal Writer revises using the note and opens a new request. This can happen up to 3 times.
7. On approval, the Proposal Writer lays the text out as a one-page proposal and saves it to Documents as a draft. Nothing is emailed or sent to anyone.

The two graphs

flowchart TD
  subgraph GM["General Manager"]
    d["decide (llm)"] --> st{"stage"}
    st -- "PLAN or ANSWER" --> say["response: plan, asks to confirm"]
    st -- "CONFIRMED" --> sub["sub_agent: Proposal Writer"]
    sub --> r{"router on status"}
    r -- "ok" --> sum["summarise, response"]
    r -- "awaiting_approval" --> wait["response: waiting for owner, request id"]
    r -- "default" --> fail["response: could not reach"]
  end
  subgraph PW["Proposal Writer"]
    draft["draft (llm)"] --> ap{"approval (owner only)"}
    ap -- "changes_requested" --> draft
    ap -- "approved" --> page["generate_artifact: html_page"]
    ap -- "rejected or expired" --> no["response: nothing generated"]
    page -- "success" --> done["response: saved to Documents"]
    page -- "failure" --> pf["response: page failed"]
  end
  sub -. "dispatch" .-> draft

The General Manager’s turn ends when the Proposal Writer pauses. The owner’s later decision resumes the Proposal Writer’s run, not the General Manager’s.

The General Manager side

The manager decides in one llm node whether the user is still planning, has confirmed, or is just asking a question, using a structured output (outputSchema) so a router can branch on the stage. The delegation is a sub_agent node:

{
  "id": "n_sub_proposal_writer",
  "type": "sub_agent",
  "config": {
    "targets": [{ "agentId": 123, "contextTemplate": "{{gm.task}}" }],
    "resultVar": "specialist",
    "timeoutMs": 90000
  }
}

Then a router reads the result. The branch you add for this recipe is awaiting_approval:

{
  "id": "n_status_proposal_writer",
  "type": "router",
  "config": {
    "variable": "specialist.0.status",
    "defaultTarget": "n_fail_proposal_writer"
  }
}

with outgoing edges labelled ok (summarise and reply) and awaiting_approval (reply that the draft waits for an owner). The waiting reply is a plain response template:

Proposal Writer has prepared this and it is waiting for an owner to approve it in Approvals (request #{{specialist.[0].approvalId}}). Nothing has been sent or published until the owner decides.{{#if specialist.[0].text}}

{{specialist.[0].text}}{{/if}}

See A target that waits for an owner approval for the result shape. The status is additive, so a graph that only checks for ok is unaffected.

The Proposal Writer side

Draft, approve, and finish:

[
  {
    "id": "n_draft",
    "type": "llm",
    "config": {
      "systemPrompt": "…the Proposal Writer's instructions…",
      "promptTemplate": "{{userMessage}}{{#if proposalDecision.comment}}\n\nThe owner sent the previous draft back. Their feedback: {{proposalDecision.comment}}\n\nPrevious draft:\n{{proposalDraft}}\n\nWrite the revised draft.{{/if}}",
      "outputVar": "proposalDraft"
    }
  },
  {
    "id": "n_proposal_approval",
    "type": "approval",
    "config": {
      "titleTemplate": "Example proposal draft needs owner review",
      "summaryTemplate": "{{proposalDraft}}",
      "approverRole": "OWNER",
      "expiresAfterSeconds": 604800,
      "saveAs": "proposalDecision"
    }
  },
  {
    "id": "n_page",
    "type": "generate_artifact",
    "config": {
      "artifactType": "html_page",
      "promptTemplate": "Lay out the approved proposal text below as ONE clean, print-friendly page of static HTML and inline CSS… no price, no figure, no customer name.\n\n{{proposalDraft}}",
      "titleTemplate": "Example proposal (draft)"
    }
  }
]

Edges out of the approval node: approved to n_page, rejected and expired to a “nothing generated” reply, and changes_requested back to n_draft. Because saveAs holds the owner’s note as proposalDecision.comment, the draft node can tell a first draft from a revision. See the approval node for request changes, and Generate Artifact for html_page.

Honest limits

• Demo on staging, engine in production. The status page marks delegation with owner approval as live because the engine support is in production, but the example employees and the workspace app screens are a demo. Do not promise a customer those screens on a production workspace until the status page and your Wetel contact say so.
• Publishing through the API. publishWorkflow no longer refuses an approval node in a workflow that is another workflow’s sub_agent target (changed 2026-11-05, in production since that date). Request changes and the awaiting_approval status are in production as well; the demo’s graphs are still set up by Wetel.
• At most 3 revisions. After the third request for changes, the owner can only approve or reject.
• Drafts only. The result is a draft one-pager labelled “Example”, with no prices. The employee is told never to invent a customer name, a figure or a capability.
• Nothing is sent until approved, and nothing is sent after either. Approval saves a page to Documents. There is no email or outward delivery in this flow.
• Owner only. Only a workspace owner decides. API keys cannot.
• The manager is not called back. After the owner decides, the General Manager does not report the outcome in the chat. The owner finds the page in Documents.
• One task per request. The manager delegates one task to one employee per confirmed request; it is not a project planner.
• The page is generated by a model. Review it like any draft. Artifact generation has its own limits and switches; see Generate Files: Voice and Video.

Related

• Delegate to a Specialist: the plain sub_agent pattern with inputs and outputs.
• Human approval: a walkthrough: approvals on their own.
• Triage a Support Ticket End to End: an approval inside one workflow.