Why Your AI Agent Still Quotes Last Year's Prices

On August 10, AWS took Web Search on Amazon Bedrock AgentCore to general availability — a managed tool that lets an agent pull live, cited web knowledge into its reasoning without any data leaving the customer's AWS account. The framing in AWS's own announcement is telling: they call it grounding your agents "in current, accurate web knowledge." That phrase is doing a lot of work. It is an admission, from the platform running a huge share of enterprise AI infrastructure, that the default state of a deployed agent is ungrounded — reasoning from whatever it learned during training, frozen at a point in time, with no built-in mechanism to check whether that knowledge is still true.

Most businesses that have deployed an AI agent have already met the consequence of this, usually without naming it. A pricing agent that quotes a promotion that ended months ago. A procurement assistant that recommends a supplier whose terms changed last quarter. A customer-facing bot that states a policy the way it used to work, not the way it works today. None of these are the model "hallucinating" in the dramatic sense people picture — inventing facts from nothing. They are the far more common and far more expensive failure mode: a model reasoning confidently and fluently from stale information, because nothing in the system told it the information had gone stale.

Why This Is a Business Problem, Not Just a Technical One

A language model's knowledge is fixed at training time. Everything after that cutoff — a new price list, an updated policy, a competitor's move, a regulatory change — simply does not exist to the model unless something feeds it in at the moment of the task. The model has no internal signal that distinguishes "this fact is current" from "this fact was true when I was trained." It states both with identical confidence.

• Pricing and inventory drift — quotes, availability, and promotions change on a timescale of days or weeks, far faster than any model retrain cycle
• Policy and compliance drift — internal policies, regulatory requirements, and terms of service change on a schedule the model has no visibility into
• Competitive and market drift — an agent researching a competitor, a supplier, or a market condition is working from a snapshot that may be a year or more out of date
• Silent confidence — an ungrounded answer reads exactly like a grounded one; there is no hedge, no flag, nothing that tells the person reading it to double-check

The cost of this rarely shows up as a single dramatic incident. It shows up as a slow leak: a handful of customers quoted the wrong price each month, a compliance answer that was technically wrong when a regulator asked for it, a sales rep who trusted an agent's competitor research and walked into a call with stale numbers. Individually forgivable. Cumulatively, it is one of the most common reasons a promising agent pilot quietly loses trust and gets rolled back.

What "Grounding" Actually Means

Grounding is the general term for connecting a model's reasoning to a verifiable, current source of truth at the moment it answers, instead of relying solely on what it memorized during training. AWS's new tool is one specific version of it — live web search with citations, run inside the customer's own cloud boundary so the query itself doesn't leak to a third party. But the same principle applies whether the source is the open web, an internal database, a document repository, or a live API:

1. 1The agent identifies that a claim it is about to make depends on current information rather than stable, general knowledge
2. 2It retrieves that information from a source that is actually current — not memorized, but looked up
3. 3It attaches a citation or provenance marker so a human (or a downstream system) can verify the claim rather than take it on faith
4. 4It is explicitly allowed to say "I don't have current information on this" rather than filling the gap with a plausible-sounding guess

Step four is the one most home-built agents skip entirely, and it is the one that matters most. A model that has been given no permission to express uncertainty will not spontaneously develop it — it will fill the gap, every time, because filling the gap is what a language model is fundamentally built to do.

A Realistic Scenario

A Wizeb client, a commercial insurance brokerage, had deployed an internal agent to help account managers answer client questions about coverage terms and underwriting appetite — the kind of detail that changes every renewal cycle as carriers adjust their risk appetite and pricing. The agent was fast, well-reviewed in testing, and initially well-liked. Three months in, an account manager relayed a carrier's appetite for a specific industry exactly as the agent stated it — and the carrier had tightened that appetite six weeks earlier. The quote the client received was withdrawn after the fact, costing the relationship real credibility. The agent hadn't malfunctioned. It had answered from what it knew, which was accurate the day it was built and silently wrong by the time it mattered. We rebuilt the underwriting-appetite portion of the agent's knowledge as a grounded lookup against the brokerage's live carrier-appetite tracker rather than the agent's general training knowledge, with every appetite statement carrying a timestamp and source reference the account manager could see. Six months on, there have been zero stale-appetite incidents, and account managers report trusting the agent's answers enough to relay them directly to clients — something they had quietly stopped doing after the incident.

How to Audit Your Own Agents for This

1. 1List the categories of claims your agents make — pricing, policy, inventory, competitive information, regulatory status — and mark which ones change on a timescale shorter than your model's training cutoff
2. 2For each category that changes, check whether the agent is actually retrieving current data at answer time, or reasoning from what it learned during training
3. 3Check whether answers carry any source or timestamp a human could use to verify them — if the answer looks identical whether it's grounded or not, nobody downstream can tell the difference either
4. 4Test the agent with a question about something that changed recently and see whether it states the old fact confidently, states it with a hedge, or correctly retrieves the new one
5. 5Where an agent can't ground a category of claim reliably, check whether it has been given explicit permission to say so — or whether it defaults to a confident guess

How Wizeb Approaches This

Every AI agent we build at Wizeb starts with a claim map: which categories of answer the agent will produce, and for each one, whether it should be answered from stable general knowledge or grounded against a live source before it goes out. Where grounding is needed, we wire it directly into the agent's tool layer — a live database lookup, an internal API, or managed web search where the source genuinely is the open web — with citations or provenance attached to every grounded claim, and an explicit, tested fallback for when current information can't be found rather than a silent guess. That distinction, decided deliberately rather than left to default model behaviour, is usually the difference between an agent that earns trust over months and one that quietly loses it after the first stale answer someone acts on. If you have agents in production and aren't sure which of their answers are actually grounded, that's worth checking before a client or regulator finds the gap for you — start at wizeb.com/services/ai-agents.

Three Questions Before You Trust an Agent's Answer

1. 1Does this answer depend on something that could have changed since the model was trained?
2. 2If it does, is the agent actually looking that up, or reasoning from memory and hoping it still holds?
3. 3If the agent doesn't know, does it say so — or does it guess?