The moment you give a model tools, you change what a mistake can cost. A wrong sentence is embarrassing; a wrong tool call can delete a record, move money, or open a door. Tool orchestration is the part of the runtime that decides which tool runs, when, under what identity, and with what permission. Done casually, it is the widest hole in an agent. Done deliberately, it is where an agent earns the right to act.

A tool is a new set of hands

A tool is any capability the model can invoke: a search, a database query, a payment, an email, a deployment. Each one extends the agent from talking about the world to changing it. That is the whole point, and also the whole risk. The same call that fetches a customer record could, if it were a different tool with broader rights, alter or delete that record.

So the first discipline is to stop thinking of tools as a flat list the model may freely use. Think of them as capabilities, each with an owner, a blast radius, and a required level of trust before it may fire.

Orchestration, not just calling

Calling a tool is easy; orchestrating tools is the hard part. Orchestration means the runtime, not the model, decides whether a proposed call is allowed right now, which concrete tool implements it, what identity it runs as, and what happens to the result. The model proposes; the orchestrator disposes.

This separation matters because the model's tool choice is a suggestion shaped by whatever is in its context, including untrusted content. If a poisoned document nudges the model toward a dangerous tool, an orchestrator that checks policy and identity can still refuse. Without it, the suggestion becomes the action.

📌
Propose vs dispose. Let the model propose a tool call, but make the runtime the only thing that can actually dispatch one.

Capability-scoped execution

Least privilege means each tool call runs with the narrowest permission and the shortest-lived credential that can do the job, and nothing more. A tool that reads one customer's order should not hold a token that can read every customer, and certainly not one that can write. The runtime mints a scoped credential for the specific call, uses it, and lets it expire.

A clean call therefore travels a short, checked path: the proposal is validated, a tightly scoped token is minted for exactly that action, the tool executes under that identity, and the whole thing is recorded. Each stage is a place to stop a bad call before it does harm.

A proposed call is validated, scoped to a short-lived identity, executed, and recorded. One Tool Call Proposed callfrom the model Validate argsallowlist & schema Scope tokenleast privilege Executeunder that identity Recordtrace the call
A proposed call is validated, scoped to a short-lived identity, executed, and recorded.

Separate reading from writing

The single most useful split in a tool catalog is read versus write. Read tools observe the world; write tools change it. They deserve different defaults. A read tool can often run with broad scope and light ceremony because its worst case is disclosure, which you handle with data labels. A write tool changes state, so it should be narrowly scoped, argument-validated, and frequently gated behind approval.

Blurring the two is how agents get dangerous quietly. A tool that looks like a harmless lookup but can also update a field carries write risk with read expectations. Split them, name them honestly, and permission them by what they can actually do.

Read tools risk disclosure; write tools change state and deserve tighter controls. Read vs Write vs Read toolsquery, fetch Broad scope OKworst case: disclosure Write toolscreate, update, delete Scoped + gatedworst case: damage
Read tools risk disclosure; write tools change state and deserve tighter controls.

Tier tools by risk

Not every tool needs the same ceremony, so tier them. Two questions place a tool cleanly: how reversible is the action, and how large is its blast radius. A reversible, small-impact call can run automatically. A reversible but wide call should run but be watched. An irreversible, contained call warrants a human check. An irreversible, wide-reaching call should require explicit break-glass approval or simply be disallowed.

Tiering turns an endless list of special cases into four predictable policies. It also makes approval feel proportional: people stop rubber-stamping trivial calls and start paying attention to the ones that can actually hurt.

Reversibility and blast radius sort every tool into one of four handling policies. Tool Risk Tiers Auto-allowreversible, small Log & watchreversible, large Require approvalirreversible, small Break-glassirreversible, large reversible irreversible Reversibility small Blast radius large
Reversibility and blast radius sort every tool into one of four handling policies.

Validate before you trust the call

Even an allowed tool can be misused through its arguments. An agent told to delete one record could be steered into a wildcard that deletes many. So the runtime should validate arguments against a strict schema and an allowlist of permissible values before executing, and treat anything outside the expected shape as a refusal rather than a best-effort guess.

Argument validation is unglamorous and decisive. It is the difference between a tool that does exactly one narrow thing and a tool that will attempt whatever the model hands it.

  • Constrain every argument with a schema; reject anything that does not fit.
  • Prefer allowlists of known-good values over blocklists of known-bad ones.
  • Bound the scope of an action (one record, not a wildcard) in the tool itself.
  • Return a clear refusal on invalid input instead of guessing an intent.

What to decide as a practitioner

Tool orchestration is where architecture becomes policy. Before wiring an agent to anything that can act, settle a handful of decisions and encode them in the runtime rather than the prompt.

Get these right and the model's occasional bad idea stays a proposal. Get them wrong and every clever suggestion becomes a live action with production consequences.

Key takeaways

  • Treat tools as capabilities with owners, blast radius, and required trust, not a flat list.
  • The runtime, not the model, must decide whether and how a proposed call runs.
  • Scope every call to the narrowest, shortest-lived identity that can do the job.
  • Split read from write tools and permission them by what they can actually do.
  • Tier tools by reversibility and blast radius so approval is proportional to risk.
  • Validate arguments against a strict schema and allowlist before any tool executes.

Glossary

Tool orchestration
The runtime logic that decides which tool runs, when, under what identity, and what happens to its result.
Capability-scoped execution
Running each tool call with the narrowest permission and shortest-lived credential sufficient for that specific action.
Scoped token
A short-lived credential minted for one action, granting only the access that action requires.
Blast radius
The extent of damage a single tool call could cause before something contains it.
Break-glass
An explicit, audited approval path required before a high-impact or irreversible action may proceed.
Allowlist
A set of explicitly permitted values or actions; anything not on it is refused by default.
Argument validation
Checking a tool call's parameters against a strict schema and permitted values before executing it.