Abstract

AI agents are quickly moving beyond generating text (or even code) and answering questions. We’re giving them tools.

Agents can now send emails, create tickets, update databases, deploy code, schedule meetings, and interact with the same systems humans use every day. That makes them dramatically more useful—but it also changes the consequences when they get something wrong.

An incorrect answer from a chatbot is frustrating. An incorrect action taken by an agent can be much harder to undo.

Building trustworthy agents therefore requires thinking beyond the model itself. What tools should an agent have access to? How narrowly should those tools be defined? How does it authenticate as different users? What happens when an API fails halfway through a task? Which actions can be retried safely? What should require human approval? And when something inevitably goes wrong, can we reconstruct what the agent actually did?

This talk explores the emerging discipline of agent reliability engineering: designing the systems around AI agents so they can safely interact with the real world. We’ll look at practical patterns for tool design, permissions, authentication, retries, idempotency, observability, and human-in-the-loop controls, as well as the subtle ways tool interfaces themselves can influence agent behavior.

The goal isn’t to eliminate autonomy. It’s to make autonomy accountable.

By the end of the session, attendees will have a framework for thinking about the boundary between an agent’s reasoning and its actions—and how to build agents that can do useful work without requiring us to simply hope they do the right thing.

Key Takeaways

• Understand why agent reliability changes fundamentally once an AI system can take actions, not merely generate responses.
• Learn how tool design—including scope, descriptions, parameters, and error handling—can significantly affect agent behavior and reliability.
• Explore practical patterns for safely connecting agents to real systems, including authentication, permissions, retries, idempotency, and execution boundaries.
• Learn how observability and tracing can help answer not just “what failed?” but “what did the agent decide to do, and why?”
• Develop a framework for deciding which actions agents can perform autonomously, which need deterministic safeguards, and which should require human approval.
• Think about agent reliability as a systems-engineering problem rather than something that can be solved solely by improving the underlying model.

Questions

• What changes when an AI agent moves from recommending an action to actually performing it?
• How much authority should an agent have, and how should that authority be scoped?
• What makes a tool easy for an AI agent to use correctly—and what seemingly minor design decisions make failures more likely?
• Which failures can safely be retried, and which actions require stronger guarantees such as idempotency or human approval?
• When an agent interacts with five different systems to complete a task, how do we understand what happened when step four fails?
• Where should we draw the line between agent autonomy and deterministic control?