AI Agents Videos

Lightly edited for clarity.

AI agents don’t just generate, they execute. So think about how you use something like ChatGPT today. You ask it to write something, summarize something, explain something. It gives you an answer. Hopefully you iterate, but then you’re done.

An agent doesn’t stop. It’s the difference between someone who writes you an email explaining what you need to do and someone who writes you an email explaining about the work they’ve already done.

So here’s what that looks like in practice. Instead of asking AI to summarize a Jira ticket, you give an agent access to Jira and GitHub and say, pull everything that changed in the last 24 hours and generate a status update. The agent AI will query Jira, it’ll read the GitHub commit history, it’ll correlate those changes, and produce a report.

And that’s not one prompt. That’s a sequence of actions across real systems. And once you have that foundation, where agents can connect to your systems, then you can start to expand on them and leverage some advanced capabilities of AI.

So not just pull everything that changed in the last 24 hours and give me a report, but review the requirements for ticket AI X5, 78. Review the code that was created in branch bug fix AI X5, 78. Analyze what requirements were met, what requirements possibly weren’t met, and specific areas that should be focused on by manual QA.

The agents sit inside your workflows. They’ll take actions on your behalf, and when you implement them properly, they can dramatically extend the capabilities and efficiencies of your team.

Lightly edited for clarity.

If you want to understand where agents fit, look for the boring parts of the job. The best place to find agent use cases is not in high-level planning; it’s in coordination work. It’s the tedious, cross-system, nobody-wants-to-do-it layer that sits between decisions and results.

Take marketing teams. A typical weekly report is not really analysis. It’s pulling numbers from analytics tools, combining it with campaign data, and then formatting it into slides or dashboards.

Same in software development. Status reporting usually means checking tickets, and reviewing recent commits, and piecing together what was actually shipped. Things like bug fixing and ADA issues, SEO issues, browser specific things, they’re all straightforward, well defined tasks, but they’re tedious and time consuming for developers and cloud.

Agents are ideal for these cases, not just writing code, but also generating summaries and PR descriptions and workflow outputs.

And it’s not just in tech. In a law firm, agents can pull case history, flag relevant precedents, and draft a brief outline before a human attorney ever opens it.

And that pattern is the same everywhere. The work that connects systems is where agents win, not replacing the decision, just handling the legwork that surrounds it.

Lightly edited for clarity.

Agents don’t replace people, they change what people are responsible for. If agents actually replace people, companies would already be running them into end to end. But that’s not what I see happening.

So let’s talk about how they’re actually being used. Take coding workflows, for example. An agent can take an issue, generate code, and open a pull request, but it doesn’t merge it into production. A human reviews it. Why? Because the hard part’s not writing the code, it’s knowing whether it’s the right code.

Does it break something else? Does it fit the architecture? Does it handle edge cases? Does it actually solve what the customer need is? And agents don’t necessarily have that full context.

So what happens is execution gets faster, but the responsibility shifts. You’ll spend less time doing the work, but more time evaluating whether that work is correct.

And that part is something most people underestimate. It’s not the job that disappears, it’s what you’re responsible for that changes.

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.