Beneath the surface of every agent — whether it books travel, reviews contracts, or writes production code — the same four-part machinery is running. The agent plans, acts, observes the results of its actions, and remembers what it has learned. Then it plans again. This loop, deceptively simple in description, is where virtually all of the interesting behavior emerges, and where virtually all of the failures begin. Understanding the mechanics of each component — not at the level of a research paper but at the level of an engineering and governance decision — is the prerequisite for everything else in this report.
The Planning Layer
Planning is the step where a model transforms a goal into a sequence of actions. In the simplest case, this is a single inference call that produces a short to-do list. In more sophisticated systems, planning is itself a multi-step process: a high-level planner decomposes the goal into sub-goals, each of which is handed to a more specialized executor. The ReAct paradigm — Reasoning and Acting interleaved in a single prompt — was an early demonstration that models could plan and act in the same context window. More recent architectures, like those underlying Anthropic's Claude Code and OpenAI's Codex-based tools, use explicit scratchpad reasoning that is stripped before the final output is produced.
The planning layer is where model quality matters most. A model that reasons well — that can decompose ambiguous goals, identify dependencies between steps, recognize when a plan needs revision — will complete tasks that a weaker model fails at, even with identical tool access. But planning quality is also where the first class of failures appears: models that confidently construct plans based on incorrect assumptions about the environment, or that over-plan (generating elaborate multi-step sequences for tasks that could be accomplished in one tool call), or that under-plan (diving into execution without adequate decomposition, creating situations that are difficult to recover from).
Enterprise architects need to understand the planning layer not only to evaluate model capability but to design appropriate oversight. A plan that is legible — that can be inspected before execution begins — enables a class of human-in-the-loop governance that is impossible when planning and execution are fused. Some orchestration frameworks, including LangGraph and CrewAI, expose explicit plan objects for this reason. Others, following the React paradigm, interleave planning and execution in a way that makes pre-execution review impractical. Neither approach is universally correct; the choice depends on the reversibility of the actions involved.
The Act Layer
Acting is the step where the agent reaches outside its own context window and changes something in the world. This is the step that distinguishes an agent from a chatbot, and it is the step that creates real risk. Tool calls are the primary mechanism: the model generates a structured call to a function, API, browser, code interpreter, or external service, and the result is returned to the context.
The range of tools available to modern agents has expanded dramatically. Early tool-augmented models could search the web and run simple computations. Current systems — using the Model Context Protocol (MCP), which has become the de facto standard for agent-tool integration — can interact with essentially any system that can expose an API: CRMs, ERPs, file systems, databases, code repositories, email, calendars, and increasingly, physical-world interfaces like browser-controlled desktops and robotic actuators.
The governance implications of tool access are proportional to the power of the tools. An agent that can only read documents has a very different risk profile from one that can write to a database, send emails on behalf of a user, or execute code in a production environment. The principle of least privilege — grant only the minimum tool access necessary for the task — is as important in agentic system design as it is in conventional access control. In practice, it is harder to enforce: tool permissions are often configured once at deployment time and not revisited as the agent's operational scope evolves.
The Observe Layer
Observation is the step where the agent processes the results of its actions. A tool call returns a response — a database query result, an API response body, a web page's text content, a code execution output — and the agent must parse that response, determine whether its action succeeded, and update its understanding of the world accordingly.
This step sounds passive but is anything but. The observe layer is where a significant class of vulnerabilities lives. The agent is, by design, trusting the content it receives from tool calls. If that content has been manipulated — if a document the agent retrieves from the web contains instructions designed to redirect its behavior, if a database record has been poisoned with adversarial text — the agent may incorporate those instructions into its planning and produce behavior that its operators neither intended nor anticipated. This is the mechanism behind indirect prompt injection, one of the most operationally significant security risks in agentic systems and a central concern of the OWASP LLM Top 10.
Designing robust observation means building not just the capability to receive tool results but the capability to verify them. Does the result make sense given the context? Is it plausible that this external source would return this content? Should the agent flag this result for human review before acting on it? These are design questions that current frameworks leave largely to the application developer, and they are questions that few developers ask with sufficient rigor before deployment.
The Memory Layer
Memory is what separates a stateful agent from a stateless one, and a useful agent from an irritating one. The simplest form of agent memory is the context window itself: everything the model has seen in the current interaction is, in principle, available to it. But context windows are finite (even very large ones impose latency and cost penalties), and they are ephemeral — they do not persist across sessions. For agents that operate over extended time horizons, on tasks that span hours or days, or in environments where they need to recall decisions made in prior sessions, external memory stores are required.
Memory architectures typically distinguish at least three layers. Short-term memory — the current context window — holds the immediate task state. Long-term memory — typically a vector database or a structured key-value store — holds persistent facts, prior decisions, user preferences, and domain knowledge that should survive across sessions. Episodic memory — a log of what the agent actually did and what the results were — is the most underbuilt of the three in current systems, yet it is the most important for both learning and audit.
From a governance perspective, memory is where data residency, retention, and privacy obligations land. An agent that accumulates a long-term memory of a user's decisions, preferences, and conversations is, in effect, building a profile. That profile is subject to the same GDPR and CCPA obligations as any other personal data store — but the tooling for managing agent memory with the same rigor as a conventional database is still immature. Organizations deploying agents with persistent memory should, at minimum, define explicit retention policies, classification labels for stored memories, and audit mechanisms before they discover these gaps through a regulator rather than an internal review.
"Most agentic failures don't live in the circles — in the plan, the act, or the observe step taken individually. They live on the arrows: in the translation between observation and the next plan, where wrong assumptions compound, and in the memory layer, where bad facts get entrenched."
How the Loop Runs
The four components do not execute once. They execute in a loop — plan, act, observe, update memory, plan again — until the agent determines that the goal has been met, that the goal cannot be met, or that it has reached its resource budget (in tokens, tool calls, or elapsed time). The loop is the source of both the power and the risk.
Power: the loop allows an agent to adapt. If a tool call fails, the agent can try a different approach. If new information changes the picture, the agent can revise the plan. This adaptivity is what makes agents useful for open-ended tasks where the path is not known in advance. Risk: the loop can diverge. An agent that loses track of its goal, or that develops an incorrect model of the environment, or that is manipulated through adversarial tool outputs, can run for many iterations in a direction that is costly or irreversible before any oversight mechanism catches it.
Practical agent deployments manage loop risk through a combination of resource budgets (maximum token spend, maximum tool call count, maximum elapsed time), explicit goal-completion checks, and human-in-the-loop confirmation gates for actions above a configurable risk threshold. The specific values of these parameters are among the most consequential engineering decisions in agentic system design — and among the least discussed in vendor documentation.