Core Thesis: Traditional Application Performance Management (APM), built on fixed metrics (latency, throughput) for deterministic user journeys, is inadequate for autonomous, agentic systems. Because software now constructs its own workflows and alters its own environment, observability must shift from mechanical telemetry to Situational Intelligence: evaluating realtime context, purpose, confidence, and system viability.
- Traditional APM (aka Observability), built for predictable workflows, hits conceptual limits in latency, throughput, utilization, and availability as autonomous systems introduce new operational challenges.
- Agents build their own paths. Agentic systems decompose goals, delegate tasks, revise assumptions, and assemble workflows dynamically; structure, duration, and objectives can shift during execution.
- Performance is increasingly shaped by context. The worth of an activity depends on its purpose, complexity, consequences, and outcomes. Meaningful assessment requires understanding what the system aims to achieve.
- Six situational dimensions become central to assessing intelligent activity.
- The intelligence to stop is essential. Autonomous systems must detect declining confidence, instability, and environmental divergence; deciding when to reassess, redirect, escalate, or suspend is an operational capability.
- System viability becomes a continuous concern. Generative software modifies its workflows, dependencies, and environment; viability demands ongoing adaptation of behavior and its representations.
- Observability must be built into the architecture of understanding: representations and signs should arise from system assessments and decisions, with higher-level intelligence guiding lower-level recognition and cognition.
- Feedback must span levels and timescales: immediate agent behavior, supervisory coordination, and engineering evolution are interdependent regulatory processes whose continuous interaction drives situational intelligence.
- APM remains essential to infrastructure performance; evaluating autonomous activity needs purpose-driven measures of uncertainty, progress, and interventions.
- Situational intelligence is vital to software operations and governance. As software becomes autonomous, engineering must enable systems that understand context, evaluate awareness, anticipate change, and act.
Introduction
There is something strangely dated about seeing Formula One cars used to advertise modern observability platforms.
The imagery is familiar: racing machines, telemetry, precision, milliseconds. The promise suggests that with sufficient instrumentation, data, and analytical tools, we can make systems behave like finely tuned cars.
This picture comes from Application Performance Management (APM), and for a long time it seemed quite reasonable.
Applications were built around clear operations. Users moved through interfaces, started transactions, sent forms, and waited for replies. Engineers understood each task’s purpose and could gauge realistic timing.
Performance optimization prioritized latency, throughput, utilization, and availability; accordingly, the initiative concentrated on identifying bottlenecks, streamlining workflows, and monitoring improvements.
The racing metaphor captured the aspiration well. We knew the machine. We knew the track. We wanted to go faster.
The software world that gave rise to this imagery is changing, and agentic systems make the change fundamental.
We are entering an era in which software increasingly determines how work should be performed, constructs the processes required to perform it, and sometimes modifies the systems through which future work will be carried out.
The machine is evolving alongside its operating environment, with an expanding range of potential behaviors. It increasingly determines its own trajectory. Managing such software requires situational intelligence and representations developed in tandem with the systems they depict.
When the User Journey Was the Unit of Performance
For decades, digital experience monitoring rested on an understandable premise: users interact with applications through a series of well-defined operations. In an online shop, a user searches for an item, opens a product page, adds it to a basket, and completes checkout. Each step is an operation with a predictable workload. A product page should load within an acceptable time, a search should return results promptly, and checkout should complete reliably.
We instrumented these operations, measured their latency distributions, and established service-level objectives.
The user journey became a sequence of measurable interactions. As applications grew into sprawling distributed systems, dozens of services, databases, queues, and external dependencies came to sit behind each interaction, and distributed tracing let us follow execution through them. Much of modern observability formed around this model, and the evidence it collected grew in detail as the transactions grew in complexity. Through all of this, the fundamental conception of the user interaction held steady. That conception is now being challenged.
The Journey the Agent Constructs
Imagine someone asking an agent to help decide whether to renovate their home, replace the heating system, or invest in another energy solution. The agent may investigate the property, consult regulations, compare technologies, and ask questions that redirect the investigation. It may delegate parts of the work to other agents, invoke external tools, revisit earlier assumptions, and construct a solution through a process it composes as it goes.
What is the appropriate response-time objective for that request?
Five seconds? Thirty seconds? Ten minutes?
The question is hard because the amount of work emerges as the investigation proceeds.
Even the objective may evolve as new information arrives. A user might begin by asking about a heating system and discover along the way that insulation, financing, or another renovation strategy deserves attention.
The value of the interaction depends on how effectively the system navigates that expanding problem space.
The agent participates in the decomposition and organization of the work. It determines which activities are necessary, which can be delegated, which assumptions require investigation, and when sufficient understanding has been achieved. The agent constructs the journey, and many of its steps unfold out of the user’s sight.
This changes the relationship between the user, the application, and the measurement of performance.
Performance Depends on What We Are Trying to Achieve
The experience of time is changing as well. In the request-response model, operation duration dictated user experience: slow responses disrupted interaction, and long delays caused abandonment.
Agentic systems introduce delegated engagement.
A user sets a goal, and the system works toward it while the user focuses elsewhere, returning with a result, a request for clarification, a progress update, or a need for intervention. If the user requests extended reasoning, investigation, or verification, the resulting computation aligns with the request, and the outcome’s quality supports the time required.
Interactive responsiveness remains critical: conversational agents must maintain usability, tools should complete within appropriate timeframes, and users require clear feedback regarding task progression or stagnation.
An increasing proportion of work is now delegated, rendering elapsed time a meaningful metric. A twenty-minute duration derives significance from its associated task.
The same technical operations serve activities whose expectations range widely.
Retrieving an account balance should be quick. Investigating a suspicious transaction may require an extended inquiry. Assessing a complex financial decision can involve research, uncertainty, alternative strategies, and several rounds of revision. All three may run on the same models, databases, APIs, and infrastructure.
Performance functions at two levels: the machinery, assessed through latency, throughput, and availability; and the activity, shaped by purpose, context, stakes, uncertainty, and progress. Optimizing an activity depends on grasping its intended outcome. This matters when agents design their own workflows, because activities starting from similar requests develop distinct structures, scopes, and end conditions.
These are open-ended processes, and open-ended processes demand situational evaluation.
Six Situational Dimensions
We need to evaluate the relationship between the work being performed, the situation in which that work occurs, and the outcomes the system is looking to achieve. Six dimensions become central.
- Relevance: Are the system’s activities appropriate to the current situation and objective? Is it pursuing information that materially contributes to the outcome? Has the situation shifted enough to reorder earlier priorities?
- Progress: Is the activity moving toward a meaningful outcome? Is uncertainty being reduced? Are necessary conditions being satisfied? Is each step advancing the outcome?
- Adequacy: Does the system possess enough insight to carry out the task responsibly? Is the current information sufficient for the next choice? Has adequate groundwork been laid to move forward, or must more inquiry occur?
- Confidence: How strongly are the system’s assessments backed? What uncertainties persist? How dependable are the assumptions guiding its choices? Does its confidence align with existing evidence and prior results?
- Stability: Is the situation moving toward a manageable state? Are dependencies, assumptions, and behaviors remaining stable? Does the system alternate between options, revise choices, or gather unresolved uncertainty?
- Intervenability: What actions are available in the current situation? Can the system pause, redirect, investigate, constrain, recover, delegate, or seek assistance? Are those actions likely to be available as the situation develops?
Together the dimensions relate the activity, the assessment, the environment, and the available actions: relevance and progress qualify the activity, adequacy and confidence the assessment, stability the environment, and intervenability the available actions. Each is assessed in flight, at the source of the activity, and each informs what the system does.
Their significance emerges through the relationships between them.
An agent can make considerable progress toward an objective as its confidence in the underlying assumptions deteriorates, and each further step along that course carries rising risk. Another can hold high confidence in an assessment that a changed environment has made irrelevant. A third can recognize a developing failure once its consequences have become irreversible. The degree of understanding required varies with the situation itself.
Understanding Enough to Intervene
Diagnosis reconstructs what happened: it explains a failure, identifies a root cause, and presents the evidence to an engineer. It serves engineering review well. An autonomous system decides what to do next continuously, across enormous numbers of activities, decisions, and interactions, and its intelligence operates through selective, situated understanding. It needs to recognize the conditions that matter, assess their implications, anticipate plausible developments, and determine which interventions are available. The required understanding is relative to the decision being made. A familiar resource shortage calls for recognition and an established corrective response. An unexpected interaction between autonomous agents calls for assessment, investigation, or a restriction on further action.
Sometimes the appropriate intervention is to stop.
Stopping can be an intelligent response to deteriorating confidence, unstable behavior, or a growing gap between what the system believes and what its environment now appears to be. This is adequacy applied reflexively: the system assessing the limits of its own understanding. The system must recognize when its assessment calls for renewal, and that recognition can trigger investigation, reorientation, escalation, or a change in strategy.
In this world, the quality of an assessment governs what the system can safely do next.
Maintaining Viability
Software is also becoming generative.
Earlier self-adaptive systems operated within predefined configurations, strategies, and responses established by their designers, utilizing mechanisms they had engineered. In contrast, agentic systems facilitate the creation of novel implementations, workflows, tool integrations, and operational structures.
Coding agents can alter the infrastructure used by other agents. Runtime agents build activity sequences during execution, and their actions reshape the environment for later agents. The outcome starts to mirror features of biological systems. Organisms respond continually to their surroundings: they regulate internal states, adapt behavior, learn from interactions, and take part in environments that are also shifting.
Development and evolution add timescales over which capabilities and structures change.
Software agents adjust through internal processes constrained by computational designs, permissions, tools, and goals set by people. This comparison highlights how systems sustain workable ties with shifting surroundings. A software ecosystem must preserve that stability as its internal structure and outside conditions change.
The system being operated today may carry capabilities, dependencies, and behavioral possibilities acquired since yesterday. Even the representation through which we understand it may now describe an earlier system.
The challenge becomes the maintenance of viability, for the system and for our understanding of it.
The Architecture of Understanding
If situational intelligence is the goal, how should the underlying systems be built to enable it?
The standard path starts with instrumentation: we record operations, release telemetry, keep evidence, and build analytical tools from the data. The demands of situational intelligence turn that engineering into a reciprocal process.
Imagine a system that must judge whether an activity shows meaningful progress. To reach that judgment, it might need to notice intermediate results, separate productive work from repeated effort, detect shifts in goals, and grasp which dependencies stay unresolved. These needs should guide what the system represents and shares. An execution boundary might need to be clear. A repeating pattern could warrant its own form. The system might send a signal about shifts in stability, confidence, or progress. Signs are emitted at the source, where the context for interpreting them is.
Higher-level assessment shapes the engineering of lower-level mechanisms, and the cycle persists: we build a representation, test the understanding it offers, find its limits, and adjust the underlying parts.
The system’s design and its intelligence develop together. In generative software, where agents produce new structures and behaviors, understanding evolution must be part of engineering and governance.
Feedback Across Levels and Timescales
Observability has organized itself around evidence moving upward through collection, storage, analysis, and presentation. Situational intelligence adds feedback that runs across levels of abstraction and across timescales.
At one level, an agent recognizes a condition and adjusts its immediate behavior. At another, a supervisory process assesses whether the agent remains aligned with its objective and whether its actions are producing appropriate outcomes. At a third, engineering processes identify situations the system needs to distinguish, prompting changes to its instrumentation, representations, workflows, or architecture. The intelligence operating at the higher levels helps determine what needs to become recognizable at the lower levels. The lower levels, in turn, determine which assessments and interventions are possible. Together they form a continuing process of adaptation and regulation.
A system can perform efficiently on irrelevant work, produce plausible results with poorly calibrated confidence, or make individually reasonable decisions whose collective effects destabilize the environment. These are situations that require interpretation across activities, boundaries, and timescales. They are addressed through representations designed for the assessments they serve, which makes representation itself part of the engineering challenge.
What Happens to APM?
Latency, throughput, utilization, and availability retain their significance. Modern distributed systems depend on predictable underlying services, efficient execution, and bounded resource consumption, and agentic workloads add infrastructure demands of their own: model inference, tool execution, scheduling, and coordination.
Performance engineering remains essential throughout these layers, and its natural home is the operation whose boundaries, workloads, and expectations are well defined. A database query can slow, a tool can time out, an inference service can saturate, and an overloaded dependency can stall an agent’s work.
The higher-level assessment must account for these conditions.
At the level of the user objective, the center of attention moves to the activity. Users delegate activities to systems that decide how to organize and perform the work, and the duration of an individual operation bears an indirect relationship to the value of the overall activity. Observability should reflect that distinction.
Infrastructure performance is one of the conditions under which intelligent activity takes place. The quality of such is assessed against its purpose, through relevance, progress, adequacy, confidence, stability, and intervenability.
Two distinct assessment tiers, each characterized by unique representations and metrics, are interdependent; consequently, they must be designed in an integrated manner.
Beyond the Racetrack
The F1 metaphor continues to convey speed, precision, and engineering sophistication.
Within F1, decisive intelligence rests on the pit wall, where strategists interpret weather, tire wear, safety cars, and rival maneuvers against a fixed track. Agentic systems extend the race into open territory.
Imagine a vehicle that reshapes its own structure, plots new paths, recruits other machines, alters its surroundings, and uncovers its goals during travel. A stopwatch reveals aspects of the mechanism. To move through that setting, we must identify what shifts, our location, what counts, where events might head, and what stays open.
That knowledge is situational awareness. Joined with assessment and adaptation, it forms situational intelligence, which becomes central to operating software that is autonomous and generative.
Effective systems must be capable of identifying significant contexts, evaluating their own comprehension, forecasting critical outcomes, and determining suitable interventions. Furthermore, engineering methodologies must iteratively refine the representations that underpin these functions.
Fundamentally, situational intelligence centers on the quality of understanding.
How relevant is our activity? How far has it progressed? How adequate is our assessment? How confident can we be in our projections? How stable is the situation? What can we still do to influence the outcome?
These questions are becoming central to the experience, governance, and evolution of software.
The racetrack is one part of the territory, and situational intelligence is how the territory is understood.