For quite a while now, I've had the feeling that AI agents are surrounded by this mystical aura. Nobody really knows what they're doing, they're pr...
For further actions, you may consider blocking this person and/or reporting abuse
Happy Birthday Sylwia :D
Awwww thanks Francis 🩷🥰🤩☺️
The "Steve reviews himself" moment is the most honest thing in this article — an agent auditing its own diff is exactly where I'd expect the most confident-sounding hallucinations, because the model has both the strongest prior and the least external ground truth. I've seen the same failure mode when static analysis tools try to lint autogenerated code: they flag real patterns as violations because the generated output follows conventions the rule never anticipated. The
forloop cap instead ofwhileis a good instinct too; bounded iteration is one of those things that looks overly cautious until the first time you watch an unbounded agent loop burn through your token quota at 2am.Exactly! 😄 It's a bit like asking an author to review their own book. Of course, it's not quite that extreme here, since my super-simple agent is only reviewing a diff rather than generating the code itself, but the idea is very similar.
And yes, the loop cap turned out to be surprisingly important. Even in a tiny demo, retries and bounded iteration are a must! Especially when you're trying to save a few dollars on tokens by using the cheaper models... like I was. 😂
Hey Sylwia, happy belated birthday! 🎉 Steve reviewing himself was probably my favorite part 😂 It's funny how AI agents seem like magic until you realize it's mostly loops, tool calls, retries... and hoping Gemini doesn't reply with a 503 😄 Great read!
Thank you so much! 😄 Hahaha, maybe it's actually a good thing that Gemini throws a 503 every now and then. 😂 It helps keep us from becoming too optimistic about LLMs. Nothing brings you back to reality faster than your "intelligent agent" suddenly discovering that the model is unavailable. 😄
First of all, happy birthday!! 🎉 The GitHub star is already in place! 😄⭐
Great article, as always, I really enjoyed reading it!
Before I wrote my first agent, I thought it would be some kind of rocket science. But as you wrote, it’s actually pretty simple and straightforward and we don’t really need any special dependencies.
I also have to confirm that using the free Gemini models these days is painful. I encountered a lot of 503 errors and had to switch between models quite often. I think Gemini 2.5 Flash was the most stable one.
This is clearly an AI agent, but have you also noticed that many people now say they’ve created an AI agent even when it’s just a simple prompt file or a skill that runs in VS Code, for example? It feels like everything is an AI agent now. 😄
P.S. Why Steve? Why not Piotr, Krzysztof, or Tomasz? 😄
Thank you so much for the birthday wishes and for the star! 🤩
And yes, exactly! These days, everything is an "AI agent"... just like everything suddenly became "AI-powered." 😂
What's funny is that if you read enough technical articles about agents, one pattern keeps coming up over and over again: our main job is basically to keep the LLM on a very short leash. 😄 Most of the engineering effort goes into making sure it doesn't do something creative at the wrong moment.
And you're absolutely right about Steve! 😂 Why didn't he catch that during his own review? Maybe I should have named him Grzegorz or Przemysław instead. We have much more challenging names for foreigners than Steve. 😄
Exactly! The problem is that we developers couldn’t even keep fully deterministic code under control: bugs everywhere! 😅 And now we have to do it with probabilistic output. It’s going to be quite a ride in the future.
Grzegorz, that’s the one! 😂
Hahaha, exactly! 😂 Maybe Steve needs to retire and make room for a grumpy reviewer from Eastern Europe. 😄 Grzegorz would be a perfect candidate. I might actually have to consider that for the next part of the series!
Okay, now I’m really looking forward to it! I can’t wait to meet the grumpy reviewer Grzegorz! 😂
This resonates deeply — and I think the distinction between 'agent' and 'workflow' is one of the most important conversations we're not having openly enough.
I've been building AgentShare (an MCP server for Solana DeFi data) and running OpenClaw agents on Railway. The hardest part isn't the LLM reasoning — it's designing the control plane that decides when to let the agent roam and when to lock it into a deterministic path.
What I've found: the best agents are not the ones with the most autonomy. They're the ones with the most structured autonomy — clear guardrails, explicit risk caps, and a feedback loop that detects when the agent is drifting off-course.
The dirty secret isn't that demos are fake. It's that real agents are boring to watch. They spend most of their time checking constraints, validating inputs, and logging state. The 'magic' is a tiny fraction of the codebase.
Would love to hear your take on how we, as builders, can be more transparent about this without killing the excitement around agentic systems.
Exactly! 😄 "Agent" sounds incredibly cool, but in practice, the hardest part is usually everything around the agent. Building the actual agent loop is often the easy bit. The real engineering is designing the constraints, the tooling, the validation, and making the whole thing predictable enough that you'd actually trust it.
As for being more transparent without killing the excitement... honestly, I have no idea either. 😂 The more technical articles I read about agentic systems, the less excited I become. Maybe that's inevitable, once you understand how the magic trick works, you start appreciating the engineering instead of the illusion. And I think that's okay. Good engineering is still pretty exciting, just in a different way.
That's beautifully said — 'appreciating the engineering instead of the illusion.' I think that's the mark of a mature builder.
I've noticed the same shift in myself while building OpenClaw agents on Railway. The moment I stopped chasing 'autonomous magic' and started focusing on survivability — retries, state recovery, and deterministic fallbacks — the system actually became more reliable. And ironically, more useful.
The 'magic' is still there, but it's no longer the centerpiece. It's just one component in a system designed to fail gracefully.
Maybe the next phase of agentic systems isn't about better reasoning, but about better forgiveness — designing agents that know when to ask for help, when to pause, and when to admit they don't know. Do you see that as a direction worth exploring?
I really like that last idea too. I think one of the most valuable capabilities an agent can have is knowing when to say, "I don't know," or "I need help." That's not a weakness—it's good engineering.
Maybe that's exactly where we're heading: taking advantage of what LLMs are good at, while surrounding them with deterministic systems that keep everything under control. The intelligence doesn't have to be deterministic, but the system around it should be as much as possible.
I have a feeling this is going to be one of the most interesting areas of software engineering over the next few years. Not because the LLMs themselves will become dramatically smarter overnight, but because we'll get better at building reliable systems around them. 🙂
Happy Birthday, Sylwia 🥳🎂
I simply have to ask: Why "Steve"? Why 15 years of experience? Is that the sweet spot of technical expertise 🤔😂😉
Have a great day!
Thank you so much!
As for Steve... we've already concluded in another comment thread (together with @gramli) that something clearly went wrong there. Steve failed to properly review himself! 😂 So in the next iteration he'll probably be replaced by Grzegorz, a grumpy reviewer from Eastern Europe. 😄
And the "15 years of experience"... well, that was basically me thinking, "Surely if someone has 15 years of experience, they must be wise!" 😂 It's a bit like writing a prompt that says at the end "make no mistakes." You're absolutely save then 🤣
“Surely if someone has 15 years of experience, they must be wise!”
That’s a dangerous conclusion, just look at me. I have roughly 15 years of experience, and I’m about as wise as a blade of grass. 😂😂
Honestly, I could be Grzegorz: a grumpy developer from Eastern Europe, just without the wisdom. 😂
Hahaha, I don't know about that! 😂 In my experience, the people who say they don't know much are often the ones who actually know quite a lot. The really dangerous ones are the people who are absolutely convinced they already know everything. 😄
Happy birthday, Sylwia! 🎂 "Steve reviewing himself" is the funniest line in this...automating yourself out of a job, one diff at a time.
your for loop cap for token safety is the small-scale version of something I've been deep in lately — rate limits and spend caps for agents that live past one session. same instinct, just before it needed to survive a restart.
curious if the MCP follow-up gives Steve any memory across reviews or if he stays stateless on purpose.
Thanks so much! 😄 I couldn't have picked a better birthday project.
Giving Steve memory across reviews is actually a great idea for a future iteration!
And yes, that's exactly how I see the rate limits and spend caps too. It's the same class of problems, just at a different scale. My goal with this little agent was to show that if you understand these challenges in a tiny, 80-line project, you won't be surprised when they show up in much larger, production-grade agent systems. The details change, but the underlying engineering trade-offs are remarkably similar. 🙂
the trade-off doesn't change shape, just the cost of getting it wrong. At 80 lines, a broken loop cap burns a few cents in Gemini tokens.
At production scale, the same missing guardrail means someone else's API key draining overnight. Same problem, bigger blast radius which makes the case for building the tiny version first even stronger, since the mistake stays cheap while you're still finding it...
Exactly! That's why I'd much rather make a mistake on a tiny agent than on a production one. I'd rather discover that my while loop never terminates after burning a few cents than wake up to a production system that's been running all night.
What's also interesting is that my little agent is intentionally harmless. It can only read things, it can't modify files, execute commands, or do anything destructive. And yet, even in that scenario, you immediately have to think about security. What if someone accidentally gives it access to a .env file? Suddenly, even a read-only agent needs guardrails.
So if these concerns already exist in an 80-line toy project, you can imagine how much more important they become once an agent is allowed to perform real actions in production. That's exactly why I think building the tiny version first is so valuable. 🙂
The 80 lines really are the whole thing, which is why I like this post. The part I would push on: your cap of 10 is a cost control, not a correctness one. It fires the same whether Steve solved it in three steps or spent ten re-reading the same file with slightly different reasoning. The cheap upgrade is a progress check: hash the tool name plus normalized arguments per step and stop on repeats. An agent going in circles burns the same budget as one doing work and looks identical in the logs.
Second thing, on read-only being harmless: with getFile and listFiles, repo content is now inside the loop. Read-only protects your filesystem, not Steve's decisions. Text shaped like instructions sitting in a file is a real problem for a code reviewer specifically, because the thing it reads is exactly the thing an attacker controls in a pull request.
Thanks! And yes, that's absolutely true!
If we really started digging into it, we could probably find many, many more issues with my little agent. 😂 But I think that actually reinforces the main point of the article: building the agent itself is usually the easy part. The real challenge begins when you try to tame all that non-deterministic behavior and turn it into something reliable, predictable, and safe.
That's where most of the engineering effort ends up: and where the interesting problems begin. 🙂
Exactly. And the thing that makes that engineering hard is that the ground moves under you: the same input can pass today and fail next week because the model changed, so you cannot lock behavior down with a single assert the way you would with deterministic code. What ends up working is treating the agent like a flaky external service you do not own. You pin behavior with a labeled eval set and thresholds instead of exact equality, run it in CI, and gate releases on the rates moving the right way. The code around the model becomes mostly about making its non-determinism observable and bounded, which is a genuinely different discipline from writing the agent in the first place. Good post, this was a fun thread.
Exactly! And suddenly it turns out that agents aren't taking our jobs just yet. They're mostly giving us a whole new category of engineering problems to solve. 😂
I think many people overcomplicate AI agents by jumping straight into frameworks without understanding the core concepts. The reality is that an agent is often just a well-designed loop with reasoning, tool usage, memory, and decision-making. Frameworks are valuable, but knowing what happens underneath helps developers build better solutions and choose the right tools.
Thanks! 😄 I completely agree. Nobody has ever been worse off for understanding the fundamentals first. These tools and frameworks are still so young that they could change completely another ten times over the next few years. And once you understand those, it's much easier to evaluate new frameworks instead of treating them as magic.
I like this perspective. Frameworks are useful, but understanding the core agent loop first makes you a better developer. Once you know what's happening under the hood, you can choose tools based on need instead of hype.
Absolutely! That was exactly my goal with this article.
Happy Birthday, Coding Queen. 😁
Such an amazing article, it's awesome to gain knowledge from your articles. Keep slaying and publishing such awesome content.
Just leave some cake for the rest of us.😂
Thank you so much, Konark! 😄❤️ That really means a lot!
And if I could, I'd buy cake for all of you. 😂🎂
Belated happy birthday, Sylwia! 🎉
Sorry for the late wishes - I hope September turned out to be a great month after all, and that the conference situation resolved itself in your favor.
I absolutely loved this demystification. Steve is charming and pedagogically brilliant -the kind of article that makes people go "oh, that's all it is?" and actually understand rather than just copy-paste framework code.
Since you asked for thoughts, I'd love to share a few security hardening ideas for Steve's next iteration. These aren't criticisms - the demo is perfect as a teaching tool. But if Steve ever moves from "birthday demo" to "production teammate," here are some layers worth considering:
Thank you so much for this comment! Honestly, these are exactly the kinds of discussions I write these articles for.
And yes, I completely agree with every single point. Steve is missing all of those things very much on purpose. If he were already a fully production-hardened agent, he probably wouldn't be sitting on my GitHub as a free open-source demo... I'd be trying to sell him instead. 🤣
Jokes aside, I think your list actually reinforces the main point I was trying to make. Building the agent itself is the easy part. The really interesting engineering happens around it: How do we keep the LLM under control? How do we handle security, validation, observability, retries, permissions, timeouts...?
Looks like curious software engineers like us won't be replaced by AI quite so quickly after all. 😄
And thanks for the birthday wishes ☺️
I would even say that this kind of work is vital, because—with AI in its infancy and all the surrounding hype—people are starting to deploy it everywhere without even understanding how it works, let alone how to protect AI systems or defend against them. I’m glad you find my advice useful! I wish you continued success and look forward to your future articles!
Thank you! Actually, your comment gave me a great idea for a follow-up article: something like "Things You Need to Think About Before Shipping Your Own AI Agent." There are so many fantastic insights in this comment section that it would be a shame to let them disappear!
I am happy that I could be of help to you!
The model does not execute the tool...the app does.
That detail matters once the tools stop being read-only. getDiff, getFile, and listFiles are one class of risk. Editing files, sending or changing a database are another.
A prompt saying "be careful" is not enough at that point. The app that executes the tool call also has to decide whether this specific action should run.
The agent loop can stay simple. The dangerous part is where text turns into action.
And happy birthday from me too :)
Agreed — the execution layer should be the one deciding whether something actually runs.
If anything, I went the other way and deliberately left a manual gate in. The capability was all there; I just chose not to wire it up automatically.
The interesting part: that deliberate design later got documented (by an AI) as "no API", and almost got "filled in" as a missing feature.
So where I've landed is this: it's not just that the app has to decide whether to execute — the decision about why something is deliberately not done also has to be recorded as design intent. Otherwise, after a while, a deliberate constraint is very easy to mistake for an omission — especially for an AI.
(Wrote this in Chinese and used AI to translate/polish the English — not a native speaker.)
Documenting the intent behind deliberate constraints so an AI assistant does not later "fix" them is exactly the kind of good old software engineering Sylwia mentioned. Funny and a little terrifying that manual gates now need comments too.
Absolutely! And thank you so much for both the thoughtful comment and the birthday wishes!
I think that's exactly what shifts the focus. The agent itself suddenly becomes the least mysterious part. The really interesting engineering is everything around it.
In a way, it's funny because it takes AI from something that feels magical back to... good old software engineering. 😂 I think that's a good thing.
Happy birthday, JS queen ✨️✨️
hahahahaha thanks a million!!!!! 🤩
The thing that trips people up when they graduate this from a demo to something real isn't the loop — it's the append-only conversation array in Step 4. You're resending the full history every iteration, and with three filesystem tools that's exactly how it blows up:
getDiffon a big changeset, then a couplegetFilereads, and by iteration five you're paying to re-send the entire diff plus every file's contents on every single call. It's O(n²) tokens over the run, not O(n).Where frameworks actually earn their keep isn't the retry logic you mentioned — that part genuinely is trivial — it's context management: trimming or summarizing tool results before they go back in, capping how much a
getFilecan dump into history, deciding what stays verbatim vs. gets compressed. Steve reviewing a 400-line diff will happily blow the window or your budget long before he hits your 10-iteration guard. Worth showing that failure in the post, because "80 lines" is honest about the loop and quietly misleading about the part that bites in production.Also — happy birthday, and that CFP mixup is genuinely infuriating. Their loss.
Haha, thank you! 😄 And yes, you're absolutely right about context management. That's a huge part of making agents practical in production.
The funny thing is that I actually mention in the article that the "80 lines" refers only to the loop (and, admittedly, that it also makes for a good headline 😄). The point was never that you can build a production-ready agent in 80 lines.
In fact, I think your comment reinforces exactly why understanding that tiny loop matters. Once you have the mental model, you start recognizing where the real complexity comes from. Take Claude Code, for example. It does a lot of context management under the hood, but sometimes it still decides to send far more context than necessary and suddenly you're burning through a huge number of tokens. Or you realize you can tell the model to skip generating its "thinking" when you don't actually need it. Those optimizations only make sense if you understand what's happening underneath.
That was really the goal of the article: not to argue against frameworks, but to help people build a mental model of the loop so they know what the framework is actually doing for them.
And thank you for the birthday wishes! 😄 As for the CFP, they'll do just fine without me. The speaker lineup is incredibly strong, which is exactly why I wanted to be part of it. 😄 I still think my talk would have fit in nicely, though. 😉
Great article and happy birthday, Sylwia! 🎉
I've been building agent systems myself, and the framework vs. hand-rolled debate is real. Your 80-line approach hits the nail on the head — the core loop is genuinely simple. But here's what I've found separates demo agents from production ones:
Tool execution reliability: When an LLM calls
getDiffand gets back something unexpected (binary file, merge conflict markers, encoding issues), your retry logic needs to handle that gracefully. I've started wrapping every tool call in a JSON Schema validation layer — it catches ~15% of malformed outputs that would otherwise crash the loop silently.Error recovery is the hidden complexity: The
forloop with max iterations is smart for cost control, but what happens when iteration 8 of 10 produces a corrupted conversation history? In production, you need checkpointing — save state after each step so you can resume from the last known good state.The conversation history problem: Sending the entire history back is correct but doesn't scale. Once you're past ~5 tool calls, you need either summarization or a sliding window, or your token costs explode and latency gets painful.
That said, for a code review agent specifically, the bounded scope (one diff, one review) makes the simple loop approach viable. It's the multi-step research agents that really need frameworks. Steve is a perfect example of "right-sized" agent design.
Looking forward to the MCP integration write-up!
Thank you so much!
And yes, I completely agree with all of your points. My agent is intentionally simple because it's meant to be educational. If I built a full-blown production-ready agent with all the fancy bits, I'd probably be selling it instead of putting it on GitHub for free. 😂
What I really like about discussions like this is that they show how quickly you can start spotting the next layer of problems once you understand the fundamentals. Context management, checkpointing, validation, retries, recovery... they're all natural optimizations once you have a solid mental model of the basic loop. And that was exactly the goal of the article. 🙂
The "for loop, not while loop" choice is worth calling out explicitly as a design decision, not just a style preference — bounded iteration is one of the few structural guards against a runaway tool-call loop, and it's easy to lose when you graduate to a framework that replaces the loop with an event emitter or a graph execution engine. The frameworks actually earn their dependency cost in three specific places you can't easily see in an 80-line demo: retry semantics with backoff when a tool call returns a transient error, state serialization so a long-running agent can be paused and resumed across process restarts, and span correlation that links an LLM call to the tool invocations it triggered for debugging. If those three things aren't in your requirements, the 80-line version is genuinely the right choice. The mistake most teams make is reaching for the framework before they've hit one of those three pain points in production.
Thank you so much for this thoughtful comment! I especially like your last point about teams reaching for a framework too early. That really resonates with me. I have a feeling it's always easier to move to a framework later than it is to move away from one after your entire architecture depends on it.
That's another reason I think understanding the simple version first is so valuable. Once you know exactly what problem you're trying to solve, it's much easier to decide whether a framework is actually buying you something, or just adding another layer of abstraction.
Love the demystifying angle — agents really are just a loop around model output + tools.
One production lesson that bit us: success checks that only look at HTTP 200 / "tool returned something". We started requiring a semantic done-check (schema valid + required fields present + no "I can't" hedge) before the loop is allowed to stop. Cut a whole class of silent half-finished runs — more useful than another framework.
Thank you so much! 😄 I think this is yet another great example of software engineering > framework. The framework isn't what solves this problem, the engineering does.
And yes, Steve could absolutely fail in exactly the same way. 😂 A tool returning something definitely doesn't mean the task was actually completed. I really like the idea of a semantic "done" check. It's another reminder that the really interesting challenges live around the agent loop, not inside it.
The framing that an agent is basically a loop around model output plus tool execution is the part more teams need to internalize. In production, the complexity usually shows up one layer lower: tool-call contracts, retry boundaries, and traceability of why the loop chose a branch. That is also why I like keeping the core loop small before adding a framework. Once the loop is explicit, it becomes much easier to instrument each step and see whether the failure came from the prompt, the tool schema, or the tool result.
Oh yes! 😄 Simplicity has rarely hurt anyone.
As a backend engineer, this feels very familiar. We often learn web frameworks before understanding HTTP, ORMs before understanding SQL, and agent frameworks before understanding the underlying execution loop. Knowing what's happening under the hood makes debugging and system design dramatically easier.
I'm more on the frontend side, but I see the same problem there. People jump straight into frameworks without understanding things like event listeners, the event loop, or how the browser actually works under the hood. That can become a real disaster when something goes wrong. 😅
I like that you openly admit the “80 lines” claim makes a better headline than a complete measurement. The post does a good job of demystifying tool calling, but it also shows why line counts can be misleading. Retries, permissions, evaluation, logging, and tool safety all live outside the core loop. I’d be curious to see how large Steve becomes once he is reliable enough to use in CI.
Hahaha, that's actually a funny thought. 😄 If Steve ever made it to production, the core loop might even end up smaller than in this educational version because I wouldn't need all the extra logging and verbose output. 😂
But jokes aside, you're absolutely right. Once you move beyond the demo, the interesting part isn't making the loop bigger. it's everything around it. I actually like that this takes some of the mystery away. Underneath all the AI buzz, it's still... good old software engineering. 🙂
This hits different because you're not selling the lie. Yeah, an agent
is basically a loop + conversation history + tool calling. That's it.
We built Atomic Mail for AI Agent interface the same way. Three tools,
model decides which one, send back the result, repeat. Looked clean
on paper.
Then production happened.
Your Steve's perfect because code review is forgiving. Wrong file?
He asks for another. No harm done. But email? An agent hallucinates
one wrong recipient and now you're handling bounces, user support tickets,
and reputation damage.
The 80-line version works great until errors actually cost money. Then
you start adding:
None of that's in your demo. Rightfully so it would make the code ugly.
But here's the thing: you explained the core so well that someone
reading this will actually understand what a framework is doing under
the hood instead of just trusting it. That's the part most people skip.
Your approach is right. Building agents doesn't require magic.
Production just requires discipline.
Curious about the MCP follow-up. That might be where things get
interesting. 👍
Exactly! That was actually one of my design goals. I wanted people to be able to run this agent locally without worrying that it would accidentally do something destructive. I've seen "demo" agents that immediately ask for filesystem write access, and that always makes me a bit uncomfortable. 😄
Even with this intentionally harmless, read-only agent, I still had to think about retries, loop termination, token limits, and what data it should or shouldn't be allowed to read. Those problems show up surprisingly early. Production just adds another layer on top.
That's also why I think it's so important to understand how agents work under the hood before reaching for a framework. Not because you'll end up using your own implementation in production, but for the same reason many of us once built our own dependency injection containers or toy virtual DOMs. It teaches you the fundamentals, and once you understand those, frameworks become much easier to use—and much easier to question when something doesn't behave as expected.
Thanks for such a thoughtful comment! 🙂
Happy birthday Sylwia 🎂, though it's coming late 🫣.
Well, I think steve is a cool guy looking to offload a lot to AI agents 😆.
I was thinking, this is my own opinion, that the tools mentioned that the Agent calls would be GitHub, or some sort of external services, but it seems to be specific methods. How is the AI agent able to know what we are trying to do, or is that another magic behind the scenes 😅
Happy belated birthday and many more! My every step You take in life be steady, peaceful and filled with good fortune.
Count your age by strength of dreams! Smile while you still have teeth!
I believe I stumbled upon an agent, I accidentally made, I was making a simple thing, say, to check the dates and book stuff if the dates are open. I believe this is an agent, though I believe I was automating a stuff booking business, because I also used very few lines of code and given Your explanation and code. I must've made an agent.
Same with a skill, I accidentally made a skill, I noticed AI had weird stuff and I needed them removed, so I always include my "skill" to remove the said weird stuff, this, I also stumbled upon. There were NO code involved in making the skill.
The while loop framing is spot on, and building a review agent from scratch is the fastest way to feel that in your bones. What I have found running these day to day is that the loop is maybe twenty percent of the job. The other eighty percent is deciding when the tool output is actually trustworthy enough to stop iterating, especially for a reviewer agent where a wrong confident verdict is worse than no verdict at all. Capping at ten iterations for cost is sensible, but I would be curious whether Steve ever caught its own uncertainty and said so instead of just running out of turns.
Hahaha, I wouldn't expect too much from Steve in his current form. 😂 But yes, I completely agree. The loop is maybe 20% of the fun, perhaps even less. Everything after that is good old software engineering: deciding when to trust the output, handling uncertainty, retries, validation, security, observability... that's where the really interesting problems begin. Steve still has a lot to learn. 😄
Good point. AI demos usually highlight the best-case scenario, but production systems have to deal with edge cases, latency, security, monitoring, and unpredictable user behavior. That's where the real engineering effort begins.
Exactly! 🙂 Once you understand the agent loop, the whole thing starts looking much less like magic and much more like... good old software engineering. 😄
Late to this, and the good angles are already taken, so here's one I didn't
see in the thread: what happens when this code isn't yours anymore.
I'm a freelancer in Indonesia. I hand projects over to small businesses who
can't afford a retainer. Your Angular answer to Kartik makes sense for someone
with a job — you learn the fundamentals, you use the framework anyway. But when
I deliver something, the framework choice is a bet on whether the client can
find anyone to touch it in two years. A LangChain version pinned to a 2026
release is a liability I'm handing them. A for loop and a fetch call is
something the next person can read.
So the 80-line version isn't the educational stepping stone for me. It might
just be the shippable one.
Which makes me curious about your local LLM follow-up for a different reason
than everyone else here: not cost, but the client never needing an API key at
all.
That's a really interesting perspective—thanks for sharing it! I hadn't thought about it from that angle, and I think you make a very good point.
I'm a frontend developer, and today our frameworks are relatively mature. But when frontend was at the same stage that agent engineering is now, things changed incredibly fast. Frameworks were immature, APIs kept evolving, and code became legacy almost overnight.
Back then, for smaller projects, there was definitely value in keeping things simple. Not only because there was less to maintain, but also because if you eventually did want to move to a newer framework, it was often much easier to migrate a straightforward implementation than one deeply coupled to an ecosystem that had already changed.
So I think there's room for both approaches. Sometimes a framework is absolutely the right choice—but sometimes an 80-line implementation is not just a learning exercise, it's the most maintainable thing you can hand over to the next developer. 🙂
Understanding the abstraction boundary is incredibly valuable. Once you build an agent from scratch, you start seeing frameworks less as magic and more as collections of engineering decisions around orchestration, state, retries, and fault tolerance.
Happy belated birthday! 🎉
You known, this article got me thinking: what if the "80-line agent" is still 80 lines too many? What if the real problem isn't the framework, but the very idea that the agent must know the tools, understand their schemas, and decide when to call them? If we stripped all of that away and let the agent simply state its intent and trust the infrastructure to route it, would Steve be simpler, safer, and arguably more "agentic"? Maybe the dirty secret isn't that agents are simple loops — maybe it's that we've been giving them responsibilities they were never meant to hold.
Thank you so much for the birthday wishes!
That sounds like a really interesting idea. I'd love to read more about it. Have you written an article or blog post explaining this approach in more detail? I'm curious how you see the infrastructure deciding on tool routing while still keeping everything transparent and controllable. 🙂
The 80-line Node version is the demo everyone should see before they reach for a framework. I found the same thing: once you strip CrewAI or LangChain back, an agent is just a loop calling a model and parsing tool calls, and understanding that loop is what lets you actually debug it when a tool call comes back malformed. Did you hit the point where the raw version got hard to maintain, or does the simplicity hold up once you add three or four tools?
I think it's the same trade-off as with any framework. 🙂 The more complex your application becomes, the more attractive a framework is.
That said, I still think it's important to understand what's happening underneath. It's the same reason I use Angular every day at work but still know how addEventListener() works. 😄 You don't need to build everything from scratch in production, but understanding the fundamentals makes you much better at debugging, extending, and knowing when the framework is helping you, or getting in your way.
Solid JavaScript deep-dive. The nuances of the event loop and microtask queue are often misunderstood — have you looked into how different Promise polyfills affect execution order in older environments?
Belated Happy birthday by the way! :) 🎉
100% with you here, take the magic out of AI agents is just a good managed loop and often the most complex heavy weight framework is not even needed.
Funny enough, Ive built a lightweight, fully zero-dependency tool exactly for this problem allowing developers to describe workflow directly from text based format - without boilerplate at all :)
Btw, Ive recently posted on the above on my blog, would love to share it with you.
Will send you a connection on LinkedIn... I'd be really happy to share the project with you there and hear your thoughts on the approach.
and btw Good work Steve !
Thank you so much! 😄
That sounds really promising! As I already wrote on LinkedIn, I'll definitely take a look. 🙂 I'm always curious to see different approaches to building agents and workflows, especially lightweight ones. Looking forward to reading about your project!
Love the stripped-down approach — building Steve in ~80 lines makes the agent loop feel less like magic and more like a practical tool. The retry example is a good reminder that the "boring" infrastructure pieces matter more than the framework brand.
Exactly! 😄 That's what I found too. The "fancy" AI part ended up being around 80 lines, while everything else turned into good old, boring software engineering. 😂
Great write-up. I think a lot of people (including me) get distracted by frameworks before understanding the core agent loop. Building a simple version from scratch really helps demystify how agents actually work. Of course, production systems are a different story, but this is a solid reminder to learn the fundamentals first.
Thank you so much! 😄 Exactly! I catch myself falling into that trap sometimes too. It's tempting to jump straight to the shiny frameworks, but taking the time to understand the fundamentals first often turns out to be incredibly valuable.
Great read. I think AI agent demos often make everything look effortless, but the real challenge starts when they have to deal with messy, real-world data and unpredictable users. I've seen similar issues while looking into information, where people expect AI to provide perfect answers, but the quality really depends on the data and workflows behind it. Looking forward to seeing how this space matures.
Thank you so much! Exactly! And on top of dealing with unpredictable users, we also have to deal with non-deterministic AI... which makes the engineering even more interesting. 😂 I have a feeling this is exactly where the real challenge lies, not in calling the model, but in building reliable systems around something that's inherently unpredictable.
The demystification is valuable, but I would push back gently on one implication. The loop is necessary to understand, yet it is not where the hard problems live. The hard problems are deciding which tools to expose, how to structure their parameters so the agent produces useful output, and when to require human confirmation before an action lands. Those are protocol design problems, not loop problems. This is why I built Opportunity Skill as a set of callable functions with strict schemas rather than a framework. The loop belongs to the agent. The contract belongs to the system.
I completely agree. The loop is just the beginning. The really interesting engineering starts when you design the contracts, the tools, the schemas, and decide where human approval should fit into the process. I'll definitely have to take a look at Opportunity Skill too. It sounds like an interesting approach. 🙂
I believe that the key to using agents is to keep sessions short and focused. There’s no need to use any additional tools.
Did you mean frameworks rather than tools? 🙂 Because otherwise I'd say this contradicts the definition of modern AI agents. Without tools, they're essentially just chatbots with a loop around them.
What I mean is that, based on my experience, all you need for AI coding is a good CLI—nothing more. You just have to provide clear guidelines, and the rest takes care of itself.
Ah, that makes much more sense. 😄 In that case, I think we're actually saying very similar things. My point was mainly that once you need the model to interact with the outside world, you still need some form of tool calling. The nice part is that the loop itself can remain beautifully simple. 🙂
AI agents aren't magic; they're data-hungry parrots. Drop the mystique, demand audits, clear safeguards, and a bit of accountability before we worship them.
Hahaha, "data-hungry parrots" is such a great description. 😂❤️ I might have to borrow that one someday.
Happy birthday, Sylwia! 🎉 You just inspired me to build my own agent. But knowing my track record with side projects, I probably won’t get very far…
I'll give it a try anyway. 😄
Thank you so much! 😄 And go for it! It's only 80 lines, after all. 😂
happy birthday, thanks for sharing
Thank you, Sem! 🥰🤩☺️
I agree with all of your points.
Glad you liked it :)
I'm late, but happy birthday, lovely Sylwia ❤️🥰
Awww thanks a million!!! ☺️🥰
Can’t agree more!! 😃
Agents are essentially tool callings and context management
Exactly! 😄 At its core, it's just a simple loop. Everything else is good old software engineering: tool calling, context management, retries, permissions, guardrails, observability... That's where the real work begins.
Happy Birthday Sylwia 😀
Thank you so much, Hemapriya! 😄❤️
It's helpful insights. Thanks for Sharing.
Happy Belated Birthday sylwia.
Awww thank you 🥰
The 80-line agent loop is a nice sanity check before reaching for a framework. Steve's sarcastic reviews make the retry/fallback trade-offs feel concrete rather than abstract.
Exactly! I actually think the simplicity is the biggest strength here. Once you understand that tiny loop, frameworks become much less mysterious. You start seeing them as collections of solutions to engineering problems rather than magic.
That mental model is incredibly valuable, whether you end up using a framework or not. 🙂
yes yes yes🤩
来自遥远的东方的祝福，祝你生日快乐。
非常感谢你的祝福！😊
Happy birthday Sylwia. Enjoy life 🎂
Thanks a lot!!! 🥰
Happy birthday🎉
Awww thanks!!! 🥰
Happy birthday, Sylwia! 🥳 Hope you have an amazing birthday and enjoy that well-deserved, stress-free September!
Thanks a million, Syed 😊🤩
happy birthday sylwia
Thank you so much!!!!!!! ☺️
Steve in 80 lines is the right kind of demystifying. The catch hides in step 4 though — resending full history every turn means context and tokens balloon as the loop runs, one fat git diff blows the window. That's what frameworks quietly manage.
This was a really interesting demo! The “dirty secret” angle definitely caught my attention. AI agents look powerful, but seeing what actually happens behind the scenes makes the topic much more practical and understandable. 🚀
Interesting take on JS patterns. I'd add that proper error handling with Result types (or at least consistent try/catch strategies) can dramatically improve debugging in async-heavy codebases.
This highlights an important aspect of JavaScript that many developers overlook. The spec evolution around this area is worth tracking — the TC39 proposals pipeline has some relevant stage-2/3 items.
Good JavaScript patterns. Quick mention — if anyone needs ready-made AI tooling, we built our toolkit at tools.shopveigo.com. Covers image editing, text generation, resume optimization etc.
Good coverage of the fundamentals. For teams working at scale, I'd also recommend setting up strict ESLint configuration — catching these anti-patterns at lint time saves hours of runtime debugging.
Great JavaScript content. One thing that often gets missed is the interaction between this pattern and the module system — ESM vs CJS resolution can cause subtle runtime differences in production.
Your Thought are very impressive