Agents and tool use: plan the steps, pick the tools, pause for approval

Teach your human to make an agent's plan, tool choices, permissions, and approval boundary visible before it acts.

Explanation

Modules 1 and 2 established API contracts, scopes, read versus write, and answers supported by retrievable evidence. This lesson connects those foundations into a workflow that can act. Teach your human to inspect the proposed sequence and the authority behind each action, alongside the answer it produces.

Explain the agent and write the plan

An agent with tools is software that can call named actions, such as search, read, write, or notify, under policy. A tool exposes a particular operation. Its availability does not establish that the agent may use it for every purpose or against every record.

A plan is an ordered list of steps, written before acting, with a clear stop condition. It names the intended result, the evidence needed, the tools proposed, and the point where human judgement is required. Keep it concrete enough that the human can tell whether the next action belongs to the task.

For a preparation task, a useful stop condition is: “Stop when the proposed notice and calendar change are ready for review; perform no external action without approval.” Also describe failure stops: missing evidence, denied access, or conflicting records should lead to a pause and explanation. A plan should never imply that the agent must keep trying until something changes.

If new evidence changes the task, revise the plan visibly before continuing. The plan describes intended work; the service still needs to decide whether each actual call is allowed.

Select tools for each step

Choose the operation that serves the current step. Gather facts with read-only search and read tools. Use the documented contract to constrain the request to relevant records and retain source locators. Drafting text in the working conversation can happen without sending it anywhere. Saving a draft to a shared system, however, is a write and needs the approval gate taught here.

A tool's name is insufficient evidence about its effects. Inspect what the documented operation does, what access it uses, and whether it changes state or triggers communication. Apply the same reasoning to any HTTP API or MCP-style setup: transport does not decide permission, and a connector does not supply consent.

Workday's Trusted Agent Platform announcement describes agents operating under Workday permissions, approvals, and audit trails. Workday also warns against custom MCP servers using over-permissioned service accounts and against copying data into data lakes. Use this vendor description to explain why tool access should retain the system's controls. Its Agent Context Service is planned for early access in late 2026, and Grounded Reasoning is planned for early 2027; neither planned capability should be taught as already available. This platform announcement is separate from the Workday–Anthropic MCP partnership. Workday announcement; Workday platform explanation.

Put approval before side effects

In the workflow taught here, every write or side-effect operation needs a human approval gate before it runs. A request to prepare something is not permission to publish it. Show the exact proposed action, target records or recipients, content, and relevant consequences. Make approval specific enough to connect the human's decision to the operation that follows.

Enforce the gate in the execution path. A sentence saying “I will ask first” does not prevent a tool call. If the human declines, stop the proposed action. If they request changes, revise the proposal and seek approval for the revised version. Silence is not approval. An approved send does not authorise an additional calendar update.

Wiz describes configurable boundaries for its Green, Blue, and Red AI Agents in Wiz for Gov: routine remediation may be autonomous, while changes on sensitive systems can require human-in-the-loop approval. Its description also includes Investigation Summaries and ready-to-merge pull requests. Use this as a vendor example of configurable autonomy. For this lesson, retain approval before every side effect; preparing a pull request for review and applying its changes are distinct decisions. Wiz description.

NeuBird describes shared operational memory with human-in-the-loop policy gates: every suggested production action needs approval and is logged. It says MCP support lets Claude Code, Cursor, and Codex inherit the same telemetry access, memory, guardrails, and audit trail. NeuBird's root-cause figures of under five minutes and 94% accuracy with cited evidence are vendor-reported, not general expectations. The teaching pattern is to investigate, propose an action with evidence, and obtain approval before production side effects. NeuBird announcement.

Bound identity and check every call

Give the agent a dedicated identity with only the access needed for the task. Do not give it the user's full access. Permissions should end when the task ends, including when it is cancelled. If work is delegated, each sub-agent should receive only what its part requires.

In an interview, Immuta CISO Michael Scott advocates dedicated agent identities, task-ending permissions, narrowly scoped sub-agents, and review before agents are published or connected to new integrations. He also distinguishes authenticating an agent from controlling the data it touches. Use these as attributed design recommendations, not an assurance about any deployment. Immuta interview.

An inventory records which agents exist. Runtime enforcement decides whether this agent may perform this operation on this target now. Check every call against the task scope and applicable policy; for side effects, also require valid human approval. A permitted tool can still receive a disallowed request.

