Agentic Loop Mental Model¶
What is an agentic loop?¶
With a simple LLM call, the system effectively does this:
input
↓
model
↓
output
That is enough for many tasks, such as:
- summarizing text,
- classification,
- generating a simple structured answer,
- giving a short explanation,
- producing one decision recommendation.
An agentic loop appears when solving the task requires the system to repeatedly:
- observe the current state,
- decide the next step,
- execute an action,
- process the new result,
- decide whether to continue.
Basic mental model:
Goal
↓
Observe
↓
Decide
↓
Act
↓
Observe result
↓
Continue / Replan / Ask / Stop
The key idea is:
An agentic system is not merely a longer prompt; it is an iterative execution model controlled by a runtime.
The model is only one component in the loop¶
A common misunderstanding is:
Agent = LLM that thinks in a loop
A better mental model is:
Agent Runtime
├── canonical execution state
├── model calls
├── tool / skill execution
├── validation
├── authorization
├── budgets
├── stop conditions
├── retries / recovery
└── observability
The model typically helps with:
current goal + current observations
↓
choose next step
The runtime controls whether that step:
- is allowed,
- can be executed,
- fits within budget,
- contains valid input,
- produces a valid new state,
- may continue the loop.
Example: coding agent¶
User goal:
Fix the failing payment retry test.
Single-call approach:
prompt with code + test
↓
model suggests patch
Agentic execution:
Goal: fix failing test
↓
Read failing test
↓
Read implementation
↓
Decide patch
↓
Edit file
↓
Run test
↓
FAIL
↓
Observe failure
↓
Read related code
↓
Edit again
↓
Run test
↓
PASS
↓
Stop
The important difference is not that the model is “smarter”.
It is that:
Environment feedback provides new information after each iteration, and the runtime can request a new decision based on that information.
When is a loop useful?¶
A loop is justified when the next step is not known in advance and depends on the previous result.
For example:
Diagnose production incident
We may not know upfront whether we need:
- deployment state,
- logs,
- metrics,
- release diff,
- dependency health.
Each observation can determine the next action.
query error rate
↓
errors started after deploy
↓
inspect latest deployment
↓
new dependency version
↓
inspect dependency errors
That is a natural agentic loop.
When is a loop unnecessary?¶
If the execution path is already known:
1. load invoice
2. validate schema
3. calculate tax
4. store result
then this is usually a workflow or normal application logic.
There is no need to ask the model at every step:
"What should I do next?"
when the answer is deterministic.
Anti-pattern: agent everywhere¶
Weak:
LLM decides:
- whether to validate input
- whether to save record
- whether to commit transaction
- whether to retry database operation
Better:
Application workflow owns deterministic control
│
└── agentic decision only where ambiguity/reasoning is useful
Workflow vs agentic loop¶
Deterministic workflow¶
A → B → C → D
The application knows the control flow in advance.
Conditional workflow¶
A
↓
condition?
├── yes → B
└── no → C
This is still deterministic workflow logic.
Agentic loop¶
Current state
↓
Model/runtime decides next useful action
↓
Environment changes
↓
Decision is made again
Part of the control flow is generated at runtime.
Agentic islands¶
In production systems, it is often better not to make everything agentic.
Instead:
Deterministic workflow
↓
Agentic diagnosis step
↓
Deterministic validation
↓
Human approval
↓
Deterministic execution
This is a useful agentic island mental model.
For example:
Incident received
↓
validate metadata deterministic
↓
agent investigates cause agentic
↓
proposed remediation
↓
approval deterministic
↓
restart deployment deterministic tool execution
This is often stronger than an unrestricted “do anything” agent.
The loop as a state machine¶
It is useful to model the loop as a state machine.
For example:
RUNNING
│
├── OBSERVING
├── DECIDING
├── EXECUTING
├── WAITING_FOR_HUMAN
├── REPLANNING
├── COMPLETED
└── FAILED
The model should not have to keep these states implicitly “in mind”.
The runtime should store them canonically.
For example:
{
"run_id": "run-184",
"status": "RUNNING",
"goal": "Fix failing retry test",
"iteration": 4,
"last_action": "run_test",
"last_observation": "AssertionError: expected 1 charge, got 2",
"remaining_tool_calls": 12
}
Canonical state vs model context¶
This distinction is critical.
Weak:
Conversation history = execution state
If all state exists only in prompt history:
- checkpointing is difficult,
- resume is difficult,
- queries are difficult,
- auditing is difficult,
- budgets are hard to enforce deterministically,
- compaction can lose information.
Better:
Runtime state store
↓
Context builder selects relevant projection
↓
Model sees only what it needs now
So:
Context is model input; state is system truth.
One iteration as an explicit transaction¶
An iteration can be decomposed into:
1. read canonical state
2. construct model context
3. request next action
4. validate action
5. authorize action
6. execute action
7. normalize observation
8. update canonical state
9. evaluate stop conditions
This is a stronger production mental model than:
while true:
ask_llm_what_to_do()
Model output as a next-step decision¶
The model can return structured decisions such as:
{
"action": "USE_TOOL",
"tool": "run_test",
"arguments": {
"test": "PaymentRetryTest"
},
"reason": "The latest patch should be verified before further changes."
}
or:
{
"action": "STOP",
"outcome": "SUCCESS",
"evidence": [
"PaymentRetryTest passes",
"related retry tests pass"
]
}
The runtime validates these according to its own rules.
Environment feedback makes the system agentic¶
The environment can change between iterations.
For example:
Iteration 1:
service healthy
Iteration 2:
deployment starts
Iteration 3:
new pod crashloops
Earlier model assumptions are not canonical truth.
Relevant actions generate new observations.
An agentic system therefore resembles:
closed-loop control
more than:
open-loop generation
Bounded autonomy¶
A loop does not imply unlimited autonomy.
In production, prefer:
Autonomy
inside
explicit boundaries
Boundaries can include:
- allowed tools,
- allowed repositories,
- max iterations,
- max cost,
- read-only mode,
- environment scope,
- approval requirements,
- timeout,
- stop policy.
For example, a coding agent may:
edit files in current repository
run tests
not push to main
not access production credentials
max 20 iterations
Cost and latency multiplication¶
Every loop iteration can add:
model call
+ tool call
+ retrieval
+ model call
+ tool call
+ ...
So the cost of an agentic request is not:
one model invocation
but approximately:
Σ iterations(model + tools + retrieval + state operations)
This becomes important for execution budgets.
Anti-pattern: while-true agent¶
while True:
action = llm.next_action(history)
execute(action)
Without:
- explicit state,
- stop conditions,
- iteration limits,
- authorization,
- typed actions,
- error policy,
- observability,
this is not robust agent architecture, only an uncontrolled loop.
Anti-pattern: the model decides everything¶
An agentic runtime is not more “agentic” because every decision is delegated to an LLM.
These usually belong to deterministic software:
input schema validation
authorization
budget check
idempotency
allowed tool enforcement
transaction integrity
hard stop limit
Use the model where semantic ambiguity, planning, or reasoning creates real value.
Takeaways¶
- An agentic loop is an iterative execution model, not merely a long prompt.
- The core cycle is observe → decide → act → observe → continue/stop.
- The model is a decision component; the runtime owns execution state and control.
- Prefer workflow when control flow is known; use loops when the next action depends on current environment state.
- Production systems often benefit from deterministic workflows with agentic islands.
- Canonical execution state should not exist only inside model context.
- One iteration can be modeled as an explicit state transition or transaction.
- Autonomy should be bounded by tools, permissions, budgets, stop rules, and approval gates.
- Use agentic loops only where dynamic decisions add real value.