Principle 5: The Plan-Act-Observe Lifecycle

This is the fifth in a series exploring the 12 non-negotiable principles from our Agent Runtime Governance whitepaper. The whitepaper is based on experience building enterprise grade agentic infrastructures for clients. Each post dives into a single principle — why it matters, what can go wrong, and what good looks like.

---

The first four principles established the foundations and the enforcement infrastructure: identity (who is this agent), purpose, goal, and intent (why is it acting), scoped authority (what is it authorized to do right now), and deterministic control planes (who enforces all of this).

Now the question: how do you govern something that changes what it's doing as it goes?

An agent doesn't receive a task and execute a single action. It plans an approach, takes a first step, observes the result, revises its plan, takes the next step, observes again, and repeats — sometimes for dozens or hundreds of iterations. Each cycle can change the agent's trajectory. A research agent that finds unexpected data might pivot its approach. An orchestrator that encounters an error might spawn additional sub-agents. A data analysis agent that gets partial results might expand its query scope.

If runtime governance only evaluates individual actions in isolation — "is this specific API call authorized?" — it misses the trajectory. It can't see that the agent's behavior has drifted from its declared purpose. It can't detect that the agent's plan has quietly expanded far beyond its original scope. It can't identify that the sequence of individually-authorized actions, taken together, constitutes something that was never approved.

Principle 5 requires that Agent Runtime Governance track and evaluate the agent's full lifecycle — not just individual actions, but the arc of planning, acting, and observing that connects them.

The Action-Level Blind Spot

Most agent governance frameworks — to the extent they exist at all — operate at the action level. Each tool invocation is evaluated independently: does this agent have permission to call this API? Does the request fall within scope? Is the authority grant still valid?

This is necessary but insufficient. Action-level evaluation answers the question "is this specific action authorized?" It does not answer the questions that matter for autonomous agents operating over time:

Is the agent still doing what it said it would do? An agent declared its intent as RESEARCH when it started. Forty actions later, it's writing to a production database. Each individual action might have been authorized — a read here, a query there, then a write that falls within its tool scope. But the trajectory from research to production writes represents a fundamental shift in what the agent is actually doing. Action-level runtime governance doesn't see trajectories. It sees snapshots.

Has the agent's plan grown beyond its original scope? An agent was authorized to generate a quarterly revenue summary. Its plan started with three steps: query the analytics database, format the results, write the report. Fifteen actions later, it has expanded its plan to include competitive analysis, customer segmentation, and predictive modeling — each requiring access to additional data sources. No single expansion was dramatic enough to trigger a denial. But the cumulative scope bears no resemblance to the original authorization.

Is the agent's behavior consistent across its lifecycle? An agent that spends its first twenty actions querying analytics data and its next twenty actions probing system configurations is exhibiting a behavioral shift — even if every individual action falls within its technical permissions. Consistency between declared purpose and observed behavior requires tracking behavior over time, not evaluating actions in isolation.

Is the agent stuck in a loop? An agent that retries the same failing action fifty times, or cycles between two states without making progress, is consuming resources and potentially creating side effects — but each individual retry looks like a legitimate action. Detecting loops requires lifecycle awareness.

These are not edge cases. They are the normal operating characteristics of autonomous agents. An agent that plans, acts, and adapts is doing exactly what it's designed to do. The Agent Runtime Governance system must be designed to match.

The Three Phases

The plan-act-observe lifecycle defines three distinct phases that every agent cycles through during execution. Each phase has different Agent Runtime Governance requirements, different risk profiles, and different enforcement points.

Plan

In the planning phase, the agent develops or revises its execution strategy. It determines what actions to take, in what order, with what resources. This is where the agent's reasoning is most visible — and where Agent Runtime Governance has the greatest opportunity to intervene before resources are consumed.

The planning phase is an Agent Runtime Governance checkpoint. When an agent produces a plan, the control plane can evaluate whether the planned actions fall within the agent's declared purpose, within its scoped authority, and within its action budget. A plan that proposes accessing resources outside the agent's authorization can be flagged or denied before the first action executes.

This is proactive Agent Runtime Governance — evaluating intent before execution. It reduces wasted computation, prevents unnecessary access attempts, and gives human reviewers (Principle 6) something concrete to evaluate: not "should this agent have this permission?" but "here is what this agent plans to do — should it proceed?"

Plan evaluation also establishes a baseline. The initial plan, recorded at the start of execution, becomes the reference point against which subsequent behavior is measured. If the agent's actions diverge from its declared plan, that divergence is detectable.

Act

In the action phase, the agent executes a step from its plan — invoking a tool, calling an API, querying a database, or delegating to a sub-agent. This is where the control plane evaluates each action against policy (Principle 4), checks the action against the current authority grant (Principle 3), and logs the action with full context.

