All services
Practice area
Tool & integration design
A tool description is not documentation. It is the entire basis on which the model decides whether to call your tool or the one sitting next to it. Two tools that describe themselves similarly will get confused for each other, and it reads exactly like a model failure when it is really an interface failure. That distinction matters, because one of those takes an afternoon to fix.
You probably need this if
- The agent reaches for the wrong tool on requests where the right one looks obvious.
- Every failure comes back as "something went wrong," so it retries things that will never work.
- One agent has eighteen tools available and chooses badly among them.
- It ignores the integration you built and does the job the slow way instead.
- Your API tokens are sitting in a config file that's checked into the repo.
What you get
- Tools that don't compete
- Each one says what it's for, what it takes, what comes back, and the part everyone leaves out — when to use the other one instead. Where two genuinely overlap, we split or rename them until the choice stops being a coin flip.
- Failures with a shape
- "Something went wrong" tells an agent nothing, so it guesses: hammers the permanent failure, gives up on the temporary one. Errors should say which kind they are, whether trying again is worth it, and what a person should be told.
- The right tools in the right hands
- Hand one agent everything and it chooses worse. Each agent gets what its own job needs. Where something genuinely spans roles, it gets a narrow purpose-built version rather than a general one it can misuse.
- Control over when tools fire
- Sometimes a specific call has to happen before anything else. Sometimes you need a real answer rather than a chatty non-answer. Both are things you can pin down directly, and knowing that saves a lot of prompt-tuning that was never going to work.
- Integrations the whole team gets
- Configuration in the repo so it arrives on clone, credentials referenced rather than committed, and your data catalogs exposed so agents can see what exists instead of going hunting for it.
The judgment behind it
These are the calls that decide whether a system survives contact with production or just demos well. They are not obvious, and getting them wrong is rarely obvious either — until it is.
- More tools, worse decisions.
- Going from five tools to eighteen does not make an agent more capable. It makes every single choice harder, and an agent handed tools outside its job will reliably find a way to misuse them.
- Nothing found is not the same as nothing worked.
- A search that ran and matched zero rows and a search that timed out call for opposite responses. Reporting both as "unavailable" throws away the one fact needed to choose between them.
- Don't swallow errors. Don't panic either.
- Reporting a failure as an empty success hides it until it's expensive. Killing the entire run over one failed step throws away everything that worked. What's actually useful: what failed, what it was attempting, and what it managed to get anyway.
- Don't build what you can adopt.
- Solid open-source connectors already exist for the systems everybody uses. A custom one earns its ongoing upkeep only when the workflow is genuinely specific to you.
Engagement shape
Usually 2–4 weeks: an audit of what you've got, rewritten interfaces tested against deliberately ambiguous requests, a real error contract, and configuration checked into your repo.