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.

Provenance is not truth. A triple can be perfectly traced to a published source and still be wrong — contradicted by a later signal, inconsistent with the schema, or hallucinated by the model that extracted it. The industry has spent years building better provenance; the harder problem is what to do when provenance says the fact is sourced but the fact is still garbage. The sharpest 2026 statement of this is TGComplete, which finds that most gold-correct edges have no supporting passage even under exhaustive retrieval — so textual verification measures provenance, not correctness (Kang et al., 2026, arXiv:2606.15833).

This is article #3 in the Autonomous Knowledge Graphs series, and it is a guardrail. Where #1 builds the curriculum concept graph and #2 reasons over it, this article keeps it accurate over time. 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. This guardrail runs as a background repair sweep over the stored concept graph.

Agentic GraphRAG treats the knowledge graph not as a static index to retrieve from once, but as a state space to reason over one node at a time. GraphRAG proved that structured knowledge could be retrieved at generation time — but a one-shot subgraph either drowns the LLM in irrelevant triples or misses the one critical edge. A question like "what must a learner master before agent orchestration, and which of those concepts does RAG build on?" is a sequence of decisions: which edge to follow, which concept to expand, when to backtrack. That is a planning problem, and the 2026 research corpus has converged on agentic traversal to solve it.

This is article #2 in the Autonomous Knowledge Graphs series. It reasons over the curriculum concept graph that article #1 builds, and 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 is an explainable answer over the curriculum graph: the agent returns not just an answer but the supporting concept sub-graph as evidence.

Releasing model weights is a one-way door, and the model behind it is a room no one can read. Those two facts — irreversibility and inscrutability — sit underneath the most-quoted thing Dario Amodei has ever said about open models, that they are heading down a "dangerous path." A 2023 clip of Anthropic's CEO warning the U.S. Senate resurfaced on Hacker News this month, and the top comment wrote the dunk for everyone: these tools will become dangerously powerful, which is why nobody should be allowed to have them except by buying them from me. It is an easy laugh. The actual argument is more careful than the clip, the evidence behind it is thinner than Anthropic implies, and the way 2026 has judged it is sharper than either side expected — because the regulatory lever Amodei spent years asking for came home in June 2026 as an export-control order that switched off Anthropic's own flagship models.

This is the long version. It runs through what "open" earned the right to mean across forty years of software; what Amodei actually argues, in his own essays rather than the meme; what the biosecurity studies actually found; and why the closed, "safe" path turned out to be the one with a government-sized switch on it.

Autonomous knowledge graph construction is the pattern where one agent loop owns the entire lifecycle of a graph — read a source, search what is already known, verify a candidate fact, then write it — instead of running a one-shot batch extraction and hoping a later merge step cleans up the mess. The cleanest 2026 formulation is RAGA, which gives an LLM agent a CRUD toolset over the graph and constrains it with a Read-Search-Verify-Construct loop (Han & Cheng, 2026, arXiv:2605.17072).

This is the first article in a new series, Autonomous Knowledge Graphs, a connected five-part arc — from human-curated graphs up to graphs that build, reason, repair, remember, and evaluate themselves. 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.

The most effective sales-enablement copilot in our production fleet never sends a single message. That cuts against every vendor demo where a glowing AI drafts the perfect rebuttal and fires it off. This sales-enablement copilot does grounded deal coaching and objection handling, but in production the highest-leverage capability is not generation — it is holding fire. The agentic-sales fleet runs a LangGraph state machine where every objection-handling draft is stamped status='draft' and routed to a human for approval. The copilot coaches, suggests, and grounds its advice in company knowledge, but it never touches the send button. That single design choice turns a liability into an asset: the rep gets a grounded, auditable recommendation that she still owns.

On the fleet's autonomy ladder this capability sits deliberately medium — it is rep-assist, not self-direction. It automates the plan step: what grounded coaching and rebuttal a given objection deserves. But it hands both act and verify to the human. The copilot drafts and grounds; the rep decides and sends. That is a conscious rung below the orchestrator and the lead-to-proposal multi-agent pipeline. The failure cost of an objection rebuttal — repeating a hallucinated compliance claim to a live prospect — is high enough that earning the send is not worth it.

This is article #4 in The Autonomous Sales Fleet series, and like every entry it adds exactly 1 capability as 1 real graph: a company-knowledge-grounded objection-handling copilot that feeds the reply path, backed by a faithfulness gate and a per-vertical playbook of 9 entries. It builds on the shared fleet introduced in An Autonomous CRM Orchestrator with LangGraph (#1) and the typed task sequencing of A Multi-Step Lead-Qualification and Sales-Support Agent (#2).