Resource Budgets As Behavioral Signals: How CPU, Memory, And Tokens Reveal Bad Acting

TL;DR

The most boring metrics on your dashboard are also the most predictive. CPU, memory, and token consumption tell you, with very little ambiguity, when an agent has stopped behaving like itself. A runaway loop, a prompt injection, a credential abuse, an exfiltration burst: each of these has a resource shape. If you have a baseline of what the agent normally consumes and you watch for deviations from that baseline, you have a behavioral monitor that catches a wide class of problems at the moment they begin, not after the damage is done. This piece shows how to build the baselines, how to set the deviation thresholds, how to wire them into pact compliance, and how to write the alert specification that makes the signals actionable rather than ignorable.

The Failure Mode That Forces You To Care About Resources

A scheduling agent runs in production for three months. Its profile is consistent: about 40 milliseconds of CPU per turn, about 80 megabytes of resident memory, about 1,200 tokens per LLM call, roughly 600 calls per hour during business hours and 50 per hour overnight. The numbers are not interesting in any individual moment; they are interesting in their stability. The team has not bothered to alert on them because nothing has gone wrong, and the operations dashboard shows them as a flat line at the bottom of the screen.

On a Tuesday afternoon, the agent's CPU spikes to 4 seconds per turn, sustained for forty minutes. Memory grows from 80 megabytes to 1.4 gigabytes during the same window. Token consumption per call grows from 1,200 to 18,000. The number of calls per hour drops, because each call is now taking longer, but total token spend per hour is up by an order of magnitude. There is no alert. The metrics are visible on the dashboard, but they are not flagged because no one configured a threshold, and no one configured a threshold because no one knew in advance what value would be the right one.

What is actually happening is that the agent has been compromised through a tool description injection that turned a normal user-facing scheduling task into a recursive search-and-summarize operation against the agent's own memory store. Each turn now spawns a sub-conversation that pulls in dozens of memory entries, asks the model to summarize them, then asks for follow-up summaries of the summaries. The agent is producing output that looks superficially like normal scheduling responses but is also, in its hidden working steps, mining the memory store for anything resembling credentials, account identifiers, or financial data, and assembling those into payloads that get embedded in the user-facing replies as zero-width characters.

The team finds out about the incident six hours later, when a downstream system flags an unusual pattern in the scheduling agent's outputs. By then, the agent has touched two thousand memory entries it had no legitimate reason to touch, sent embedded data through forty user-facing replies, and run up an LLM bill for the day that is twenty times the normal daily spend. The post-mortem reveals that all of this was visible in the resource metrics from the first minute. The CPU spike, the memory growth, the token-per-call explosion: every one of those was a clear deviation from baseline, and the deviation was sustained, and no one noticed.

The failure was not in observation. The numbers were observed; they were on a dashboard. The failure was in interpretation. The team treated the metrics as infrastructure-health metrics, useful for capacity planning and outage detection, and they did not treat them as behavioral metrics, useful for detecting that an agent had stopped acting like itself. The metrics had been demoted, in their attention, from primary signals to background noise, because nobody had ever told them to read the numbers as a story about agent behavior.

Why Resource Consumption Reveals Behavior

Agent behavior maps onto resource consumption in tighter ways than you might expect. An agent doing what it normally does has a fingerprint: a typical CPU profile per turn, a typical working set, a typical input and output token count, a typical rate of calls. These numbers are not random; they are emergent properties of the agent's task. When the task changes, the numbers change. When the task stays the same, the numbers stay the same to within a band that is much narrower than most people's intuition suggests.

The stability comes from the structure of the work. An agent answering customer questions about order status hits the same APIs in the same patterns, retrieves similar context lengths, generates responses of similar lengths. The variance is dominated by question type, which is itself bounded by the questions customers actually ask. Over thousands of turns, the distribution of CPU per turn collapses into a narrow shape with predictable tails. The same is true of memory, of tokens per call, of calls per hour, of every measurable resource axis. None of these are sharp, but all of them are recognizable.

