When Model Output Can Change State: An Architecture Guide to Agent Reliability

TL;DR for operators

A tool-using agent does more than generate an answer. It observes part of a workflow, carries information forward, decides what to do, changes external state, and then reacts to the result. A wrong answer in a chatbot may remain text; a wrong action in an agent can alter a file, submit a transaction, call the wrong service, or create a bad state that later decisions treat as valid.

Arunkumar V, Gangadharan G. R., and Rajkumar Buyya frame this distinction by representing an LLM agent as a recurrent perception-memory-planning-action-feedback system.¹ Their architecture-focused review then organizes Agentic AI across six connected dimensions: core components, cognitive architecture, learning, multi-agent systems, environments, and evaluation.

For an operator, the useful shift is to stop treating model capability as the complete unit of evaluation. Reliability also depends on what the agent can observe, what it remembers, which tools it may invoke, how execution is constrained, where verification occurs, and whether failed steps can be detected and recovered.

The review does not experimentally prove that graph orchestration, multi-agent decomposition, or any other architecture is generally superior. Its contribution is an engineering framework for locating failure surfaces and deciding which controls should surround the model.

A multi-step agent accumulates state as well as mistakes

Consider an agent handling an enterprise workflow. It reads an incoming request, retrieves prior records, chooses a next step, calls an internal API, receives a response, updates its working state, and continues.

Each step depends partly on what happened before. If perception misses a relevant field, memory retrieves the wrong record, planning produces an invalid next step, or a tool returns an unexpected result, the defect can enter the next iteration rather than disappear.

The paper formalizes this as a partially observable control process. In plain terms, the agent never sees the complete environment directly. It acts from an observation plus accumulated internal state. Its current memory is updated using previous memory, the latest observation, earlier reasoning, and execution feedback. Planning then generates a reasoning trace, and an action policy selects an external action from the available tool space.

The authors summarize the system as:

where the agent is defined not only by a policy, but also by its environment states, observations, memory, and available tools.

This POMDP-like formulation is conceptual rather than an empirically validated agent metric. Its value is diagnostic: it gives teams several places to look when an apparently capable model produces unreliable behavior.

Reliability has multiple architectural failure points

The review decomposes the field broadly, but three parts of the control loop have especially direct deployment consequences: grounding, memory, and action.

Perception determines what evidence reaches the model. The review’s examples range from screenshots and HTML-plus-vision systems to audio, video, proprioception, and 3D inputs. Their reported challenges differ—visual clutter, unstable interfaces, coordinate grounding errors, spatial resolution, turn-taking, or real-time latency—but they share a systems consequence: stronger reasoning cannot recover information that was never captured correctly.

Memory has a different problem. The six representative architectures in the review do not merely store more history. They retrieve, summarize, decay, page, cluster, merge, compress, or learn what to retain. Long-running agents therefore require a retention policy as well as a storage backend. An agent that remembers everything can still retrieve poorly; an agent that compresses aggressively can remove information later required for action.

Action increases the stakes further. The review traces a progression from predefined API calls to executable code, curated computer interfaces, generic mouse-and-keyboard control, and continuous embodied actions. Capability expands with the action space, but so does the failure surface. Code execution brings runtime and sandboxing concerns. GUI control adds brittleness, latency, and injection exposure. Physical action adds real-time and sim-to-real constraints.

For teams deciding how much autonomy to expose, this suggests a concrete mapping:

This mapping is a Cognaptus interpretation of the review, not a tested framework reported by the authors. It translates their control-loop model into deployment questions.

Orchestration becomes part of the safety architecture

The paper also documents a shift in multi-agent design from open-ended dialogue toward more explicit coordination structures: chains, hub-and-spoke systems, meshes, hierarchical arrangements, dynamic graphs, and developer-defined workflow graphs.

The production-relevant feature of a workflow graph is not that it prevents the model from making mistakes. It restricts which transitions are available and creates explicit locations for persistent state, guard nodes, approvals, checkpoints, and recovery.

That changes what developers can control. An unconstrained agent may decide both what to do and what may happen next. A constrained workflow can leave local judgment to the model while reserving transition rules and permissions for the surrounding system.

The review treats LangGraph as a representative workflow-graph architecture and Swarm as a lightweight handoff architecture. It also compares systems such as AutoGen, MetaGPT, DyLAN, and hierarchical verifier-worker arrangements. These comparisons describe coordination properties and intended use cases; they are not head-to-head experiments establishing a universal ranking.

There is also a cost boundary. Reflection, branching search, debate, hierarchical reasoning, and additional agents can improve opportunities for checking or decomposition, but the review associates them with additional tokens, latency, evaluator dependence, synchronization complexity, or coordination overhead. More reasoning machinery should therefore be justified against the failure it is intended to reduce.

Agent readiness needs more than task success

Once an agent interacts with production systems, successful task completion becomes only one deployment criterion. The paper organizes evaluation around the CLASSic dimensions: cost, latency, accuracy, security, and stability.

This is particularly useful for procurement and governance because two systems with similar task accuracy may create very different operating profiles. One may require substantially more inference. Another may exhibit larger run-to-run variance. A third may expose broader tool permissions or make failures harder to reverse.

Security also changes when generated outputs become executable actions. The review highlights indirect prompt injection, hallucinated actions, irreversible state changes, cascading errors, and repetitive loops. Its proposed response is systems-level: constrained permissions, authentication, sandboxing, allowlists, confirmations, independent policy or audit components, and operational monitoring.

For businesses, this implies that an agent evaluation should specify not merely whether a workflow was completed, but under what compute budget, latency tolerance, permission boundary, failure severity, and stability requirement it was completed.

What this review cannot establish

The paper is an architecture-focused narrative review. It reports no systematic search and screening protocol, fixed review corpus, original benchmark experiments, ablations, or replications. Its five comparison tables use selected representative systems, and quantitative performance claims discussed elsewhere in the review are inherited from heterogeneous prior studies.

That limits comparative conclusions. The review can organize the available architecture choices and explain their associated mechanisms and failure modes. It cannot establish that workflow graphs outperform meshes, that multi-agent systems outperform single agents, or that any specific memory or planning architecture is generally optimal.

The appropriate use is therefore architectural diagnosis rather than architecture ranking.

The autonomy question starts with the failure surface

The paper’s most practical contribution is not another catalog of agent capabilities. Its control-loop formulation makes clear that once an LLM repeatedly observes, remembers, reasons, acts, and reacts, reliability becomes an end-to-end systems property.

For an agent-product team, that changes the deployment conversation. The relevant questions include what the agent is permitted to see, what state it carries forward, how much reasoning it may spend, which actions it can execute, which transitions are prohibited, where independent verification occurs, and how the system recovers after an action produces an unexpected result.

Model quality remains part of that system. It simply does not determine the system alone.

Reference

Cognaptus: Automate the Present, Incubate the Future.