When Reasoning Leaves the Prompt: Designing the Agentic Control Loop

TL;DR for operators

When an LLM has to plan, call a tool, inspect the result, remember what happened, and decide what to do next, the system has changed in a more fundamental way than “adding more reasoning steps.” Agentic Reasoning for Large Language Models frames that change as a move from mostly static generation toward an interactive reasoning-and-control loop.¹

The survey separates that design space along two dimensions. First, it distinguishes foundational reasoning—planning, tool use, and search—from self-evolving reasoning, where feedback changes persistent memory, skills, tools, policies, or code across episodes, and collective reasoning, where work is distributed across communicating agents. Second, it separates capabilities created through inference-time orchestration with frozen model parameters from capabilities internalized through post-training.

For an operator, these distinctions affect different decisions. A workflow that only needs a browser call does not automatically need persistent memory. A workflow that improves from yesterday’s mistakes requires controls over what is written into durable state. A multi-agent design introduces communication, coordination, and credit-assignment problems that a single-agent tool loop does not. Post-training can reduce reliance on runtime scaffolding, but it also converts an orchestration decision into a model-development decision.

The paper does not establish a universal winner among these architectures. Its evidence is a qualitative synthesis across heterogeneous systems, applications, and benchmarks rather than a pooled quantitative comparison.

The change happens when reasoning can affect what happens next

The survey’s Table 1 provides the cleanest starting point. Conventional LLM reasoning is characterized as passive, static-input, single-pass, context-limited, non-persistent, prompt-driven, and reactive. Agentic reasoning instead introduces dynamic context, multi-step interaction, feedback, external memory, persistent state, explicit goals, and planning.

That distinction matters because more tokens alone do not create the same engineering problem. Once a model can issue an external action, the result of that action becomes part of the next decision. Once the system can preserve state, yesterday’s trajectory can influence tomorrow’s behavior. Once it can communicate with another agent, another policy becomes part of its environment.

The paper formalizes this by separating internal reasoning from external execution:

Here, the system first produces an internal reasoning state $z_t$ from its interaction history $h_t$, then selects an external action $a_t$ conditioned on both. The value of this formulation is not mathematical novelty by itself. It makes the control boundary explicit: reasoning and acting are coupled, but they are not the same operation.

Cognaptus inference: permissions, validation, logging, and rollback should therefore attach to execution boundaries and state transitions, not only to the model endpoint.

Three layers correspond to different architecture commitments

The survey organizes agentic reasoning into three analytical layers.

These layers are not mutually exclusive product categories. A deployed research agent could search the web, accumulate experience, and delegate subtasks to other agents simultaneously.

That makes the taxonomy more useful as a decomposition tool than as a labeling exercise. A team can ask which capabilities its workflow actually requires instead of adopting “agentic” as one undifferentiated architecture.

The survey’s tables reinforce this diversity. Planning systems range from sequential and hierarchical structures to trees and graphs. Tool-use systems include inference-time prompting, post-training, and system-level orchestration. Search systems similarly span interleaved, iterative, reflective, graph-based, and learned approaches. The paper’s evidence therefore supports a broad design space, not one canonical agent stack.

Runtime orchestration and post-training solve different problems

A second distinction cuts across all three layers.

Some capabilities can be produced at inference time while keeping model parameters fixed. The paper describes this as searching or orchestrating candidate reasoning trajectories and evaluating them using heuristics, verifiers, or other feedback. Tool selection, iterative search, planning, and workflow routing can all live in this runtime layer.

Post-training takes a different route. Supervised fine-tuning or reinforcement learning can internalize policies for tool use, retrieval, planning, memory management, or collaboration into model parameters.

For engineering leaders, the decision is not merely “prompting versus fine-tuning.” It changes where complexity and cost reside.

Inference-time orchestration keeps behavior easier to inspect and modify at the system layer, but may add latency, repeated model calls, search overhead, and orchestration code. Post-training can move recurring behaviors into the model policy, but adds trajectory collection, training infrastructure, evaluation requirements, and model-version maintenance.

The survey does not provide the quantitative evidence needed to identify a universal crossover point. The appropriate choice remains workload-specific.

Persistent memory changes the governance surface

The paper treats memory as part of reasoning and control rather than as a larger archive attached to the model.

Its memory survey includes factual and experiential memory, flat and structured representations, multimodal memory, and post-trained memory-control policies. More importantly, the cross-episode formalization allows completed trajectories and environmental feedback to modify persistent system state:

That state can include memories, skills, tools, policies, or code.

This is the dividing line between improving the current attempt and changing future behavior. A retry loop disappears when the task ends. A stored workflow, revised memory, or updated tool policy does not.

Cognaptus inference: persistent adaptation should be treated as a governed write operation. Teams need to decide what can be stored, who or what can modify it, how provenance is retained, how corrupted updates are detected, and how state can be rolled back. A memory feature becomes materially different once it can influence later decisions without the original evidence being re-examined.

More agents add coordination problems, not just capacity

Collective reasoning extends the same control problem across several agents. The survey emphasizes differentiated roles, communication, division of labor, and shared or distributed state.

That can create specialization, but it also creates new failure modes. Messages consume context and compute. Agents may disagree. Shared state can propagate errors. It becomes harder to assign credit or blame for a final outcome. The survey explicitly identifies communication efficiency, stability, credit assignment, and trustworthiness as unresolved challenges.

The practical consequence is that a multi-agent architecture should be justified by a task dependency that specialization or parallelism actually addresses. Adding agents is not evidence of greater capability by itself.

For evaluation teams, aggregate task success is consequently insufficient. Planning, tool execution, search, memory behavior, communication, and coordination can fail for different reasons and require different controls.

Use the framework as a design map, not an architecture leaderboard

The survey connects its taxonomy to mathematics and coding, scientific discovery, embodied systems, healthcare, autonomous web exploration, and research agents. It also organizes evaluation into mechanism-level benchmarks and application-level benchmarks.

But the evidence base has an important boundary. The paper does not report a reproducible literature-search protocol, explicit screening criteria, or a formal included-study count. The reviewed systems also differ substantially in tasks, environments, models, metrics, and interaction horizons. No meta-analysis or standardized quantitative ranking is provided.

That limits what operators should infer. The survey provides a strong vocabulary for decomposing an agent system and locating research questions. It does not demonstrate that self-evolving systems outperform stateless systems in general, that multi-agent systems outperform single agents, or that post-training is more economical than inference-time orchestration.

Those comparisons still require workload-specific measurement.

Treat agency as a control architecture

The most useful contribution of this survey is to move the agent discussion away from a checklist of features.

Planning, tools, search, memory, feedback, and additional agents all change how decisions are produced, executed, remembered, and revised. The resulting system has more control surfaces than a model answering a prompt: execution permissions, validators, memory writes, policy updates, communication channels, and cross-episode state.

That gives operators a clearer sequence of decisions. First determine whether the workflow requires interaction beyond one inference. Then determine whether experience must persist across episodes. Only then ask whether cognition should be distributed across multiple agents. Separately, decide which recurring behaviors should remain visible in runtime orchestration and which justify investment in post-training.

The survey does not settle those choices. It does something more immediately applicable: it makes them distinguishable.

Cognaptus: Automate the Present, Incubate the Future.