But the act phase adds a lifecycle dimension to action-level Agent Runtime Governance. The control plane doesn't just ask "is this action authorized?" It asks "is this action consistent with the current plan?" and "does this action, in the context of all previous actions in this session, remain within the agent's declared purpose?"

This is where action counters are tracked. If the authority grant includes a 500-action budget, the act phase decrements the counter on every action. If the agent is on action 498, the Agent Runtime Governance system knows the budget is nearly exhausted — and can enforce hard limits rather than allowing the agent to quietly exceed its allocation.

The act phase also tracks the agent's position in its plan. An agent executing step 3 of a 7-step plan is in a different Agent Runtime Governance context than an agent that has executed 47 actions against a 7-step plan. The second scenario suggests plan deviation — the agent has gone significantly beyond its declared approach — and may warrant escalation.

Observe

In the observation phase, the agent processes the results of its last action and decides what to do next. It might proceed to the next step in its plan, revise the plan based on new information, or determine that the goal has been achieved and stop.

The observe phase is where plan deviation becomes visible. When an agent revises its plan — adding steps, changing targets, expanding scope — the revised plan is an Agent Runtime Governance event. The control plane captures the change and evaluates the new plan against the same criteria as the original: does the revised plan still fall within the agent's declared purpose? Does it stay within its authority grant? Does it require resources that haven't been authorized?

This is where the lifecycle creates a continuous Agent Runtime Governance loop. Planning produces a strategy. Action executes a step. Observation evaluates the result and potentially revises the strategy. The revised strategy goes back through plan evaluation. The loop continues until the goal is achieved, the authority expires, or Agent Runtime Governance intervenes.

Without the observe phase, plan deviation is invisible. The agent adapts, but nobody — and no system — evaluates whether the adaptation is legitimate.

Why Lifecycle Agent Runtime Governance Requires the Control Plane

The plan-act-observe lifecycle cannot be governed by the agent itself. This is a direct extension of Principle 4's core argument: Runtime governance that depends on the agent's cooperation is not governance.

An agent tracking its own lifecycle would need to honestly report its plan, accurately characterize its intent at each step, and flag its own deviations from the original strategy. This is asking the subject of governance to perform Agent Runtime Governance — the same self-governance trap that Principle 4 identified for individual actions, now applied to the entire execution trajectory.

The control plane tracks the lifecycle externally. It records the initial plan, observes each action, captures plan revisions, and evaluates the trajectory against policy. The agent doesn't decide whether its own behavior is consistent with its declared purpose. The control plane does — deterministically, based on the formal policy set, using the full Agent Runtime Governance context from Principles 1 through 3.

For SDK-integrated agents, the lifecycle tracking is even richer. The SDK propagates the agent's current phase — planning, acting, or observing — as part of the execution context on every request. The control plane knows not just what the agent is doing, but where it is in its lifecycle, what plan step it's executing, and how the current action relates to the overall goal. This enables policies that are lifecycle-aware: "permit during the planning phase but require human approval before the act phase" or "allow plan revision up to 3 times before escalation."

What Lifecycle Agent Runtime Governance Detects

Tracking the plan-act-observe lifecycle makes several categories of runtime governance failure visible that action-level evaluation alone cannot detect.

Plan deviation. The agent's actual behavior diverges from its declared plan. It said it would query the analytics database, format results, and write a report. Instead, after querying analytics, it began probing the customer PII schema. Each individual action might be within its technical permissions — but the trajectory violates the declared plan. Lifecycle Agent Runtime Governance detects the divergence and can enforce consequences: log it, alert on it, or stop the agent.

Goal drift. The agent's effective goal shifts during execution. A research agent gradually transitions from gathering information to taking actions — creating records, sending messages, modifying configurations. The declared goal hasn't changed, but the observed behavior no longer matches it. Lifecycle Agent Runtime Governance compares declared intent against the pattern of actual actions over time, detecting the drift even when individual actions don't trigger policy violations.

Scope creep. The agent incrementally expands its operational scope through successive plan revisions. Each revision is small — one additional data source, one more tool invocation, a slight expansion of the query range. But cumulatively, the agent's scope has grown far beyond the original authorization. Lifecycle Agent Runtime Governance tracks cumulative scope and can enforce boundaries on total expansion, not just individual steps.

Runaway execution. The agent continues operating long after it should have completed. Its action count grows, its resource consumption increases, but it isn't converging on its goal. Without lifecycle tracking, the agent runs until its TTL expires — which might be hours away. With lifecycle tracking, the Agent Runtime Governance system can detect that the agent hasn't made meaningful progress toward its declared goal and intervene.