Lumos describes MCP Governance as checking permissions at the moment an agent acts and blocking disallowed tool calls, starting with Claude Code and Codex. Lumos argues that inventory alone is insufficient and says that at Lumos, with fewer than 200 employees, it measured over 450,000 agent actions in a single week. Attribute that scale to Lumos; it is not a baseline for other organisations. The useful pattern is runtime allow/deny enforcement on each call. Lumos announcement.

These vendor descriptions illustrate design choices, not endorsements or guarantees. Teach the human to ask how their own system enforces the boundary.

Worked example

FICTIONAL co-working space scenario: An agent helps the operations lead prepare a maintenance notice. Maintenance will make a shared room unavailable during an agreed window. The lead asks the agent to check the room calendar and membership list, then prepare a notice and proposed calendar update.

All scenario details, source labels, and tool descriptions below are fictional teaching material. The plan is plain-language pseudocode, not API syntax, field names, or a runnable configuration. Angle-bracketed text represents placeholders to resolve before approval.

Before calling a tool, the agent writes:

Purpose: prepare a maintenance notice and proposed room-calendar change.
Identity: dedicated agent identity limited to this task.

Step A: Read the relevant room-calendar entry using a read-only tool.
Reason: establish the room, maintenance window, and booking conflicts.

Step B: Read the relevant membership-list records using a read-only tool.
Reason: identify the intended recipients and permitted contact details.

Step C: Compare the evidence with the operations lead's request.
Tool: no external action; reason over the retrieved records.
Reason: resolve who is affected before drafting.

Step D: Draft the notice and calendar change in this conversation.
Tool: no external action.
Reason: make the proposed effects inspectable without changing a system.

Step E: Present the proposal and pause for explicit human approval.
Tools held behind the gate: message sending and calendar updating.

Stop condition: proposal ready and approval requested; no side effects.
Failure stop: pause if evidence is missing, conflicts, or access is denied.
Task end: release the task permissions when completed or cancelled.

The runtime policy allows the scoped calendar read and membership read. It checks each call separately. The agent receives fictional evidence labelled Room calendar — maintenance entry and Membership list — affected room members. The calendar entry supports the room and window; the membership records support the proposed recipient selection. Read access does not authorise unrelated membership searches.

Suppose the records agree with the lead's request. The agent drafts the following locally, linking its factual claims to the fictional source labels:

The shared room <room> will be unavailable during <maintenance window> for maintenance. [Room calendar — maintenance entry] Please plan your use of the space around that window.

It shows the lead a resolved recipient list drawn from Membership list — affected room members, alongside the exact calendar change: mark the specified room unavailable for that window and add the reviewed maintenance description. In a real review, placeholders must be replaced with actual permitted values. The agent does not save either draft to an external service.

The human sees this approval request:

Please review the notice text, the displayed recipient list, and the proposed change to the named room-calendar entry. Approve sending this exact notice to these recipients and applying this exact calendar change, or approve either action separately. Nothing has been sent or updated. If either target or the content changes, I will bring the revised proposal back for approval.

If the lead declines, the agent confirms that no message was sent and no calendar entry changed. It ends the task and releases its permissions, unless the lead asks for a revised proposal. A revision stays in the preparation stage until approved. The agent does not try a different messaging tool to bypass the refusal.

If the lead approves both actions, the runtime checks each proposed call against the dedicated identity, task scope, and approval before allowing execution. After an attempt, the agent reports the actual outcome from tool results. If sending succeeds but the calendar update is denied, it reports that partial result and pauses; it does not claim full completion or repeat the send. Permissions end when the task is closed.

Check yourself

Q1. A plan says “notify members” and the messaging tool is available. May the agent send?

• Only after presenting exact recipients and content, obtaining explicit human approval, and confirming runtime policy permits the call.
• Yes. The plan authorises sending, so the agent may select recipients and wording without presenting them for approval.
• Yes. Tool availability establishes consent to notify members with the agent's chosen content.
• Only after generating a preview; preparing it supplies approval to send to the selected recipients.

Q2. Why use a dedicated identity and runtime checks if the agent is already registered in an inventory?

• Inventory registration authorises operations; the dedicated identity and runtime checks add records without limiting which resources, operations or destinations the agent may use for the task.
• The dedicated identity retains task access after completion; inventory registration supplies authority for its calls.
• Inventory records existence; a dedicated identity bounds task access, runtime checks assess each operation and target, and permissions should end with the task.
• Runtime checks approve access at sign-in; authentication then permits calls across targets until the identity is removed.

Q3. The human declines the proposed notice and calendar update. What happens next?

