--- type: Article name: "What happens when an agent's request doesn't match your rules." id: "https://selfe.ai/insights/agent-ready-transactions/what-happens-when-an-agents-request-doesnt-match-your-rules" url: "https://selfe.ai/insights/agent-ready-transactions/what-happens-when-an-agents-request-doesnt-match-your-rules" publisher: "did:web:selfe.ai" description: "A request that falls outside a business's rules doesn't have to end the transaction, as long as there's a real, bookable alternative behind it that an AI agent can complete." datePublished: "2026-09-14T19:26:59.104Z" author: The Selfe team --- # What happens when an agent's request doesn't match your rules. > A request that falls outside a business's rules doesn't have to end the transaction, as long as there's a real, bookable alternative behind it that an AI agent can complete. ## In short - An agent told "we might be able to do something else, call us" has learned a fact, not been handed a transaction. Only a specific, bookable alternative moves the request forward. - The fix isn't a vague suggestion, it's a specific, bookable alternative offered at the same moment the original request fails. - The business's own real flexibility already exists; the gap is only ever whether it's connected to the moment it's needed. A party size, a date range or a delivery radius that falls outside a business's stated rules doesn't have to be a dead end. What turns a mismatch into a completed booking anyway is a real, checkable alternative an agent can book on the spot, not a vague note that something else might work. ## A refusal is not the same as a completed alternative Fourteen people want a table at your countryside pub's function room, which seats twelve for a sit-down meal. A person calling to ask gets a real conversation: "we can't quite fit fourteen at one table, but two tables of seven in the same room would work, or the barn seats up to twenty if that suits." The booking still happens, just not the exact shape it was first asked for. An AI agent hitting the same limit, with no equivalent path, gets a flat no, and the transaction ends there instead of landing somewhere that could be confirmed. Every business has real limits: a maximum party size, a minimum number of nights, a delivery radius. None of that is a problem to fix. The problem is what the system does the moment a request crosses one of those limits. A refusal on its own doesn't move the transaction forward, and a vague suggestion doesn't either. What rescues the booking is a specific alternative that can be confirmed the same way the original request would have been: two tables instead of one, held and payable right now, not a general note that other options might exist. ## The alternative has to be something an agent can commit to, not just hear about This is the part that keeps it inside transaction territory rather than becoming a discovery problem. An agent told "we might be able to do something else, call us" has learned that the pub exists and has options, which is a fact, not a transaction. An agent told "two tables of seven, same room, bookable now" has been handed something it can confirm on the spot, the same live check, the same commit step, the same terms as any other booking. The difference between those two responses is the whole distance between a business that copes with an odd request and one that completes it. ## The business already has the answer The pub's own next-best option, two tables, or the barn, already exists in the landlord's head, offered instinctively to anyone who calls and asks. Nothing about this requires inventing new flexibility the business doesn't already have. It requires connecting the alternative that already exists to the exact moment a request doesn't fit, in a form specific and current enough for an agent to book against it directly, rather than leaving it to be discovered only by whoever happens to phone. ## The alternative has to be checked at the same standard as the original request An agent offered "two tables of seven" still needs to confirm that both tables are genuinely free on the date asked for, the same live check the original party-of-fourteen request would have needed had the function room held that many. An alternative that turns out to be unavailable when the agent tries to book it is worse than never being offered one, because it costs a second round of failed requests before anything lands. The alternative only counts as a real transaction path if it's checked with the same rigour as the request it's replacing, not offered as a hopeful guess and left for the agent to discover doesn't hold. A mismatched request handled this way still ends in a completed booking, just not the one first asked for. That's the outcome worth building for: not a business that lists every possible exception in advance, but one whose real alternatives are as bookable as its standard offer. Connecting a business's real rules to its real, bookable alternatives is the specific layer Selfe builds, so a request that doesn't fit still has somewhere to land. ## Doesn't this mean listing every possible exception in advance? No, it means connecting the handful of alternatives staff already offer by instinct, two tables instead of one, a different room, so they're bookable at the moment a request doesn't fit, not buried in someone's head. ## What if there genuinely isn't an alternative? Then a clear, specific no is the right answer, and an agent stating that clearly is still a completed, honest transaction outcome, just not a booking. ## 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.