The interesting part of AI is the system around it

A model that writes a convincing answer and a system that completes a useful task are different engineering problems. The first produces text. The second has to know what happened, what it may change, and when to stop.

That difference becomes visible as soon as you give a model a tool. A request to rename a file now needs a path, permission to write, a result from the filesystem, and a way to handle failure. None of those disappear because the model can explain its plan fluently.

Start with the loop

A minimal tool-using loop takes a request, sends relevant context to the model, checks any proposed tool call, runs the permitted action, and returns the result. The next step depends on that result. A failed operation should change what happens next.

Anthropic distinguishes fixed workflows from agents that choose their next steps dynamically. That distinction is useful: a predictable task may need a small workflow, while an open-ended task may benefit from a loop that adapts. More freedom also creates more paths to inspect. See Building effective agents (opens in a new tab).

Put authority in code

Consider an illustrative system that prepares a deployment. Reading a log and changing production are different permissions. They shouldn’t become equivalent simply because both are exposed as tools.

The application should validate the operation, the target, and the credentials before executing it. A sentence in a prompt isn’t an access-control boundary. Give the process only the access the task needs, and require explicit approval where the product calls for it.

Make the result observable

Keep the tool name, validated arguments, outcome, and relevant state changes together. That record makes a failure reproducible. Logging a model’s confident explanation without the actual tool result leaves a hole exactly where the evidence should be.

For a file edit, useful feedback might include a diff and a test result. For a data query, it might include the schema and the rows returned. The feedback should describe the outside world, including errors.

Give completion a definition

“Keep improving this” has no natural stopping point. “Produce a patch that passes these checks” is easier to evaluate. Set a budget for tool calls or elapsed time, define the evidence needed for completion, and decide how the application reports partial progress.

You can swap or upgrade the model. The permissions, state, evidence, and stopping rules are the part you still have to build yourself.