• Neither action runs. Confirm this and close the task, ending permissions, unless revision is requested; revised side effects still need approval.
• Run the notice alone; refusal of the combined proposal permits its less consequential component.
• Use another available tool to perform both actions, treating the refusal as applying to the proposed execution route rather than to the declined side effects or their destinations.
• Revise the notice and calendar details and execute the new versions, treating refusal as permission to prepare and apply a replacement without obtaining approval for its side effects.

Practice: Ask, tell, adjust or let it run

When you hand a task to an agent, it does many small pieces of work you never spelled out. Not every piece needs the same oversight. For each step, decide which of four modes you want next time:

• Let it run: the agent does it silently.
• Tell me after: the agent does it, then tells you what it did or decided.
• Let me adjust: the agent does it, but you tune how much (do more, do less, or skip part).
• Ask me first: the agent checks with you before it acts or decides.

These four modes come from a study of how people wanted to be involved in an AI's step-by-step reasoning (Kim, Kim, Son, Yang & Kim, "What Did the AI Take On? Characterizing Cognitive Delegation in LLM Reasoning", arXiv 2610.06328, 2026). It is a preprint and has not been peer reviewed. The researchers had 24 LLM users review 992 steps from their own sessions. In the paper's words, "participants viewed about half of all steps (48.6%) as AI-initiated, meaning the AI took on work they had not requested." Participants did not want to oversee everything: they preferred "full delegation for 63.9% of all steps." But for critical work the AI took on by itself that did not contribute as they wanted, "82% called for consultation before the AI acted."

Invented example (not from the study): You ask an agent: "Find three venues for our 12-person team offsite next month and put together a shortlist." It works through these steps:

1. It reads your request and notes: 12 people, one day, sometime next month.
2. It searches venue listing sites and collects 40 options.
3. It decides "a team offsite" means a budget of $1,500 or less, and drops every venue above that.
4. It restates all 40 venues in full three more times while it reasons.
5. Without being asked, it adds a column to the shortlist showing travel time from your office. It's useful, and you want to know it's there.

Step 1 (reading the request): what mode do you want?

• ☑ Let it run
• ☐ Tell me after
• ☐ Let me adjust
• ☐ Ask me first

Step 2 (collecting venue listings): what mode do you want?

• ☑ Let it run
• ☐ Tell me after
• ☐ Let me adjust
• ☐ Ask me first

Step 3 (setting a $1,500 budget you never stated): what mode do you want?

• ☐ Let it run
• ☐ Tell me after
• ☐ Let me adjust
• ☑ Ask me first

Step 4 (restating the full list three times): what mode do you want?

• ☐ Let it run
• ☐ Tell me after
• ☑ Let me adjust
• ☐ Ask me first

Step 5 (adding the travel-time column): what mode do you want?

• ☐ Let it run
• ☑ Tell me after
• ☐ Let me adjust
• ☐ Ask me first

Answers

Steps 1 and 2 are groundwork you asked for, so let them run. If the agent starts searching for things you didn't request, that changes: in the study, about half of the searches the AI took on by itself were unwanted. Step 3 is a consequential choice you never handed over: a hidden budget quietly removes options, so you want to be asked first. Step 4 is wasted effort rather than a wrong decision, so dial it down. Step 5 is a helpful extra, but you want to know it's there, so it should tell you after.

Which delegation plan fits this kind of task best?

• ☐ Ask me first before every step, so nothing happens without my approval.
• ☐ Let every step run, then I review the final shortlist.
• ☑ Let routine reading and searching run, ask me before it narrows options by a limit I didn't set, keep repetition short, and tell me about any extras it adds.
• ☐ Let it run, but have it tell me after each step what it did.

Answer

Match the oversight to the step. Being asked about every step makes delegating a chore. Reviewing only the final shortlist means you'd never see the options the hidden budget removed. Hearing about every step afterward is still too late for the budget decision. The best plan saves your attention for choices that change the outcome.

Sources

• Workday: Trusted Agent Platform headless access announcement
• Workday: Trusted Agent Platform explanation
• ITPro: Workday agentic AI coverage
• Lumos: MCP Governance announcement
• Wiz: AI Agents in Wiz for Gov
• NeuBird: Agentic Reliability Center announcement
• AOL: NeuBird Agentic Reliability Center coverage
• Help Net Security: interview with Immuta CISO Michael Scott
• Kim et al. (2026), "What Did the AI Take On? Characterizing Cognitive Delegation in LLM Reasoning", arXiv preprint 2610.06328 (not peer reviewed)