AI Agents and Automation: Choose the Right Level of Control

A fixed automation follows steps you define. An AI agent uses a model to choose some next steps. Both can be useful. The best choice depends on how much judgement the task needs and how costly a mistake would be.

Start with a fixed workflow

If a task always reads a CSV, calculates a total and saves a report, ordinary code is often enough. Adding a model can make the result slower, more expensive and harder to test without adding value.

A model is more useful when input varies in language or the next useful step depends on context. Even then, keep parts that can be deterministic under normal program control.

A small agent loop

1. The user asks for a lesson.
2. The model sees the allowed tool descriptions.
3. It requests a lesson lookup.
4. The application checks the request and user access.
5. The tool returns the approved data.
6. The model answers, or the loop stops at its limit.

The six-lesson study-helper project implements this path. It uses made-up lesson data and a read-only tool. Start there before giving an agent an operation that changes real information.

State is not automatic learning

An agent may keep conversation state, a task record or retrieved notes. That does not mean the model's weights learn from each interaction. Persistent memory needs a storage design, access rules and a deletion policy. Keeping everything forever is not a sound memory plan.

Some systems revise a plan using feedback. That can improve a task run, but the system can also repeat a wrong assumption. Check progress with observable results, not the length of its explanation.

Give tools narrow jobs

A get_lesson tool is easier to validate than a run_any_command tool. Check names, types, ranges and authorisation in your code. Keep secrets out of model-visible results. Limit the number of calls and the time spent.

For a write action, show a concrete target and effect before any approval step. Prevent repeated requests from causing duplicate actions where needed. A model saying “approved” is not evidence that the user approved it.

Frameworks and multiple agents

Frameworks can handle loops, state and integrations. Their APIs and recommendations change. Start with one understandable process and choose a maintained framework only when it solves a real need.

Multiple agents can divide work, but they also add messages, cost and coordination failures. Agreement between several model-generated answers is not independent proof. Use separate roles only when you can define their inputs, outputs and checks.

Test the failures

Test an unknown tool, malformed arguments, a missing record, a timeout and a tool result containing hostile instructions. Treat outside text as data. A log or document must not be able to tell your agent to reveal credentials.

Measure task success, unsupported claims, unnecessary actions, latency and cost. Use fake model responses to test control logic without paying for every run, then evaluate model behaviour separately on approved real examples.

Practice

Take one task you do each week. Split it into fixed steps and uncertain language tasks. Decide whether a model is needed at all. If it is, define one read-only tool, a stopping rule and three failure tests before adding more autonomy.

Official references

Reviewed on 25 October 2026. Use documentation for your installed versions.

• Function calling
• MCP architecture

All AI & Machine Learning tutorials