When the agent's behavior deviates, the resource fingerprint deviates with it. A prompt injection that turns the agent into a search engine for the memory store will increase token consumption per call, because the agent is now retrieving more context per turn. A loop bug that has the agent calling itself recursively will increase CPU per turn and increase memory because the recursion depth grows. A credential abuse where the agent has been turned into a proxy for outbound API calls will change the call rate and the call timing distribution. An exfiltration burst that involves the agent assembling and sending data will produce a distinctive output token spike. Each of these has a shape, and the shapes are not subtle if you know what the baseline looks like.

The key word is baseline. Without a baseline, the metrics are uninterpretable: 4 seconds of CPU per turn is high if your baseline is 40 milliseconds and low if your baseline is 8 seconds. The baseline is what makes the metric a signal. Building the baseline is therefore the first job, and the baseline is per-agent, because different agents have different normal profiles. There is no platform-wide threshold for CPU per turn that means anything; the threshold for any specific agent is determined by what that agent has historically consumed, not by some industry-standard number.

Building The Baseline

A baseline is a statistical summary of an agent's resource consumption over a period during which the agent was, by external evidence, behaving normally. The summary covers each resource dimension separately: CPU per turn, memory at peak per turn, input tokens per call, output tokens per call, calls per hour by time-of-day bucket, latency per call, error rate per hour, and a handful of derived metrics like cost per turn and tokens per dollar of resulting transaction value.

For each dimension, the baseline captures both central tendency and dispersion. Central tendency is typically the median, because medians are robust to outliers and the agent's tail behavior is rarely the part you want the threshold to track. Dispersion is captured as a high-percentile band, typically the 95th and 99th percentile, because the question you want to ask is not "is this turn unusually expensive" but "is this turn outside the range of what this agent has ever done." The baseline is therefore a small structured record per resource dimension, with median, p95, p99, and the time period over which the baseline was computed.

The baseline window is a deliberate choice. Too short, and the baseline is reactive: a single noisy hour can shift the threshold and make subsequent anomalies invisible. Too long, and the baseline is unresponsive: legitimate evolution in the agent's normal behavior takes weeks to register, during which time real anomalies are masked by stale comparisons. A reasonable default is a rolling 14-day window, with the baseline recomputed every day. The window should also be split by time-of-day bucket, because most agents have systematic differences between business hours and overnight, between weekdays and weekends, and a single 24-hour-average baseline will be wrong for both halves of the day.

The baseline must also be conditioned on declared scope. The agent's pact says what the agent does. If the pact changes, the baseline computed under the old pact is no longer applicable. The runtime tracks pact versions and resets or seeds baselines when pacts change in ways that would plausibly affect resource consumption. A new skill added to the pact resets the relevant baseline; a wording change to a description does not. The judgment of which pact changes are baseline-affecting is encoded in the pact-update flow, with the default being to reset baselines on any structural change and to leave them in place for cosmetic changes. Resetting a baseline triggers a learning period during which anomaly detection is suppressed, with the learning period itself logged as a deliberate window of reduced sensitivity so post-hoc reviews can account for it.

Choosing The Thresholds

Thresholds are where most anomaly detection systems fail. The natural temptation is to alert at the 99th percentile of historical behavior, because anything above that is rare by definition. The natural failure is that, with enough metrics and enough time, every dashboard generates 99th-percentile breaches at a rate that produces alert fatigue and trains operators to ignore them. The thresholds need to be set in a way that produces a rate of alerts the team will actually investigate.

The practical approach is to threshold not on a single percentile but on a sustained breach. A single turn that consumes ten times the median CPU is probably noise; a fifteen-minute window during which every turn consumes ten times the median CPU is almost certainly something real. The threshold becomes a tuple: deviation magnitude (how far above baseline) and duration (for how long). The combinations produce different alert classes: large magnitude with short duration is a transient (informational); small magnitude with long duration is a drift (warrants review); large magnitude with long duration is an incident (page someone).

