Stop expecting prompts to rescue agent design. Call it context engineering or loop engineering, it still just begs the model to “not hallucinate.” That path multiplies drift and failure points. There is a simpler and sturdier way. Treat agents like software with explicit operating logic. Build a harness that decides when and how to call the LLM. In this article, we cover context and memory, durable execution, and progress evaluation that keeps agents on track.
Context and memory: where does a reliable agent begin?
A reliable agent begins with managed context and explicit memory. Every request resends the full conversation, so the “chat” is only a UI. You quickly hit the context window, get truncation, rot, and drift. The fix is a semantically packed window, moving only relevant state between agents, and dropping “thinking” that adds no value.
Full resend simplifies management and lets you massage content within the window. Even very large windows still drift. A useful consequence is this: you can lift context from one agent, hand it to another, and continue the session without extra tool calls, keeping only what matters semantically.
Context has a lifecycle: system prompt, tool definitions, user prompts, reasoning, tool calls. You must control what enters the window. Gumloop offers a Context Usage Meter with categories like System, AI Instructions, Abilities, Tools, Skills, Subagents, Conversation. In long sessions, the conversation share grows while system definitions stay stable.
As context accrues, compress it. Trim irrelevant tokens, summarize large chunks into compact equivalents. Google’s ADK Context Compaction reduces size by summarizing older workflow events with a sliding window and invocation thresholds. But you cannot summarize forever. Periodically, the harness should perform a full context reset and rebuild the next request from durable artifacts.
“The chat-like experience is a UI. A user illusion™.”
LLMs are stateless, so ephemeral context dies with the session. Write context to persistent storage. Ideally, use immutable ledgers where agents can write and read, but not modify or delete. You define permissions deterministically. What to store is your call: the full window, summaries, or only headings.
In Google’s EAP, memory generation bundles several choices. Extraction pulls only the most meaningful content. Consolidation merges new with existing memory so it can evolve. Generation runs asynchronously, so the agent does not wait. Event ingestion streams session events and triggers generation by batching rules. Extraction is customizable with topics and few‑shot examples.
With stored context, the ledger reconstructs state. A fresh session reads the durable plan, progress notes, and append‑only history to answer “where am I.” A structured plan can carry enough context itself: “I am on step 3 of 7, the step was ‘await the sanctions‑check result,’ and the result just arrived.”
“As Cloudflare put it, you can fire 20% of your employees to replace them with AI and use the Agent’s plan as context.”
In Google’s EAP, managed storage and retrieval bring isolation per identity, persistence across environments, similarity search scoped to identity, TTL for stale data, automatic revisions, and IAM conditions. Identity is a context concern. A memory’s scope is defined at creation and immutable, making it durable across jobs and sessions.
In Cloudflare, Durable Object identity persists across hibernation and restart without re‑establishment. It anchors task state and identity memory after crashes. That durability requires mechanisms for continuity across instances and failure points. We cover those next.
Durable execution: how do agents survive failures without loops?
Durable execution relies on deterministic resumption, not asking a model to “pick up.” A long‑running agent does not run continuously. It wakes on events, carries plan, state, and context, then sleeps again. The harness must structure data so the model behaves consistently from step to step.
What should persist? From Cloudflare’s pattern: agent state, all SQLite tables, scheduled tasks that raise alarms, and WebSocket connection states. What does not need to survive? In‑memory variables, timers, open HTTP calls, callbacks, and promise chains. Identity and state persist. Compute is event‑driven.
Wake sources are straightforward. Webhook callbacks: the agent kicks off external work, registers its callback URL, and hibernates until it arrives. Polling with backoff for services without callbacks. The agent schedules polls, increases intervals, and caps the delay. Wide, multi‑step pipelines with independent retries belong in a workflow engine, not inside the agent.
Sub‑agents inherit durability. Each child owns its state, schedules, lifecycle, and colocated data. The parent need not stay active while a child works. A crash will not take down the family; each identity is recoverable on its own. Token and rate‑limit monitoring provide predictive signals, so the harness can checkpoint, throttle, or switch models before hitting limits.
“A long-running agent doesn’t run for long. It runs when needed, keeping track of tasks and context.”
Recovery starts coarse‑grained: a session reads the ledger on startup and answers “where am I.” Then persist a row for the work unit, stash intermediate state at checkpoints, and recover from the last stash on restart. Idempotency is essential, especially for webhook‑driven agents with delivery retries, to avoid duplicate side effects.
The underlying pattern is event sourcing and journaling. Maintain an immutable task ledger for the plan and a separate append‑only execution log for what actually happened: every tool call, model response, and state change. Replay it deterministically to reconstruct state on any process.
That idea underpins Restate’s journal and DBOS’s workflow/step annotations. Restate persists every step and replays deterministically, while DBOS checkpoints into Postgres. Both offer compensation and rollback to undo partial work after failures. In the durable execution landscape, evaluate DBOS, Restate, and Inngest to compare approaches.
Common capabilities include suspend‑and‑resume on external events, flow control with concurrency caps and rate limits, and expressing durability in application code versus a managed orchestration layer. You can also design durable logic in n8n using deterministic workflows, retries, persistent storage, schedules, and webhooks.
Identity is a durability property. In Cloudflare’s model, an agent’s name is the routing key that survives hibernation, restarts, and redeploys. Credentials are scoped per agent or sub‑agent. The payoff is attribution: every execution‑log entry ties back to a durable identity. At the platform level, Google’s Agent Identity and Registry track which identity, at which version, is running which task.
Task progression and evaluation: how do you verify work without an LLM‑judge?
Asking a model “is this okay” is the easiest and least reliable approach. Minimize dependence on LLM judgment and confine it to narrow, checkable roles. Progress should be validated by deterministic gates that read the live system or the execution log.
Start with a checklist. Define the completion criterion for each entry before execution. This prevents the agent from redefining “done” mid‑run. The companion rule is to work one entry per pass. That focuses on completion and simplifies validation, since each pass claims exactly one state transition.
Next, add validation gates. From cheapest to heavier: API status codes, schema validation, cross‑field consistency, state‑diff checks via re‑query, and tests. These return booleans without any model call. They are both more reliable and cheaper than LLM‑based evaluation.
Other mechanisms help too. Finite‑state machines map legal states and transitions. Sandboxing and behavioral baselines, then production allowlists for observed‑safe actions. Non‑generative, encoder‑only classifiers (BERT family, including DeBERTa, RoBERTa, ModernBERT) output a scalar against a threshold and give a verdict without text generation. Anomaly detection on tool‑call patterns kills runs with recursive loops, token spikes, or out‑of‑order execution.
“LLM-as-judge is the easiest fix and the least reliable one.”
When is LLM‑as‑judge acceptable? Only when intent is explicitly defined before execution. That means an enumerated tool allowlist, a defined step or state sequence, defined data sources, rules for spawning sub‑agents, and defined API endpoints and methods. Then evaluation collapses into Yes/No checks against the execution log.
If you use an LLM, constrain it to a narrow, checkable judgment, like “does this trace match taxonomy category X.” Here, the model acts as a fuzzy compiler mapping observed behavior onto a deterministic category, not inventing “good” on the fly.
Implementing this will span multiple products and require ongoing engineering. Do not treat it as a step‑by‑step blueprint for flawless agents. It is an exploration of deterministic components many self‑titled loop engineers overlook. We will continue exploring how this applies to n8n and the broader market. The author welcomes improvements, feedback, and corrections—reach out on LinkedIn.
Based on the provided material.
