Feature store for AI agents: decisions that know the history

Ten small refunds, one large loss.

A retailer lets its customer-service agent issue refunds up to $200 without review. The rule is sensible: most refunds are small, and making a person approve each one would bury the team.

One evening, a single account asks for a refund on a damaged item. Approved: $184. Twelve minutes later, a different order, a similar story. Approved: $176. By the end of the hour the agent has issued ten refunds to the same account, each under $200, for $1,830 in total. Every decision checked the amount against the limit. Not one of them asked how many refunds this account had already received tonight.

The policy was correct for a single request. It failed because it had no memory of the business, only of the request in front of it.

Why do AI agent policies need history?

Because many risky patterns are invisible in a single request. Volume, velocity, cumulative totals and recent status changes only appear when a decision can see what already happened.

Agents make this worse in two ways. They act fast and tirelessly, so a pattern that would take a person a week can happen in an hour. And they're easy to steer: a customer, a compromised account or a manipulated prompt can split one large request into many small ones, each within limits. OWASP's agentic risks include exactly this kind of misuse of legitimate tools, where every call is allowed and the sequence is the problem.

Typical questions a policy needs answered:

What is a feature store for AI agent decisions?

It's a store of computed facts about history, such as counts, totals and status over time, kept fresh and ready at decision time so a policy can judge an agent's proposed action in context.

The term comes from machine learning, but the job here is different. The main consumer isn't a model. It's a rule: "hold for review if refunds in the last hour are three or more, or if the 30-day total exceeds $1,000." The features are business quantities people can read, argue about and sign off.

How is this different from a feature pipeline?

Feature pipelines are built for model training and inference, maintained in code by data teams. Decision features serve policy, so they're authored by the people who own the rule, in SQL or visually, with freshness and snapshots built in.

Most features an agent policy needs are window queries over operational data. A count of refunds in the last hour per account is a few lines of SQL with a window function or a grouped time filter. Authoring it directly, or building it visually, keeps the definition next to the rule that uses it, rather than in a pipeline repository few risk owners will ever read.

Freshness is part of the definition

A feature is only as good as its age. "Refunds in the last hour" computed 40 minutes ago misses most of the hour.

Give every feature a freshness limit: the oldest value a policy may use. Refund velocity might need to be under a minute old; a 90-day dispute rate can be a day old. Then decide in advance what happens when a feature is older than its limit or missing. The safe default for consequential actions is to hold the request for a person, not to allow it on stale data and not to treat "no value" as zero.

Features can be refreshed on a schedule, or triggered by an event through an API call when the underlying data changes: a refund issued, a bank detail updated, a dispute opened. Event-triggered refresh keeps velocity features close to current without recomputing everything constantly.

Record the snapshot with the decision

When a policy allows or holds an action, record the feature values it read, with their timestamps and the feature version. A month later, the current count for that account will be different. The question an auditor asks isn't "what's the count now?" but "what did the rule see when it decided?"

This also makes changes safe. When someone proposes tightening a rule, you can run the new version against recorded decisions and their snapshots to see which past requests it would have held. See audit trails versus evidence for what else a decision record needs.

History informs. It doesn't reserve.

This is the honest limit of the pattern. A feature describes what has already happened. It doesn't hold a place for what's about to happen.

Suppose the rule allows up to five refunds an hour, and the count is four. Two requests arrive at the same moment. Both read four, both pass, both refund. The account now has six. Event-triggered refresh narrows the gap but can't close it, because reading history and acting on it are separate steps.

For most risk rules, that's fine: the goal is to catch patterns, and one request over a soft threshold is still caught on the next. Where a limit must be strict (a credit line, a budget, an inventory allocation) the reservation has to happen where the value is committed:

• Reserve in the system of record. Use an atomic, conditional write: decrement the remaining budget only if enough remains.
• Serialize per entity. Process actions for the same account one at a time where the stakes justify it.
• Use features for judgement, not for accounting. Let history decide whether to hold or escalate; let the ledger decide whether capacity remains.

Common anti-patterns

Ten rules for history-aware agent decisions

1. Judge each consequential request alongside the ones before it.
2. Define features as counts, totals, ratios, status and time since, per entity.
3. Give each feature a window, a version and an owner.
4. Set a freshness limit for every feature, and check it at decision time.
5. Hold the action when a feature is missing or too old.
6. Refresh velocity features on events, not only on schedules.
7. Author features in SQL or visually, where rule owners can read them.
8. Record the feature values, their age and version with every decision.
9. Test rule changes against recorded decisions before publishing them.
10. Remember that history informs, it doesn't reserve: put strict limits in the system of record.

The result: rules that see the pattern, not just the request

Per-request limits are a good start, and on their own they're blind to the patterns that matter most when agents act fast and at volume. Decision features give policy the context a careful person would have: how many, how much, how recently, and what's still unresolved.

Built well, they're readable by the people who own the risk, fresh enough to trust, recorded with every decision, and honest about their limits. The tenth refund gets judged with the nine before it, and when a limit truly can't be crossed, the ledger, not the history, says no. Agent memory isn't a substitute: see memory versus application state.