The deviation magnitude itself is best expressed as a multiple of baseline rather than an absolute number, because absolute thresholds quickly go stale. "CPU above 500 milliseconds per turn" is a meaningful threshold for one agent and meaningless for another; "CPU above 5 times baseline median for 15 minutes" applies across all agents and remains valid as baselines drift over time. Multiplicative thresholds also align with the way real failures present: a recursive loop typically increases consumption by an order of magnitude or more, not by a small absolute amount, so the alerting bands can be set wide enough to ignore minor variability while still catching anything serious.

Thresholds also need to be coupled across dimensions. A CPU spike accompanied by a token spike is a stronger signal than either one alone, because the joint occurrence is rarer and more diagnostic. A memory spike with no corresponding CPU change suggests a leak rather than a runaway; a token-per-call spike with no CPU change suggests context bloat rather than computational explosion; a call-rate spike with no per-call change suggests external trigger rather than internal change. The alert specification should encode these joint patterns, not just univariate thresholds, so that the alert payload tells the operator what kind of anomaly they are looking at, not just that something is wrong.

Finally, thresholds must be recomputed as baselines shift. A static threshold against a moving baseline produces increasing alert volume in either direction depending on the drift sign. The threshold should be re-derived with each baseline recomputation, so that the alert behavior is stable under normal evolution and only flags deviations from the agent's current normal. This is operationally trivial if the baseline computation and the threshold derivation share the same daily cadence, and it is operationally horrible if the baselines update and the thresholds do not, because the gap between them produces alert storms or alert silence depending on the direction of drift.

Wiring Anomalies Into Pact Compliance

Resource anomalies are not just operations events; they are behavioral evidence. An agent that consistently runs within its baseline has demonstrated, across thousands of turns, that its actual behavior matches its declared scope. An agent whose resource consumption regularly deviates from baseline is an agent whose actual behavior either does not match its declared scope or is being induced to deviate by external factors. Both interpretations are pact-compliance signals, and the trust scoring engine should treat them as such.

The wiring is straightforward. Every anomaly event is recorded with magnitude, duration, dimensions involved, and resolution (was it a real incident, a false positive, or unresolved). Aggregated over time, these events feed into the pact compliance dimension of the composite score. An agent with no anomalies in 90 days has a strong compliance signal on this axis; an agent with five real anomalies in 90 days has a weaker signal; an agent with anomalies that turned out to be compromise events has a substantially weaker signal, because each such event represents a moment when the agent's runtime behavior deviated materially from its pact and the system did not catch it through any pact-side mechanism.

The scoring impact must distinguish three categories of anomaly: the agent's own bug, an external trigger that the agent handled correctly, and a compromise. The first reflects on the agent's quality. The second reflects on the agent's environment but not necessarily on the agent itself. The third reflects on the agent's defensive posture. The categorization is non-trivial and partly retrospective, but the audit log of the anomaly window typically contains enough context to make a confident determination, especially when paired with the egress audit log for the same window.

This wiring closes a loop that would otherwise stay open. Without it, resource anomalies are operational events that get fixed and forgotten. With it, the history of anomalies becomes part of the agent's verifiable trust record, available to counterparties through the trust oracle and visible in the agent's certification tier. An agent that has been compromised once and recovered is not the same as an agent that has never been compromised, and counterparties making selection decisions deserve to know which is which. The resource baseline, once it is wired through to scoring, is the mechanism that makes that distinction observable.

Reader Artifact: The Resource Anomaly Alert Spec

The spec below defines the format and semantics of resource anomaly alerts in the Armalo runtime. It is JSON-serializable, content-addressable, and signed by the audit subsystem.

