--- type: Article name: What a failed readiness check actually looks like. id: "https://selfe.ai/insights/buyability-and-readiness/what-a-failed-readiness-check-actually-looks-like" url: "https://selfe.ai/insights/buyability-and-readiness/what-a-failed-readiness-check-actually-looks-like" publisher: "did:web:selfe.ai" description: "A failed readiness check rarely looks dramatic. It usually looks like an AI agent quietly giving up or guessing, which is harder to notice than an obvious error." datePublished: "2026-09-14T19:47:41.232Z" author: The Selfe team --- # What a failed readiness check actually looks like. > A failed readiness check rarely looks dramatic. It usually looks like an AI agent quietly giving up or guessing, which is harder to notice than an obvious error. ## In short - Nothing crashes and nothing returns a visible error: a venue's own dashboard shows normal traffic even while every agent asking a real question quietly gets nowhere. - Conditional facts stated without their condition, like a capacity that depends on the layout, are a common cause. - The only reliable way to see the failure is testing a real, specific request, not checking whether the site looks fine. Nothing crashes and nothing returns a visible error. A confident answer that's only conditionally true, a reassuring sentence that settles nothing, or silence exactly where a booking should start, all read as ordinary until someone deliberately tests a real, specific request the way an agent actually would. ## The first failure: a confident, wrong answer A hundred and twenty guests, a Saturday in June next year, an outdoor ceremony if the weather holds: a real enquiry to a barn wedding venue, run through an AI agent checking the venue's own site rather than a person on the phone. Watching exactly what the agent does with that question is more instructive than any score on its own. The agent states the venue holds up to a hundred and fifty guests, quoting a figure from the venue's marketing page. What the page doesn't say, because it was written for the barn's largest possible layout, is that a hundred and fifty only fits with a specific seating plan that isn't available if the couple also wants a dance floor, which almost every wedding does. The agent isn't lying. It's repeating a real number that turns out to be conditionally true, and the condition never made it into anything the agent could check. ## The second failure: a vague answer that sounds like an assurance Asked about the outdoor ceremony option, the agent says the venue "offers a beautiful garden space, weather permitting." That sentence sounds like an answer and settles nothing: what happens if it rains, is there a covered fallback included in the price or booked separately, how late can the decision be made. A person calling the venue would ask a follow-up question without thinking about it. An agent has nothing to follow up with, because the page gave it a mood rather than a policy. ## The third failure: silence exactly where progress should start Asked to check availability for the specific Saturday, the agent has no way to find out. There's an enquiry form, built for a person to fill in and wait for a reply, and nothing an agent can check directly. This is the quiet failure the earlier two were building toward: even with the guest count and the weather question settled, there's no route from "interested" to "held," so the request simply stops. ## None of these look like an error message This is why a failed readiness check is easy to miss from inside the business. Nothing crashed. Nothing returned a visible error. The venue's own dashboard shows normal traffic and a normal enquiry count, because the failure happened entirely on the agent's side, in the gap between a real question and an answer specific enough to act on. A business only sees it by deliberately testing a real request the way this one just was, not by waiting for something to look broken. The venue's own staff would have caught all three of these in a single phone call, correcting the capacity figure, naming the wet-weather fallback, offering to pencil in the date. That knowledge already exists, correctly, in someone's head. It simply never got written down anywhere an agent could reach it, which is the whole distance between a business that would clearly say yes on the phone and one that reads, to an agent working from the website alone, as vague and slightly evasive. Selfe exists to close exactly this distance: connecting a venue's real capacity, its real wet-weather terms and its real availability to something an agent can check directly, rather than a page that reads well to a person and answers nothing for the system now doing a growing share of the asking. ## Wouldn't we notice if agents couldn't book us? Not necessarily. The failure happens on the agent's side and rarely shows up as anything unusual in a business's own traffic or enquiry numbers. ## Is this the same as just having bad website copy? Related, but narrower. The copy can read perfectly well to a person and still lack the specific, conditional facts an agent needs to act rather than guess. ## Act on this - [Check whether an agent can buy from you](https://selfe.ai/agentic-commerce/buyability-check) — the free readiness scan. - [Discover venues](https://selfe.ai/api/registry/discover) — `POST`, semantic browse across the registry. - [Match a bookable answer](https://selfe.ai/api/registry/match) — `POST` with dates and party size. - [Verify Selfe's identity](https://selfe.ai/.well-known/did.json) — `did:web:selfe.ai`. - [Agent card](https://selfe.ai/.well-known/agent-card.json) — how to connect over A2A or MCP.