19 posts tagged with "AI Agents"

Most AI agents you deploy today are frozen the moment they go live. You handcraft the prompts, select the tools, wire up the memory, and hope the configuration survives contact with real users. It doesn't. Tasks drift, APIs change, user intents shift – and your agent silently degrades. The conventional fix is another round of manual reconfiguration. But there's a more principled path: treat agent design not as a one-time assembly but as a continuous search problem.

Most self-evolving agent demonstrations—those that appear to learn by picking better tools or adjusting dialogue style—avoid modifying the core reasoning engine. Evolving the reasoner itself—the chain-of-thought architecture, the internal planning logic, the very way an agent thinks—is the hard, brittle, data-starved problem that separates parlor tricks from genuine lifelong adaptation.

Most teams building self-evolving agents obsess over prompt engineering or fine-tuning the LLM. They miss the bigger lever: the substrate—what the agent remembers and which tools it wields. A prompt is ephemeral; memory and tools are structural. Evolving the substrate yields compounding returns that no amount of prompt tweaking can match. Fang et al. (2025) survey of self-evolving agents confirms this: the components that persist across sessions—memory and tools—define the agent's operational range far more than any instruction string. In this third part of the series, I'll lay out why memory and tool optimisation are the neglected backbone of lifelong agent systems, back every claim with data from the literature, and give you a decision framework you can implement today.

The moment an agent can rewrite its own code, evaluation ceases to measure and starts to train.

Here’s the uncomfortable truth the hype cycle doesn’t want you to hear: a single, well-prompted model often beats an entire team of specialised agents on standard reasoning benchmarks. Pan et al. (2025a) demonstrated that single large LLMs with carefully crafted prompts can match the performance of complex multi-agent discussion frameworks across multiple reasoning tasks arxiv:2508.07407. Jwalapuram et al. (2026) push the finding further: a single-agent GPT-5 instance using chain-of-thought with self-consistency “reliably outperforms the most sophisticated GPT-4o-based MAS frameworks (e.g., ADAS or AFlow) while consuming less than half the total tokens,” and automatically generated multi-agent systems “consistently underperform CoT-SC despite being up to 10x more expensive” arxiv:2606.13003. If you’re building an agent system and your first instinct is “let’s spin up three agents and make them debate,” you might just be burning tokens for no gain.

Two agents answer the same user query. Both return the identical string—correct, well-formatted, cited. An answer-level eval gives them both a perfect score, identical down to the decimal.

One agent made three redundant retrieval calls (same tool, same query, same corpus) before stumbling on the right source. The other called exactly the right tool once and answered. The answer-level eval cannot tell the difference. It never could.

The keys are in the trajectory.

I built a trajectory observability lane for my agents in three small pieces: the JSONL traces every workflow already emits but nobody reads, a judge that scores the tool-call sequence instead of the answer, and a Langfuse uploader written against the raw REST ingestion API—no SDK. Publication volumes indicate this is the moment: agent-observability research jumped sharply into 2026 (the phrase barely existed before), and the first dedicated fault-detection benchmark for agent observability was published this week.

This post is the full walkthrough: what trajectory observability is, why answer-level evals miss half the story, the three-module build, and how the research on partial observability validates the approach.

A flat agent swarm caps its own autonomy. Let every worker talk to every peer with no leader tracking progress, and the system can run for hours without anyone — human or machine — able to say whether the work was actually done. That is the ceiling this article is about. Hierarchical coach→worker delegation raises it: a single coach plans once, delegates to specialized workers, and those workers act unattended against that one plan instead of re-improvising every step. The autonomy gain is not that more agents run; it is that one durable plan governs many executions over time, so the plan→act→verify loop stops being per-run and becomes a property of the whole campaign.

On the fleet's autonomy ladder this capability sits high. The coach automates the plan step across an entire multi-touch campaign — a sequence that unfolds over weeks, not a single run — and worker subgraphs act against that plan unattended, with the human verify preserved only at each draft's approval. This article grounds that argument in two flag-gated graphs from one production agentic-sales fleet: a campaign-level coach (AA02) and a single-email organized team (AA06). It connects both to the organized-teams paper by Guo et al. (2024) and to decades of organizational evidence. The constants, enums, and feature flags below are read from the code, not from a benchmark. The claim is contrarian because the zeitgeist says "swarm good, hierarchy bad." The evidence says the opposite.

Most AI agents are built as a single process holding state in memory: a while loop, local variables, maybe a sleep(). That holds up until the workflow has to outlive the process that started it — and in production it always does. The math is unforgiving: chain ten steps that each succeed 85% of the time and the whole run finishes only about 20% of the time (0.85¹⁰ ≈ 0.20). Without durability, every one of those failures restarts from scratch. The model might be reliable; the tool calls aren't. Better LLMs don't fix network failures — only durable execution does.

The research consensus is that the infrastructure around the model, not the model itself, is where production agents live. The 2026 design-space analysis Dive into Claude Code found that only 1.6% of Claude Code's codebase is AI decision logic; the other 98.4% is operational infrastructure for context management, tool routing, and recovery. LangGraph's answer to that reality is durable execution through its persistence layer — making the agent a row in a checkpoint store, not a stack frame in a living process. This article dissects how that works, the sharp edges it creates, and how to observe a workflow that — by design — no longer runs as a single process.

TL;DR — CrewAI's real uniqueness is that it models problems as "build a team of people" rather than "build a graph of nodes" (LangGraph) or "build a conversation" (AutoGen). The Crews + Flows dual-layer architecture is the core differentiator. The role-playing persona system and autonomous delegation are ergonomic wins, not technical breakthroughs. The hierarchical manager is conceptually appealing but broken in practice. This post separates what's genuinely novel from what's marketing.

There's a difference between an AI that can edit code and an AI that can repair code. Editing is mechanical — find a string, replace it. Repair requires understanding what's broken, why it's broken, and what the minimal fix looks like within the constraints of an existing codebase.

The Code Improver is the fourth agent in our six-agent autonomous self-improvement pipeline for nomadically.work. It's the only agent that writes application code. The Trajectory Miner finds patterns, the Codebase Auditor diagnoses issues, and the Skill Evolver improves instructions — but the Code Improver is the one that actually opens files and changes them.

Five research papers informed its design, curated from the VoltAgent/awesome-ai-agent-papers collection. The central insight across all of them: structured repair workflows outperform ad-hoc fixing.