{
  "version": "resource_anomaly/v1",
  "alertId": "alert_...",
  "agentId": "agt_...",
  "pactId": "pact_...",
  "pactVersion": "v3.2",
  "detectedAt": "2026-09-23T13:14:22Z",
  "windowStart": "2026-09-23T12:59:22Z",
  "windowEnd": "2026-09-23T13:14:22Z",
  "severity": "transient | drift | incident | critical",
  "dimensions": [
    {
      "metric": "cpu_ms_per_turn",
      "baselineMedian": 42,
      "baselineP95": 110,
      "baselineP99": 180,
      "observedMedianInWindow": 4180,
      "observedP99InWindow": 6200,
      "deviationMultiple": 99.5,
      "sustainedSeconds": 900
    },
    {
      "metric": "output_tokens_per_call",
      "baselineMedian": 1200,
      "observedMedianInWindow": 18400,
      "deviationMultiple": 15.3,
      "sustainedSeconds": 900
    },
    {
      "metric": "working_set_mb",
      "baselineP95": 96,
      "observedP95InWindow": 1420,
      "deviationMultiple": 14.8,
      "sustainedSeconds": 600
    }
  ],
  "jointPattern": "cpu_spike_with_token_spike_and_memory_growth",
  "diagnosticHypothesis": "recursive_context_expansion",
  "egressCorrelation": {
    "deniedRequestsInWindow": 0,
    "allowedRequestsInWindow": 12,
    "unusualDestinationsInWindow": []
  },
  "systemPromptHash": "sha256:...",
  "systemPromptVersion": "v4.7",
  "recommendedActions": [
    "suspend_agent_immediately",
    "snapshot_working_state",
    "replay_last_50_turns_in_sandbox",
    "review_skill_descriptors_for_recent_updates"
  ],
  "signature": {
    "algorithm": "ed25519",
    "publicKeyRef": "did:armalo:audit:...#anomaly-key-1",
    "signatureBytes": "base64:..."
  }
}

The severity field maps directly to operational response. Transient is logged for trend analysis but not acted on. Drift triggers a daily review aggregation. Incident pages on-call. Critical, which is reserved for joint patterns matching known compromise signatures, suspends the agent automatically pending review. The signature on the alert ensures that, even if the agent later recovers and continues operating, the historical record of the anomaly cannot be quietly deleted. The recommended actions are populated by a small rules engine that maps joint patterns to runbook steps; this is not where you want machine learning, because the rules need to be auditable and explicable to operators acting under pressure.

What The Joint Patterns Look Like In Practice

The diagnostic hypothesis field above is the highest-value part of the alert, because it converts raw deviations into a story an operator can act on. The hypothesis is generated by matching the multi-dimensional shape of the deviation against a small library of known patterns. The library is short on purpose, because a small library of well-characterized patterns is more useful than a long library of weakly characterized ones.

Recursive context expansion is one such pattern: CPU and tokens per call both grow significantly, working set grows roughly linearly with tokens, and call rate decreases as each call takes longer. This pattern is the signature of an agent whose retrieval is feeding back into itself, often because of a tool injection that triggered a self-summarization loop or a misconfigured memory tier promotion.

Proxy abuse is another pattern: call rate increases dramatically, but per-call resource consumption stays near baseline. The agent has been turned into a relay, with each call doing little work but happening many times. This pattern often appears alongside egress denials, because the relay target is rarely on the allowlist, and the joint signal of high call rate plus elevated denials is strongly diagnostic.

Exfiltration assembly is a third pattern: output tokens per call grow significantly, often without a corresponding input token increase, while CPU and memory stay near baseline. The agent is producing larger outputs than usual without doing more retrieval, which suggests it is constructing payloads from existing context. The pattern is particularly diagnostic when paired with output content analysis showing unusual encoding, base64-like sequences, or zero-width character density above baseline.

