The fastest way to make an AI agent
dangerous, I'm convinced of this, is to
let everyone use it and nobody own it.
And I want to start there because I
think we've made agents sound way more
confusing than they really need to be. A
lot of us hear the word agent and we
immediately think, okay, this is some
fully autonomous thing running in the
background. Is this a digital employee?
Is this a model? Is this codeex? Is this
claude? Is this chat GPT with a custom
trench coat? What are we talking about?
And that confusion matters because the
word agent means kind of all of those
things in different contexts. And if
you're still stuck asking, "Am I even
using an agent?" You are probably not
asking the most important question.
Who's responsible for the work that this
thing is now doing? So, this video is
going to be very simple. I want to make
the basics clear. How to know if
something is close enough to an agent
that you should care. What to do with it
once you have it, what care and feeding
means, and when this becomes a team
workflow. Because the big shift here is
not that everyone needs to become an AI
engineer. The big shift is that more of
us are going to have little systems that
do work for us. And if those systems can
read files and draft messages and maybe
change code or summarize customers or
update records, somebody needs to own
them. Not philosophically, not on an org
chart operationally. So let's make this
really concrete. Let's say you open Chad
CPT. You can go ahead and do that. Type
a question, get an answer, and then you
move on about your day. That is an
assistant interaction. You asked, it
answered. You decide what to do next.
Now, let's say you have a custom GPT
that reads your notes every week. It
prepares your Monday priorities. It
follows your rules. And it produces a
work product you actually use. That is
close enough to an agent for this
conversation. Let's say you open Claude
and ask it to help write a paragraph.
Same thing. That's mostly an assistant.
But if you have a clawed project with
files and instructions and examples in a
repeated job or if you use claude code
to inspect files and make changes and
issue commands and come back with a
result, now you're in Asian territory.
And many uses of codecs are very clearly
in this category. If you give codeex a
repo and say inspect this code, fix the
bug, run the test, show me the diff,
it's doing work across steps with tools
and real consequences. It may be
supervised, it may ask for approval, it
may not be autonomous in the sci-fi
sense, but it's an agentic workflow. The
brand name, the word agent is not the
point. Chad GPT, Claude, Codeex, Cursor,
a workflow tool, they can all be agents.
The label doesn't matter. The job does.
And once you delegate a job, your job of
owning starts. And I think this is where
people get tripped up because the AI
conversation is still obsessed with
building. Build an agent, make an agent,
launch an agent, connect tools, automate
the workflow. And sure, that matters. I
like building. I want people to build.
But the moment after the initial build
demo is where your real responsibility
for that agent over the long term
begins. Useful agents don't stay in demo
land on day one and two. They start
becoming part of how daily work gets
done for you for your team. A research
agent has to find sources you trust
every single day. A writing agent has to
work with your voice as it evolves every
single day. A coding agent changes files
and has to be trusted to do that. A
support agent shapes what customers hear
from the company. That's critical. A
product agent shapes what shows up in
the backlog for engineering. And if no
one owns that agent and feels like they
have skin in the game, the danger can
feel ordinary until it's not. The agent
will use an old policy. Maybe it'll pull
from stale docs. Maybe it'll repeat a
bad pattern. Maybe it will draft
something plausible but wrong and you'll
say, "Oh, chat GPT is hallucinating
again." Maybe it'll turn an assumption
into a recommendation. And because the
output looks really clean, people will
stop noticing where it came from. And
that's the risk. It's not evil AI. It's
that unowned work starts to have real
consequences over time because people
don't check it and care for it. So what
do you do with your agent? I would start
with four things. And I want to keep
this really, really simple. Give it a
job. Give it a diet. Give it boundaries.
And give it a review loop. The job is
what this agent is supposed to do. Not
help with the product. Not something
vague, right? Not make me more
productive. a real job that matters,
like prepare first pass backlog items
for refinement, draft refund replies for
this ticket type, inspect a poll request
for risky changes, build me a weekly
research brief from these sources. If
you can't say the job in a sentence, the
agent is probably too vague. The diet is
what the agent reads. This matters a lot
more than people think. Agents eat
context, right? They eat docs and
tickets and transcripts and repo
instructions and examples and whatever
else you put in front of them. If the
diet is stale or bloated, the agent can
get stale and bloated. If the diet is
messy, the agent can get messy. If the
diet uses incorrect examples, the agent
learns bad habits. This is why the
little Pokemon analogy works so well for
me. Collecting the Pokémons isn't the
point. You have to know what each
Pokemon is good at. You have to know
where not to use it. You have to know
what it has been trained on, and you
have to notice when it starts picking up
bad habits. And that sounds kind of
silly, but the responsibility for care
is real. And then come the boundaries.
What can this agent touch? Can it read
files? Can it draft? Can it write to the
system? Can it send or delete? Can it
update Jura? These are not the same
level of risk. A drafton agent is one
thing. An agent that can write into a
system of record is much much more
serious. An agent that can send a
customer message or merge code is in a
different category entirely. And your
sense of ownership should move with
that. You should feel emotional stakes.
So, the rule is simple. Start with read
only. Start with draft only if you're
unsure. Let the agent earn more
permission and make sure you're
comfortable moving outside that narrow
job. And then the review loop is how you
keep it healthy. And this is one of the
phrases people like to use. Loop system
workflow. It's getting used a lot and I
think it can sound more complicated than
it is. A loop just means the work comes
back around. The agent runs a human
reviews. Maybe another agent reviews. In
some cases, mostly a human reviews. You
notice what was good and what was bad.
You update the instructions, the
sources, the permission, the agent runs
again. There's the loop. It's not magic.
It's not a giant governance process.
It's not the best thing since sliced
bread. It's just a way work gets done
with agents. Run, review, improve, run
again. So, let me give you a product
team version because this is where this
becomes really obvious with a specific
example. Imagine a scrum team building a
new onboarding flow. Every week before
backlog refinement, someone has to do
the same messy prep. You read the
customer tickets. You check the PRD. You
look at the design changes. You review
the backlog. You pull the pain and you
turn it into acceptance criteria and
dependencies and tickets. It's real
work. It's a lot of product managers
weeks. So the PM starts to build a story
prep agent to help themselves. And the
first vision is simple. It's going to
read the current PRD, the design brief,
the tag support tickets, the backlog,
and a few examples of good stories. And
then it's going to prepare a refinement
packet. Not final tickets, just a
packet. It's going to say, "Here are the
candidate stories. Here's the customer
evidence. Here are the acceptance
criteria. Here are the dependencies.
here are the assumptions I'm making and
here's the open decisions my human needs
to make. It's a great agent job to start
with. You can do that in codeex or
claude, but now imagine the team starts
relying on that packet every week. It's
now a team agent. Now the agent is
shaping the sprint. If the PRD is old,
old product assumptions are going to
enter real work. If the support tickets
are noisy, agent oversight start to
matter. If the design changed yesterday
and the agent didn't pick up on that
because of a job conflict, that's going
to matter. It's not going to be an
explosion or a robot takeover, right?
but it's going to be an issue for the
team. So what does ownership look like
in that context? The product manager
owns the job because the product manager
owns backlog quality. The operating team
has to own the operating agent. And the
maintenance loop is not complicated. So
what does ownership look like? The
product manager owns the job and is the
single threaded owner that should care
about whether the agent works or not.
That simple. The engineering lead can
help with technical assumptions. The QA
team can help with testability. The AI
team might help with tooling in some
cases and the maintenance loop for that
agent, it's not as complicated as it
might sound, even though it's an agent
that does a lot of work. Before
refinement, the agent prepares the
packet and the PM should review that.
During refinement, the team can notice
where it helped and where it confused
the discussion. After the sprint, the
owner, the PM should check a few
stories. Did engineers have to rewrite
them? Did QA understand them? Did
dependencies show up late? If you can
fix the inputs to the agent and change
your output, you can fix the system. So
remove the stale PRD, add a better
example, change what it is allowed to
read. That's care and feeding. And
that's how you go beyond prompting and
start to work like you're in 2026 with
agents and loops. Prompting is asking,
agent work is giving context and care
and feeding to the agent so it can do
its job. There's a big difference
between asking write acceptance criteria
for this feature, please, and giving an
agent a job. The job might look like
read the PRD, the last 20 support
tickets, the design brief, and our three
best backlog examples. Draft the stories
for refinement, attach the customer
evidence, mark assumptions, and don't
create juror tickets. Put everything
into review so I can look at it first.
Do you feel that difference? One is a
prompt, and the PM may feel more
productive, but it may not hit the team.
The other is a job with sources and
boundaries and output and a review loop,
and it absolutely affects the entire
team. And this is the move that most
people need to make in 2026. From
prompts to jobs. Now, if you're thinking
about this as a team leader, the
question becomes bigger, but it doesn't
need to become more abstract. This is a
danger spot where agents can go unowned.
Nobody owns the AR agent that summarizes
performance notes before calibration.
So, nobody checks whether it's pulling
from stale manager feedback or
flattening important context. That's a
real example, by the way. Nobody owns
the recruiting agent that drafts
candidate scorecards. So, no one's
accountable when it drifts. No one knows
the support triage agent. So refund
policy may be stale and may be
misapplied. You see the same thing
cropping up all over the business when
you have projects that parachute in from
an AI team and that end up unowned in
those target teams. Finance can have the
same thing, right? You're going to need
an agent roster as a team lead. Not a
big database, right? Just a list of
agents your team is using. This is our
story prep agent. This is our release
note agent. This is our customer call
summary agent. This is our PR review
agent. And for each of them, you should
know who the owner is. You should know
who what the sources are. The agent can
look at what the permissions are, the
review cadence, and the known failure
modes. And that's it. Because once the
agent is visible, you can manage it. As
a team leader, you can manage it. If
it's invisible, it just becomes this
weird shadow process where work is
moving through tools and nobody can
explain how the output got there. And
there's these anecdotes that people will
bring up in performance reviews that
say, "I'm AI native." Now, that's not
productive. And I get it. The energy
right now is build, build, build build.
But if every ambitious person in the
company creates three agents, you don't
necessarily have more productivity if
you don't scale that ownership. I love
the build energy. It's not bad. It's
powerful, but powerful things need
owners. And if you want the simplest
version of this, here is the owner card
that you should take with you. For every
agent that matters, write down the name,
the owner, the job, the sources, what it
can do, what it can't do, and the
failure mode you need to watch for. I
said that was a spreadsheet for team
leaders, but that card can also be the
agent ownership card for individuals.
Literally, you can make a Slack channel
with a bunch of agent owner cards where
you can say, "This is my agent. This is
what it does." And like people can share
them. And this is something where if
you're trying to create agentto agent
collaboration in the company, which a
lot of people are doing through Slack,
you kind of need a way for the humans to
understand what these agents are doing
at the top and to have almost an agent
registry so the humans can understand
what's going on. And yes, this is on
purpose a little bit like Google's ATA
protocol. Google's ATA protocol assumes
that agents need introduction cards like
that to each other. That's great, but
what about the humans? We need a sense
of ownership almost like a certificate
for the agent. And I find that companies
that have that mindset, regardless of
what they call it, do better because
they take agent ownership more
seriously. And they should than agent
building. Just building a new agent, you
shouldn't get credit for these days.
Owning an agent and using it to deliver
value, that's what you should get credit
for. And I think this is what catching
up with AI actually looks like today.
It's not having the most agents. It's
not knowing every tool. It's not winning
a vocabulary argument about loops and
evals. It's having a small number of
agents that you own and that deliver
real value in workflows. You know what
they do. You know what they eat. You
know what they can touch. You know how
you review them. You know when to trust
them and when not to do. They're your
pets. You know what work you delegated
and what responsibility you kept. This
is the grown-up version of Asian
adoption. Ironically, as a child of the
80s and 90s, Pokemon prepared me well.
Prompting was the first skill for us,
right? Back in 2023, we had to learn how
to ask better questions and and that's
still a useful skill because it forces
us to articulate. Delegation was the
next skill. We had to learn how to hand
over real work. That's a very 2025
thing. Maintenance is a 2026 skill
because useful agents become our
responsibility. So, here's your decision
rule. Very easy. If a system can read
important context, produce work you act
on or your team acts on, touch a
workflow other people depend on, it
needs an owner. Now, if it's yours, you
own it. If it belongs to the team, the
team needs to name one person as an
owner. And if nobody's willing to own
it, it probably shouldn't be doing
important work, and you should think
about decommissioning it.
Look, I put the deeper checklist and the
owner card and the whole guide for how
to sort of develop an agent registry at
the company or frankly for you, your
Pokemon collection agent set over on
Substack because that works much better
as a written guide. But the mental model
really is this simple. Stop asking only
whether you can build an agent. Start
asking whether you can care and feed it.
Every agent needs an owner. Not because
agents are bad, because useful agents
must become part of our work in 2026.
That is the bar. So, take care of your
little Pokemon agents. I hope this has
helped clear up a lot of the buzz and
the confusion around what an agent is
and what our job is with agents in 2026.
I'll see you next time.