Delegating a goal

Instead of driving the page itself, your agent can hand Deputy a goal and let it work. Deputy knows the page, the session you're signed into, and what each form accepts. Your agent never needs to see the page.

delegate_goal

{ "goal": "search for a cordless drill under $80" }

Deputy looks at the tab (the active one, unless your agent passes a tabId), and its planner chooses one of the tab's tools and the arguments for it. Then Deputy calls the tool and reports back:

{
  "state": "completed",
  "artifact": { "tool": "…", "args": { }, "result": "…" },
  "steps": ["looking at …", "calling … with …"],
  "taskId": "…"
}

A delegation works with the forms of one tab. If the tab has none, the task fails with exposes no tools, even after grafting. It may have no forms.

With Deputy Pro, the planner is Deputy's hosted model. If you set your own OPENROUTER_API_KEY, that key is used instead (Settings).

Task states

Tasks use the A2A protocol's state names, because they cover the two things a browser agent runs into all the time: needing a decision, and needing someone to sign in.

Deputy uses A2A's vocabulary, not its wire format: tasks are reached through the three MCP tools on this page.

When a task needs you

• If your client can show approval prompts, Deputy asks you there. Approve, and the task carries on; decline, or leave it unanswered, and it stops with Not done: no approval came back.
• If it can't, delegate_goal returns the paused task with a note to ask you. Once you've decided, or signed in to the site in your browser, your agent calls answer_task and the task resumes.

task_status and answer_task

delegate_goal counts against Pro's hosted actions, like browser_ask and browser_look (see Open source and Pro).