What most people get wrong about AI agents
The mindset behind AI agents that nobody is talking about.
I checked on the agent I had set up a few days ago. It had been running quietly in the background, doing its work. When I opened it, it showed me what it had done. Tasks completed. Each one ticked off. I felt exactly like a parent checking that the homework is done.
That feeling is the whole essay. Not the technology. Not the steps. The feeling. The moment you realise something you built is working without you watching it. That your intention, clearly expressed, became action you did not have to take yourself.
This is what I want to talk about. Not how to build an AI agent. Not a tutorial with steps and screenshots. Something harder. The mindset you need before you write a single line of anything. The understanding that separates people who build systems that work from people who build systems that impress no one, including themselves.
Because most people are getting this wrong. And most companies already know it.
This has always been about control
Before you start, understand what you are actually after.
Organising things, planning things, building systems that run predictably. None of this is really about efficiency. It is about control. The assurance that tomorrow will resemble today in the ways that matter. That the bills will be paid. That the work will get done. That the life you are building will hold its shape.
There is a reason so much of Western culture suffers from stress. And there is a reason the people trying to decompress keep being told to live in the moment, to accept chaos, to surrender to what will be. Que sera, sera. For most of us, this is almost an impossibility. You cannot relax into an unseen future when the mortgage, the bills, the life you are holding together, all depend on decisions with causes and consequences. The anxiety is not irrational. It is the correct response to real uncertainty.
We automate for the same reason we make lists and set alarms and build routines. To hold the uncertainty back a little. To create small pockets of predictability in a world that does not offer them by default.
I think about what Frederick Winslow Taylor did to work. The factory model. Every motion measured, every task broken into its smallest repeatable unit, every worker optimised for output. It gave us productivity and it gave us alienation in equal measure. And I look at practices like DevOps, Agile, the whole vocabulary of modern organisational efficiency, and I see the same logic in softer clothes. The factory did not disappear. It learned to use words like flow and iteration.
These things we call AI agents are the newest expression of that same impulse. Control, at scale, dressed up as intelligence. And there is a particular kind of person, usually an engineer, who will tell you proudly that they no longer write code themselves. That their hundred agents are busy doing things, all managed from a phone. I find that image genuinely funny. And also worth examining.
Someone somewhere said we would sell intelligence by the metre. A commodity. Like water, like electricity, like the oil before both. And I think they were right about the direction, even if the destination is still unclear.
I could have written this essay as a tutorial. How to use any of the popular tools. That would have been easier to write and probably easier to find. But I refuse to join the chorus of “just use it or lose it.” The pressure to adopt without understanding. The anxiety that if you pause to think you will fall behind. I struggle with this myself. Genuinely. Because if I stop thinking carefully about things, if I outsource the reasoning as well as the execution, I am not sure what I am left with. The organ in my skull that helps me navigate this world is not something I want to hand to something that, at this point, cannot comprehend reality. And yet that same thing is now shaping decisions that are ending some people’s lives. Not metaphorically.
And it is worth saying plainly: this conversation is happening mostly in the West, among people who can afford twenty dollars a month, or two hundred. But when I speak with someone from Nigeria, Mumbai, Brazil, I notice something different. They squeeze every drop. They think carefully before passing anything to an AI, because they cannot afford to waste the exchange. There is no superfluous prompt. No casual experiment. The constraint sharpens them. It is a remarkable thing to witness, and an uncomfortable one, because it shows that the creativity this technology promises is already unevenly distributed before a single agent is built. Gen Z, meanwhile, has grown up assuming the web is just there, like oxygen, which makes the dependency harder to see and harder to question.
This is the same behaviour companies have normalised on a larger scale. Move fast. Adopt early. Work out the value later. And when the platform goes dark, when the credits run out, when the service changes its terms, the dependency is already built in. I know people building entire products on credits they do not own. I see competitors sharing cloud infrastructure with the very companies they are competing against. It is a strange tangle when you look at it all at once.
It is here to stay. How it unfolds, I believe, depends on whether ordinary people decide they have a voice in it. Not just technologists. Not just investors. Everyone who lives inside the systems being built.
What you actually need to understand to get the best from an automation agent
Given all of that, what do you actually need to understand to get the best from an automation agent?
Start here: they are still flawed. Mistakes will happen. The question is whether you have built something that makes mistakes visible and correctable, or something that makes them invisible and compounding. Everything that follows is an answer to that question.
The word “agent” is getting in the way
Let me remove a word that is causing confusion.
When people hear “AI agent” they imagine something sentient. Something making decisions with intention. Something that understands you. Something, if we are honest, that might care about getting it right.
It does not.
What you are building, in almost every case, is an automation agent. A system that takes instructions written in natural language and executes them against real tools, real data, real consequences. The “AI” part is the interpreter. The part that reads your instruction in plain English and translates it into action. But the action itself is deterministic. It follows a path. Your path.
Understanding this distinction changes everything about how you build.
Here is the human problem underneath it. We anthropomorphise relentlessly. We name our cars. We thank the GPS when it finds us a parking space. We apologise to the chair we walked into. We have always done this. It is not stupidity. It is how human perception works. We are pattern‑matching animals who find faces in wood grain and intention in weather.
The risk is not that you find your agent charming. The risk is that you extend it the kind of trust you extend to a person. That you stop auditing its output because it has been reliable lately. That you assume it understood what you meant rather than checking what it did. An automation system you trust like a colleague is an automation system that is one edge case away from a problem you did not plan for.
Keep a useful distance. Not cold. Not suspicious. Just clear‑eyed. You are the architect. The system is the scaffolding. The clay and the chisel. You are the one who knows what the shape should be.
Before you build anything, understand what you are automating
The most common mistake I see is people who start with the technology.
They install the tool. They connect the API. They write a prompt. They run it. Something happens. It is not quite right. They tweak the prompt. Run it again. Something else happens. They are now two hours in, iterating on something they never properly defined.
This is not building. This is tinkering. Tinkering has its place. But tinkering with no map produces nothing you can rely on.
Before you build, you need to understand the process you are automating with the same depth you would use to explain it to a new hire on their first day. Not the high‑level version. The actual version. Every edge case. Every exception. Every point where a human would normally make a judgment call without naming it as a judgment call.
Ask yourself this: if I wrote down every step of this process on a piece of paper, would a careful twelve‑year‑old be able to follow it without asking me a single question?
If the answer is no, you are not ready to automate it.
This is not about making things complicated. It is about making the invisible visible. Most processes we run daily are invisible to us precisely because we have done them so many times. Our hands know the steps. Our judgment fills the gaps without being asked. Automating an invisible process is how you get a system that works perfectly in normal conditions and fails silently the moment something unusual happens.
Why are you actually automating this?
This is the question most people never ask. And it is the one that matters most.
The honest answer, for many people, is this: because it feels like the right thing to do right now. Because everyone is talking about agents. Because the tools exist. Because it seems faster.
That is not a reason. That is a feeling. And building a system around a feeling produces a system that solves a problem you may not actually have.
Automating a broken process does not fix the process. It accelerates the breaking. You get the same wrong output, faster, at scale, with less visibility into where it went wrong. That is not progress. That is expensive noise.
Before you write a single instruction, you need to be able to answer one question in two sentences or fewer: what specifically changes for a specific person if this works? Not in theory. Concretely. What do they stop doing. What do they start doing instead. What does that free them for.
If you cannot answer that, stop. Do not build yet. Watch the process run three more times with human eyes. Talk to the person doing it. The real answer is almost always in the gap between the process as documented and the process as actually lived. That gap is what you are automating. Not the steps. The gap.
Prerequisites, requirements, and the trial that actually teaches you
There is a framework I return to every single time I build something new. Not because it is elegant. Because it has saved me from myself more times than I can count.
Three questions before anything else.
What does this need to have access to? These are your prerequisites. Data sources, credentials, file paths, external services, permissions. Write them down. Every single one. Because you cannot build a system around a dependency you have not named. And you cannot test a system against a dependency you discovered halfway through.
What must this system do, and how must it behave? These are your functional and non‑functional requirements. Functional is what it does: produces a summary, sends an email, updates a record. Non‑functional is how it does it: responds within a defined time, never contacts someone without explicit confirmation, logs every action so you can audit it later. The non‑functional requirements are where most people get caught. Easy to forget until the system does something you never told it not to do.
Then you trial.
Not the full system. A small piece. The most uncertain piece. The part you think you understand but cannot prove yet. You run it with real data. You watch what it does. You do not assume. You observe.
Trialling is not a step in the process. It is the philosophy of the process. The assumption that what you think will happen and what actually happens are different things, and the only way to close that gap is to create the conditions where reality can surprise you.
Most people rush this stage because they want to see the finished thing. The finished thing is the wrong goal. The goal is a system you trust. Trust is earned through iteration against reality, not through theoretical correctness.
One more thing about trialling. Modern agents can persist. They can keep going, trying different approaches, circling back, until they arrive at something that looks like a solution. This is now genuinely possible. It is also one of the more misleading features if you do not understand what it means.
A plausible solution and the right solution are not the same thing. An agent that finishes is not an agent that finished correctly. Before you run anything, define what correct looks like. Write it down. Because a system with no definition of done will produce a definition of its own. And you may not recognise it when it arrives.
Tokenisation is not a technical detail. It is a budget.
Here is the thing nobody explains when they talk about agents at scale.
Every instruction you give your system, every piece of history it carries forward, every document you ask it to hold in memory while it works, has a cost. Not just in money. In reliability. In the probability that your system reaches the end of the task without pausing, degrading, or stopping in a state you did not plan for.
Think of it like a meeting room. You can invite as many people as the space allows. But the more people in the room, the harder it becomes to make a sharp decision. Too many voices, too much context, and the output blurs. The model works the same way. Push too much into its context and the precision softens. Hit the limits of your plan and the task stops mid‑run. You come back to find it at step four of twelve. The work is incomplete. The data is in an intermediate state. Whatever it touched is now partly done.
I have seen well‑designed systems fall over the first time someone ran them on real data at real volume. The demo worked. Production did not. The difference was almost always the same thing. Too much history carried forward. Too much documentation included because it might be relevant. Too little discipline about what actually needed to be in the room.
The practice is simple in principle and requires constant attention in execution. Include only what the model needs to do the current step. No more. A focused, scoped instruction set is not a limitation. It is the architecture of a system that actually finishes what it starts.
Your local setup is your independence
There is a version of AI agent infrastructure where everything lives in someone else’s cloud. Their model, their servers, their pricing, their uptime, their terms of service.
That version is a rental agreement. And like any rental agreement, the terms can change.
I want to argue for ownership. Or at least for an architecture that behaves like ownership.
Running models locally is more possible than most people realise. You can run capable open‑source models on hardware you already own. Not the most powerful models available, but powerful enough for many real tasks. Summarisation. Classification. Extraction. Conversation with your own documents. A home server or a reasonable laptop is enough to begin.
But the larger argument is not about which model you run. It is about your knowledge base.
Your knowledge base is the information you have curated, organised, and made available to your agents. Your notes. Your processes. Your reference material. Your institutional memory. It is what transforms a general‑purpose model into a system that knows your specific context. That speaks your language. That understands your constraints without being told them each time.
Most people build their knowledge base inside a tool. Inside a platform. Inside someone else’s structure. And when that platform changes its pricing, or shuts down a feature, or gets acquired, the knowledge stays but the coherence goes. You have to rebuild. Or you lose it quietly over time.
Here is the design principle that changes this. The knowledge base is the soul of your setup. The model is interchangeable.
If you build your knowledge base in open, portable formats—plain text, Markdown, structured documents you own—you can swap the underlying model whenever a better one arrives. You can move from a cloud provider to a local model. You can upgrade without starting over. Your agents will still behave consistently because the knowledge that shapes them travels with you.
Back it up. Version it. Treat it the way you would treat the original manuscript of something you could not rewrite from memory. Because you could not. That accumulation, the way you structured it, the connections you drew between pieces, the decisions you recorded, that is yours. No model produces that. You did.
The possibilities you cannot see yet
I want to give you two pictures. Not to impress you. To show you that the ceiling is higher than you think.
The first is a house. Lights that adjust when the sun moves. Heating that learns the difference between a working day and a slow morning. A front door that knows your rhythm better than you do. A voice that can tell you what is in the fridge, book a table, set a reminder, send a message, and do it all from a single sentence spoken out loud. None of this requires expensive hardware. None of it requires a developer. It requires someone willing to understand what they want, define it clearly, and build it in pieces.
The second is a working day. Emails read, summarised, and sorted before you open your laptop. Meeting notes structured and distributed before the next meeting starts. Reports drafted from data you already have. Research aggregated from sources you trust. Follow‑ups written in your own voice. None of this requires you to surrender your judgment. It requires you to define your judgment clearly enough that a system can apply it on your behalf.
The possibilities most people cannot see are not the dramatic ones. They are the quiet ones. The hour you get back on a Tuesday. The decision you make faster because the context was already prepared. The task that used to live on your list for three weeks because it required a specific kind of focused attention, now done in the background while you do something only you can do.
We are still in the infancy of this. We set up a few toys and there they go, doing their things, oblivious. Some get it right. Others keep bumping into the same wall and we have to go and turn them in a different direction. The parent checking the homework. That is where we are. Not at the end of something. Very much at the beginning.
The living book
Books are boring until you open them. There is something that happens when you start reading, when certain passages come alive in your mind, when you find yourself inside a world built from ink and paper. Sometimes a book changes your life entirely. But a book is just there, waiting. It is up to the reader to start the discovery.
We have always purchased books to feed us knowledge. We carry them. We annotate them. We return to them when we need the specific thinking they contain. A good book does not just inform you. It shapes the way you see a problem. It is a mind made portable.
Think about an agent the same way.
Every instruction you write into your system is a page in that book. The prerequisites are the index. The requirements are the argument. The knowledge base is the library the book draws from. What you are building, when you build it with intention, is a book that does not sit on a shelf. A book that acts on what is written in it. A living book.
The difference between a book and an agent is not intelligence. It is action. The knowledge was always there. What changes is that now it moves.
This framing matters because it changes what you invest in. You do not invest in the model. Models change every six months. You invest in the writing. In the quality of what you put into the book. In the clarity of the instructions, the precision of the requirements, the integrity of the knowledge base. That is what lasts. That is what carries forward when everything else upgrades around it.
A badly written book is still a bad book, regardless of the printing technology. A poorly defined agent is still a poorly defined agent, regardless of how powerful the model underneath it becomes.
Write the book well. The rest follows.
Most companies already expect this of you
Here is the thing I want you to sit with.
The skills I have described in this essay are not advanced. They are not reserved for engineers or technical architects or people with a specific background. They are, at their foundation, the skills of someone who thinks clearly about process, communicates precisely, and understands that a tool is only as good as the intention behind it.
And most companies, right now, are building teams around exactly these skills. Not teams of people who can write code. Teams of people who can think about what needs automating, define it properly, build it incrementally, and maintain it with judgment.
The same way we once expected people to know how to use a spreadsheet. To use email. To navigate a database. We did not expect everyone to build those tools. We expected everyone to use them with competence. Agents are next.
The people who understand this now are not ahead of a trend. They are ahead of a requirement. In three years, being able to define an automation agent, scope its requirements, trial it responsibly, and maintain it with the right level of oversight will be assumed. The way typing is assumed. The way knowing how to search for information is assumed.
The gap between people who understand this and people who do not is not primarily technical. It is a gap in how clearly they can think about what they are trying to do and why. Technical literacy helps. But it is not the foundation. The foundation is the ability to make the invisible visible. To ask the right question before reaching for any tool.
You have always had that ability. This is about applying it somewhere new.
The question I cannot answer for you
When you build a system that works well, something shifts. Tasks disappear from your awareness. Things happen in the background. Reports arrive. Messages go out. Data moves. And you are elsewhere, doing something that requires you more directly.
That is the promise. And it is real. The drive to do things with less effort is not laziness. It is one of the oldest human instincts there is.
But there is a version of this that goes wrong quietly. Where the system requires as much attention to maintain as the task originally required to do. Where you spend the hour you saved debugging the thing that saved it. Where the invisible work is not gone, it is just harder to see. And harder to see means harder to fix. Social media understood this perfectly. Easy to join, easy to use, but your attention is required every single day to keep getting anything from it.
The question is not whether to build. The question is whether what you build is genuinely serving you, or whether you are now serving it. I understand why certain people feel the urge to replicate someone else’s cornucopia, especially if he or she is a reference in the field. But why? Start simple and the rest will develop in response to real challenges.
A living book that demands constant revision is not a tool. It is a responsibility you chose. Sometimes that is the right trade. Sometimes it is not. The only way to know is to keep asking why you built it, what it actually changed, and whether the answer still holds.
I have a friend who is remarkably good at home automation. What he has built is genuinely impressive. But it is not uncommon for him to call me when things go wrong. The television that will not switch on from his phone. The front door that, for some odd reason, would not open one afternoon. The window blinds that started operating by themselves. The heating that turned on in the middle of summer. The more he automated, the more threads there were to pull, and the harder it became to know which one had come loose.
When something breaks in a simple system, you find it. When something breaks in a system of dependencies, you spend an afternoon wondering where to start.
I checked on my agent before I finished writing this. Still running. Tasks still completing. Homework still done.
I still think it is worth building.
I am just more careful now about what I ask it to hold.
About the Author
Tino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.
This essay is a reflection on what it really means to build and use AI agents, framed around the mindset rather than the technology. At its core, I argue that automation is ultimately about control, clarity, and responsibility, not about tools or “hacks.”
The real skill is not coding agents, but thinking clearly enough about work and responsibility that you avoid building systems that impress on the surface but quietly fail or reverse‑capture your time.
I’m curious how others draw the line between useful automation and dangerous dependency. What do you refuse to automate?