Building Tools for AI Agents

Daytona cofounder and CEO Ivan Burazin thinks a new job is opening up around AI agents: building the software they use, not just the models that drive them. His complaint is blunt. He does not want agents roaming through his bank account under his own credentials, and he does not want them failing because they cannot reach the tools they need. In his view, the latter problem bites harder than the model itself.

That turns “agent support” into an engineering problem, not a vibes problem. Burazin’s framing starts with identity: who is acting, who granted the permission, and what, exactly, is allowed. A service might use delegated user access, a separate service identity, or a mix of both. OAuth token exchange is one way to keep the person and the actor distinct, but the real work is in the authorization rules the system enforces.

That matters because an agent should be able to do one thing without being handed the whole kingdom. A user might allow a report for one project but not an export of everything else in the company. The integration has to respect that boundary even if the model asks for more. Burazin says the useful questions are painfully concrete: which application is acting for which user, what can it touch, how long does that permission last, and how will anyone know what happened afterward.

He also spends a lot of time on failure, because agent failures are messy in a way regular API failures often are not. A task can go wrong because the model picked the wrong tool, the request was denied, the service broke mid-call, or the model got a response and still did not know what to do next. If an export times out, that timeout does not reveal whether the server rejected it, started it, or already finished it. Recovery needs to be designed on purpose, with status checks, idempotency only where the server actually supports it, and a clear path when the outcome is still unknown.

Burazin says the most annoying failures are the ones that show up on tasks an agent has already completed before. That is the point of a real test, not a demo: repeat the job, keep the model and setup fixed, reset the environment, and see what happens when the world shifts a little. Anthropic’s guidance on tool design and agent evaluation comes up here too, especially around explicit tool descriptions, useful error messages, and shared state that can poison a run. Daytona’s founder says he regrets hedging on this kind of work; the company moved slower than it should have because of that. In his telling, agents are heading toward becoming the main users of software, which means the software has to stop pretending every caller is a person at a keyboard.