Expose app functionality as tools the agent can call

Build your application’s functionality as API endpoints first, then register those endpoints as tools the agent can call. The agent speaks (or types), decides to take an action, calls the tool, and the action happens on the interface. This pattern gives you flexibility that direct integration never will: you can call the same endpoints from a voice session, from curl, from a test suite, or from a different agent entirely.

The implication for agent architecture is that the API layer IS the agent interface. Every endpoint is a potential tool; every tool is a capability the agent can invoke. This means the harness (see: an agent harness is everything that constrains and shapes an agent) is partly defined by what APIs you choose to expose. A narrow API gives the agent fewer options and more safety; a broad API gives more power and more risk. The lethal trifecta (see: the lethal trifecta makes agents exploitable) applies here: if your API exposes private data AND accepts untrusted input AND can communicate externally, you have built an exploitable agent.