Building Reliable Agents Videos

Lightly edited for clarity.

If your process isn’t well defined, an agent’s going to make it worse, not better. The agent use cases that work all look the same. There are very clear inputs, there’s clear outputs, and the sequence of steps that someone has actually thought through.

So for example, take new weeds from the CRM, enrich them with this external data, and prepare a summary that I can use on my sales call. There’s a defined start and a defined end, and it works.

Now if you compare that to respond to customer complaints and resolve them appropriately, that might sound reasonable, but resolved and appropriately are carrying a lot of undefined weight there. They’re not instructions, they’re judgments.

What counts as resolved? Who decides what’s appropriate in what context, with what authority and for which customers? And we’ve already seen multiple cases of what happens when you skip that step.

But I recently read a Reddit thread where a small UK company put an AI chatbot on their website to handle customer questions, and a customer spent time steering the conversation until the chatbot started offering discounts. And it ended up generating an 80 discount on an 8,000 euro order.

And it’s not because the system was malicious, it’s because it was never given a clear boundary for what it was allowed to do. That’s the issue.

And this is where organizations get into trouble, reaching for agents on problems that look structured but aren’t. Agents don’t just bring order to a messy process, they run it faster.

If you want an agent to work well, the real work is upstream, defining the process clearly enough that a person could follow it without asking questions.

Lightly edited for clarity.

Most agent failures aren’t really AI problems, they’re system design problems. When agents fail, it’s usually because something around the model got something wrong, not the model itself, because the system wasn’t built carefully enough.

As a real version of this, let’s say we’re gonna build an agent to generate a weekly status report. So it will go to Jira for ticket status, and it will go to GitHub for code changes, and it will go to Teams for chats and updates.

And this seems straightforward, but in Jira, if you’ve got some tickets that are marked as done while others are marked as closed, or you’ve got tickets that just haven’t been updated properly, or in GitHub your commit messages don’t map cleanly to tickets in Jira, and in Teams, half the actual decisions are happening in threads that never get captured or monitored.

So in that case, what does our agent do? It’s still going to pull everything together, and it’s going to give you a very clean, well-written, completely misleading report because LLMs match tokens; they don’t make judgments.

The model did exactly what the system allowed it to do. The system wasn’t designed well enough.

And then in addition to that, there’s the permissions problem. If that same agent has write access, it’s not just reporting. It could update tickets, or trigger workflows, or send communications based on bad assumptions.

So you give it too much access, and it can do the wrong thing, and too little access, and it misses what matters.

And that’s why security teams are increasingly focusing on agent-specific risks—not just bad outputs, but bad actions. The model’s not usually where it breaks down; it is the system design.

Lightly edited for clarity.

When an agent makes a mistake, who’s responsible? That question should make you think about how you design agentic systems.

Agents do eliminate work, but they also create new work, and they move where that work happens. When you automate a workflow, you remove manual steps, but you create new ones.

If an agent writes daily reports across 10 different projects, someone now has to review 10 reports. You scale that up, and you built a review bottleneck that didn’t exist before.

Same problem with data. An agent’s only as good as what it connects to, garbage in, garbage out, but faster and at a higher volume.

And then there’s the accountability question when something goes wrong. So a report is off, a change gets made incorrectly. Was it the model, the data, the workflow, the permissions? And most organizations genuinely don’t know how to answer that yet.

But the teams that get this right, that design the system carefully, and put human judgment in the right places, they’re not just saving time, they’re building systems that are reliable enough to trust, and fast enough to increase their competitive advantage.