How we keep agent answers fresh

The quiet failure mode of agent-readable business data isn’t downtime. It’s staleness: an endpoint that answers instantly, confidently, and wrong, because the business changed and the data didn’t. An agent has no way to smell that an answer is three weeks old unless you tell it. Most of CoreLoop’s internal machinery exists to make staleness structurally hard. Here’s how, for the technically curious.

One source, derived surfaces

The load-bearing decision is that there is exactly one profile record per business, and every surface, the public page, the MCP tools, the A2A endpoint, llms.txt, the directory listing, is a derived view of it. No surface owns a copy. This sounds obvious and is constantly violated in the wild: most businesses’ web presence is five hand-edited copies of the same facts, aging at different rates. Rule one of freshness is: have one thing to keep fresh.

The edit cascade

When a profile changes, whether the owner edited it, a re-crawl change was approved, or a connected source updated, a save is the start of a cascade, not the end of a write:

• The database commits.
• Caches are invalidated, including every locale variant of the cached profile.
• Page and llms.txt caches are busted.
• If services changed, the agent tool definitions regenerate to match, a business that gained a second service in a category grows a comparison tool, automatically.
• The directory listing updates.
• If translatable fields changed, translations regenerate per enabled language.
• If the logo changed, favicons and sharing images regenerate.

Every step runs on every qualifying change, because a missed step is precisely a stale surface. The cascade is boring by design; boring is what correctness looks like at this layer.

The re-crawl: watching the source you don’t control

The owner’s website is the one input CoreLoop doesn’t manage, so it’s re-read on a schedule: weekly on paid plans, manual only on Free, per-profile, checked hourly against each profile’s own next-due time. Detected changes split by blast radius. Minor ones (an updated photo, hours from a connected source) auto-apply with a notification. Major ones, services, prices, policies, descriptions, never auto-apply; they queue for explicit owner review, and until approval, agents keep receiving the last approved truth. Freshness never outranks consent.

Failures fail safe: one retry after six hours, then the last-good profile stays live, the status flips to failed, and the owner gets an email. A broken website never breaks the answers about the business.

Generate live where staleness would hurt most

llms.txt is generated from the current profile on each request rather than stored. A pointer file is the worst place for staleness (it’s the first thing a crawler reads), so it’s the place we spend the compute to never be stale. Meanwhile every MCP response carries last_updated and data_source metadata, so an agent can see the age of what it’s being told instead of trusting blind.

Even the part we can’t reach

The one artifact CoreLoop can’t update is the snippet pasted into a customer’s own website; it’s a copy, on someone else’s server, by definition. So it’s built to point rather than state (pointers don’t rot), and a weekly job scrapes the customer’s site anyway and raises a drift flag if the pasted block stops matching current URLs. When you can’t prevent staleness, detect it.

The theme, if there is one: freshness isn’t a feature, it’s a bunch of unglamorous plumbing that has to be right everywhere at once. Owners see none of it. They edit a field, and everywhere an agent looks, the answer is already the new one. Which is the whole loop, working as designed.