# What changes when AI agents use your software > Source: > Published: 2026-09-23 14:00:23+00:00 *Daytona cofounder Ivan Burazin sees a growing role for engineers who build tools for agents. His frustrations with the agents he uses show where that work begins.* Ivan Burazin’s frustration with [AI agents](https://arize.com/glossary/agent/) gets especially concrete when he talks about his bank account. “I don’t want my agents to have access to my bank account under my credentials.” Ivan Burazin, Daytona’s cofounder and CEO, wants agents to carry out work on his behalf while maintaining a distinction between his identity and theirs. In his conversation with Arize for *[Rise of the AI Engineer](https://www.youtube.com/watch?v=rfx2fS2EysM)*, that complaint sits alongside another: the agents he uses frequently struggle to access the tools they need. He says those difficulties have caused more failures in his own experience than the model itself. Burazin has a business interest in making that work easier. Daytona supplies [sandboxes for executing code](https://www.daytona.io/docs/en/process-code-execution/), and he expects agents to become the dominant users of digital tools. His definition of an [AI engineer](https://arize.com/resources/what-is-ai-engineering/) consequently includes the people building software for agents to use. Taking that prediction seriously starts with a question a product team can investigate now: can an agent complete a real customer task through your software, within the authority and time budget it was given? ### Build better agents with Arize Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today. **Prefer open source?** [Try Arize Phoenix for self-hosted, open source agent observability](https://arize.com/phoenix?utm_source=blog&utm_medium=referral&utm_campaign=ax-inline-cta&utm_content=building-tools-for-ai-agents-inline-cta-phoenix). ## **AI agent identity and delegated access** Burazin describes the identity problem in conversational terms: the agents he works with tend to behave as though they are him. Translating that frustration into an engineering requirement means specifying what the system will permit, regardless of how the model describes itself. There are several ways to represent that relationship. A workflow may use delegated user access, a service identity, or a combination. The [OAuth token exchange standard](https://datatracker.ietf.org/doc/html/rfc8693#section-4.1), for example, provides a way to distinguish the subject of a token from an actor performing delegated work. The appropriate implementation depends on the services involved and the permissions they support. Giving an agent a separate account would still leave the central authorization decisions to make. A user might authorize a report about one project without authorizing exports from the rest of the organization. The integration needs to preserve that boundary even if the model requests a broader dataset. An [agent harness](https://arize.com/blog/what-is-an-agent-harness/), the runtime coordinating model calls and tool execution, can help carry the relevant context and gate [tool calls](https://arize.com/glossary/tool-calling/). The services executing those requests must also [enforce authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). Trusted integration code can hold credentials and expose permitted operations without putting the secrets themselves into the model’s context. The useful implementation questions are concrete: which application is acting for which user, what resources may it access, and how will access expire or be revoked? An [audit record](https://arize.com/guides/ai-agent-handbook/agent-observability/) should let the team reconstruct that relationship after a request has been executed. Those decisions also belong in the product specification. If completing a report requires additional permission, the team needs to decide whether the agent should request approval, return a clearly labeled partial result, or stop. Each choice creates a different promise to the customer. ## **Handling tool failures and safe retries** Burazin’s complaint about tool access invites a closer look at where an agent’s plan encounters the rest of the system. As he puts it, “these agents actually have to go out and do these things.” A [failure at that boundary](https://arize.com/blog/common-ai-agent-failures/) can have several causes. The model might choose the wrong tool or construct invalid arguments. A correctly formed request might be denied, or the service might fail while processing it. Even a successful response can leave the model uncertain about what to do next. Those cases call for different investigations. Consider an agent preparing a report. It asks a service to export a dataset, but the response times out. The service may have rejected the request, started the export, or finished it before the connection failed. From the timeout alone, the caller cannot establish which happened. For an export API, the recovery contract should specify how to check operation status and when a retry is safe. If the backend supports [idempotent requests](https://docs.stripe.com/api/idempotent_requests), a caller can reuse the same key and parameters under that service’s documented rules. The server must enforce the duplicate handling; adding an identifier to a request does not create that guarantee by itself. The key’s validity window also matters. When the outcome remains unknown, the system needs a defined reconciliation or escalation path. Having the agent start another export may add cost or produce conflicting results without resolving what happened to the first one. These concerns will sound familiar to anyone who has maintained an API. What deserves additional testing with an LLM is how the model [selects an operation](https://arize.com/blog/how-to-evaluate-tool-calling-agents/) and interprets the evidence returned to it. [Anthropic’s work on tool design](https://www.anthropic.com/engineering/writing-tools-for-agents) highlights the value of explicit descriptions, relevant response content, and actionable errors. For the report workflow, the tool should make an accepted request distinguishable from a completed export. It should expose a way to check the job, explain whether retrying is supported, and make permission failures distinguishable from temporary unavailability. An existing API or CLI may already provide everything needed. ## **Evaluating agent reliability across repeated runs** The failures that most surprise Burazin occur on tasks an agent has completed before. While describing tests of Daytona involving concurrency and timing, he notes that some attempts fail to get the job done at all. His example of nine successes followed by a failure illustrates the frustration, without establishing a measured failure rate. A previous success establishes that the system could complete the task under those conditions. On a later attempt, the model may choose a different sequence of actions, while the environment may also have changed. A stale token, a different dataset, or a service under load can alter the outcome. Those possibilities need to be investigated separately. For the team building the report workflow, a useful investigation would begin with a reproducible task and a clear [definition of success](https://arize.com/guides/ai-agent-handbook/agent-evaluation-metrics/). The expected file must contain the requested data, be accessible to the intended user, and arrive within an agreed time budget. The evaluation should also check for unauthorized access and unintended duplicate operations. A correct file can coexist with a serious mistake elsewhere in the run. To compare two tool implementations, hold the model, instructions, harness, and run budgets fixed, and record their versions. Run each variant repeatedly from equivalent starting states in a resettable test environment. Leftover exports or cached results can otherwise assist later attempts. [Anthropic’s guidance on agent evaluations](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) explicitly warns that shared state can distort results. Then test recovery deliberately, using scenarios such as a lost response after the server accepts the export or a permission change before the task resumes. These tests answer a different question from the baseline: how does the system behave when a dependency stops cooperating? An [agent evaluation](https://arize.com/guides/ai-agent-handbook/agent-evaluation/) also needs to distinguish completing the customer’s task from following the workflow correctly. A test can pass because the agent properly stops an unauthorized export, even though no report is produced. Required approval should be tracked separately from an unexpected human rescue. For product decisions, task completion should be considered alongside the time and cost required to get there. Fewer retries are useful when they eliminate wasted work; they can also reflect an agent giving up sooner. Report the number of trials and the circumstances of the failures before treating a small change in the average as an improvement. ## **Building tools for agents as an AI engineer** Burazin puts particular emphasis on engineers who build tools for agents, because that work requires understanding how models use the interfaces they are given. His forecast of agents becoming software’s dominant users remains a forecast, but testing an existing product with an agent does not require accepting its full scale. A team maintaining an export service could begin with a task its customers already delegate. It could test whether clearer operation states reduce abandoned jobs, or whether a documented recovery path reduces unnecessary human intervention. The result would be evidence about that workflow, which is enough to inform a product decision. There is a tradeoff to manage. A larger tool response may explain more while consuming [additional context](https://arize.com/blog/context-management-in-agent-harnesses/) and obscuring the field the agent needs. A narrowly designed operation may simplify one task while making other workflows harder to express. Improvements need to earn their place through the tasks the product is supposed to support. For Burazin, the strategic mistake was hesitating to invest in this work. Looking back at Daytona’s decisions, he says, “we also hedged our bets and because of that we were slower than we should have been.” Those improvements ultimately have to pay off for the person who handed over the task and expected to get on with something else. If the agent needs someone waiting by the keyboard to explain every ambiguous result, the product has left a substantial part of the job with its customer. Watch [Ivan Burazin’s full interview](https://www.youtube.com/watch?v=rfx2fS2EysM) in *Rise of the AI Engineer*.