The question I am building toward is how to build AI systems that can take action by selecting tools, gathering information, recovering from errors, and producing conclusions that people can trust:
What systems and infrastructure do tool-using AI agents need to automate real work safely and reliably?
Football tactical analysis provides a useful setting in which to explore this problem. A capable agent would need to identify the relevant match data, retrieve evidence from multiple sources, combine it appropriately, and explain conclusions such as why a team struggled to progress through midfield. Each conclusion would need to remain traceable to the evidence behind it. Choosing the wrong data, failing to recover from an error, or presenting an unsupported claim with confidence would all represent failures of the system, even if the final response sounded convincing.
Starting with a full football-analysis platform, however, would make it difficult to determine why the agent behaved as it did. The investigation therefore began with a smaller, complete system that could be examined from end to end: a local weather assistant with three tools.
The system I built
The assistant can look up current weather, a five-day forecast, or air quality for a city. A user asks a question. The model chooses a tool. Python runs ordinary code that calls the weather service. The result returns to the model, which writes an answer.
flowchart LR
U[User question] --> M[Model chooses a tool]
M --> P[Python validates and runs the tool]
P --> W[Weather service]
W --> P
P --> M
M --> A[Answer]
This is the tool-calling pattern documented by Ollama: a model requests a function, the host application executes it, adds the result to the conversation, and asks the model to continue [1].
The diagram makes the division of responsibility clear. The model can decide that a forecast is relevant. It does not call the weather service directly, hold the API key, decide whether its input is valid, or determine how to recover from a failed request. The surrounding software does those things.
What changed in my understanding
Before writing the program, I thought of tool calling mainly as a model capability: provide a list of functions and the model can use them. Building the loop made the system around the model more visible.
The current implementation keeps a registry of allowed functions and carries the conversation forward while the process is running. It also turns weather-service failures into structured error results. Those are useful starting choices. They are not enough to make the system reliable.
For example, the program still assumes that a requested function exists and that the model supplied a usable city. It does not define a retry policy. It does not preserve work if the process stops. It does not store a trace that lets me reconstruct why the model chose one tool rather than another. Most importantly, it does not check whether the final answer is actually supported by the returned data.
These are not peripheral engineering details. They determine whether the system can be trusted to act beyond a demonstration. Work on agentic execution environments makes the same broader point: an agent acts through stateful files, APIs, processes, memory, and policy boundaries, not only through a model prompt [2].
A working loop is not yet reliable automation
The weather assistant can produce a correct answer on the happy path. It can also produce a plausible answer after a weak path:
- the model selects the wrong tool;
- the user asks for several facts but the model retrieves only one;
- the weather service fails and the error reaches the model as ordinary text;
- the model receives a result but explains more than the result supports; or
- the process stops after a tool call, leaving no durable record of what was done.
None of these failures are obvious from the final sentence alone. That is why I care about evidence, state, and recovery rather than only whether an agent can call functions.
What this first step does not establish
This is not a research experiment and it does not establish a new reliability method. I have not measured failure rates, compared alternatives, or tested a recovery mechanism. I have built one small system and used it to identify the questions that a larger system must answer.
The practical result is a more disciplined next step. Before I ask an agent to make a tactical claim, I need a system that can show what evidence it collected, what each tool returned, which step produced the final claim, what happened if a tool or process failed, and whether the claim remains supported when the system is resumed or rerun.
What comes next
The next step is to move from a single lookup to a system that must assemble an answer from several pieces of evidence. The important outcome is an inspectable path from question, to data, to conclusion: which tools the agent selected, what each returned, how the results were combined, and whether the final claim follows from them. That execution and evidence model can then be tested in the football-analysis setting and used to expose the failure and recovery questions that matter.
References
- Ollama, “Tool calling,” documentation. [Online]. Available: https://docs.ollama.com/capabilities/tool-calling
- E. Ang et al., “Agentic Data Environments,” IEEE Data Engineering Bulletin, vol. 50, no. 1, 2026. [Online]. Available: https://arxiv.org/abs/2607.07397