Understanding what agents can do and when

The hype

Hobbyists and early adopters started experimenting with "agents" as early as 2023. Posts on Twitter and Reddit showed how we were moving from basic prompting to giving AI tools it could use in a loop, letting it work more and more on its own.

But the real wave came in 2025 and 2026. "Agentic AI" became the topic and the pitch of almost every company. Courses, talks, and posts all said the same thing: if you weren't using one, you were falling behind. Having fifteen agents doing your work while you slept was the dream, and apparently the path to becoming a millionaire.

The wave was so big that people with very little knowledge jumped on it too. They preached their success, how much they were achieving, and how many agents they ran. But very few had a real use for them, and even fewer were producing anything of real value, let alone commercial value.

It didn't take long for people to understand the cost of running one. It also became clear that you can't just ask your agent, "Look at our sales data and make us more profitable," or "Think of an idea that will make me rich and execute it."

Framework fatigue

I've been circling this topic for a long time without really getting into it. Honestly, I felt it was mostly hype. And as usual in software, being early or an early adopter often just means being the tester.

Years ago, before AI, a couple of JavaScript frameworks came out every year. Each one claimed to be better than the last, React was supposedly doomed, and the tech gurus kept telling us why we had to learn it right now and why everything we knew meant nothing. Many developers ended up experiencing what we call "framework fatigue."

The most important lesson I learned back then is not to jump into every new piece of tech that comes along. Watch the video, read a few articles, maybe follow a small crash course of someone building something so you can see how it works. But don't learn it just because a guy with 200K followers on Twitter told you to. He probably doesn't care whether you learned it or whether it worked. He wanted your like, and maybe a comment.

If something is good enough, it will stick. And if it sticks, it will improve. Once it's mature and there's a real need for it, go and learn it. What's the risk? You might be a few months behind. A few hours on a project and a look at the docs will get you up and running. That's much better than the burnout of trying to be on top of everything and grounded in nothing.

What I think about agents

Agents were that for me. Yes, they sound cool. They're great, and I'm happy for you. But show me some results. Show a practical example of how it worked for you, and how it could apply to someone else.

So at this point, my opinion is that agents won't save anyone's life. They're only necessary when solving a specific problem. In other words, they're another tool in your toolbox.

So what is an agent?

My understanding of an agent, so far, boils down to this: a model that can use tools in a loop. It picks an action, sees the result, and decides what to do next until the task is done.

That doesn't mean every case needs one. In most cases, an efficient workflow is a better option, because it solves the problem faster and cheaper.

Here's a rough test I use to decide whether something needs an agent: can you draw the steps as a flowchart before you run it? If yes, a normal workflow or script is usually cheaper, faster, and more predictable. But if the next step depends on what an external tool returned—like a database match forcing the model to re-evaluate its choices—and you can't predict the branches, an agent starts to make sense.

If the task is small and you can see all the steps, an agent is overkill. But when the volume is high enough that a person's time is the bottleneck, the rules are fuzzy enough that writing a script for every variant is impractical, and the cost of a mistake is contained (a bad refund can be reversed, and a human can review the risky cases), an agent can pay off.

So a fair summary is: agents pay off when many similar but not identical tasks come in, each one needs a bit of judgment, and a person would otherwise be the bottleneck.

Questions to ask before you believe a pitch

These are the questions I'd ask.

Evaluation. This is probably the most important one. Agents are hard to test because the same input can produce different paths. Teams build a set of sample tasks with known good outcomes and score the agent against them after every change. Without this, you can't tell whether an update made things better or worse. Ask anyone pitching an agent how they measure quality.

Tool design. The model only sees tool names, descriptions, and parameter schemas. A vague description leads to wrong calls. Good tools are narrow, have clear inputs and outputs, and return errors the model can read.

Permissions and blast radius. Decide what the agent can read, what it can change, and what needs human approval. Read-only tools are safe to let it call freely. Anything that sends money, emails customers, or deletes data should be gated. This is the question that most often separates a demo from a production system.

