This article is published in English.
From Goal to Guarded Action: Loops, Verification and Permissions in AI Agents
Learn how AI agents turn a goal into tool calls through a plan-act-observe loop, and why verification, autonomy levels and permission layers decide if they are safe.
Most people first met language models as question-answering machines: prompt in, reply out, done. Agent systems break that pattern. Given a goal, they plan, call tools, inspect the results and keep going until the job is finished. This walkthrough covers the loop, tools, memory and multi-agent setups, then focuses on what matters most in production: verifying an agent's work and limiting its authority.
Responding versus working toward a goal
A classic chatbot is a single pass. A question goes in, the model produces an answer, and nothing else happens.
User
↓
Question
↓
AI
↓
Answer
Ask it "What is machine learning?" and you get an explanation, nothing more. An agent is organised around a goal, reached through a sequence of actions with feedback in between.
User
↓
Goal
↓
AI Agent
↓
Plan
↓
Use Tools
↓
Observe Results
↓
Take More Actions
↓
Complete Goal
A request like "analyse this dataset and produce a report" has to be broken into concrete stages:
Read dataset
↓
Understand columns
↓
Clean data
↓
Analyze statistics
↓
Create graphs
↓
Find patterns
↓
Write report
In short, a chatbot answers, while an agent carries out work and adjusts as it goes.
What qualifies a system as an agent
There is no single agreed definition. A practical one: an agent takes in a task, makes decisions, uses available tools, looks at the outcomes and chooses further actions until the goal is reached. The defining feature is the branch at the bottom that sends control back up.
USER GOAL
↓
AI AGENT
↓
PLAN
↓
SELECT ACTION
↓
USE TOOL
↓
OBSERVE
↓
EVALUATE
↓
NEXT ACTION?
↙ ↘
YES NO
↓ ↓
Continue Finish
Without that loop you have a pipeline that runs once. With it, the system can recover from surprises, which is both its power and the reason it needs supervision.
The think, act, observe cycle
The simplest mental model for that loop is think, act, observe. Imagine asking an agent to find the best laptop within your budget and compare three candidates. Internally it might proceed like this:
Goal
↓
Understand requirements
↓
Search for products
↓
Read results
↓
Compare specifications
↓
Check prices
↓
Evaluate options
↓
Generate recommendation
The agent is not writing about laptops from training memory. It queries real sources and bases its recommendation on what it found, and that contact with the outside world is what separates it from plain text generation.
Three parts: model, tools and state
A basic agent can be described in terms of three components.
The model as decision-maker
Usually a large language model, which interprets instructions and decides what to do next.
Tools as capabilities
Tools are the external abilities the agent can invoke, for example:
Search
Python
Calculator
Database
API
File system
Computer
Vision model
State as a running record
State is what the agent knows about the task so far. It answers questions like these:
What did I search?
What did I find?
What have I already done?
What remains?
Put together, the three components feed into the actions the agent takes:
AI AGENT
│
┌──────────┼──────────┐
↓ ↓ ↓
Model Tools Memory
│ │ │
└──────────┼──────────┘
↓
Actions
For a longer treatment of these building blocks, see our guide to agent goals, tools, memory and the loop.
Why tools carry so much weight
Ask a model to multiply 938472 by 827391 and it may get it right, but it predicts digits rather than computing them, so a calculator or Python is more dependable. An agent can hand the job off:
User
↓
LLM
↓
"I need exact arithmetic."
↓
Calculator
↓
Result
↓
LLM
↓
Answer
The model does not have to do everything itself. It delegates.
Choosing the right tool for the input
How does the agent pick among its tools? Suppose it can reach all of these:
Python
SQL
Search
Calculator
Vision Model
File Reader
Email API
Calendar
Given "look at this sales spreadsheet and explain why revenue fell", it reasons from the input type, data shape and task to a tool:
Input = Spreadsheet
↓
Data = Tabular
↓
Task = Analysis
↓
Tool = Python/pandas
From there the chosen tool does the heavy lifting and hands its findings back:
pandas
↓
Analyze sales
↓
Find patterns
↓
Return results
The agent then interprets those results. In practice, tool choice depends heavily on clear tool names and descriptions, since that is all the model sees.
Chaining several tools into one workflow
Consider "analyse our sales data, chart it and email the report to my manager", which spans analysis, visualisation, writing and delivery:
Sales Dataset
↓
Python / pandas
↓
Statistical Analysis
↓
Matplotlib
↓
Create Charts
↓
LLM
↓
Write Report
↓
Email Tool
↓
Send Report
The system is now coordinating a workflow, where each output feeds the next step, so an early mistake propagates all the way to the email.
Planning through task decomposition
"Build a website for my project" is too big for one move. A capable agent splits it into ordered pieces:
Goal
↓
Understand requirements
↓
Create project structure
↓
Build frontend
↓
Build backend
↓
Connect database
↓
Run application
↓
Test
↓
Fix errors
↓
Deploy
This is task decomposition: the goal becomes a series of smaller actions that can each be executed and checked.
Reacting to failure instead of reporting it
The loop pays off when something breaks. Say the agent runs some code:
Write code
↓
Run code
↓
ERROR
A chatbot can only report the error. An agent can read it, fix the code and try again:
Write code
↓
Run code
↓
ERROR
↓
Read error
↓
Identify problem
↓
Modify code
↓
Run again
↓
SUCCESS
Generalised, that is the agentic loop, with evaluation feeding a new plan:
┌──────────────┐
│ PLAN │
└──────┬───────┘
↓
┌──────────────┐
│ ACT │
└──────┬───────┘
↓
┌──────────────┐
│ OBSERVE │
└──────┬───────┘
↓
┌──────────────┐
│ EVALUATE │
└──────┬───────┘
│
└──────→ PLAN AGAIN
A loop that can retry can also retry forever, so real systems cap iterations.
Memory and continuity across steps
Without memory, every task starts from nothing:
Task 1
↓
Forget
↓
Task 2
↓
Forget
With state carried forward, each step builds on the last:
Task 1
↓
Save result
↓
Task 2
↓
Use previous result
↓
Task 3
Memory comes in several scopes:
- Short-term state holds information from the task in progress.
- Long-term memory persists across interactions, where the system supports it.
- External memory lives outside the model, in databases, documents, vector stores or files.
An agent might consult project documents and earlier results before the current step:
Agent
↓
Memory
↓
Project documents
↓
Previous results
↓
Current task
Combining retrieval with action
Retrieval-augmented generation (RAG) pairs naturally with agents. To answer from internal company documents, an agent searches them, reads the relevant passages and reasons over them:
Question
↓
Search company documents
↓
Retrieve relevant information
↓
Read context
↓
Reason about it
↓
Answer
Add tools and the agent can also act on what it finds:
AI AGENT
│
┌───────────┼───────────┐
↓ ↓ ↓
RAG Python APIs
↓ ↓ ↓
Documents Analysis Actions
Splitting work across multiple agents
When one agent is not enough, several specialised agents can work under a coordinator:
MAIN AGENT
│
┌────────────┼────────────┐
↓ ↓ ↓
Research Agent Coding Agent Data Agent
│ │ │
Search Code Analysis
Research, coding and data agents each handle their specialty while the main agent routes work between them. This is a multi-agent system.
The team analogy and its limits
The structure resembles a software company with distinct roles:
Manager
↓
Developer
↓
Tester
↓
Designer
↓
Deployment
An AI system can mirror that division of labour:
Coordinator Agent
↓
Research Agent
↓
Coding Agent
↓
Testing Agent
↓
Deployment Agent
The comparison is loose, but it suggests a direction: coordinating specialised models and tools instead of relying on one model. Each extra agent also adds cost and latency, so the specialisation must be real.
How agents go wrong
Autonomy does not imply reliability. An agent can:
- pick the wrong tool
- misread the goal
- produce broken code
- retrieve irrelevant material
- repeat an action that already failed
- hallucinate facts
- make a poor decision
- take an action nobody intended
Errors compound through every later stage:
User Goal
↓
Wrong interpretation
↓
Wrong tool
↓
Wrong result
↓
Wrong action
The more freedom an agent has, the more its work needs to be checked.
Building verification into the loop
The anti-pattern is an agent that acts and simply assumes the action worked:
Act → Assume success
The better pattern inserts an explicit check before moving on:
Act
↓
Observe
↓
Verify
↓
Continue
For code, the check is a test run with a clear branch on the outcome:
Write Code
↓
Run Tests
↓
Tests Pass?
├── NO → Fix
└── YES → Continue
For data, it is a sanity check on the result before anyone relies on it:
Database Query
↓
Check Result
↓
Is result reasonable?
├── NO → Investigate
└── YES → Continue
Verifying instead of assuming is much of what separates an adaptive agent from a simple script. Prefer deterministic checks, such as tests or schema validation, over asking the model to grade itself.
Autonomy is a dial, not a switch
Agents do not need total freedom. Picture a scale, starting with a system that only answers:
Level 1
AI only answers
The higher levels add suggested actions, then tool calls, then multi-step planning, and finally workflows executed with limited supervision:
Level 2
AI suggests actionsLevel 3
AI calls toolsLevel 4
AI plans multiple actionsLevel 5
AI executes workflows with limited supervision
Each step up the scale raises the requirements around the agent:
Permissions
Safety
Monitoring
Verification
Human oversight
The lowest level that solves the problem is usually the safest choice.
Scoping what an agent may touch
Picture an agent wired into all of the following:
Email
Banking
Files
Database
Cloud infrastructure
Production servers
Unrestricted access would be reckless. A safer design routes actions through a permission layer:
AI Agent
↓
Permission Layer
↓
Allowed Tools
↓
Action
Permissions are then set per action: reading a file may be fine, while deleting, emailing, deploying or database access depend on context:
Read file ✓
Delete file ?
Send email ?
Deploy software ?
Access database ?
The principle is least privilege.
Guardrails and human approval
Production agents also need hard limits on how they operate:
Allowed tools
Maximum actions
Time limits
Budget limits
File permissions
Network permissions
Human approval
For high-impact actions, the agent prepares the action and waits for a person to approve it:
Agent
↓
Prepare Action
↓
Human Approval
↓
Execute
That is a human-in-the-loop design. Bounded loops are covered in our article on bounded agentic loops in TypeScript.
Where agents are being applied
The same loop shows up across many domains.
Software development
Requirement
↓
Coding Agent
↓
Code
↓
Testing
↓
Bug Fixing
Data analysis
Dataset
↓
Data Agent
↓
Cleaning
↓
Analysis
↓
Visualization
↓
Report
Customer support
Note the "permitted action" step: support agents work within a narrow, pre-approved set of operations.
Customer Question
↓
Retrieve Account Information
↓
Understand Problem
↓
Take Permitted Action
↓
Respond
Research
Research Question
↓
Search
↓
Read Papers
↓
Extract Information
↓
Compare Findings
↓
Generate Report
Personal productivity
Goal
↓
Calendar
↓
Email
↓
Documents
↓
Tasks
↓
Summary
A different kind of interface
Conventional software maps a control to a function to a result:
Button
↓
Function
↓
Result
An agent maps a stated goal to a plan, tool calls and actions:
Goal
↓
Planning
↓
Tools
↓
Actions
↓
Result
Instead of learning which buttons to press, the user describes the outcome. That changes human-computer interaction and makes visibility of the agent's actions a design requirement.
A note on the word "thinking"
When we say an agent "thinks", we usually mean computational steps: interpreting input, planning, choosing actions, evaluating outputs and updating state. That does not establish consciousness. More precisely, agents run iterative cycles of reasoning and action selection toward a goal; "agent" describes behaviour and architecture, not experience.
The full picture in one loop
Assembled, the pieces form this architecture: plan, act through a tool, observe, verify, then continue or stop.
USER
│
▼
┌─────────┐
│ GOAL │
└────┬────┘
↓
┌─────────────┐
│ AI / LLM │
└──────┬──────┘
↓
PLAN
↓
SELECT ACTION
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Search Python SQL
↓ ↓ ↓
└─────────────┼─────────────┘
↓
RESULT
↓
OBSERVE
↓
VERIFY
↓
Continue or Finish
That cycle sits at the centre of most agentic systems.
Where this is heading
Imagine asking your computer for your weekly research report, and an agent handling the chain:
Open research sources
↓
Collect information
↓
Read documents
↓
Analyze data
↓
Create charts
↓
Write report
↓
Check errors
↓
Prepare final document
The computer then coordinates applications rather than just hosting them. Over a longer arc, the progression looks like this:
Rule-Based Software
↓
Machine Learning
↓
Chatbots
↓
LLMs
↓
Tool-Using LLMs
↓
AI Agents
↓
Multi-Agent Systems
The change is not just bigger models, but models that increasingly operate external systems.
Key takeaways
A chatbot tells you how you might analyse a dataset. An agent-oriented system could find it, load it, analyse it, chart it, flag problems, draft the report, ask for sign-off and deliver it:
Find the dataset
↓
Load it
↓
Analyze it
↓
Create visualizations
↓
Detect problems
↓
Write a report
↓
Ask for approval
↓
Deliver the result
The progression is answering, then planning, acting, observing and verifying. A few points to carry into any agent you design:
- The loop, not the model, is what makes a system an agent; bound it with iteration, time and budget limits.
- Delegate precise work such as arithmetic, queries and code execution to tools, and describe those tools clearly.
- Verify each consequential step with checks that do not rely on the model grading itself.
- Grant permissions per action, start from least privilege and require human approval for anything irreversible.
- Pick the lowest level of autonomy that gets the job done.
Agents are less about machines that think like people and more about systems that turn a goal into actions. The key question is not how capable the model is, but what you are prepared to let it do.