Why does my AI agent get blocked at "contact sales"?

Your agent gets blocked at "contact sales" because that button is a wall built for a person, not a price built for a machine. An account wall is a REST verb standing in for a posted price, and a demo-call calendar is a waiting room a machine cannot sit in — an agent has no way to fill a form, book a call, or charm a rep, so the capability exists but cannot be bought, and your demand leaves the building as abandoned sessions instead of settled calls. To an agent, a capability it cannot buy is a capability that does not exist. The fix is that every gate returns a typed outcome — either an OFFER (posted price · hard ceiling · x402 accepts) or a NEEDS_HUMAN Handoff — and the worst-case cost is posted before the call, so the agent always knows what it can and cannot do. On b2a.vin, "contact sales" is treated as a conformance failure: a gate that answers with neither an OFFER nor a Handoff is broken, not gated.

Think of "contact sales" as the desk in its machine franchise. The desk is the old human bottleneck — the rep who holds the price close and makes you ask for it — and it has learned to wear a REST endpoint. The account wall is the desk with a verb; the demo-call calendar is the desk's waiting room. A person can be charmed at the desk, can fill the form, can take the call. An agent can only read what is posted. So when your fleet hits "contact sales," it isn't being told no — it's being handed a gesture it has no organ to complete, and it stalls there silently, because there was never a machine-legible answer behind the button.

the two ways a gate can honestly say "not free, not now"

The reason "contact sales" is a failure and not just a paywall is that a paywall, done right, is a typed thing an agent can act on. There are exactly two honest outcomes a gate can return, and neither is a form:

• OFFER — the capability is buyable, so the gate returns a typed envelope: outcome · posted price · hard ceiling · x402 accepts · checkout fallback · expiry. The agent reads the price, compares it against its Mandate ceiling, and settles or declines. No conversation, because the price is already the answer the conversation would have produced.
• NEEDS_HUMAN Handoff — the law reserves this act for a person (a signature, a notarization, a consent), so the gate returns a typed, resumable Handoff — a URL the human authorizes, after which the agent resumes. It is a routed step, not a dead end.

"Contact sales" is a third thing that should not exist on machine rails: a gate that returns neither. It is a price withheld dressed as a process, and to a machine a withheld price is indistinguishable from no capability at all. The diagnosis, then, is exact — your agent isn't failing at a hard step; it's failing at a step that was never given a machine-shaped answer.

the asymmetry tax, paid in dead ends

Here is what the blocked gate actually costs, and why it is worth naming precisely rather than estimating. Every agent that reaches "contact sales" and stalls is demand that arrived and could not transact. It doesn't retry into a settlement; it abandons. So the capability's owner pays a tax not in a line item but in shape: real purchase intent, structured and specific, converted into abandoned sessions instead of settled calls. The asymmetry is that a human hitting the same wall might email, might wait, might call back — the wall leaks some conversions through sheer human persistence. A machine has no persistence to leak through. It reads the gate, finds no price, and is simply gone. The wall that merely slows a person stops a machine dead, and every stop is demand the platform emitted and never captured.

That is why "post the price" is not a courtesy on these rails — it is the difference between demand you can settle and demand you can only watch abandon. An agent that pulls decode, value, and history for one VIN and then hits an OFFER is a purchase-intent event with structure; the same agent hitting "contact sales" is that same event, discarded.

the fix: worst case posted before the call

The concrete remedy is to move the number to before the call. On these rails every gated action returns its worst case in the OFFER envelope — the posted price and a hard ceiling that is contractual, meaning settlement above it does not occur. So the agent knows the outer bound of a capability before it commits to it, and a slot without a real figure reads a dash, never an estimate. This inverts the desk's whole logic: the desk keeps the price behind the conversation so the conversation can shape the price; the OFFER puts the price in front of the conversation so no conversation is needed. The check digit certifies; it never sells — the record's job is to state what is true and what is priced, not to route you to someone who will decide what to charge once they've sized you up.

One honest boundary. Not every "contact sales" is hiding a price that should be posted — some gates sit in front of an act the law genuinely reserves for a human, and for those the correct answer is not an OFFER but a typed NEEDS_HUMAN Handoff, which is the other door's motion. The failure this piece diagnoses is narrower and more common: a gate in front of a capability that is machine-buyable, withholding its price behind a human-shaped process for no reason the machine can act on. That is the account wall as machine franchise — and the fix is not a better form. It is a posted price and a typed outcome, so the agent is never left reading a button that was drawn for an eye it does not have.

---

Related:

• b2a.vin — where the account wall becomes a posted price: every gate a typed OFFER, worst-case cost known before the call.
• apis.vin — where the posted prices and the keys live: one MCP server, per-call prices on the page.
• b2h2a.vin — the other typed outcome: when a gate returns NEEDS_HUMAN instead of OFFER, the human approves one step and the agent resumes.