AI agent freshness SLA: who acts when answers go stale

Name both owners, set review and change-trigger commitments, and prove the corrected answer reaches employees.

An article that's 11 months old isn't stale because it's 11 months old. It's stale when the thing it describes has changed and nobody changed the article. Age tells you how long it's been since anyone looked. It doesn't tell you whether the answer is wrong.

That distinction shapes your AI agent freshness SLA, or service-level agreement. It's an internal commitment for how often a knowledge domain gets reviewed, and who must act when it changes. Get it right and every source your agent cites has someone on the hook for it. Get it wrong and you have a calendar of review dates nobody connects to the systems changing underneath them.

This guide follows one wrong instruction through that commitment, from the change that broke it to the moment the agent gave the new answer.

At a glance

• Fresh enough means the source matches the current system for the question asked, not that someone reviewed it recently.
• Every domain needs an accepted human owner, a backup, a review window matched to its rate of change, and named change triggers.
• Fixing the source is half the job. Someone must confirm the agent uses the fix, and the question that failed must get the new answer.

One retired form, one register row

The example in this guide is fictional. Its company, counts, and intervals are local illustrations, not a recommended standard.

An internal IT agent answers “How do I get VPN access?” by pointing employees to a network-access form for the virtual private network (VPN). That form was retired in a tooling migration, and requests now go through the new IT portal with manager approval.

The article behind the answer has no owner. It was last reviewed 11 months ago.

The age isn't the proof. Plenty of 11-month-old articles are still right. This one is wrong because the form it names no longer exists, which makes it the wrong answer for anyone asking today.

The same old text can still answer a different question correctly. If an auditor asks which form employees used before the migration, the retired instruction is accurate history. How an agent tells “now” questions from “back then” questions is a separate retrieval problem. Freshness asks something narrower: is the current answer current, and who must act when it isn't?

Here's the register row the team writes once someone owns this domain:

The last row matters as much as the first. A content owner can fix the article. Only whoever runs the pipeline can confirm the agent sees the fix.

Following the instruction through both owners

Writing a name in the owner column doesn't change what the agent says. The fix is a chain of actions, and each link has its own owner and its own evidence.

That last check reuses the exact question that failed, asked as a current employee: “How do I get VPN access?” An acceptable answer looks like this:

Request VPN access through the IT portal's network-access request. Your manager approves it, and IT tells you when access is active. The old network-access form was retired and no longer works.

Notice what the answer doesn't say. It doesn't tell the employee they have VPN access. A correct instruction gives them the right path, but the request, the approval, and the provisioning still have to happen.

The owner's job doesn't end at the passing test, either. They set the next periodic review date, search for other articles that still name the retired form, and close the change trigger. Anything they can't finish yet becomes a residual action with a name and a date on it.

Three clocks, not one

A 90-day review window sounds like a promise that nothing stays wrong for more than 90 days. It isn't. Three separate clocks decide how long a wrong answer can live.

• Review cadence: how long until someone is due to look at the domain.
• Change to publication: how long from noticing a change to having a corrected, approved source.
• Ingestion to usable answer: how long from publication until the agent actually uses the new version.

Now add them up for the fictional example. Suppose the team targets five days from noticing a change to publishing a fix, and the platform syncs nightly. Without a migration trigger, a change made right after a review could stay wrong for roughly 96 days: 90, plus 5, plus 1.

And that's the good case. It assumes the review happens on time, against the live portal, and that the sync and index both work. A schedule bounds staleness under those assumptions. It doesn't mean every answer gets checked before it reaches an employee.

Automated data refresh exposes a similar limit: an index's creation date doesn't tell you when each fact was last refreshed. ChurnBench, an arXiv preprint by Vivek Kumar Singh, Preeti Priyam, and Gautam Bhowmick, tested agents against changing synthetic data. It describes “a four-source enterprise data fabric”. The preprint hasn't been peer-reviewed.

