Agent = LLM + Tools + State + Stop Conditions
Explore how to design and implement bounded agent-like loops in AI workflows that integrate large language models with tool execution, shared state, and explicit stop conditions. Learn the importance of separating model proposals from tool calls, managing state for repeated steps, and controlling loop execution with stop rules to ensure safe, reliable automation in production support workflows.
A support email arrives that says the invoice shows a charge after cancellation, and the customer asks for a refund. In a one shot setup, the workflow sends the email text and a triage_json into one LLM call and receives a draft reply that may sound plausible but can easily miss account facts, such as whether the plan is active or already refunded.
When the same email runs through a bounded loop, the first model output proposes an action instead of a final reply. That proposal can be a customer lookup request, the workflow executes the lookup tool, and the returned status gets written into state before the model is called again to draft the reply using the new facts. The pattern is agent-like because the workflow repeatedly runs propose, execute, update, and stop, and it stays bounded because the workflow controls which tools can run and when the loop ends.
The key boundary is that this is not an autonomous long running system. It is a small, inspectable loop inside the support inbox workflow, and it only progresses when the workflow accepts a machine readable action and executes an allowlisted tool.
The four parts that carry the load
With the trace in mind, the loop only works because four parts are explicit and wired together. The model produces a structured action proposal, the workflow optionally runs a tool, shared state accumulates the results, and a stop condition ends the loop before it can ...