A dev.to post says most AI agents are built wrong, but shows no logs

A bold headline, an opinion underneath

As dev.to reported, one developer has published a post titled "Everyone's Building AI Agents Wrong and the Logs Prove It." The title promises evidence from system logs, the records that show what a program actually did, step by step. The text itself shows none. There are no log excerpts, no counts of failures and no comparison between teams.

What the post offers is the author's account of what they see while reading papers, building things and talking to engineers who ship products. That makes it an informed opinion rather than a finding. It is still a useful one, because the mistakes it describes are specific and easy to check.

What counts as an agent

The author starts with a complaint about vocabulary. Almost anything that touches a tool now gets called an agent: a function that calls a tool, a chatbot with memory, a script with a loop. The author says this vagueness causes real mistakes, such as teams building elaborate multi-step setups for jobs that one well-written prompt would handle.

Their own definition is stricter. An agent has an objective, not just an instruction. It decides what to do next, copes with failure, and knows when it has finished. If a person has to tell it every step, it is closer to a chat window.

The post sketches a ladder. A system that recovers when a tool call fails and tries another route is getting somewhere. A system that breaks a goal into subtasks and hands them off is the real thing.

What working systems have in common

According to the author, most real deployments are narrow. They do one job well, such as sorting customer support requests, pulling data out of documents, or reviewing code in one specific project. They are closer to purpose-built pipelines with some judgment built in than to general reasoning machines.

The teams that do well, the author says, focus on three things:

• Tool design: what the agent is allowed to call, and how clean that interface is.
• Failure handling: what happens when a tool returns nothing useful.
• Observability: whether you can trace exactly why the agent made a given decision.

The third point connects to the headline. Logs are how you see the repeated steps and quiet failures that a polished demo hides. The teams doing badly, the author says, upgraded to the newest top-tier model and expected better behavior without changing anything around it.

Patterns matter more than frameworks

The post names several popular toolkits for building agents: LangChain, LangGraph, CrewAI, AutoGen and Semantic Kernel. The author calls the debate over which is best a distraction. Having rebuilt the same design in three of them with similar results, they conclude: "The framework is scaffolding. The architecture is the building."

They list three patterns that hold up whichever toolkit you choose:

• Plan, then execute. One step produces a plan and a separate step follows it, without mixing the two.
• Keep retrieval and reasoning apart. Fetching information and using it are different jobs, and systems that blur them get confused.
• Make handoffs explicit. When one agent passes work to another, the handoff should be structured and logged, not just text slipped into a prompt.

The retrieval problem in the details

The author also flags a weak spot in RAG, short for retrieval-augmented generation, where a system looks up relevant documents and feeds them to the model as context. Documents are cut into chunks before they are stored, and those cuts are often in the wrong place. A paragraph that only makes sense after the one before it can be retrieved alone, and the model may invent the missing context.

Overlapping windows, chunking by meaning, and retrieving the parent document all help, the post says. The deeper fix, they argue, is rethinking what gets stored, sometimes a structured summary instead of raw text. If results are technically correct but unhelpful, suspect the chunking or the metadata before the embedding model, the component that turns text into searchable numbers.

Where the author thinks this goes

The author expects models to keep improving, context windows to grow and costs to fall. None of that, they say, removes the core job: building systems you can trust when nobody is watching. They name governance, observability and reliable tool use as the problems worth solving.

That fits the argument of the whole piece. The claim is not that agents cannot work, but that they work when the plumbing around the model is built with care. Without published logs or numbers, readers can't verify it, so it is best used as a checklist to test against their own experience.