Cost and latency. Every step is another model call, and each call re-sends the growing conversation. A ten-step run costs far more than a single call, and it's slower. Knowing this helps you decide whether the time an agent saves is worth what it costs per task.

Failure modes. Agents fail in predictable ways: looping on the same tool, giving up too early, calling tools with made-up arguments, or confidently claiming success when a step failed. Knowing these names helps you spot them in logs.

Prompt injection. If an agent reads external content like web pages, emails, or support tickets, that content can contain instructions meant to hijack it. Any serious agent design has to treat tool outputs as data, not commands.

Human in the loop. Deciding where a person reviews or approves an action is a product decision as much as a technical one. Many useful agents draft, and a human sends.

Building Capital Tales

I always believed the best way to learn is by doing. So I decided to build one. But since I wasn't very convinced about the whole idea, I set a few rules before I started: it shouldn't take long to build, it should be completely free to run, and it should be interesting.

The result is Capital Tales. It turns the day's tech and crypto news into short illustrated bedtime fables. Each fable explains a market idea through a story about animals and their little town, and links back to the real news story it came from.

capitaltales.maxiruti.com

Capital Tales – Where Markets Become Bedtime Stories

Wall Street cycles, AI infrastructure, and crypto mechanics translated into gentle, vintage three-chapter fables.

Once a day, a scheduled job wakes up the system:

"crons": [{ "path": "/api/curator", "schedule": "0 21 * * *" }]

The model then reads headlines from a few news feeds, picks one story, checks whether it has already been covered, writes a three-chapter fable, and saves it to the database. It has three tools for this: one to fetch the news, one to check past stories, and one to save the finished fable. A loop limit stops it after five steps, so it can't run forever:

stopWhen: isStepCount(5),

The instructions I give the model are a short list of steps, taken from the system prompt:

1. Call 'fetchMarketNews' to retrieve recent headlines across Tech, Markets, and Crypto.
2. Select ONE high-impact story.
3. Call 'checkTopicHistory' with the core entity or concept to make sure it hasn't been covered recently.
4. Translate the mechanics into a whimsical, imaginative allegory.
5. Call 'saveFableStory' with the headline, the title, the pages, the image prompts, and the moral.

The model decides the details inside each step, but the order comes from that list. Everything around that model is ordinary code. The schedule, the security check, the database writes, and the page refresh always run in the same order, and the code handles success and failure the same way every time.

I'll be honest about the weak spots. The check for repeated stories is only a suggestion to the model. It can skip it and save a repeat. The right fix is to enforce it in the save step, and that's on my list. And since headlines from outside feeds go straight into the model's context, the project has the same prompt injection exposure I described above.

So, workflow or agent?

The rule I'd use is simple: if the code decides what happens next, it's a workflow. If the model decides what happens next, it's an agent.

Capital Tales is mostly the first. The model's real decision-making happens in one place: it picks a headline, chooses a keyword to check, and writes the fable. Even there, the order of steps comes from the prompt, and the code would behave the same way if you hard-coded those steps.

So the short answer is that it's a workflow that uses an LLM for the parts that need judgment. That's a common design, and often a better one than a fully autonomous agent.

Did I over-constrain it?

It depends on your definition. What I built is a system that uses an agent for the parts that require judgment, wrapped in deterministic code. That was a design decision, not a failure.

It's also worth separating two meanings of "agent." In the technical sense, Capital Tales qualifies. The model calls tools, reads the results, and decides the next move inside a loop capped at five steps. In the stronger sense people often mean, a system that plans its own path toward an open-ended goal, it doesn't. The sequence is fixed by the prompt and the code. Most projects called agents fall somewhere between those two, and the less autonomy a system has, the easier it is to test and trust.

Hype aside, that's the part I find most useful. An agent is a tool. Use it when the problem needs it, and keep the rest of the system as simple as you can.