Cold Acquisition That Works in 2026

In the past twelve months, 88 percent of enterprises reported at least one security incident involving an AI agent. Only 21 percent had runtime visibility into what their agents were actually doing. Both numbers come from Gravitee's State of AI Agent Security 2026, a survey of 919 executives and practitioners. Read together, they describe an uncomfortable position: nearly every organization running agents has already had something go wrong, and four out of five could not reconstruct what happened.

For a property operator, that is not an abstract governance concern. When a maintenance agent creates work orders, schedules technicians against capacity and closes tickets on its own, the record it leaves behind is usually a status flag. Ticket 4471: resolved. That flag is enough for a dashboard. It is worthless in a dispute. A tenant claims a habitability issue was closed without a fix. A vendor bills for a visit to a unit nobody sent them to. An owner asks why an emergency plumber went out at triple rate for a dripping tap. If the only answer available is that the agent decided, you do not have an operations problem. You have an evidence problem.

The fix has a name, AI agent observability, and it is a build pattern rather than a product you buy. This piece covers what the pattern looks like inside a ticket flow, what a replayable work order actually contains, and how long you need to keep the records.

AI Agent Observability Is Not the Same as Logging

Most teams that deploy agents believe they are covered because their systems write logs. The data says the confidence is misplaced. In the same Gravitee survey, 82 percent of executives believe their policies protect against unauthorized agent actions, while 88 percent of their organizations reported incidents anyway. Belief is outrunning capability by a wide margin.

The reason is structural. Standard application logging captures what happened: an API call was made, a record was updated, a message was sent. What it loses is why. The model's reasoning disappears the moment the context window closes. The policy version in force at decision time is not attached to the outcome. The data the agent read before acting, the tenant's history, the contract terms, the urgency score, sits scattered across systems that each keep their own partial logs on their own clocks. Six months later, nobody can stitch that back together, and six months later is exactly when the question arrives.

Observability means the chain is captured as one structured record at the moment of action, not reconstructed afterwards from fragments. For conventional software that is a nice-to-have, because the code path explains the behavior. For an agent, the same input can produce a different decision tomorrow. The trace is the only place the behavior exists at all.

What a Replayable Work Order Actually Contains

The pattern that works in production is to treat every agent action as a structured event with five parts. First, the trigger: the tenant message, sensor alert or scheduled check that started the run, with its timestamp and channel. Second, the inputs: what the agent pulled from the domain system before deciding, unit records, past tickets, contract terms, and the versions of each. Third, the decision itself: what the agent concluded, the urgency it assigned, the confidence it reported, and the policy or prompt version that governed it. Fourth, the tool call: the exact write it performed in the domain system, work order created, technician slot booked, status updated, with the system's response. Fifth, the human: who approved, overrode or never saw the action, and under which escalation rule.

None of this requires exotic tooling. It requires discipline about where writes happen. If your agent acts through a small set of tool interfaces, instrumenting those interfaces gives you the complete action record almost for free. If the agent's actions are spread across ad hoc scripts and direct database writes, no monitoring product will recover the chain afterwards. This is why observability is an architecture decision, and why it belongs in the design of operational AI agents rather than in a retrofit six months after go-live.

The industry is converging on the same shape. The OpenTelemetry project, which standardized how conventional software emits traces, has finalized a draft semantic convention for AI agent applications and is extending it into a common standard across agent frameworks, precisely so that agent telemetry does not end up locked into vendor-specific formats. You do not need to adopt the spec wholesale. You do want your trace schema to record the same categories, so the closed ticket can be replayed end to end: this came in, this was read, this was decided, this was done, this person signed off.

Retention Is a Liability Question, Not a Storage Question

How long to keep traces is usually decided by whoever manages storage costs. That is the wrong desk. The EU AI Act's Article 12 requires high-risk AI systems to support automatic event logging over their whole lifetime, with the record-keeping obligations applying from 2 August 2026. Article 19 sets the retention floor: at least six months, and longer where the intended purpose of the system demands it.

For property operations, the intended purpose demands considerably more than six months. Habitability disputes, deposit conflicts and vendor billing disagreements surface on the timescale of tenancy law, which runs in years, not months. A maintenance agent's decision from eighteen months ago can become the central fact in a proceeding today. Most operators already know this timescale from their document retention policies. The agent trace is a new document type on the same clock. Whether your agents fall inside the high-risk categories or not, the direction of regulation is clear, and the commercial logic is older than the regulation: the deployer answers for the agent's calls, a point we examined in detail when we looked at AI agent liability in property maintenance. An operator who cannot produce the trace does not get the benefit of the doubt.

The practical rule: set trace retention to match your longest liability window, not your storage budget. Structured events are small. A full decision trace for a work order is a few kilobytes. Even a portfolio closing thousands of tickets a month is storing megabytes, not terabytes. The cost of keeping everything is trivial next to the cost of missing the one record that mattered.

Make Replay Your Acceptance Test

The test for whether your setup works is concrete: pick one closed work order per week, at random, and replay it end to end from the trace alone. You should be able to answer five questions without opening any other system. What started this ticket? What did the agent know when it decided? What did it decide, and under which policy version? What did it actually change in the domain system? Which human touched it, or which rule decided no human needed to?

If any of the five comes back empty, you have found a schema gap, and you have found it on a quiet Tuesday instead of during a dispute. Run the same drill on your escalations: the tickets where the agent handed off to a human are the ones where reasoning matters most, because those are the calls someone will later ask about. Teams that already run structured intake and AI maintenance triage have a head start here, since classification and urgency scoring already produce the decision data. The remaining work is persisting it as a first-class record instead of letting it evaporate after the ticket closes.

The 21 percent of organizations with runtime visibility did not get there by buying a dashboard. They got there by deciding that an agent's action without a trace is an incomplete action, and building the write path accordingly.

An autonomous agent that closes 400 work orders a month is not the impressive part anymore. The impressive part is being able to pull any one of those 400, eighteen months later, and show exactly what happened and why. Autonomy creates throughput. The trace is what makes the throughput defensible, to a tenant, to an owner, to a regulator. Build the record the day you build the agent, because the day you need it, it is too late to start.