An agent that has to look something up, change a record, check the result, and recover from a failed tool call is not doing one thing. It is making a sequence of decisions. The code that controls those decisions is the agent's reasoning loop.
Loop engineering is the practice of designing how an AI agent decides what to do next at each step: the repeating cycle of thinking, taking an action, and observing the result, rather than a single one-shot answer from a language model. Most AI tools answer a prompt once and stop. An agent is different. It thinks about the task, takes an action such as calling a tool, looks at what happened, and decides whether to think and act again or stop. That repeating cycle is called a reasoning loop, and loop engineering means choosing and shaping it on purpose instead of accepting whatever a framework hardcodes by default.
Why an agent needs a loop
A single model call works when the answer is already in context. It is a poor fit for a task that needs to retrieve information, use it to choose the next action, and try again when an external system returns an error. That task needs a loop.
The industry's default answer is ReAct, short for reason and act. The agent decides what to do, takes one action such as calling a tool, reads the result, and decides again. ReAct is simple, well understood, and a good starting point for tool-calling agents.
The limitation appears when every task gets forced through that same cycle. LangGraph and CrewAI provide primitives for state machines and custom graphs, but designing and testing a new graph is still a separate engineering project. A quick lookup and a multi-step plan are different kinds of work. Use the same loop for both and you may get wasted tool calls, a shallow plan, or an agent that keeps retrying after the useful work is done.
Researchers have proposed other reasoning patterns for other kinds of problems, not all of which are literal repeating loops. A few of the best known:
- Chain of Thought: the model reasons step by step in plain text before answering, without necessarily calling any tools in between.
- Tree of Thoughts: the model explores several possible reasoning paths at once and picks the most promising one, instead of committing to a single line of reasoning.
- Reflexion: the agent reviews its own earlier attempt, generates feedback on what went wrong, and tries again with that feedback in hand.
- Plan-and-Execute: the agent plans the entire task upfront, then works through the plan step by step, instead of deciding one step at a time.
None of these is universally best. A fixed sequence can suit a predictable back-office task; branching search can help when the answer is uncertain. The loop should match the task, not the other way around.
One note on the name: "loop engineering" is our framing, not an established industry term. ReAct, Chain of Thought, Tree of Thoughts, and Reflexion are published research patterns. We use one name for the practical decision of selecting and shaping them, and we are stating that distinction plainly.
How Matimo engineers this
We introduced this part of the platform in Introducing Matimo.ai as "Loop: Matimo Reasoning Engine." This is the deeper version: what the loop does, how Workbench selects one, and what is still incomplete. It is the fourth post in our series on the engineering surfaces a production agent needs: prompt, context, harness, and graph engineering.
Get the attribution right first: this is a Workbench capability
Loop engineering, as we describe it here, lives in Matimo Workbench, not Matimo OSS.
Matimo OSS is the tool-execution layer. It does not have an agent loop of its own. In the examples, a framework such as LangChain's AgentExecutor drives the loop and calls Matimo OSS when the loop decides to act. That is intentional: an open-source library that works across frameworks should not assume it owns the reasoning process.
Matimo Workbench is different. It makes the loop configurable per agent. That is the subject of this post. The distinction from harness engineering matters: Matimo OSS governs what a tool call is allowed to do after the loop chooses it; loop engineering governs how the agent gets to that choice. The two layers work together, but they are not the same product or responsibility.
Sixteen reasoning engines, one dispatcher
Matimo Workbench ships 16 distinct, fully implemented reasoning engines. UniversalReasoningManager dispatches an execution to the engine configured for that agent:
- ReAct: the industry-default loop, reason, act, observe, repeat
- Chain of Thought: step-by-step reasoning without tool-call interleaving
- Tree of Thoughts: explores multiple reasoning branches and evaluates which is most promising
- Reflexion: retries with self-generated feedback when an earlier attempt falls short
- RAISE: ReAct with enhanced memory for longer-running tasks
- Plan and Execute: plans the full task upfront, then executes the plan
- Scratchpad Reasoning: keeps an explicit working-memory trace across steps
- Goal Decomposition: breaks a large goal into subgoals before acting
- Graph-Based Planning: plans across branching, non-linear paths
- Multi-Agent Reasoning: coordinates multiple agents on one task
- Reflection-Critic: a second reasoning pass critiques the first before finalizing
- Fixed Action Sequence: a predetermined, deterministic sequence of actions
- Scratchpad Action Sequence: a scratchpad trace paired with a fixed action sequence
- Dynamic Planning: a meta-reasoning engine, described below
- Hybrid Symbolic + ML: combines rule-based logic with model-driven reasoning
- Plan-Retrieve-Generate: plans, retrieves relevant context, then generates
The mapping is practical. Exploratory work may suit Tree of Thoughts. A predictable process may suit Fixed Action Sequence or Plan and Execute. A task that needs coordination may suit Multi-Agent Reasoning, while a large hierarchical goal may suit Goal Decomposition. The point is not that one engine wins. It is that the builder can make the choice explicitly.
Dynamic Planning: the one engine that picks for you
The other 15 engines are explicit choices: the builder selects a strategy and can change it as the agent's role evolves. Dynamic Planning is different. It is a meta-reasoning engine that can select an underlying strategy at runtime based on the task, rather than requiring one strategy for every request.
You still have to configure an agent to use Dynamic Planning. The difference is where the next decision is made: once by the builder, or per task by the system. That flexibility is useful when one agent handles requests with meaningfully different shapes.
Why this is the differentiator, not a nice-to-have
ReAct is the default in much of the agent tooling landscape because it is useful and quick to stand up. That is also why it is the only engine on Matimo Workbench's free tier. The problem is not ReAct. The problem is having no practical alternative when the task calls for one. If choosing another loop means building and validating a custom orchestration graph from scratch, most teams will keep the default, even when it is a poor fit.
Matimo's bet is that the reasoning loop should be a configuration choice matched to the task: exploratory, sequential, collaborative, or hierarchical. Sixteen engines, including one that can choose among the other 15 at runtime, is what that bet looks like in the product.
Where we'd push back on ourselves
There is an important limitation. Self-critique is not implemented evenly across the 16-engine catalog. A handful of reflection- and evaluation-oriented engines produce an internal signal, such as a reflection pass deciding that an attempt was insufficient or a branch score marking a path as unpromising. The other engines do not produce a comparable signal today.
The broader feature that would surface those signals to a builder or administrator is not live yet. This is not a finished self-improving or self-auditing loop. What exists today is the 16-engine catalog and the reasoning-shape choices described above. Turning partial self-assessment into a useful operational signal is still ahead. That distinction matters when evaluating the product.
Frequently asked questions
What is loop engineering in AI agents?
Loop engineering means choosing how an agent decides what to do next: which actions it can take, how it uses their results, and when it should stop. The choice should follow the task rather than a framework default.
What is the ReAct pattern?
ReAct, short for reason and act, is a loop in which an agent chooses an action, observes the result, and chooses again until it can finish. It is the default in most agent frameworks and a solid choice for straightforward tool-calling tasks.
What other reasoning patterns exist besides ReAct?
Chain of Thought reasons step by step before answering. Tree of Thoughts explores several paths and evaluates them. Reflexion reviews an earlier attempt and retries with feedback. Plan-and-Execute plans the task upfront before working through it. Each fits a different problem shape.
How many reasoning strategies does Matimo Workbench support?
Matimo Workbench ships 16 fully implemented engines, including ReAct, Chain of Thought, Tree of Thoughts, Reflexion, Plan and Execute, and Dynamic Planning. UniversalReasoningManager dispatches each execution to the engine configured for the agent; Dynamic Planning can select an underlying strategy per task.
Can Matimo's reasoning engines tell when their own reasoning fell short?
Only partially. A handful of the engines, mainly reflection- and evaluation-oriented ones, produce an internal signal when an attempt looks insufficient. Most do not produce a comparable signal, and the feature that would surface it to a builder or administrator is not live yet.
Is loop engineering part of Matimo OSS?
No. Matimo OSS is a tool-execution layer with no agent loop of its own. A framework such as LangChain's AgentExecutor drives the loop and calls Matimo OSS when it decides to act. The 16 reasoning engines and their dispatcher live in Matimo Workbench.
Where to look next
For a free-tier starting point, Matimo Workbench includes ReAct on Freemium and all 16 engines on Pro and Enterprise, at matimo.ai. The rest of the series covers prompt engineering, context engineering, harness engineering, and graph engineering, where individual steps become a workflow.
If you're evaluating this for a team that needs a specific reasoning engine, or wants to know exactly where the self-assessment gap above sits relative to your use case, contact us directly.