Skip to content

AI Systems

Tool-using agents: give it tools, not keys

Some work can't be written as fixed steps, because each step depends on what the last one found. An agent handles that by choosing its next action from a short list of tools you approved. Each tool does one thing with checked inputs, anything that reaches a customer waits for a person, and every action is on the record. So work that needs judgment at each step can be automated without handing an agent the keys to your systems.
Discuss your systemSee when an agent is the right call ↓
Objective · from the office leadRepeat leak at 31 Cedar Row. What's installed, is it covered, when can we go?Agentstep 1step 2step 3step 4step 5step 6find_jobsJ-377, Mar 2024get_equipment50 gal · R40-77812check_warrantyparts 2030 · labour endedfind_slotsThu 08:00 · T3draft_replydraft readysend_replyneeds approvaldelete_jobnot a toolwaiting · office lead

Most work doesn't need an agent

We start with a workflow and one model step, and move to an agent only when the steps can't be written down in advance.
The stepsKnown in advance, in orderDepend on what the last one found
The model's jobOne decision inside fixed stepsChoosing the next action
ExampleLabel a message, then route itInvestigate a repeat leak across jobs, equipment, warranty and the calendar
What can go wrongA wrong decision at a known pointA wrong action, or too many of them
What you needTests for that decisionTests, tool limits, a step budget and a view of every action

A tool is a contract

check_warranty

does
Looks up warranty cover for one serial number
input
serial, in the manufacturer's format
returns
parts cover until, labour cover until, source document
reads
equipment register, warranty records
writes
nothing
who may run it
office staff and above
needs approval
no
limit
20 calls per run

The agent never gets database access or an API key. It gets a short list of tools like this one, each doing one thing, with inputs that are checked before it runs and effects that are known in advance.

Tools that only read are the safest. Tools that change something for a customer, like sending a reply, are marked as needing approval, and the run waits for a person.

What the agent can see

Context is part of the specification. More isn't better; each of these is a decision.

  1. 01

    Always in view

    Every step

    The objective, who asked, today's date and the rules it must follow.

  2. 02

    Fetched when needed

    Through tools

    Job records, equipment and warranty, retrieved only when a step calls for them.

  3. 03

    Summarised as it goes

    Long results condensed

    Big tool results are reduced to the facts that matter, so they don't bury the objective.

  4. 04

    Remembered between runs

    Only by decision

    Nothing carries over unless you choose it to. Persistent memory is a design choice, not a default.

  5. 05

    Tools it can see

    Only this task's tools

    A tool the agent can't see is a mistake it can't make.

The manager's view

Delegated work needs a view of what was done: every action, its result, and where the run is waiting.

Run a-1182 · Leak at 31 Cedar Row

  1. find_jobs

    J-377, installed March 2024

    done

  2. get_equipment

    50 gal, serial R40-77812

    done

  3. check_warranty

    parts covered to 2030; labour ended March 2025

    done

  4. find_slots

    Thu 08:00–10:00 with T3

    done

  5. draft_reply

    offers Thursday; part free, labour charged

    done

  6. send_reply

    office lead to approve

    waiting

Six steps, every result visible, and the one action that reaches the customer waiting for a person. Stopping, editing or redirecting the run is one click.

What an agent hands off

In

Objective
from a person
Approved tools
bounded and checked
Context
role, rules, date
Agent loop
choose → call → check → continue

Out

Actions taken
each one logged
Proposals
waiting for approval
A clear stop
with reasons, at a limit

Worth building when the next step depends on the last

Good fit

  • The steps depend on what each step finds.
  • The actions fit a short list of bounded tools.
  • Someone will watch the runs and approve what reaches customers.

Not the right fit

  • The steps are known in advance. A workflow with one model step is simpler, cheaper and easier to test.
  • The task needs broad access you wouldn't give a new employee on their first day.

Where agents do the work

Next to tool-using agents

Questions about tool-using agents

What's the difference between an agent and an automation?

An automation follows steps you wrote. An agent chooses its next step from tools you approved. We use agents only where that choice is actually needed.

Can it act on its own?

Only through the tools you allow, and only the ones that don't need approval. Anything that reaches a customer or moves money can require a person.

What stops it looping or running up costs?

A step budget, time limits and stop conditions on every run, plus monitoring that flags runs that hit them.

Do you use MCP?

Where it simplifies connecting tools and keeps permissions clear. The contract for each tool matters more than the protocol that carries it.