Back to Writing

Tool use as a privilege, not a default

“Tool use as a privilege, not a default” stops being abstract the moment you ask who gets paged when it fails.

Treat agents like junior systems: limited privileges, explicit tools, budgets, and a human who owns the outcome. Autonomy without audit is distributed risk.

The rest develops that one idea with controls you can install and failure modes you can recognize.

Write one page while the decision is still warm — context, options, choice, owner, revisit date. Verbal alignment on Tool use as a privilege, not a default evaporates under ordinary calendar pressure, and Slack archaeology is a poor substitute for a decision record.

Measure what you claim to care about. If Tool use as a privilege, not a default only appears in kickoff slides and never in review, incident, or planning artifacts, it is branding. Put a verification signal where people already look.

Practices with enough detail to copy

Cadence beats intensity. These hold when they fit inside weeks people already live.

1

Require event emission for every tool call in production.

Useful specialization looks like a retrieval agent, a draft agent, and a verifier — each with narrow tools — not five personas arguing in a shared context window for theater value.

2

Ship the harness before the autonomy: budget, log schema, kill switch, allow-listed tools.

Every tool grant is a privilege expansion. Review tool allow-lists the way you review IAM — on a cadence, with least privilege as the default.

3

Chaos-test retries: kill mid-flight and prove no duplicate side effects.

Tool use as a privilege, not a default. Grant the minimum side effects; expand with evidence. Omnipotent agents that “just figure it out” eventually figure out the wrong production action.

4

Define stop-and-ask rules in writing; review them like any other safety control.

Design hand-offs: when an agent must stop and ask, what context is packaged for the human, and how the resume is recorded. Dropped context forces humans to redo work the agent already “knew.”

Idempotency for agentic side effects — retries must not double-charge, double-page, or double-merge. Partial failure is normal; duplicate effects are optional if you design poorly.

Human resume paths need packaged context: what the agent tried, what failed, and what must not be retried. Empty hand-offs erase the value of automation.

For Tool use as a privilege, not a default, the inheritance test is blunt: after a week, can someone outside the original room explain what changed, who owns it, and how you will know if it breaks? If the answer depends on hallway memory, you still have a story — not a practice.

Scenes

An agent retries a payment side effect after a timeout. Without idempotency keys, customers see duplicates. Treat agent side effects with the same discipline as payment systems.

A multi-agent demo impresses leadership. In production, nobody can explain which agent wrote which file or why. Specialization without interfaces is just distributed confusion.

Stop-and-ask rules were informal. The agent emails a customer. Now you have a process problem and a trust problem. Irreversible writes, authz changes, and customer communication belong on an allow-list with human gates.

Tradeoffs

Human hand-offs add latency. Unbounded autonomy adds blast radius. Pick the latency.

Narrow tools feel less magical than one omnipotent agent. Magic is not an operability strategy.

Harnesses slow the first demo and save the first incident. Sequence matters.

Resist the urge to expand scope into neighboring slogans. If a control does not make Tool use as a privilege, not a default more operable for the next person, leave it for another note. Dilution is how coherent essays become stitched scrapbooks.

Side effects need the same discipline as payments: idempotency, clear hand-offs, and a human who still owns production outcomes. Retries without keys turn partial failure into duplicate harm.

Failure modes

Each of these is a missing control, not a personality problem:

  • Hand-offs that drop context, so humans redo the work.
  • Retries without idempotency keys — duplicate side effects under partial failure.
  • Omnipotent agents that “just figure it out” until they take the wrong production action.
  • Multi-agent theater without clear interfaces or ownership of outcomes.

Event-driven agentic workflows teams can operate look like other event-driven systems: schemas, consumers, dead-letter paths, and owners.

Orchestration without a black-box conductor means you can explain the workflow on a whiteboard and pause any step. If you cannot, you cannot operate it.

Orchestration without a black-box conductor: prefer explicit workflows over an opaque planner nobody can debug. Debuggability is a product requirement.

Owning outcomes when agents ship changes means the human merge still carries production accountability. Agents accelerate the middle; humans own the edge.

Budgets are product constraints. Token, time, and blast-radius limits keep agents from optimizing for activity over outcomes.

Emit events for every tool call in production. Incidents without forensics become superstition. Event-driven design is how you keep humans in the loop without standing over the process.

Harnesses first: logs, token/time budgets, blast-radius limits, and a kill switch a human can use without a war room. Autonomy is earned after those exist.

Close

Autonomy is earned with observability. Until then, keep the blast radius small.

If someone new cannot explain Tool use as a privilege, not a default from your artifacts in fifteen minutes, the practice is still private.