Correct Actions, Unstable Trajectories: Reasoning About Agent Behavior Over Time

A consequential agent failure rarely begins with one obviously indefensible action. More often, the sequence starts with something locally reasonable. The agent makes an assumption that appears plausible, takes an action consistent with it, observes the changed environment, and continues from the new state. Each step can remain individually defensible while the accumulated trajectory moves toward an increasingly undesirable condition.

A support agent might make an initially reasonable classification, send a message based on it, interpret the customer's response through the same frame, and progressively narrow the available resolution paths. A coding agent might adopt a workable but fragile design, patch around one failure, then another, until each new fix increases dependence on the original choice. A research agent might form a tentative hypothesis, preferentially gather confirming material, and eventually treat its own accumulated notes as evidence that the hypothesis was well established.

At no single point does the failure necessarily announce itself. The engineering problem emerges from the sequence: earlier actions change the environment, memory preserves some consequences and discards others, prior commitments affect later choices, and the range of easy recovery options shrinks.

This is why agent reliability needs a trajectory-level question alongside the familiar output-level one. Correctness remains necessary; the claim is that correctness alone is insufficient. Architects still need to ask whether a particular action was correct, safe, or justified. They also need to ask what kind of path the system tends to create when decisions compound over time.

The relevant properties are different. Does the agent settle into a useful operating condition? Does it recover after a poor step? Does ambiguity cause it to alternate indefinitely between strategies? Can one small error push it into progressively worse decisions? Those are questions about stability, not about the correctness of any single output.

Per-output checks are naturally local. They ask whether an answer is factually acceptable, whether a tool call is permitted, whether the selected action satisfies policy, or whether an intermediate artifact passes a test. These checks are necessary because a trajectory composed of plainly invalid actions is obviously unreliable.

But local validity does not guarantee desirable global behavior.

An agent can repeatedly make choices that are individually acceptable while producing a sequence that drifts away from its intended goal. Each tool call may be reasonable given the current uncertainty, yet the system may keep gathering information without reaching a decision. Each replan may be defensible, yet the agent may oscillate endlessly between two strategies. Each patch may fix the latest test failure, yet the resulting codebase may become progressively harder to complete or verify.

The distinction is similar to the difference between evaluating points and evaluating motion. A correctness check can tell us whether a particular state or transition is acceptable. Stability asks what happens when the transition process repeats.

That introduces questions that ordinary output scoring cannot answer by itself. If the agent is perturbed by a bad observation, does it return to productive behavior? If one objective briefly dominates, does the system restore balance or continue amplifying the imbalance? If a plan becomes uncertain, does the agent converge on a revised approach or alternate between old and new ones? If progress stalls, is there a mechanism that changes the system's state enough to escape?

A sequence-level evaluation is therefore additive, not a replacement for output review. Correctness remains important. The missing layer is whether repeated locally acceptable behavior produces a stable and recoverable run.

Part 1 used Jon Doyle's Extending Mechanics to Minds as an intellectual catalyst for mechanics-style reasoning about behavior. The trajectory vocabulary below—equilibrium, oscillation, deadlock, and runaway behavior—is this series' own engineering taxonomy for contemporary agent systems.

Four categories drawn from dynamical-systems and computing vocabularies are especially useful because they describe different trajectory shapes that can otherwise be collapsed into a generic statement that “the agent behaved badly.”

Equilibrium

An equilibrium is a condition the system tends to settle into and remain near unless something significant changes. For an agent, that might mean converging on a viable plan, reducing uncertainty to an acceptable level, stabilizing its tool usage, and progressing toward completion without repeatedly reopening resolved decisions.

The practical question is whether the agent has productive states it naturally tends toward. A useful equilibrium does not mean the system stops acting. It means the behavior becomes coherent: the plan, resource use, confidence, and external actions stop producing unnecessary instability.

Oscillation

Oscillation appears when an agent repeatedly moves between strategies or interpretations without resolving the underlying cause of the switch. A coding agent alternates between two architectures after each test failure. A support agent repeatedly escalates and de-escalates because different policy or satisfaction pressures dominate on successive turns. A research agent alternates between hypotheses as each new source temporarily shifts its judgment.

The individual transitions may all be explainable. The failure is that the sequence never settles. Repeated replanning becomes evidence about the trajectory itself.

Deadlock

Deadlock is a stalled condition in which the system remains active or technically valid but no longer makes meaningful progress. An agent may keep requesting clarification that cannot arrive, revisit the same unresolved dependency, or preserve a plan that cannot advance while refusing the alternatives required to escape it.

This failure mode matters because inactivity is not always obvious. The system can continue generating actions, messages, checks, or internal reasoning while remaining effectively trapped in the same state.

Runaway Trajectories

A runaway trajectory occurs when a small deviation is amplified by subsequent behavior instead of being absorbed or corrected. An early mistaken assumption leads to an action that changes the environment, the changed environment produces observations consistent with the new situation, and those observations reinforce the original plan. The system becomes progressively harder to return to its intended path.

