How to narrow AI tools: define responsibility through inputs and outputs

FROM PRIMARY SOURCES

What official guidance says about tool purpose and execution paths

Anthropic's article published in September 2025 describes giving each tool a distinct purpose, distinguishing related functions through naming and returning information useful for decisions.[1] We refer to those design principles without treating them as a guarantee of a particular product's performance.

Its December 2024 design article distinguishes workflows whose paths are set by code from agents whose approach is selected by the model.[2] These are established principles. The divisions and record fields below are editorial proposals for applying that distinction to everyday work.

Sources: [1][2]

EDITORIAL PRACTICE

Keep search, proposed changes and commitment separate

Consider outsourcing assistance with enquiry management. This is a specification example, not an actual case study. A broad tool called “process customer” does not clarify whether it searches history, changes a classification or sends a reply. First separate record search, change proposal and commitment of an approved change.

Limit search by period and result count, and restrict proposals to a draft destination. Commitment should require identifiers for both the approved target and proposal. If the business only needs classification, it does not need a connected send operation. Ask the implementation team to list operations that each tool cannot perform as well as those it supports.

EDITORIAL PRACTICE

Turn ambiguous inputs into questions before implementation

Specify required fields, allowed values, the target organisation, search limits and the handling of empty values. If a customer name does not match, for example, avoid silently widening the search to every customer. Agree whether the tool returns no match or asks a person to choose a candidate. Date boundaries and time zones also need more than a natural-language description.

Ask the team to submit results for ordinary inputs, identifiers from another organisation, empty strings and counts above the limit. Saying “stay within your responsibility” in a description is different from the server rejecting an out-of-scope request. Operational records should distinguish requests that were rejected from those that actually executed.

EDITORIAL PRACTICE

Return the minimum information needed for the next decision

Do not judge outputs by brevity alone. People and AI need the same understanding of whether a target was found, what changed and whether the result is still a proposal. Returning only “success” for an intermediate step can make a later owner assume that the change is final. Consider separating decision-ready results from references to investigation records rather than returning all internal logs.

The table below is an editorial example of useful fields. Do not add personal information that the work does not need, and apply the same policy to investigation records. When several candidates remain, expose that state and identify who must choose what next. This can reduce stalled handovers between teams working in different time zones.

EDITORIAL PRACTICE

Test operations that should be disallowed

During delivery review, express the same goal in different ways and observe whether tool selection changes. Also request an update under a role that permits search only, and verify that execution is rejected. This checks the execution boundary rather than the politeness of the model's response. A displayed rejection does not satisfy acceptance criteria if the update was nevertheless saved.

Begin with one workflow and a small set of tools, recording wrong selections, unnecessary searches and approval waits. Add another tool when those records reveal work that existing operations cannot address. Version names, input specifications and outputs together, and retain a way to rerun the same requests for comparison after a change.