Anatomy of an agentic loop
An agent isn’t a prompt: it’s a loop that reasons, calls tools, observes and repeats until it can answer. Here is that loop, running.
A chatbot takes one message and returns one answer. An agent does something fundamentally different: it runs a loop. It reasons about what to do, takes an action (usually a tool call), observes the result, and decides whether it is done or needs to go around again.
That loop is the whole game, and everything Thaliq builds sits under it. So instead of describing it, press Play and watch one run:
The agent loop
A scripted example, not a live agent.
- Where is my order #1234?
- Press Play or Step to watch the agent work.
Step 0 of 4
Reason, act, observe, repeat
Every turn of the loop has the same shape:
- Reason. The model decides what has to happen next. Sometimes that is “I can answer now.” Often it is “I need more information.”
- Act. The model calls a tool: an HTTP endpoint of yours, or an MCP server. This is where the agent touches the real world.
- Observe. The tool’s result comes back into context, and the model reasons again.
The loop keeps going until the model has enough to answer. Two tool calls or ten, the shape never changes, which is exactly why it can be infrastructure.
Tools are how agents do anything real
A model on its own can only produce text. Declare a tool such as check_order or create_ticket, as an HTTP tool that points at your API or as a tool of an MCP server you run, and the agent can look things up and take actions. In the first run above, the agent doesn’t know where order #1234 is: it calls a tool to find out, then answers from the result. No invented tracking numbers.
When the loop should stop and ask a person
Look at the second run, Refund with approval. The agent reaches a point where it could act, but a refund moves money. A tool declares its risk (read, write or money), and a Policy decides which risks wait for a person. So the run pauses, holds no worker while it waits, and carries on when someone with the right role approves it from the console.
That is not a limitation; it is the design. Autonomy where it is safe, a human checkpoint where it isn’t. The loop is where you enforce it.
Why this is infrastructure, not a prompt
Running one loop in a notebook is easy. Running thousands in production is not. The loop needs:
- Streaming, so people see the answer and the tool calls as they happen.
- Durable execution. A checkpoint after each step, so a run whose worker restarts or crashes continues on another worker from the last step it completed.
- Timeouts, cancellation and safe retries for tools that fail or hang. A tool call has a timeout, a run can be cancelled, and a step that runs again after a restart carries the same idempotency key, so it does not repeat its side effects.
- A Policy in the loop. Which tools an agent may call, and which calls wait for a person, enforced on every call.
- Usage facts. Tokens in, tokens out and what they cost, per run and per agent, in Lens.
That is the part nobody wants to rebuild, and it is what Thaliq is: the loop, the tools, the memory and the policies, as infrastructure. The runtime is not tied to one model vendor: it speaks to Anthropic, Amazon Bedrock and OpenAI, and to local models through Ollama or vLLM. The hosted service runs Claude Haiku 4.5 on Amazon Bedrock today, and you can run Thaliq in your own infrastructure too.
The loop is simple. Making it dependable is the work.
Jhosetp Chino
We write about how we build Thaliq: the decisions, what went wrong and what we changed. From Lima.