delegateToAgent

Hand an organisation agent a brief (a piece of work, big or small) and get its job back. The job runs in the background, in steps, and this call waits for it for up to waitSeconds (default 20, at most 45): a job that settles in time comes back with its outcome and, once finished, its receipt (a short summary, counts of what changed, links, issues that need a person); otherwise you get status: running (or queued), progress and pollAfterSeconds, and you follow it with getAgentRun. Changes that must wait at the run's approval level (approvalMode, else the agent's own level) land in the approvals inbox and in pendingApprovals; decide them with approveAgentAction. Pass the same idempotencyKey when you retry. A job that reaches its budget (model steps, tool calls, tokens or 30 minutes of work) pauses with a summary of what is done and left: continue it, with a fresh budget, by calling delegateToAgent with continueRunId (no brief needed). A job whose requester loses access to what it needs pauses as rights_changed. Plan mode: with mode: plan, or at confirm and confirm_destructive when the job would make more than five changes or delete anything, the agent first drafts the complete change set (reads run, nothing changes) and the job waits for ONE approval of the whole plan: pendingApprovals holds it with the counts, any tool fees and the first steps, and getAgentRun plan pages every step with its preview. Approving runs exactly those steps, in order, with no model in between. If an item a step changes was edited after the plan was drafted, the job pauses as conflict naming it; continuing the job re-plans the remaining steps as a new plan that needs its own approval. Undo: pass undoRunId (no brief needed) to undo a finished job. The undo is a job of its own, acting for you: the agent builds the compensating plan from what the job journaled (restore each edited document to its version before the job, move items back, put fields back, delete what the job created) and it waits for ONE approval like any plan. An item changed since the job is skipped, never overwritten, and the plan lists what cannot be undone (permanent deletes, effects outside Stable Baseline such as a meeting bot, and tool fees already charged, which stay charged). The job's requester, the agent's owner and its managers may undo it; getAgentRun undo says whether you may now. It is categorised as a Destructive tool in the Stable Baseline MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.

delegateToAgent accepts 8 parameters: mode, brief, agentId, undoRunId, waitSeconds, approvalMode, continueRunId, idempotencyKey. Required: agentId. The full parameter table on this page comes from the server's own tool schema.

Register the Stable Baseline MCP server in PolicyLayer and add a rule for delegateToAgent: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Stable Baseline. Nothing to install.

delegateToAgent is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.

Yes. Add a rate_limit block to the delegateToAgent rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for delegateToAgent. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

delegateToAgent is provided by the Stable Baseline MCP server (https://api.stablebaseline.io/functions/v1/cloud-serve/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.