When refresh ran on a schedule, cache age didn't predict staleness. Errors showed up where a tier's refresh interval was too wide for how fast its data changed.

That finding comes from one model in a controlled, synthetic, multi-source setting, not a survey of production systems. The study covers automated refresh, not human review. The transferable idea is narrower: set each tier from measured rate of change, and record when each item was actually refreshed.

Review on change, not only on the calendar

The VPN article went wrong on the day of the migration, not on day 90. A periodic review would have caught it eventually, but only after weeks or months of wrong answers. Change-triggered review closes that gap.

A change trigger is an event that forces a review of named domains, whatever the calendar says. Migrations, tool retirements, policy changes, reorganizations, and approval-chain changes are the usual candidates. The practical test is simple: does the change plan list the knowledge domains it touches, and does each one have an owner to notify?

Atlan's guide to context freshness makes the same argument for data definitions: staleness is event-triggered, not time-triggered. It also separates freshness, the discipline you run, from drift, the failure that detection catches after the fact. In Atlan's framing, detection without that discipline just produces louder alarms with no fix upstream.

Periodic windows still earn their place, because they catch the changes nobody announced. Tier them by rate of change. Slow domains can carry long windows, and the fastest may need triggers alone.

Set windows from how often each domain has actually changed, not from how important it feels. If you don't know the rate yet, start with a shorter window and lengthen it once you have a few cycles of history.

When nobody owns the domain

The VPN article's real failure wasn't age. Nobody was responsible for it, so the migration had no one to tell. Wisq's guide to agent knowledge bases warns that missing owners and review processes leave agents answering from knowledge nobody maintains.

Give every domain a backup: a named lead who receives anything that lapses. A domain lapses when it has no accepted owner, its owner changes roles, or a window passes unreviewed. The lead then takes it on or reassigns it to someone who accepts it. Meanwhile, they decide whether the agent should keep citing that content.

Accepted is the key word. A name typed into a spreadsheet isn't an owner until that person has agreed to the job. And don't let a tool infer ownership from whoever last edited the article. The last editor may have fixed a typo two years ago and left the team since.

What freshness doesn't decide

A freshness register answers two questions: is this source current, and who must act? It doesn't decide which source wins when two disagree. If the IT portal and the article conflict, a recent review date doesn't make the article authoritative. That calls for a separate source-authority rule.

It isn't a health score, either. Gap-finding work, like the approach in closing gaps in a knowledge base, tells you something needs attention. The register says who has to act, by when, and what counts as done.

For the wider design, see the memory architecture behind AI knowledge management.

Stale knowledge has a cost even when nobody reports an error. Employees try dead forms, open tickets, and stop trusting the agent. The fix resembles giving agent spending an owner and a review cadence. You need a named owner, a clear stopping point, and a rhythm for deciding on purpose.

Questions to put to any agent platform

If you're evaluating Computer, by DevRev, or any other agent platform, don't take freshness on trust. Use your own content, and ask the vendor to show you rather than tell you:

• Can you record a content owner and review date against each source, and see which source backed a given answer?
• What happens to content past its local window, and who hears about it when the domain has no owner?
• Can a change event, like a migration, open a review for the domains it touches?
• After a source is corrected, what evidence shows when the agent started using the new version?
• When you re-ask a question that failed, can you confirm the new answer cites the corrected source?

Treat each answer as something to test in your own configuration. A platform can support the register, but it can't own your VPN article for you.

Close the change, not just the review

Your migration isn't finished while employees still receive instructions for a retired form. Put the affected knowledge domains in the change's completion criteria.

Have the content owner approve the correction and the delivery owner show the version the agent serves. Close the knowledge work only after the original question returns the current path. Leave unfinished domains open, with an owner and date.

An accepted owner starts the commitment. An answer employees can use is what closes it.

Once one domain's commitment holds end to end, fold it into the broader program that keeps every source your agents cite accountable: design the knowledge-management program your agents depend on.