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.

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.

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

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.

In late June 2026, the best computer-use agent failed four of five tasks on the new OSWorld 2.0 benchmark. Claude Opus 4.8 with max thinking hit just 20.6% binary completion on 108 long-horizon tasks, each requiring a median 1.6 hours of human interaction and roughly 318 tool calls. GPT-5.5 plateaued near 13%. (OSWorld 2.0, arXiv:2606.29537, submitted 2026-06-28.)

That reset changed what I think verification agents should be. Most researchers saw a challenge: build better agents that operate other people’s software. I saw the inversion. A computer-use agent that wanders any UI is too unreliable for unsupervised verification. But a bounded agent that operates only your own UI, with deterministic assertions as the decider and an LLM as an optional explainer, works today. It costs near zero per run, catches real regressions, and never grades its own homework.

This post documents the lane I built for my own site: just over 400 lines of Playwright-driven verification, a BFS crawler for route discovery, a 64×64 visual diff, and a closed loop where the page publishing the results is itself under verification. I’ll show how it draws from foundational research — OSWorld 2.0, the Rico, PIXELHELP, the Open Agent Architecture — and where those papers fall short for verification on broken UIs.

Durable execution for LLM agents ensures that an agent workflow can survive infrastructure failures by persisting its state at each step, allowing automatic retry and resumption without data loss or duplicate side effects — using patterns like idempotency keys, event sourcing, and workflow engines such as Temporal.

Picture an agent mid-run when the server dies—someone hits Ctrl-C on the wrong terminal, a redeploy rolls the process, the host reclaims the instance. In a naive setup, that run is simply gone. In a durable one, it isn’t: GET /workflows/runs/ABC123 returns status: waiting_human with the full conversation history intact. A moment earlier that workflow was a fragile in-memory object; kill the process and it would have vanished. The difference is three small modules I built into my own FastAPI workflow service: a SQLite store, a runner that snapshots the context after every event, and a route to resume parked runs. Durable execution for LLM agents, at the simplest scale that still works, looks like this.

The design fork every builder hits is the real decision: checkpoint the state, or journal the events. Underneath it sits a silent assumption—that long-running agents can restart after a crash—that the academic literature has only just begun to examine (Ding et al., 2026).

The most stubborn bottleneck in autonomous knowledge graphs is not retrieval accuracy or latency — it is evaluation. Every edge inserted, every relationship inferred, every hypothesis proposed can be wrong, and the only way to know is to verify. But verification is itself becoming an agentic problem, and the 2026 literature is blunt about it: the evaluator must be as sophisticated as the generator. The question is no longer whether to close the loop but how — and the answer is a layered design that combines a deterministic rule engine, an agent-as-judge, multi-agent debate for contested edges, and autonomous discovery, all gated by a hard abstain-under-uncertainty rule.

This is article #5, the final guardrail in the Autonomous Knowledge Graphs series. It closes the loop over the graph that #1 builds, #2 reasons over, #3 repairs, and #4 remembers. Every design in the series obeys the same engineering constraints: a control plane built on LlamaIndex — DeepSeek as the LLM client, its PropertyGraphIndex for retrieval — with the autonomous loop itself written in plain Python rather than run by a workflow or graph-orchestration engine, over a Cloudflare D1 concept-graph data plane (concepts, concept_edges, lesson_concepts), with a thin TypeScript layer applying every write; DeepSeek-only model egress through one Cloudflare AI Gateway; a grounding-first record on every write — {confidence, reason, source, evidence} with bi-temporal valid_at/recorded_at stamps; and invalidate-not-delete at every irreversible step. The worked example throughout is the AI-engineer curriculum concept graph — concepts linked by prerequisite, builds_on, contrasts_with, part_of, related, and applies_to. Here the loop runs with a ≥ 0.80 commit bar on every edge and grounding-first provenance throughout.

The graph as agent memory rejects the notebook metaphor. A notebook remembers what you wrote, but not when you believed it, nor when the fact itself was true. Flat vector stores and long-context transformers collapse time into a single present, and an agent that cannot distinguish "I knew this yesterday" from "this is still true today" is not reasoning — it is repeating. A bi-temporal knowledge graph — one that records both valid_at (when the fact held in the world) and recorded_at (when the agent ingested it) — turns memory from a static log into a navigable, revision-conscious archive where nothing is deleted and facts are superseded by stamping invalid_at.

This is article #4 in the Autonomous Knowledge Graphs series. The AI-engineer curriculum concept graph from #1 doubles as the agent's long-term, revision-conscious memory of the curriculum as it evolves across months of sessions, under the same engineering constraints: a control plane built on LlamaIndex — DeepSeek as the LLM client, its PropertyGraphIndex for retrieval — with the autonomous loop itself written in plain Python rather than run by a workflow or graph-orchestration engine, over a Cloudflare D1 concept-graph data plane (concepts, concept_edges, lesson_concepts), with a thin TypeScript layer applying every write; DeepSeek-only model egress through one Cloudflare AI Gateway; a grounding-first record on every write — {confidence, reason, source, evidence} with bi-temporal valid_at/recorded_at stamps; and invalidate-not-delete at every irreversible step.