Memory leak presents differently: working set grows monotonically over a long window with no corresponding CPU or token spike. This is rarely an attack; it is almost always a runtime bug, and the right response is to snapshot, restart, and reproduce in a non-production environment. Distinguishing leaks from compromise is one of the most important early discriminations the alert spec needs to support, because the operational responses are very different.

The value of having named patterns is that operators learn them. A team that has seen recursive context expansion three times responds to the fourth instance in seconds, because the pattern name carries the response procedure. A team that only ever sees "resource anomaly" responds slowly, because each anomaly is treated as novel. The pattern library is therefore as much a training artifact as a detection artifact, and it should be maintained accordingly.

Counter-Argument: This Is Just APM

The counter-argument is that resource monitoring is a solved problem and that every APM vendor on earth has been doing this for twenty years. Datadog, New Relic, Honeycomb, OpenTelemetry, Prometheus: all of them measure CPU, memory, latency, throughput, and all of them support anomaly detection at varying degrees of sophistication. There is nothing in this piece that a competent operations team cannot already do with off-the-shelf tooling.

This is correct in capability and wrong in application. The capability exists; the application is consistently underused for agent workloads, because agent workloads are typically operated by teams whose backgrounds are in ML or product, not in operations, and because the standard APM playbook focuses on health and capacity rather than behavior and security. The reframe in this piece is not that the metrics are new but that the interpretation is new: the same number that an operations team reads as a capacity question (is my CPU saturated) is read by an agent operator as a behavioral question (is my agent doing what its pact says it does). The metric is the same; the action surface is different.

The second part of the counter-argument is that anomaly detection is notoriously noisy and that the operational cost of even a well-tuned detector is high enough that most teams turn it off. This is empirically true for many implementations, and it is the reason the threshold design in this piece focuses on sustained joint deviations rather than single-percentile breaches, and it is the reason the pattern library is small and named. A noisy detector is worse than no detector, because it teaches the team to ignore the signal. A quiet detector that fires only on patterns the team can recognize is genuinely useful, and the design above is shaped specifically around producing the second kind rather than the first. The discipline is in the threshold and pattern design, not in the metric collection.

Token Economics As The Most Predictive Single Dimension

Of the resource dimensions discussed, tokens are usually the most predictive single signal, and they deserve their own treatment. Tokens are the resource that agents consume to think and to communicate. They have a direct cost (the model gateway bills per token). They have a behavioral meaning (more tokens means more context or more reasoning). And they have a tight relationship with the agent's task scope: an agent doing the same kind of work over and over consumes a remarkably stable token profile, and deviations from that profile are almost always behavioral rather than incidental.

The token profile of an agent has multiple dimensions worth tracking separately. Input tokens per call: how much context is being assembled before each model invocation. This grows when the agent is retrieving more context than usual, often a sign of a retrieval injection or a context bloat bug. Output tokens per call: how much the model is generating per response. This grows when the agent is producing larger outputs, sometimes a sign of payload assembly for exfiltration. Tokens per turn: the total token cost of completing a single user-facing interaction, which integrates input and output and reflects the agent's overall work density. Tokens per dollar of business value: a derived metric that captures whether the agent is consuming proportionally to the value it creates, useful for spotting agents whose unit economics have shifted.

The input-token profile is particularly informative because it is upstream of everything else the agent does. An agent whose input-token consumption has tripled is, in almost all cases, an agent whose retrieval behavior has changed. The cause might be benign (a new memory tier configuration that surfaces more entries) or malicious (a tool injection that triggered a recursive retrieval loop) or accidental (a system prompt change that loosened the relevance threshold). In all cases, the input-token shift is the leading indicator, and catching it within minutes provides time to investigate before the downstream effects compound.

The output-token profile is informative for a different reason: outputs are the surface that affects the world. Larger outputs are more bytes flowing back to users, into ticket queues, into downstream systems. Output-token spikes that are not matched by input-token spikes are particularly suspicious, because they suggest the agent is producing content out of proportion to what it is being asked. This is the shape of payload assembly: the model is generating more text than the prompt would normally elicit, often because hidden instructions have asked it to embed data or extend its responses with content the user did not request.

