AI Agents, and What Do They Even Do?
The first sign something was wrong wasn’t a crash or an error message. It was how hard it became to describe what was actually wrong.
No hallucinations. Not (always) confident nonsense dressed up as fact. What I was getting was stranger than that. The agent would start on a task, make a reasonable first move, then just... produce garbage. Losing the thread halfway through. Writing a snippet of code or calling a tool that looked right on its own, but made no sense in the context of what I’d actually asked for. It would finish, return something that held together syntactically, and be almost entirely useless.
Thanks for reading Hinde Sight Dev! Subscribe for free to receive new posts and support my work.
Re-prompting felt like arguing with someone who was being perfectly logical about the wrong problem. I remember one Tuesday afternoon specifically; I was cold coffee and stale air, swimming through treacle trying to explain why it was wrong, getting nowhere with a counterpart that insisted, not to my face but in its output, that it wasn’t. Hours of verbose code I’d need to untangle manually. The kind of session where you slowly start to feel like Alice, tumbling into a hole built from every open-source repo and Stack Overflow thread ever written.
“Getting pulled down the agentic rabbit hole is a rite of passage for AI-empowered developers.”
My first instinct was to blame the model. That’s where most people go. It must be underpowered, or the context window must be doing something odd. So I swapped things around, tried different models. The failures kept coming in slightly different shapes. Rabbit holes kept opening up, swallowing a frustration-filled afternoon each time. Something had to give.
What even is an agent?
The term gets thrown around so much now it’s nearly lost all meaning. I spent days searching for a definition that didn’t sound like marketing fluff until I finally stumbled on this one, which eventually made things click: an agent isn’t a smarter prompt. It’s an LLM with access to tools — one that can make decisions based on your prompt, act on them, then assess what it just did and carry on, without you asking it to.
The concept isn’t new. Classical AI has talked about rational agents for decades — perceive the environment, decide on a action, execute it, observe what happened, repeat. What’s changed is that the perceiving and deciding can now be handled by a language model, and the acting can be wired up to whatever you connect it to: APIs, file systems, browsers, databases.
“An agent is an LLM that acts on its own output — then keeps going.”
That loop is what separates it from standard prompting. A regular prompt is one shot: input in, output out. An agent reasons iteratively, each step informing the next, the model deciding what to do rather than just answering a question. It’s supposed to handle tasks too complex for a single context window by breaking them apart and working through them. But in practice, if there are more steps, there are simply more places for a rabbit hole to open up.
My first real encounter with one
The task wasn’t exotic. I wanted the agent to build a fairly simple CRUD API service — with some specific requirements for our security approach and how we handle query sizes. I’d expected it to gather context, make decisions, build the thing, check itself, and report back. A decent junior engineer would have it done in a week.
The requirement was clear enough: all endpoints should use POST. No long URLs outing the details of what we’re querying. I spelled it out in the prompt. I included example services, all using POST throughout. Didn’t matter.
The agent built it with standard REST methods. GET, PUT, POST, DELETE — textbook. It simply couldn’t accept there was another way. No amount of re-prompting, clarifying, or pointing at the examples changed anything. It kept producing what it believed a CRUD service should look like, and it was certain about it. That’s the bit that gets you. Not confused. Not hedging. Certain, wrong, and remarkably hard to shift.
The stubbornness wasn’t the worst part. The worst part was how long I kept pulling on the same rope. Another prompt, another model swap, another hour gone. Rabbit holes have a particular quality: they don’t feel like going in circles, they feel like progress. Each attempt is almost right. Close enough to keep you going, far enough from right to keep you stuck. You surface having lost an afternoon and gained very little clarity on what went wrong.
What made it worse: the output wasn’t broken. It would have worked. Technically sound, syntactically fine, exactly the kind of service you’d find in any tutorial or starter repo. Built by someone who’d read every textbook and none of our internal standards. It didn’t fail loudly — it failed quietly, confidently, and at complete odds with how we actually build things. Our conventions, our security approach, our architectural decisions — none of it landed. The agent had absorbed the most common patterns the internet had to offer, and common was exactly the problem.
I hadn’t hit a model problem. I’d hit a design problem I didn’t yet have the language to describe. That’s a harder hole to climb out of, because you can’t fix what you haven’t named. And honestly? I’m still not sure I’ve fully named it yet.
Thanks for reading Hinde Sight Dev! Subscribe for free to receive new posts and support my work.