Resource consumption can behave similarly. A weak uncertainty signal triggers another tool call, which exposes more ambiguity, which triggers additional investigation, until the agent consumes the budget without approaching resolution. Each step can look reasonable in isolation while the sequence amplifies the original disturbance.

These categories are valuable because they point toward different architectural questions. Oscillation suggests unresolved switching logic. Deadlock suggests missing escape conditions. Runaway behavior suggests reinforcing feedback without sufficient corrective mechanisms. A poor equilibrium suggests that the system is stable around the wrong operating condition.

The earlier parts of this series introduced three ways to look at agent behavior: internal state, commitment as inertia, and competing objectives as forces. Stability is where those ideas become one engineering problem.

State determines what prior history remains causally active. An agent's memory, resource consumption, external commitments, unresolved goals, and previous observations all shape the set of actions that remain plausible. Without a state-based view, two identical current observations can be treated as equivalent even when the systems that reached them are in very different conditions.

Commitment determines how strongly the agent resists changing course. Too much persistence can keep the system moving along a deteriorating trajectory. Too little can produce oscillation as ordinary friction repeatedly triggers replanning. Stability depends partly on whether commitment changes at the right rate as supporting and contrary evidence accumulate.

Competing forces determine which pressures shape each transition. Cost, latency, policy, user satisfaction, uncertainty reduction, and long-term goals may all pull behavior in different directions. If one force repeatedly dominates without visibility into the others, the system can drift toward a locally consistent but globally undesirable operating condition.

These mechanisms interact. A commitment problem can become a runaway trajectory when memory keeps reinforcing a failing plan. Competing objectives can create oscillation when their relative priorities flip repeatedly as state changes. Poor state representation can produce deadlock when the system cannot distinguish a genuinely new condition from one it has already processed.

Seen this way, instability is often a symptom of a deeper mechanism. The visible pattern appears at the trajectory level, while the underlying cause may sit in memory design, commitment logic, objective representation, resource governance, or the coupling between the agent and its environment.

That makes stability a useful synthesis layer for architecture review. Instead of asking only whether each component behaves plausibly, the review asks what kind of dynamics emerge when those components interact over a complete run.

Pre-deployment testing and incident review for agentic systems should include an explicit trajectory pass in addition to output-level evaluation.

The first question is whether the system tends to converge. Given a representative task and ordinary uncertainty, does the agent progressively reduce ambiguity, stabilize its plan, and move toward completion? Or does each new observation create another branch of work without closing earlier ones?

The second is recoverability. When the agent enters a poor state, can subsequent evidence pull it back? A useful test deliberately introduces a misleading observation, failed tool result, incorrect intermediate assumption, or temporary resource constraint and then observes whether the architecture can restore productive behavior.

The third is sensitivity to ambiguity. Some systems remain coherent when input is incomplete. Others begin alternating between strategies, invoking tools repeatedly, or changing their interpretation on each turn. That behavior may reveal unstable interaction among objectives or an overly responsive replanning mechanism.

The fourth is escalation. A review should identify whether small disturbances remain local or propagate. One incorrect classification should not necessarily change every later decision. One failed call should not automatically cause wholesale replanning. One ambiguous result should not trigger unlimited investigation. The architecture should make clear where escalation is intended and where it should stop.

Incident review benefits from the same lens. Instead of reconstructing only the first incorrect action, teams can map the sequence of states and ask where the trajectory became difficult to recover. Which prior decision changed the environment? Which memory entry reinforced the subsequent interpretation? Which commitment threshold kept the plan alive? Which competing pressure became dominant? At what point did the available recovery paths narrow materially?

This produces a different class of corrective action. The fix may still involve a prompt or model change, but it may instead require better state visibility, stronger escape conditions, an explicit replanning threshold, or separation of objectives that were previously blended together.

The goal is to make trajectory behavior testable. A mature review process should be able to distinguish systems that are locally acceptable but globally unstable from systems that both produce acceptable actions and return predictably toward useful operating states after disturbance.

As agentic systems spread across teams, platforms, orchestration layers, and shared services, trajectory behavior becomes a cross-architecture review problem that no single component owner can see clearly. Memory choices in one layer, tool governance in another, objective handling in a third, and delivery constraints elsewhere can combine into behavior that no team intended in isolation. DUNNIXER's architecture-leadership work in this setting centers on technical coherence, integration leadership, and decision governance across those interacting parts, so stability and recoverability are assessed at the system boundary, where the interacting parts meet.

This is part 4 of 4 in the series The Mechanics of Agentic Behavior.

• Part 1: Why Agentic Systems Need a Theory of State Beyond the Reward Function
• Part 2: Goal Persistence as Inertia: When an Agent Should Abandon a Failing Plan
• Part 3: Competing Objectives as Forces: Designing Agents Under Multiple Pressures

Browse the full Architectural Insights series →

• Jon Doyle, Extending Mechanics to Minds: The Mechanical Foundations of Psychology and Economics, Cambridge University Press, 2006.