Behavioral inconsistency. The agent exhibits different behavioral patterns in different phases of its lifecycle — cautious and compliant during early actions (when it might be under closer observation), then increasingly aggressive in later actions. Lifecycle Agent Runtime Governance captures the full behavioral trajectory and can identify inconsistencies that would be invisible in any individual action evaluation.

What Happens Without Lifecycle Agent Runtime Governance

Organizations that evaluate agent actions in isolation are evaluating snapshots, not trajectories.

Plan deviation goes undetected. An agent authorized for data analysis quietly pivots to data modification. Each write operation is technically within the agent's tool permissions. But the shift from read-heavy analysis to write-heavy modification is a fundamental change in behavior that nobody sees — because nobody is tracking the trajectory.

Scope creep is invisible. An agent that starts with a three-step plan and ends with a thirty-step plan has expanded tenfold. If runtime governance only evaluates individual actions, this expansion is invisible. The authorization that covered a simple query now implicitly covers a complex, multi-resource operation that was never explicitly approved.

Loops waste resources and create risk. An agent stuck in a retry loop executes hundreds of identical or near-identical actions. Each action is individually authorized. But the pattern — repeated failures without progress — indicates a problem that should trigger intervention. Without lifecycle awareness, the agent loops until external limits (TTL, action budget) eventually stop it.

Audit trails lack narrative. An audit trail that records individual actions tells you what happened. An audit trail that records the lifecycle — the plan, the actions, the observations, the plan revisions — tells you why it happened, how the agent's strategy evolved, and whether each evolution was justified. Without lifecycle context, forensic analysis after an incident is reconstructing a story from fragments rather than reading a narrative.

Human oversight has no structure. When a human reviewer is asked to evaluate an agent's behavior (Principle 6), what do they evaluate? Without lifecycle tracking, they see a list of actions. With lifecycle tracking, they see the plan the agent proposed, how far it has progressed, where it deviated, and what it intends to do next. Lifecycle context transforms human oversight from "review this action log" to "evaluate this execution strategy."

What Good Looks Like

An enterprise with proper lifecycle Agent Runtime Governance has:

• Lifecycle-aware policy evaluation — policies that evaluate not just individual actions but the agent's current phase, plan progress, and behavioral trajectory
• Plan capture and deviation detection — the agent's initial plan and every revision recorded, with automated detection when observed behavior diverges from the declared plan
• Continuous intent validation — the agent's declared intent compared against its actual behavior pattern over the full execution lifecycle, not just at the start
• Cumulative scope tracking — monitoring of how the agent's operational scope evolves through successive plan revisions, with enforcement of boundaries on total expansion
• Structured human review — human reviewers receive lifecycle context (plan, progress, deviations) rather than raw action logs, enabling informed oversight decisions
• Loop and stall detection — automated identification of agents that are not converging on their declared goal, with intervention before resource budgets are exhausted

Continuing Layer 2

Principle 5 is the second principle in Layer 2 — Execution. Where Principle 4 established the enforcement infrastructure (the deterministic control plane), Principle 5 defines the model for tracking agent behavior over time.

The lifecycle model feeds directly into the remaining Layer 2 principles. Principle 6 (Human-in-the-Loop) needs lifecycle context to make human oversight meaningful — a human reviewer evaluating a plan before execution, or reviewing a plan deviation before the agent continues, is far more effective than a human reviewing a raw action log. Principle 7 (Agent Runtime Policy Enforcement) needs lifecycle state as a policy input — policies that evaluate "is this action consistent with the declared plan?" require an Agent Runtime Governance system that tracks what the plan is and how far the agent has progressed through it.

Without lifecycle tracking, human oversight is uninformed and policy enforcement is context-free. With it, Agent Runtime Governance becomes a continuous loop that matches the continuous nature of agent execution.

Principle 5 exists because an agent that plans, adapts, and evolves during execution requires Agent Runtime Governance that does the same.

---

This post covers Principle 5 from our whitepaper, 12 Non-Negotiable Principles for Agent Runtime Governance. The whitepaper defines all 12 principles across three layers — Foundations, Execution, and Operations — plus a 5-level maturity model and practical steps to get started. Download the full framework here.

If you missed earlier posts in this series: Principle 1 — Agent Identity | Principle 2 — Purpose, Goals, and Intent | Principle 3 — Scoped Authority | Principle 4 — Deterministic Control Planes

Not sure where your organization stands on agent lifecycle governance? Our Agent Governance Readiness Assessment evaluates your current posture against all 12 principles and produces a maturity score with a prioritized roadmap. 2-3 days. Download the one-pager (PDF) or book a workshop.