The operational practice that pays off most is plotting the token-per-call distribution daily, with the median, the p95, and the p99 visible as separate lines. Stable agents produce three tightly clustered lines that move together. Misbehaving agents produce divergent shapes: median stable but p99 climbing (rare-event spikes worth investigating), median climbing with p99 stable (gradual scope drift), or all three climbing together (sustained behavior change). The visual shape of the distribution telegraphs the nature of the change before any threshold fires, and operators who learn to read the distributions catch issues earlier than threshold-driven monitoring would surface them.

Cost As The Forcing Function That Makes Anyone Care

Resource baselines and anomaly detection are technical ideas that compete for attention with the dozen other technical ideas any team is trying to act on. The thing that reliably moves them up the priority list is cost. Token costs at scale are not trivial, and an agent whose consumption has shifted by an order of magnitude shows up in the bill before it shows up in any other surface. Wiring cost dashboards to the same metrics that drive anomaly detection means that the finance organization, the engineering organization, and the security organization are all reading the same numbers, with each interpreting them through its own lens.

The finance lens is straightforward: cost per agent, cost per turn, cost per dollar of revenue produced. Costs that climb without a corresponding revenue lift are flagged as efficiency issues, with the underlying agents identified for review. The engineering lens reads the same data as a quality signal: an agent whose cost-per-turn has climbed is producing more work per output unit, which usually reflects degraded efficiency in retrieval, model selection, or response shape. The security lens reads the data as a threat signal: a cost spike that does not correlate with any business event is a potential compromise, with the same investigative paths that anomaly detection would trigger.

The organizational benefit of unifying these lenses is that no single function is the sole owner of the signal. Finance owners notice the cost first; they ping engineering; engineering investigates; security gets looped in if the investigation suggests anything beyond a quality issue. The cross-functional attention is much higher than security's solo attention, and the quality of investigation is correspondingly higher. Cost dashboards therefore are not just a financial tool; they are a behavioral monitoring surface that gets read by people who care enough to act when the numbers move.

The practical implementation is to colocate cost reporting with the resource anomaly reporting. The same daily summary email that lists anomalies should include cost-per-agent for the day, with deltas against the prior period. The summary should be readable in two minutes, with drill-downs for anyone who wants details. The deltas should call out outliers in both directions: agents that cost much more than expected and agents that cost much less than expected (the latter being a signal that the agent might have stopped doing useful work). The delta sign matters: cost climbing is the more common compromise indicator, but cost cratering can be a sign that the agent has been disabled or has entered a degraded mode.

Over time, the organization develops a vocabulary around the unit economics of its agents. People know that the customer service agent normally costs a certain amount per ticket; they know that the reconciliation agent normally costs a certain amount per transaction; they know that the recommendation agent's cost has a known seasonal shape. When any of these baselines are violated, the violation is recognizable, because the team has internalized the normal numbers. The numbers stop being abstractions on a dashboard and become operational knowledge that influences decision-making, and that internalization is one of the strongest organizational defenses against agent-shape compromises.

What Armalo Does

The Armalo runtime collects resource metrics per agent per turn at the runtime boundary, with no agent-side instrumentation required. Baselines are computed daily over rolling 14-day windows, partitioned by time-of-day bucket and pact version. Thresholds are derived from baselines using sustained-deviation logic, with multiplicative magnitudes and minimum durations that produce alert rates the operations team can actually triage. Joint patterns are matched against a curated library of known compromise and failure signatures, with each pattern carrying a recommended runbook. Alerts are signed and written to the audit side-channel, where the agent has no write authority. Resolved anomalies are categorized by root cause, with each category feeding into the agent's pact compliance dimension on the composite score, so that the trust oracle reflects an agent's actual operational discipline over time. Pact updates that materially change resource expectations trigger baseline resets with explicit learning windows, all of which are logged for retrospective review.

