Charles JonesExposing tools to an assistant moves your site from something that gets read to something that gets called — and calls have deadlines that reading does not.
The budget is not yours
When an assistant calls check_availability, a person is waiting on the other end of the
conversation. The assistant is holding a turn open, and it has a limit on how long it will hold it.
Exceed the limit and the tool call fails. From the customer’s side there is no error and no apology — the assistant simply reports what it managed to find out, which no longer includes you.
A failed call is worse than no tool at all
This is the part worth sitting with. A site with no tool surface is read as a static page and answered from its text. A site with a tool surface that times out has offered the assistant a route, taken up its budget, and then failed — and it may have spent time it would otherwise have used reading the page.
Advertising a capability you cannot serve quickly is worse than not advertising it.
What this means in practice
- Tools read what the page already has.
list_servicesreturning the services block the page renders needs no database call. Data that is already built into the page is the fastest thing you can serve, and it cannot drift out of date. - Keep the surface small. Three or four tools that always answer beat a dozen that sometimes do.
- Refuse fast. A clean, quick refusal on a closed day is a good outcome — the assistant tells the customer you are closed. A slow refusal costs the same as a slow success.
The honest boundary
We have not benchmarked commercial assistants’ tool-call timeouts, and no such figure appears on this page. What is documented is the standard, and what is measured is our own crawler’s behaviour under a budget. The rest is reasoning, marked as reasoning.