Small AI-Built Tools: Set the Boundary Before You Build

Anthropic's engineering guidance recommends that developers define strict boundaries for AI-built tools before coding, specifying inputs, outputs, and preservation rules to avoid unintended system-wide changes. The guidance, illustrated with a hypothetical file-preparation utility, advises keeping originals untouched, making changes inspectable, and assigning a maintenance owner or disposal date, while noting that deterministic tasks may not require runtime AI models.

Give a coding agent one bounded job before asking it to replace a whole system. A useful small tool might prepare copies of selected files and produce a reviewable manifest. Its first specification should say what it accepts, what it creates and what it must leave alone. Small should describe the responsibility, not the number of screens or lines of code. A tiny application that silently becomes the only place important records are stored has already taken on a large obligation. 1. 01Define the edge.List supported inputs, expected outputs and cases the tool rejects. 2. 02Preserve a way back.Keep originals separate and make the changes inspectable. 3. 03Choose a lifespan.Decide who maintains the utility or when it is discarded. 01 — Write the boundary before the feature listWrite the boundary before the feature list The worksheet below describes a hypothetical file-preparation utility. It creates renamed copies of selected assets and lists the mapping for review. It does not edit the source library or publish anything. These are proposed requirements, not the report of a tool we tested. | Illustrative utility contract, reviewed September 7, 2026; not a product comparison or measured implementation. | | | |---|---|---| | Boundary | Example requirement | Reason | |---|---|---| | Input | Only explicitly selected files in supported formats | A directory is not permission to process every file beneath it. | | Output | New copies plus a source-to-output manifest | The reviewer can inspect each transformation. | | Preservation | Original paths and contents remain unchanged | A rejected result can be discarded without restoring the library. | | Collision | Reject ambiguous destination names | A convenient overwrite must not decide which file survives. | | Unsupported case | List it with the reason; leave it untouched | Partial success is visible rather than silently incomplete. | | Lifespan | Name an owner or record a disposal date | A working prototype should not become an unowned dependency. | 02 — Decide whether the finished tool needs AIDecide whether the finished tool needs AI An agent can write a deterministic utility: software that follows fixed rules once it is built. Renaming according to an agreed pattern does not necessarily require a model call at runtime. The agent’s role in creating the tool and the tool’s need for AI are different decisions. Anthropic’s guidance on building agents https://www.anthropic.com/engineering/building-effective-agents recommends starting with the simplest adequate solution and adding complexity when needed. We apply that principle here as a design choice; the guidance does not measure the cost of the example utility. Use a runtime model when the task actually requires interpretation, and specify how uncertain interpretations are reviewed. If a fixed rule is enough, write down the rule and ask the coding agent to implement it directly. That gives the reviewer a smaller set of behaviors to inspect. 03 — Define preservation at the right levelDefine preservation at the right level For files, “keep a copy” can mean more than preserving visible content. Filenames, timestamps, permissions and embedded metadata can affect how another application uses the result. Decide which properties matter for this job and verify them explicitly. The Python file-operation documentation https://docs.python.org/3/library/shutil.html warns that even high-level copying functions cannot preserve all file metadata. That is a concrete reason not to treat a successful copy operation as proof of complete preservation. The behavior depends on the operation and platform. For the hypothetical utility, keep source files untouched, write outputs to a separate location and show the mapping before anyone adopts them. Where metadata preservation is essential, either verify the required properties or reject the unsupported transformation. Avoid describing a convenience copy as a backup system. 04 — Let rejected cases keep the tool smallLet rejected cases keep the tool small A bounded utility should be allowed to say that an input is unsupported. That is often a better first release than adding a partial converter, background sync, account system and shared database because one file did not fit the rule. Review the rejected cases after using the utility on a representative selection. If many legitimate inputs fall outside the contract, change the scope deliberately. If only a rare exception needs manual handling, document that route instead of making every user depend on a more complex application. This differs from the system-replacement rollout pattern /blog/replace-internal-system-safely-read-only-rollout , which assumes an enduring application and a migration. A file utility can remain a separate, limited tool for its entire useful life. 05 — Decide what happens after the first successful runDecide what happens after the first successful run For a disposable tool, retain the source, the input contract and enough instructions to reproduce the result until the work is accepted. Then archive or remove the tool according to the project’s needs. Repeated use is a new maintenance decision, not an automatic consequence of a successful demonstration. For a maintained utility, name who receives failure reports, how dependency changes are checked and what happens when the input format changes. A named owner need not create a large support process, but users should know where unresolved work goes. Use the file-output acceptance reference /blog/ai-file-output-acceptance-reference to inspect the deliverable. If the requirement expands into an enduring application, revisit the build-versus-buy framework /blog/build-vs-buy-ai-custom-tools-vs-branded-saas-2026 with that larger scope. 06 — DecisionWhat to do next Keep the first tool accountable to one job. Write its input and output contract, preserve originals and make unsupported cases visible. Decide explicitly whether the result is a disposable utility or software somebody will maintain. For implementation support, explore our AI transformation services /services/ai-transformation .