Skip to content

Reasoning

Agent Reasoning Patterns: The Complete Guide

Agent reasoning patterns are the different control flows an LLM follows to solve a task — a single tool-calling loop, a plan-then-act cycle, an adversarial debate, or a hand-built graph. Most guides quietly imply the opposite of what's true: they suggest that stacking more reasoning stages makes an agent smarter. On today's capable models it usually just adds latency and tokens. By the end of this guide you'll know what each of the built-in patterns actually does, when the extra stages earn their cost, and how to switch between them with a single argument.

When Agent Tool Loops Fail: Fixing Context Bloat

If your agent is stuck in a tool loop — calling the same lookup over and over, its answer never arriving, its token bill climbing every turn — you are hitting the single most common production failure on deep tool tasks. It is not a prompt-wording problem and it is not a model problem. It is context bloat: a naive tool-calling loop feeds the model its entire transcript on every turn, and once that transcript grows large enough, the model loses the thread and re-fetches facts it already has. By the end of this post you will know exactly why the loop degrades, how the context_scope lever bounds it, and how to flatten token growth with a one-argument switch.

Code-Action Agents: Write One Program, Not 30 Tool Calls

A code-action agent flips the action space of an LLM: instead of chaining dozens of conversational tool calls to gather facts and then guessing the arithmetic in its head, the model writes one Python program over your tools and runs it. If you have ever watched an agent re-query the same records, blow its context window, and still return the wrong total, this pattern is for you. By the end of this post you will know when the codeact pattern wins, how to switch it on in Promptise Foundry with a single argument, and why the sandbox it runs in is locked down by default — not a bolt-on you have to remember to add.

Multi-Agent Debate for Better LLM Reasoning

A multi-agent debate LLM setup runs the same question through three roles — one model proposes an answer, another attacks it, and a judge decides who was right — instead of trusting a single pass. The appeal is obvious: adversarial scrutiny catches mistakes that a lone model, confidently wrong, will happily ship. The catch is just as real: you pay for it in latency and tokens. By the end of this post you'll know exactly what the Proposer → Critic → Judge graph does in Promptise Foundry, how to stand one up in a few lines, and — just as importantly — the narrow set of queries where it earns its keep versus the far larger set where a single verify pass is the smarter buy.

Plan-and-Execute Agents: How Planning Loops Work

A plan-and-execute agent writes an explicit plan before it touches a single tool, then works through that plan step by step instead of improvising one call at a time. It sounds strictly better than a plain tool-calling loop—and that intuition is the biggest trap in agent design. By the end of this post you'll understand exactly what the Plan → Act → Think → Reflect loop does, how to run one in Promptise Foundry with a single parameter, and—just as important—how to tell when the extra planning step earns its cost versus when it just burns tokens.

The ReAct Agent Pattern Explained (with Code)

The ReAct agent pattern is the loop underneath almost every tool-using LLM agent you have ever built: the model reasons about what to do, acts by calling a tool, observes the result, and repeats until it can answer. It is simple enough to hand-roll in twenty lines — which is exactly why so many production agents ship with a fragile version of it that quietly degrades on longer tasks. By the end of this post you will understand the pattern from first principles, be able to name the specific failure mode that bites hand-rolled loops, and stand up a production ReAct agent in a single function call where context stays bounded automatically.

ReAct vs Plan-and-Execute: Which Pattern to Use?

Choosing between react vs plan and execute is one of the first real architecture decisions you make once an agent stops being a demo and starts doing work someone depends on. Both patterns are legitimate; the internet's advice is mostly vibes. This guide is grounded in how the two actually behave on capable models, names the specific task shapes where each one wins, and shows you how to settle the question empirically on your own task instead of arguing about it. By the end you'll know which to reach for first — and how to A/B the two in Promptise Foundry by flipping a single argument.

Reflection, Self-Critique & Self-Consistency Agents

A self-critique agent is an LLM that checks its own work before it answers — it drafts a response, inspects that draft for mistakes, and fixes them in the same step. The appeal is obvious: catch the careless error before the user ever sees it. The catch is that reflection is not free, and most teams bolt it onto models that don't need it. By the end of this article you'll know which introspection techniques pay for themselves, which mostly burn tokens, and how to add a cheap self-check to a small model in a single line.