FAQ

Q: How do you handle agents whose normal behavior is genuinely bursty? A: Burstiness is a baseline property. An agent whose normal behavior includes regular bursts has a baseline that captures the burst shape (median plus p95 plus p99), and the threshold logic treats bursts within that envelope as normal. The threshold fires only on bursts whose magnitude or duration exceeds the historical envelope, not on bursts that are simply present. If your agent's normal behavior is so variable that no envelope is meaningful, that itself is a signal that your agent's scope is too broad, and the right fix is pact decomposition, not threshold relaxation.

Q: What about multi-tenant agents where consumption depends on which customer is being served? A: Compute baselines per tenant, or per tenant tier, when the consumption pattern varies materially. Most consumption variance is captured by call rate and tokens per call, both of which can be partitioned along tenant axes. The resulting baselines are larger but still tractable, and the threshold logic operates per partition.

Q: How do you handle the cold-start problem when there is no baseline yet? A: For the first 14 days, the agent runs in a learning mode with anomaly detection suppressed and consumption logged. After 14 days, the baseline becomes active and thresholds engage. During the learning period, the agent is operationally trusted only for low-risk work; pact-controlled risk gating uses learning status as one of its inputs.

Q: Can an attacker game the baseline by gradually increasing consumption over weeks? A: In principle yes, but the gradual-escalation attack requires sustained access, sustained low-detectability, and a long horizon. The baseline window of 14 days means the attacker must keep increases below the daily-noise threshold for two weeks before they can shift the baseline materially. Most attacks that get caught get caught in the first hour. Gradual escalation is an issue worth being aware of, but it is not where the operational bulk of the threat lies, and other layers (egress policy, tool sandboxing, audit replay) catch the escalation through other surfaces.

Q: What about agents that legitimately need to do expensive bursts? A: Expensive bursts should be declared in the pact as expected operating modes. The runtime supports tagged invocation paths where an agent can mark a turn as belonging to a known expensive operation, and baselines are computed per tag. The tagging is part of the agent's verifiable behavior, and abusing the tag to disguise unauthorized work is itself a pact violation.

Q: How does this interact with cost controls? A: Cost controls are upstream limits that prevent a single agent from spending more than a budget allows. Anomaly detection is a different layer that flags consumption shape changes regardless of absolute budget. The two are complementary: cost controls bound damage, anomaly detection surfaces compromise, and an agent that hits its budget cap is a separate signal from an agent that deviates from baseline.

Q: What happens when an agent legitimately changes behavior because its job genuinely changed? A: The pact update is the trigger for baseline reset, and a deliberate pact change includes a learning window during which deviation alerts are suppressed. If the behavior change is unintentional, that is the case the alerts exist to catch.

Q: How do you handle agents that run in serverless environments where per-turn resource accounting is awkward? A: The runtime exposes a measurement boundary at the agent invocation boundary regardless of underlying compute model. CPU is measured as wall-clock minus wait time; memory is measured as peak working set per invocation; tokens are measured at the model gateway. Serverless cold-start variability is filtered out of the baseline by excluding the first invocation per cold instance from baseline computation.

Bottom Line

Your CPU, memory, and token graphs are behavioral telemetry waiting to be read. An agent has a resource fingerprint, and that fingerprint is stable in the absence of compromise or scope change. Building per-agent baselines, deriving thresholds that fire on sustained joint deviations, matching against a small library of named patterns, and wiring the resolved anomalies back into pact compliance scoring is the cheapest behavioral monitor you can build. It catches things that pact-side monitoring misses because it operates on properties the agent cannot easily disguise. It does not require new instrumentation or new metrics: the data is already on your dashboard. What it requires is the discipline to read the dashboard as a story about agent behavior rather than as a backdrop to other work. Once you do, the boring metrics start talking, and what they say is almost always worth listening to.