Why a 700-endpoint chatbot agent failed in two days
A two-day hackathon project tried to build a chatbot agent for a specific product. The goal was to read a user request and choose the right action from about 700 . The team used LangGraph and because of company .
The project did not reach its goal because the REST API was only documented in Swagger, did not have a clean OpenAPI 3.1 setup, and had no library that mapped common user wording to the right . A request like changing a ticket could match several different endpoints depending on what part of the ticket needs to change, so the agent could not reliably pick the right one. Sending all available to the model every time would waste tokens and raise cost.
Many real requests also need several API calls: gather data, analyze it, possibly fetch more data, then make an update. Turning plain user language into query settings or POST/PUT data for hundreds of endpoints is very hard when the and examples are thin. The practical lesson is that agents need a better API index, intent matching, and clear small skill documents before they can handle this kind of work well.
Key points
- The agent had to choose from about 700 , which made the job too broad.
- Swagger alone was not enough for reliable tool choice without OpenAPI 3.1 and examples.
- The missing layer was intent matching: connecting user wording to the right .
- Sending all to the model would burn too many tokens and increase cost.
- Multi-step requests should be split into planning, data lookup, analysis, and final action.