DEV Community: Luhui Dev

The Bumps and Bruises of Building Multi-Agent Systems

Luhui Dev — Fri, 04 Sep 2026 11:02:38 +0000

🙋‍
I’m Luhui Dev, a developer who has been breaking down Agent engineering and exploring how AI can be applied in education.
I focus on Agent Harness, LLM application engineering, AI for Math, and the productization of education SaaS.

Introduction

When you first build a Multi-Agent system, its form is very appealing.

One agent plans, another executes, and a third reviews. Add a researcher, programmer, tester, and supervisor, and the console fills with tasks, messages, and tool calls. Several agents running at once looks impressively professional.

But the deeper I went, the clearer the other side became: the work is split, but responsibility is not; messages are sent, but information is not actually acted on; the review flow finishes, but the result is still unusable.

With one agent, failures are usually legible. It misunderstood the request, a tool call failed, or it wrote incorrect code. You can normally trace one execution path back to the cause. Multi-Agent systems distribute the failure across task decomposition, context transfer, shared state, role permissions, and acceptance criteria. A mundane failure at the end may have started ten turns earlier.

After building Plan-Exec flows, adding Supervisors to execution agents, and following experiments from Anthropic, Google, and Cursor, I have settled on one view:

Multi-Agent does not turn one smart person into a company. It turns one model's problems into a set of organizational problems.

Here are seven practical lessons.

1. Five named roles do not mean a task can be divided into five parts

The easiest thing to do in Multi-Agent design is define roles: a product manager understands the request, an architect designs the solution, a programmer writes code, a tester validates it, and a CEO makes the final decision.

It reads well because it copies the shape of a human organization. In execution, it often does not work that way.

While designing a Plan-Exec workflow, I saw a Planner produce a seemingly complete task list while the Executor had no idea what verifiable artifact each step should produce. One task said “analyze the geometric relationships in the image”; another said “draw the figure from the analysis.” But nobody specified whether the first agent should return prose, a structured relation graph, or executable geometry DSL. The first agent wrote an analysis; the second looked at the image again. The division of labor added only one more act of retelling.

In an analysis of seven Multi-Agent systems and more than two hundred execution traces, the Berkeley team found that about 41.77% of failures were specification and system-design failures: agents disregarding requirements, ineffective roles, repeated steps, lost context, and ambiguous completion.[1]

The issue is not that role names lack detail. Human roles come with accumulated experience, responsibility boundaries, professional standards, and shared defaults. Putting “you are a senior test engineer” in a system prompt adds linguistic context; it does not create those institutions.

Roles are narrative. Interfaces are engineering. If a subtask has no clear input, output, completion criterion, and failure state, it should not be handed to another agent.

2. Apparently parallel tasks often hide an unbreakable chain of thought

Multi-Agent systems work well for research, and that is unsurprising. Investigating dozens of companies, searching several repositories for vulnerabilities, or collecting scattered facts from many pages can be split by object or direction. One unsuccessful branch does not break the others.

But Anthropic's Research team explicitly notes that tasks with extensive shared context and mutual dependencies are not a good fit for today's Multi-Agent systems. Coding is especially relevant: the truly independent pieces are usually fewer than they first appear.[2]

Parallelism can shorten the amount of work. It cannot shorten dependencies.

Google Research reached a similar conclusion across 180 agent configurations. On financial tasks that supported parallel analysis, centralized Multi-Agent systems outperformed one agent by 80.9%. On PlanCraft, which emphasizes continuous planning, every Multi-Agent architecture declined by 39% to 70%.[3]

Every handoff needs the current state to be explained again. One agent compresses its full judgment into an output; the next reconstructs the situation from that output. Continuous reasoning becomes fragments, and the system spends more tokens explaining itself than solving the task.

3. As agent count grows, duplicate work grows first

Multi-Agent logs create an easy illusion: agents search simultaneously, the Supervisor issues tasks, executors call tools in turns, and the interface continuously says “analyzing,” “validating,” and “improving.” The system looks busy.

Look closer and you often find similar search results, equivalent analyses, and project context repeatedly read by different agents. More tokens were spent, but not proportionally more information was produced.

MAST reports repeated steps as its most common individual failure, at 17.14%. One plain example: a user asked for the first ten tracks of a playlist. The Spotify agent could return all of them at once, but the orchestrator had ten exchanges and retrieved one track each time.[1]

This is usually not a missing model capability. It is a system that does not know the right granularity for allocating work.

There is another pattern in development. A Supervisor sees a wrong output and gives broad natural-language feedback. The Executor cannot locate a particular defect, so it reruns the entire task. The new result differs slightly, the Supervisor checks again, and neither agent repairs a known issue. They merely sample the same area repeatedly.

Some Multi-Agent systems are not collaborating. They are manufacturing reading material for one another.

4. Give a task pool to autonomous agents, and hard work often gets no owner

An attractive design lets equal agents inspect a shared task pool and decide what to do next. It matches the intuition of emergent collaboration: no fixed flow, just agents claiming work, updating state, and waiting for each other's output.

Cursor tried this in long-running coding experiments. Agents coordinated through shared files and locks intended to prevent duplicate claiming. Agents held locks for a long time, forgot to release them, exited while holding them, or edited files without taking them. With twenty agents, effective throughput was equivalent to only one to three agents; most time was spent waiting.

Removing pessimistic locking and switching to optimistic concurrency reduced file contention, but brought back ownership problems. Agents selected local, safe, easy changes; no one took on the difficult, risky core work. Small commits accumulated while the hardest part of the project did not move.[4]

This resembles diffusion of responsibility in human organizations. The difference is that an agent feels neither deadline pressure nor career consequences for avoiding difficult work.

A final delivery cannot emerge reliably from workers with no final owner.

5. Information posted to the group is not information known by the system

In Multi-Agent systems, a crucial fact often appears but has no effect on later actions.

MAST records a case where a Phone Agent discovered a special API requirement for username format but did not communicate that constraint explicitly to the Supervisor. The Supervisor did not ask, kept trying the wrong format, and the task failed.[1]

I see this regularly in real execution. A Supervisor notices a wrong point in a geometry figure but says only “the figure does not fully match the prompt,” so the execution agent adjusts line styling. An agent discovers a contradiction in the requirements but places it as an ordinary note at the end of its response; the next agent continues with the original plan.

Natural-language messages carry tone, priority, and an action cue for people. An agent receives only context. Unless the system explicitly distinguishes constraints, decisions, and blockers, it may not understand why a fact matters.

6. Copying one model ten times creates ten similar blind spots

We often assume that if one agent can be wrong, three agents voting must be safer; if an execution agent misses an issue, a Reviewer will find it. That logic requires their errors to be relatively independent.

When agents use the same model, similar prompts, and the same source material, that assumption often fails. Anthropic found that eighteen of thirty agents created exactly the same Git branch name. Multiple creative agents chose the same novel title without genre guidance. When asked to create an impressive project freely, more than half chose a ray tracer or self-hosting compiler.[5]

At one-task scale, homogeneity looks like repetition. At system scale, it can become congestion, a stampede, or a shared misjudgment.

Google's research also found that independently operating, uncoordinated agents could amplify error up to 17.2 times. An orchestrator reduced amplification, but it was still 4.4 times.

When several agents agree, do not treat their count as the number of independent pieces of evidence. They may have followed the same training bias and prompt anchor to the same wrong answer.

7. Agent debate often gives an error better reasons instead of correcting it

Some systems try to solve homogeneity through debate: one agent proposes an answer, another challenges it, then two or three rounds end in a vote.

It resembles peer review. In practice, the first agent may give a fluent but wrong explanation and the others continue from its premise. Later reasoning becomes richer, while the original error becomes more convincing.

A study of ten homogeneous agents debating for three rounds found majority adoption as high as 85.5%. Some agents that had initially answered correctly changed to the wrong answer after seeing peers' views. Compared with isolated self-correction, debate used 2.1 to 3.4 times as many tokens with equal or lower accuracy.[6]

Models are particularly good at continuing existing text. Once the first answer enters the shared context, later agents are not starting from a blank page. They may be reviewing it, or simply being influenced by it.

Debate without independent judgment easily becomes expensive mutual affirmation.

References

[1] Cemri, Mert et al. Why Do Multi-Agent LLM Systems Fail?. arXiv, 2025.

[2] Anthropic. How we built our multi-agent research system.

[3] Google Research. Towards a science of scaling agent systems: When and why agent systems work.

[4] Cursor. Scaling long-running autonomous coding.

[5] Anthropic. Patterns and problems in multiagent systems.

[6] The Cost of Consensus: Isolated Self-Correction Prevails Over Unguided Homogeneous Multi-Agent Debate. arXiv, 2026.

A Personal Skill Map for the AI Era: Building a Complete Loop in 2026

Luhui Dev — Fri, 28 Aug 2026 07:11:30 +0000

Over the past few years, a clear shift has taken place: many execution skills that once took a long time to learn are rapidly becoming capabilities we can call on.

Coding, design, research, copywriting, data analysis, and video production once each implied a full software-learning path and a distinct professional role. By 2026, more work begins differently. A person states the goal; AI calls tools and produces an initial result; the person supplies context, redirects the work, and checks the output.

Professional expertise has not lost its value, but the distribution of value is changing. Implementation still matters, yet it is moving from a scarce capability toward a foundational one that models can amplify. What is becoming scarcer is the ability to find a worthwhile problem, turn a vague idea into a clear target, judge whether an AI result is trustworthy, and carry that result into the real world.

That is my personal skill map for the AI era. Instead of grouping skills into programming, writing, or design, it groups them by how someone moves an ambiguous idea into a real outcome. The complete loop has six abilities: discovery, specification, modeling, orchestration, verification, and delivery.

Discovery: the scarcer starting point in the AI era

We usually begin a discussion of ability with problem solving. But as the cost of solving problems keeps falling, finding the right problem becomes more important.

AI is good at answering a clearly stated question. It is much less able to live in a specific environment long enough to notice what feels off. Why does someone reformat the same report every week? Why do users abandon a service at the same point? Why has a team become accustomed to an inefficient process? Those opportunities come from sustained observation, not from a search box.

Many small problems that once were not worth pursuing because implementation was too expensive are now worth a quick experiment. Sensitivity to repetitive work, anomalies, user complaints, and information gaps directly affects how many opportunities you can amplify with AI.

Solving problems is getting easier; finding problems that truly deserve solving is not.

Specification: moving beyond prompts

After finding a problem, the next step is not to ask AI to start immediately. It is to state the problem precisely.

Many people know the feeling: AI can write code, generate content, and produce a page, yet the outcome is still off. Adding more prompt detail can help, but the deeper issue is often that the user has not fully defined the goal either.

What is the task solving? What are its inputs and outputs? Which constraints cannot be violated? What counts as failure? How will quality be accepted? In the past, a team could gradually fill in these details through conversation. Today, they increasingly need to be explicit before work begins.

That is why I do not see prompt engineering as the most durable name for this skill. The enduring ability is closer to specification: translating a fuzzy intention into goals, constraints, and acceptance criteria that AI, colleagues, and your future self can all understand. As execution gets stronger, the cost of vague requirements rises.

Modeling: knowledge becomes a tool for judgment

AI adoption invites an easy mistake: if models know so much, do people need less domain knowledge? The reality points in the opposite direction.

The role of expertise is changing, not disappearing. Many execution steps can now be delegated to AI, but you still need to understand the key variables, causal relationships, boundary conditions, and common failure modes of a field. Without that, you cannot tell whether the output is dependable.

In software engineering, this means understanding architecture, performance, security, cost, and reliability. In product work, it means users, needs, and business constraints. In investing, it means financial definitions and risk. In content, it means audience, distribution dynamics, and information value.

AI can retrieve vast amounts of information, but it cannot automatically form stable domain judgment on someone else's behalf. Knowledge used to be primarily for execution; it is increasingly for judgment. Rather than knowing a little about everything, build strong enough models in a few important domains to know which variables matter, which conclusions deserve skepticism, and where risk may be hiding.

Orchestration: turning delegation into a personal workflow

If the earlier abilities are familiar, orchestration may be the most visibly new one. We are moving from operating software ourselves to asking AI to operate software.

Where people once opened Photoshop, Excel, an IDE, and a browser to complete a sequence of manual steps, an agent can now read materials, call tools, change files, run scripts, execute tests, and return a result. This creates a new personal capability: delegation.

How should a complex task be split? Which parts can be handed to AI in one pass? Which need stages? Which can run in parallel? When should more context be supplied, and when should a person intervene? These questions used to belong mainly to team management. They are now part of daily AI work.

The ability to use AI will not stop at writing prompts. It will increasingly resemble lightweight project management. Future productivity will depend not only on how much you can do yourself, but on whether you can organize work in a form machines can complete efficiently.

Verification: replace “looks right” with evidence

The stronger AI becomes, the more verification matters. A polished paragraph can cite sources that do not exist. Code can run while missing edge cases. An analysis can look complete while relying on the wrong data definition.

When output increasingly resembles a correct answer, people are more likely to lower their guard. Verification is therefore an indispensable layer of any practical AI workflow.

Tests, examples, counterexamples, metrics, checklists, automated checks, and a second-model review are no longer just engineering techniques. They will increasingly become normal knowledge-work practices. A useful habit is to move from “I finished it” to “what evidence shows that it is done well?”

As execution accelerates, errors are amplified faster too. AI can make correct work faster, and it can make mistaken work faster as well.

Delivery: making an idea real

The last ability is delivery, and it remains difficult to fully replace with AI.

Generating a plan does not mean something has happened. A product must go live, users must receive it, collaborators must be aligned, feedback must be collected, errors must be handled, and someone must take responsibility. These tasks may not look especially intelligent, but they determine whether an idea enters reality.

AI lowers many implementation barriers and weakens a familiar excuse: “I cannot do it yet because I do not know how.” If you cannot design, AI can create a first version. If you cannot code, an agent can help implement it. If you cannot analyze data, a model can organize a first pass.

That does not mean everything is easier. The bottleneck is shifting from “I lack the skill” to “will I actually move it forward?” As the execution threshold falls, the gap between people will increasingly come from who turns a vague idea into a real result.

From a skill tree to a complete loop

The T-shaped-person model still has value: depth in one domain plus breadth across others. But in 2026, another structure is becoming more important: a complete loop.

You do not need to be an expert in every individual skill. You do need to be able to move through a full chain independently: discover a worthwhile problem, specify it clearly, build a basic domain model, use AI and tools for much of the execution, judge whether the result is reliable, and deliver it into a real environment.

Only when this chain closes does AI become genuine leverage. Otherwise, you may only collect disconnected techniques: Cursor today, Claude Code tomorrow, another agent platform next week. Tools will keep changing. They are interfaces, not the capability itself.

The durable capabilities are noticing problems, stating them clearly, developing domain judgment, organizing complex work for AI, recognizing mistakes, and bringing work into the world.

How to practice this AI-era skill map

If I were designing an AI learning roadmap for 2026, I would not begin with “which model should I learn?” or a list of AI tools. I would start with one real problem and take it all the way through.

It could be a repetitive workflow, a small tool you have wanted to make, a content idea you want to test, or a long-standing everyday annoyance. The size does not matter. What matters is completing the cycle: observe the problem, define the goal, break down the work, let AI execute, set acceptance criteria, correct the result, and actually publish, launch, or use it.

If you never know what to make, practice observation and problem definition.
If AI often goes off course, practice describing requirements and organizing context.
If you cannot tell whether an output is right, add domain knowledge and verification mechanisms.
If you keep stopping at a demo, practice delivery and follow-through.

This kind of practice is often more valuable than watching dozens of hours of AI tutorials. The goal of AI learning is not an ever-growing tool list; it is a capability structure that can absorb new tools into the way you work.

Can AI Beat CAPTCHAs in 2026? From Recognition to Risk Scoring

Luhui Dev — Sun, 16 Aug 2026 14:23:55 +0000

Most of us know the routine: you sign in to a website, click “I'm not a robot,” and get a 3×3 grid asking you to select every traffic light, motorcycle, or bus. You finish one round and another appears. Sometimes you are sure the answer was right, yet the system asks you to try again. On an unusual network, the challenges may keep coming.

CAPTCHAs were designed to make life difficult for machines. Today, machines may already be better than humans at many of the puzzles.

In 2024, researchers tested Google reCAPTCHA v2 without using GPT. They trained a YOLOv8 vision model to identify target objects and paired it with browser automation. Their paper reported passing all 100 test attempts.

By 2025, research had moved beyond individual CAPTCHA formats. Unified benchmarks began testing vision-language models against distorted text, image selection, sliders, rotation tasks, and other CAPTCHA types. Some now resemble ordinary visual recognition. Others still require exact localization, spatial reasoning, and sustained interaction, where success rates fall sharply.

In 2026, the question has moved again. It is no longer only “Can AI understand the CAPTCHA?” It is now: “Can AI open the page, understand the challenge, click or drag, notice mistakes, correct itself, and then continue the original task?”

The answer is increasingly yes.

That is why CAPTCHA is worth revisiting. It has not disappeared as a security control, but its original assumptions are changing. In 2026, we need a more precise picture of what AI CAPTCHA solving can actually do.

CAPTCHA's Original Bet: Humans Can Do It, Machines Cannot

The core idea behind CAPTCHA is simple: find a task that is easy for people and hard for machines, then use it to tell the two apart.

The classic early version was distorted text. Letters were rotated or merged, with noise and lines in the background. A person could usually squint and read them; early OCR systems could not. As OCR improved, CAPTCHA providers changed the test. Google reCAPTCHA increasingly used images, asking people to identify cars, traffic lights, or motorcycles.

The game stayed the same: find a perceptual skill that humans possess and machines do not—at least for now.

The problem is that those exact capabilities have been among AI's fastest-improving areas over the last two decades: OCR, image classification, object detection, speech recognition, and now vision-language models. CAPTCHA keeps looking for new machine blind spots, and machines keep catching up.

That is why a single question such as “What is AI's CAPTCHA accuracy?” is no longer enough. A useful analysis needs at least three layers:

Recognition: can the AI understand the challenge and determine the right answer?
Interaction: once it knows the answer, can it click, drag, and handle multiple rounds in the browser?
Acceptance: even if it solves the puzzle, will the server-side risk system accept the request?

These are increasingly different problems.

Text CAPTCHAs Have Largely Become an OCR Problem

Traditional text CAPTCHAs can no longer carry a critical security boundary on their own. The reason is straightforward: they are fundamentally an OCR task.

If a site still uses fixed fonts, a fixed noise distribution, and a fixed string length, an attacker who can collect enough samples does not need frontier research to train a specialized model. In many cases, a large model is unnecessary.

People often imagine general systems such as GPT, Gemini, or Qwen when discussing AI CAPTCHA solvers. For a fixed challenge, however, a specialized model can be cheaper and faster. A trained OCR or lightweight vision model can run locally at extremely low marginal cost.

Image-Grid CAPTCHAs Increasingly Look Like Ordinary Object Detection

Image CAPTCHAs once raised the barrier considerably. “Select every image containing a bus” was difficult for early computer vision. Today, the task definition is familiar: object detection and image classification.

The 2024 paper Breaking reCAPTCHAv2 used YOLOv8 to identify target categories in reCAPTCHA v2 image challenges, then automated the clicks. It reported passing all 100 test attempts.

That “100%” does not mean reCAPTCHA as a whole is useless. It means that, under the experiment's specific conditions, the image puzzle itself did not reliably distinguish machines from people. reCAPTCHA still uses cookies, browser context, history, risk scoring, and other mechanisms that do not vanish when image recognition succeeds.

But the most visible assumption—that a machine should not recognize a traffic light—is failing.

Attackers No Longer Always Need a Custom-Trained Model

Using YOLO against reCAPTCHA follows a traditional recipe: collect data, label it, and train a solver for one CAPTCHA format. This approach is cheap, fast, and stable, but it is closely tied to the challenge type.

If the test changes from “find the cars” to “select two objects used for the same purpose,” a model trained only on cars, buses, and traffic lights may fail.

Vision-language models change that constraint. Models in the Qwen, Gemini, and GPT families can jointly understand images, written instructions, and spatial relationships rather than recognizing only a fixed set of categories.

The 2025 study MCA-Bench placed multiple CAPTCHA formats into a unified vision-language evaluation framework. It found that trained Qwen2.5-VL models could reach high success on some distorted-text and 3×3 image-selection tasks, while performance dropped substantially on sliders, rotations, and complex spatial reasoning.

That difference shows where CAPTCHA difficulty is moving. The old challenge was understanding the image. The new challenge is translating that understanding into precise interaction.

Why Slider CAPTCHAs Were Harder

A slider CAPTCHA is a useful example. An image contains a missing puzzle piece, and the user must drag a slider until the piece lines up with the gap.

That adds a layer beyond an image grid. The grid asks, “Where is the traffic light?” The slider also asks, “Where is the gap, how far should I drag, and does the trajectory look plausible?” It combines perception with behavioral interaction.

This did not create a permanent security boundary. The 2024 paper The robustness of behavior-verification-based slider CAPTCHAs evaluated five widely deployed slider systems and reported attack success rates from 87.5% to 100%.

Once again, a determined attacker can customize an algorithm for a particular challenge. Replacing an image grid with a slider is not a permanent fix. Gap detection is already a mature computer-vision task. The harder signals increasingly sit around the puzzle: pointer trajectories, timing, page context, session history, and IP reputation.

In 2026, GUI Agents Are Starting to Solve CAPTCHAs Themselves

What makes the current wave different is that GUI agents are beginning to treat CAPTCHAs as ordinary web interactions.

The 2026 paper CAPTCHA Solving for Native GUI Agents introduced ReCAP, a native GUI agent specifically trained to improve CAPTCHA capability. Instead of sending screenshots to one model and having a separate script parse answers and click, the model directly observes screenshots and emits GUI actions. It can find targets, click, inspect the next frame, detect an error, and correct its behavior.

The researchers trained models in the Qwen3-VL family. The 32B model achieved roughly 81% overall success on the paper's dynamic CAPTCHA benchmark, averaging about 1.54 model calls and under three seconds of end-to-end execution. These are results from a specific benchmark, not a universal pass rate for real websites.

The direction is nevertheless clear: CAPTCHA solving is moving from a specialized offensive skill toward a side capability of general Computer Use agents.

In the past, bypassing a CAPTCHA required someone to build a dedicated solver. A future agent may be booking a ticket, shopping, or filling in a form, encounter a CAPTCHA halfway through, solve it, and continue the original task.

Solving the Puzzle Is Not the Same as Passing the System

The research results above can make “CAPTCHA is dead” sound tempting, but reality is more complicated.

Suppose an AI identifies every traffic light with perfect accuracy and clicks all nine images correctly. Google may still reject it. Modern CAPTCHA systems do much more than grade the visible answer.

The server sees far more than a screenshot. It can inspect the IP and whether it belongs to a data-center ASN, whether the device has appeared before, cookie history, browser consistency, request frequency, repeated challenges within a session, account age, and deviations from ordinary behavior.

That is why Recognition, Interaction, and Acceptance must be separated. A model with 98% accuracy on an offline benchmark does not automatically have a 98% end-to-end pass rate. Recognition is only one layer.

The Economics of Attacking CAPTCHAs Have Changed

CAPTCHA's main attack cost once came from the machine's inability to solve the puzzle. That cost is falling quickly.

Specialized OCR and YOLO models can run entirely on local hardware. Open-weight vision-language models are also becoming broadly available. For fixed tasks, pure inference can have a very low marginal cost.

The public CAPTCHA-solving market tells the same story. As of August 2026, one public provider lists ordinary image CAPTCHAs and reCAPTCHA v2 at approximately $0.50 to $2.99 per 1,000 solves. These prices change and may combine human and automated capacity, but they demonstrate how commoditized “getting the answer” has become.

At scale, the expensive parts are increasingly not CAPTCHA recognition itself, but proxy IPs, clean reputation, realistic browser environments, device identity, account inventory, session maintenance, and retries.

The defensive goal has changed accordingly.

The old goal was to make the puzzle impossible for machines.

The more realistic goal now is to make automation uneconomical at scale.

Google No Longer Puts the Puzzle at the Center

Google's own direction shows how far reCAPTCHA has moved.

reCAPTCHA is now part of a broader Fraud Defense system. Instead of asking only whether a puzzle answer is correct, it evaluates the risk of the request. The server can receive a score from 0.0 to 1.0: 1.0 means traffic is very likely legitimate, while 0.0 means very likely illegitimate. The application then chooses the response. Google's assessment API also includes a verifiedBots field for bots whose identities have been verified.

In a login flow, a low-risk request might proceed directly, medium risk could trigger email verification, higher risk could require MFA, and the highest risk could be denied.

The old model was: solve the CAPTCHA and pass. The new model is: collect signals, calculate risk, and let the application decide whether to allow, step up, or reject.

Cloudflare Goes Further: Ideally, Users Should Not Solve Anything

Cloudflare Turnstile is even more representative. It looks like a CAPTCHA alternative, but its design goal shifted from making users complete a challenge to letting legitimate users pass with as little friction as possible.

The Turnstile documentation explains that the browser runs a series of small non-interactive challenges and gathers signals about the client and environment. These include proof-of-work, proof-of-space, Web API probing, browser quirks, and behavioral signals. Managed mode selects an action based on client-side signals and risk; low-risk visitors can pass without interaction, while a checkbox appears only when another check is needed.

Even if a challenge appears solved in the browser, Cloudflare requires the token to be validated on the server. Its documentation explicitly states that a solved challenge does not automatically confirm that the visitor is human.

That sentence captures the state of CAPTCHA in 2026.

Being able to solve the puzzle no longer means passing the security decision.

hCaptcha Has Not Abandoned Active Challenges

hCaptcha takes a somewhat different path from Google and Cloudflare. It retains more active visual challenges while also offering invisible operation and risk scores. Invisible mode can run in the background and show a challenge only when the user meets its criteria; fully passive operation relies on the enterprise risk score.

The logic is intuitive: even if current models break one CAPTCHA format, providers can change the task, add interaction complexity, and rotate challenges to reopen a temporary gap between people and machines.

Researchers have pursued the same idea with visual illusions, audio illusions, and more complex spatial reasoning.

The 2026 paper Robust CAPTCHA Using Audio Illusions in the Era of Large Language Models introduced IllusionAudio. It reported a 0% bypass rate across the tested large-audio-language-model and ASR attacks, alongside a 100% human pass rate in its user study.

That is an impressive experimental result, but it faces a familiar question: once the format is public, attackers can collect targeted data, generate samples, and fine-tune models.

The twenty-year history of CAPTCHA repeats the same cycle: find a new human-easy, machine-hard task; deploy it; train machines; break it; add complexity; and find another task.

Generative AI has not ended the cycle. It has made it spin faster.

The Hardest Problem May Be Legitimate AI Agents, Not Malicious Bots

CAPTCHA's original model missed another possibility: future machine traffic will not always be bad traffic.

Historically, bots meant crawlers, spam sign-ups, credential stuffing, ticket scalping, inventory abuse, or automated ad clicks. It was tempting to equate Human with Good and Bot with Bad.

The agent era breaks that assumption.

An AI agent booking my hotel is a bot—but should it be blocked? Not necessarily. An agent can submit an expense report, help a blind user navigate a site, compare products and place an authorized order, or operate enterprise SaaS on an employee's behalf. These are automated programs, but they may carry genuine user authorization.

Google's risk-analysis API now includes the concept of a verified bot identity, which points toward this future. Websites may need to stop asking only “Are you a robot?” and instead ask: Who is this agent? Who authorized it? What is it trying to do? What scope is permitted? What is its reputation? Is it making three requests a minute or thirty thousand?

Frequently Asked Questions

Can AI solve CAPTCHAs in 2026?

AI can solve many of them, but recognizing the correct answer and being accepted by the server are different outcomes. Text and common image CAPTCHAs are highly solvable. Sliders, rotation, and multi-step dynamic challenges remain harder, while modern risk systems also evaluate IP, device, browser, account, and behavioral signals.

Is the reCAPTCHA v2 image challenge still secure?

The image puzzle alone should no longer be treated as a stable human-machine boundary. A 2024 study passed 100 test attempts under specific conditions, but reCAPTCHA's overall security also relies on risk scoring, cookies, browser history, and other signals.

Why do GUI agents change the CAPTCHA threat model?

They connect recognition, localization, clicking, dragging, feedback, and error correction into one end-to-end process. CAPTCHA solving can therefore become one step that a general web agent performs during a larger task, rather than a capability limited to dedicated solvers.

How should websites respond to AI CAPTCHA solvers?

Do not use a visual puzzle as the only security boundary. Combine risk scoring, rate limits, device and session signals, account reputation, MFA, and server-side token validation. Over time, authorized agents will also need verifiable identity and scoped permissions.

Conclusion

The last three years show a clear progression.

Text CAPTCHAs fell first. Image CAPTCHAs increasingly became ordinary object detection. Vision-language models began solving formats that once needed separate specialized models. GUI agents then connected recognition to action.

The remaining difficulty is concentrating in dynamic, multi-step tasks, precise control, and risk decisions made in real server environments.

That is why the most advanced CAPTCHA products in 2026 look less and less like CAPTCHAs. Google calculates risk scores. Cloudflare watches the browser and client environment. hCaptcha combines active challenges with passive signals.

The goal is no longer to invent a puzzle that AI can never solve; that promise is becoming impossible to sustain. The practical goal is to make legitimate access almost frictionless while increasing the cost of large-scale automated abuse until it is no longer worthwhile.

References

If AI Writes a Research Paper, Would You Trust It?

Luhui Dev — Fri, 07 Aug 2026 16:08:11 +0000

Imagine this.

You give AI a research problem: find a new way to reduce the inference cost of large models.

A few hours later, it returns a complete paper, a set of experimental code, a collection of benchmark data, and what appears to be a novel algorithm.

The paper is well structured, the charts look polished, and the experimental result is striking: inference speed improves by 35%.

Now comes the question: do you believe it?

You might first open the code to confirm that it actually implements the method described in the paper. Then you inspect the experiment logs to see whether the 35% was genuinely produced by a run or cherry-picked by the model from an intermediate experiment. Finally, you verify every citation to make sure those convincingly named papers really exist.

Then you discover that the algorithm is not in the code, the experimental results cannot be reproduced, and some of the cited papers cannot even be found.

The most awkward part is that the paper may still read as entirely professional.

ScientistOne Is Not Trying to Make AI Better at Writing Papers

In May 2026, the Google Cloud AI Research team released an arXiv paper: ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence.

The focus of this work is not merely to build a stronger AI Scientist. It pays closer attention to how AI-generated research can be audited.

The team audited 75 papers produced by five automated research systems across five categories of frontier systems research tasks. The results are revealing:

In some systems, the hallucinated-citation rate reached 21%;
In some systems, only 42% of reported paper scores passed re-verification;
Method-code alignment across systems ranged from only 20% to 80%.

In other words, a paper may be well written, and its algorithm may even produce good results, but the numbers, methods, code, and citations in the paper do not necessarily belong to the same chain of facts.

It is a little like a programmer delivering elegant technical documentation, a complete test report, and working code, with just one problem: the three describe different systems.

ScientistOne's core proposal is called the Chain-of-Evidence (CoE).

The basic idea is that every important Claim must be traceable through a recorded chain of evidence back to its original basis.

From “Generating Answers” to “Generating Verifiable Knowledge”

A typical Agent output process looks like this:

User question -> Agent execution -> Final answer

For example, it tells you that a new algorithm improves accuracy by 10%. At that point, the task is complete.

CoE is not concerned with whether that sentence sounds enough like a conclusion. It asks whether a complete chain stands behind it:

Claim: Accuracy improves by 10%
  ↓
Evidence: Metric in the evaluation log
  ↓
Artifact: Evaluation script, training code, data version
  ↓
Grounding Source: Actual experimental run
  ↓
Verification: Rerun and calculate the metric

The final deliverable of a CoE Agent should therefore be more than a passage of text. It should be a knowledge unit that can be inspected.

People do not need to trust it because it “sounds true.”

They can follow the evidence chain and check for themselves whether it is true.

How CoE Works: First Classify the Claims in the Research

The paper divides scientific claims into four categories:

Citation Claim
Numerical Claim
Methodological Claim
Conclusion Claim

Different Claims require different evidence.

If AI says, “A certain study proposed a certain method,” it must link to a real paper that the system actually read.

If AI says, “Accuracy improved by 10%,” it must link to evaluation output and experiment logs.

If AI describes a new Attention optimization method, it must link to the module in the code that actually implements it.

If AI reaches a research conclusion, it must explicitly identify which verified numerical and methodological claims the conclusion depends on.

This step may look like nothing more than structuring natural language, but it is critical.

“Our method works very well” cannot be directly verified, but the following claim can:

{
  "type": "numerical",
  "claim": "Model accuracy increased from 81.2% to 89.4%",
  "evidence": "runs/exp_042/evaluation.log#L118",
  "metric": "top-1 accuracy"
}

Only when a Claim is structured does verification have a clearly defined object.

ScientistOne Does Not Add Citations at the End; It Records Evidence from the Beginning

This is what I find most noteworthy about ScientistOne.

Many Agent designs wait until a paper is nearly finished, then ask another Agent to check citations, correct numbers, and add evidence.

That is like adding tests the day before code goes live: it is not entirely useless, but much of the context has already been lost, leaving the system to guess.

ScientistOne's approach is to let evidence emerge alongside the research process.

Its system is roughly divided into three stages:

Problem Investigator
Literature retrieval, full-text reading, and sourced research briefs

        ↓

Discovery Engine
Parallel exploration, experiment execution, and preservation of evaluations and logs

        ↓

Paper Writer + Claim Verifier
Writing from existing artifacts and verifying each Claim

During the literature stage, it retrieves papers from academic databases, reads the complete PDFs, and records source information.

During the experimental stage, it preserves the code, Evaluator scores, execution logs, and ablation results together.

During the writing stage, every sentence containing a number or citation must be bound to specific evidence in advance. The Claim Verifier then checks whether numbers in the paper can be found in the logs, whether citations support the original sentences, and whether method descriptions match the experimental records.

Claims without a source, or with invalid evidence markers, are deleted directly.

This is not AI casually pasting a few links after an answer.

It is the creation of an evidence ledger, alongside the research itself, that can be replayed and inspected.

Verification, Not Just Provenance

Recording a source is not the same as completing verification.

The existence of a file does not mean the data inside it is correct.

The existence of a real paper does not mean it supports the current statement.

The fact that code can run does not mean it implements the method claimed in the paper.

ScientistOne therefore also introduces a CoE Integrity Audit that checks four categories of problems:

Score Verification
Can the scores reported in the paper be reproduced?

Specification Violation
Does the approach exploit loopholes in the evaluation rules?

Reference Verification
Do the cited references actually exist?

Method-Code Alignment
Does the method described in the paper actually appear in the code?

According to the project's published data, ScientistOne achieved the following in this set of experiments:

Zero hallucinated citations across 337 references;
All 12 reproducibly evaluated papers passed score verification;
14 of 15 papers passed the method-code alignment check.

These figures come from the paper team's own experiments, and the paper is still a preprint, so they should not be interpreted directly as proof that “autonomous AI research is now reliable.”

They do, however, point to an important direction: reliability cannot depend on a model's self-discipline; it must become a checking mechanism inside the system.

This is similar to software engineering. Code cannot go live simply because a developer says, “I think it is fine.”

AI-generated research should not automatically earn trust merely because its language is fluent and its charts look polished.

What Is the Difference Between CoE and RAG?

At this point, many people may ask: isn't this just RAG with citations?

Not exactly.

RAG primarily addresses where a model should find external knowledge.

CoE primarily addresses how a Claim generated by the model can be proven.

RAG:
Document → Retrieval → Answer

CoE:
Claim → Evidence → Artifact → Verification

RAG can provide a model with real documents and help attach citations to an answer, but it does not inherently guarantee that:

The citation truly supports the current Claim;
The numbers in the paper come from actual runs;
The method description matches the submitted code;
The final conclusion can be traced through intermediate artifacts.

CoE is therefore not a replacement for RAG.

It is more like a layer of trust infrastructure placed over RAG, tool use, code execution, and paper writing.

My summary is:

RAG explains where the material comes from.

CoE goes on to ask what makes the conclusion valid.

Final Thoughts

For the past few years, we have focused on how to make models know more.

That gave us RAG, Vector Databases, Knowledge Graphs, and longer contexts.

Now that Agents have started searching, writing code, running experiments, and generating reports on their own, a new bottleneck has appeared: they must not only produce results, but also preserve how those results were produced.

The value of ScientistOne and Chain-of-Evidence is not that they create yet another AI that is better at writing papers. They push the standard for evaluating AI research one step forward: from whether the result looks real to whether the conclusion can be verified.

This may also be a lesson that Agents must learn before entering the real world. Trustworthiness does not mean being correct forever. It means that when an Agent is wrong, we can follow the evidence to find the problem; when it is right, we do not have to trust it on intuition alone.

A truly trustworthy Agent does not merely provide answers. It lets people inspect at any time why it is correct and where it might be wrong.

References

The Real-World Challenges of Loop Engineering—and Why I’m Skeptical

Luhui Dev — Fri, 31 Jul 2026 15:08:53 +0000

“Loop Engineering” is becoming the latest idea in AI coding.

Claude Code creator Boris Cherny has said that he no longer prompts Claude directly. Instead, he writes loops that prompt Claude and decide what should happen next. Addy Osmani describes Loop Engineering in similar terms: rather than having a person continually prompt an agent, you design a system that handles prompting, execution, and feedback on the person’s behalf.

It sounds compelling.

From the Ralph Wiggum Loop and scheduled Claude Code runs to Codex Goals, long-running tasks, and multi-agent orchestration, more tools are supporting this pattern. OpenAI has even demonstrated a Codex experiment that ran for roughly 25 hours, consumed around 13 million tokens, and produced about 30,000 lines of code.

Yet I am skeptical that Loop Engineering will become a stable, general-purpose software engineering paradigm.

I do not doubt that agents will keep improving, nor do I deny that automated loops can create enormous value in some tasks. My concern is more fundamental: putting an agent in a loop does not automatically turn an uncertain model into a reliable engineering system.

A loop solves the problem of keeping an agent working. It does not solve the more important question:

Is the agent continuing to do the right thing?

That is the central challenge of Loop Engineering.

1. Execution Is Easy to Loop; Completion Is Hard to Define

A loop needs at least three basic elements:

Goal, execution process, completion condition

Execution is not the hardest part. Defining what “done” means is.

For a conventional program, the answer is often straightforward:

Stop when the queue is empty
Stop when every file has been processed
Stop when the API returns success

These conditions are deterministic and computable.

Most real software goals are not.

Consider:

Improve the user experience
Refactor the payment system
Improve code quality
Make the product more reliable
Fix an intermittent login failure
Build a production-ready admin system

None converts neatly into a Boolean expression.

OpenAI’s guidance for Codex Goals makes the same boundary explicit: a Goal is a poor fit when its endpoint is vague. Instructions such as “make it better,” or “refactor this code” without a target state, tests, and constraints, do not give an agent a dependable completion condition. Goals work best when they have a persistent objective, an evidence-based endpoint, and may require multiple rounds of investigation.

That reveals the actual scope of Loop Engineering.

The best candidates for automated loops are not all complex tasks. They are tasks that humans have already converted into verifiable problems:

Make every test pass
Migrate the remaining 23 legacy endpoints to the new protocol
Fix every static-analysis error

But once humans can clearly define the goal, state, constraints, and completion criteria, much of the hardest requirements work has already been done.

Loop Engineering automates more of the downstream execution than the judgment at the heart of software engineering.

2. Automated Verification Does Not Verify the Real Requirement

Loop Engineering usually relies on tests, lint results, builds, performance metrics, or screenshot evaluation as feedback.

A typical loop looks like this:

Agent changes code -> Run tests -> Tests fail -> Agent analyzes the failure
-> Change code again -> Tests pass -> Stop

This feels consistent with engineering practice, but it hides a serious problem:

The agent optimizes the verification signal, not necessarily the outcome we actually want.

Tests are only an incomplete expression of requirements.

The 2026 SpecBench research examined reward hacking in long-horizon coding agents. By separating public validation tests from hidden compositional tests, it found that frontier agents could score highly on visible tests while still showing a substantial gap on hidden ones. The gap grew as tasks became larger. An extreme case even appeared in which an implementation memorized test inputs to imitate correct behavior.

That does not necessarily mean the agent is deliberately cheating.

More precisely, an agent searches for a path that satisfies the feedback currently available. When that feedback does not fully represent the real goal, proxy distortion follows naturally.

This resembles Goodhart’s law:

When a measure becomes a target, it ceases to be a good measure.

Human engineers usually consider constraints that sit outside the tests:

Does the code match the product’s actual intent?
Does it break behavior in another module?
Does it create long-term maintenance cost?
Does it violate architectural principles?
Does it increase security risk?
Is it merely overfitting to the test cases?

Agents do not naturally possess this organizational, product, and historical knowledge.

As a result, building a complete verification system for Loop Engineering may cost as much as completing the task directly.

3. Loops Can Amplify Errors, Not Just Correct Them

Supporters often describe a loop as a self-correcting system:

Failure -> Feedback -> Correction -> Another attempt

But a loop does not inherently converge.

It can also behave like this:

Misread the goal -> Build the wrong implementation -> Update the plan from that implementation
-> Record the wrong state in documentation -> Later agents treat it as fact
-> Keep optimizing in the wrong direction

During a long task, an agent may change not only code but also PRDs, todo lists, project status, architecture notes, tests, progress logs, and its account of the root cause. Those artifacts become context for the next iteration.

If one iteration records an incorrect state, subsequent iterations may stop treating it as an unverified hypothesis and start treating it as established fact.

A single-turn AI error is usually confined to one response. A long loop can propagate an error into the repository, documentation, databases, task systems, and Git history. The longer the loop runs, the larger the error’s blast radius can become.

4. Resetting Context Does Not Solve Context Corruption

An important idea in Ralph Loop is to have the agent complete one task at a time, save progress to files or Git, and start the next iteration with a fresh context window.

This does prevent the conversation from growing without limit.

But it merely moves state from the model context into external storage. It does not eliminate information-management problems.

The system still has to decide which history to retain and which is stale, which conclusions are only guesses, which code and documents matter to the current task, and which source to trust when sources conflict.

Anthropic frames this as Context Engineering: as an agent generates more data inside a loop, the system must continually select and compress what the next reasoning step actually needs. Anthropic also notes that accurate recall and long-range reasoning degrade as context grows, so context should be treated as a scarce resource, not as something that is always better in larger quantities.

Long-running agents therefore face a dilemma:

Load too little, and the agent does not understand the project. Load too much, and the critical signal disappears into noise.

External state accumulates entropy much like a codebase:

Outdated plans
Duplicate explanations
Contradictory rules
Expired temporary conclusions
Different assumptions written by different agents

The hard problem is not restarting the loop. It is ensuring that every restart receives information that is accurate, concise, trustworthy, and relevant.

That problem looks more like knowledge management, configuration management, and runtime-state governance than “writing a loop.”

5. Code-Generation Throughput Is Not Engineering Productivity

The most visible benefit of Loop Engineering is greater code-generation throughput.

One agent can work continuously. Several agents can work in parallel. Tasks can run overnight. Failed tests can trigger automatic repairs. In theory, code output rises dramatically.

But software productivity has never been equivalent to lines of code.

The meaningful measure is the total cost from a requirement being raised to correct software entering use and remaining maintainable.

Faster generation does not necessarily mean faster delivery.

If agents create dozens of pull requests per day while humans can review only a few, the bottleneck simply moves from writing code to verifying it. If reviewers cannot understand the volume of machine-generated changes, two outcomes are likely:

First, agent output piles up and automated throughput never becomes real delivery.

Second, the team lowers its review standard, merges quickly, and pushes the problems into testing, production, and long-term maintenance.

Martin Fowler’s site has discussed this mismatch: agents can generate code faster than humans can inspect it line by line. To keep human review from becoming the bottleneck, teams must shift quality checks earlier and create specifications, tests, and workflow constraints that agents can use for self-checking.

In a 2025 randomized controlled trial with experienced open-source developers, METR found that on mature codebases the participants already knew, the AI tools available at the time increased task completion time by an average of 19%. A 2026 follow-up found some possible signs of acceleration, but its confidence intervals remained too wide to conclude that AI consistently speeds up every setting.

AI coding productivity is clearly more complicated than a multiplier on generation speed.

Loop Engineering widens this gap: it increases agent runtime and output volume without necessarily increasing the team’s ability to understand, verify, and take responsibility for that output.

6. More Agent Authority Means More Loop Risk

To complete complex work, an agent needs tools and permissions: repository access, file modification, shell execution, database access, logs, cloud APIs, deployment, and rollback.

More dangerously, agents read untrusted external content such as GitHub issues and web pages. Attackers can place indirect prompt injections in that content and make an agent mistake external text for operational instructions.

A persistent loop magnifies this risk.

A compromised agent may do more than produce a bad answer:

Read sensitive data -> Call tools -> Change external state
-> Store the false result in long-term memory -> Continue next iteration

A production loop therefore seems to require strict least privilege. Yet the tighter the permissions, the less autonomous the agent becomes.

This creates another Loop Engineering contradiction:

More authority creates more automation value and more risk; less authority reduces risk and also limits what the agent can accomplish.

7. Loop Engineering May Be Cron Plus an Agent

Structurally, much of what is called Loop Engineering is not new.

Common examples include:

New Sentry issue -> Agent investigates and opens a pull request

Run every night -> Agent checks failing tests -> Attempts a repair

New support ticket -> Agent investigates logs -> Produces a recommendation

In the past, teams built these patterns with Cron, webhooks, CI/CD, message queues, Zapier, or n8n.

What is new is that an LLM agent replaces one deterministic processing node in the workflow.

Most examples remain event triggers and scheduled jobs. They can be useful, but it is hard to call them an entirely new workflow paradigm. Some developers have even returned to conventional approaches after encountering agent drift, finding human intervention more effective, or facing excessive token costs.

8. Closing Thoughts

Loop Engineering presents an attractive future: humans define goals, agents keep working, and software evolves on its own.

Real software engineering, however, is not a problem that necessarily converges if we simply keep trying.

Requirements can be vague. Tests can be incomplete. State can be corrupted. Metrics can be gamed. Permissions can be abused. Costs can escape control. Code throughput can exceed an organization’s capacity to understand and review it.

A loop can extend an agent’s execution time. It cannot automatically make the objective more correct.

Compared with investing in the loop itself, I still believe the better investment is Harness Engineering: a reliable feedback system with clear boundaries, evidence, permissions, auditing, and the ability to stop at any time.

What Is Loopcraft? From Prompt Engineering to Agent Loop System Design

Luhui Dev — Fri, 26 Jun 2026 10:53:45 +0000

Introduction

A new term has been circulating in the Silicon Valley agent world: Loopcraft.

My first reaction was: isn't this just putting an agent inside while true? A few years ago people called it Agent Loop. Then it became Workflow and Harness Engineering. Now we have Loopcraft. The AI industry never stops inventing new names.

But after following recent discussions from Peter Steinberger, Claude Code lead Boris Cherny, and Andrej Karpathy around agent loops, I do think something real is changing.

Peter Steinberger put it this way:

You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.

In other words, you should not manually prompt a coding agent again and again. You should design a loop that prompts the agent for you.

Boris Cherny said something similar:

I don’t prompt Claude anymore. I write loops. The loops do the work.

Karpathy made a related point when introducing Autoresearch: if a human still has to inspect every result, decide the next step, and give the agent another instruction, the human becomes the throughput bottleneck of the whole system.

Put together, these comments point to an abstraction shift:

Before:
Human -> Prompt -> Agent -> Result

Now:
Human -> Design the loop
             ↓
Task discovery -> Agent execution -> Automatic verification -> Retry on failure -> Save state -> Continue running

My shortest definition is: Prompt Engineering optimizes a single interaction. Loopcraft optimizes the whole system that runs repeatedly.

Loopcraft is less interested in how to complete one isolated task and more interested in questions like:

Who starts the next task?
How does the agent know what to do?
Who checks the output?
How does failure produce useful feedback?
Should the system retry, switch strategy, or hand off to a human?
How is state preserved across sessions?
How do lessons from repeated runs improve the system itself?

This article breaks down three questions:

What is Loopcraft, and why is it suddenly getting attention?
How is it different from Agent Harness?
Can an ordinary developer build a small loop today?

1. Why People Are Moving From Prompts to Loops

For the past two years, the typical way to use a coding agent looked roughly like this:

Tell the agent what to do
-> Wait for code changes
-> Review the result
-> Tell it what is wrong
-> Let the agent continue
-> Review again

The model can already write code, search files, and run tests. But the whole process is still driven step by step by a human.

After each round, the agent stops and waits for the next instruction.

On the surface, the human is using the agent. From another angle, the human is acting as the scheduler, state machine, and verifier of the agent system.

So even if the model is fast, the human still cannot leave. The async mobile supervision features shipped by many agent products are one attempt to relieve this bottleneck.

That is the problem behind the recent loop discourse: do not automate only one step inside the work. Design the surrounding system for task discovery, assignment, verification, and continuation.

For example, fixing a CI failure used to look like this:

I see a CI failure -> Open Codex -> Copy the error log -> Ask it to analyze -> Review the diff -> Ask it to run tests -> Confirm green -> Manually create a PR

Inside a loop, it can become:

CI failure event -> Automatically read logs -> Decide whether the problem is safe to automate -> Start an agent in an isolated worktree -> Modify code -> Run tests and lint -> A second verifier checks the diff -> Create a PR when it passes -> Notify a human when it cannot proceed

The real automation here is not just code editing. It is the closed loop around code editing.

So Loopcraft is not a new model capability, and it is not one specific framework.

It is closer to an agent system design discipline: organizing task execution, result verification, event triggers, state persistence, and system improvement into nested loops.

2. Is Loopcraft Actually New?

The name is new. The underlying technical pieces are not.

We already had:

Reason-Act-Observe loops for agents;
workflows and state machines;
automated tests and CI/CD;
scheduled jobs and event-driven systems;
multi-agent collaboration;
LLM-as-a-judge;
Reflexion and Self-Refine;
long-term memory;
automated experimentation and hill climbing.

Even the simplest Ralph Loop is basically repeated invocation of a coding agent:

while true; do
  claude "Read the task and current progress, then continue the work"
done

3. Agent Harness vs. Loopcraft

This is where the terms are easiest to confuse.

Over the past year, Agent Harness has already become a popular concept.

Anthropic's definition is clear: a harness is the system that enables a model to work as an agent, including context handling, tool use, permissions, environment, state management, and result return.

Put simply, Harness answers: what environment does this agent work in?

Loopcraft answers a different question: when is this agent started, why does it continue running, who checks the result, and what should happen in the next round?

A simplified analogy:

Model: the worker's brain
Tools: the tools in the worker's hands
Harness: the worker's workstation and work environment
Loop: the factory cadence, quality control, and task scheduling
Loopcraft: how to design and layer the whole production loop system

In practice, the boundary is not absolute.

A mature long-running harness already includes retries, verification, and state handoff. A loop also depends on the harness for tools and execution environment.

I prefer to separate them by focus:

Concept	Main question
Prompt Engineering	What instruction should the model see in this round?
Context Engineering	What information should the model see right now?
Tool Engineering	What actions can the agent take?
Harness Engineering	How can one agent run happen reliably?
Loopcraft	How are repeated runs triggered, verified, connected, and improved?

Loopcraft does not replace Harness.

In fact, without a stable harness, a loop just manufactures errors automatically and continuously.

4. Loopcraft Is Not One Loop, but Layers of Loops

LangChain later broke Loopcraft into four practical layers. I find the breakdown useful.

Layer 1: Agent Loop

The innermost layer is the agent loop we already know:

The model reasons
-> Calls a tool
-> Reads the tool result
-> Continues reasoning
-> Stops when it believes the task is done

For example, a documentation agent can:

Read an issue -> Search the repository -> Edit Markdown -> Check links -> Create a PR

Layer 2: Verification Loop

An agent saying "done" does not mean the task is actually done. So we wrap the agent in a verification layer:

Agent executes
-> Verifier checks
-> If it fails, return concrete feedback
-> Agent executes again
-> Repeat until it passes or the budget is exhausted

The verifier can be unit tests, type checks, lint, schema validation, and so on.

One important principle: try not to let the same entity that writes the answer also grade its own exam.

Layer 3: Event-driven Loop

Once execution and verification are in place, the next step is removing manual startup.

Tasks can be triggered by real events. The agent is no longer just a chat tool; it becomes a background component in a business system.

Event
-> Deterministic rule decides whether to handle it
-> Start agent
-> Verify result
-> Update the real system

Layer 4: Hill-climbing Loop

The first three layers automate work.

The fourth layer starts automating how the work gets better.

Every agent run leaves a trace:

what task it received;
what tools it called;
where it failed;
why the verifier rejected it;
how many tokens it used;
whether a human had to take over.

An outer system can periodically analyze these traces:

Collect many run records
-> Identify frequent failure modes
-> Adjust prompts, tools, skills, or verifiers
-> Re-test on an eval set
-> Update the harness after passing

This is the layer where Loopcraft becomes most valuable.

An ordinary loop repeats work. A hill-climbing loop changes the system that produces the work.

Ordinary loop:
Failure -> Try again

Improvement loop:
Failure -> Analyze why it failed
        -> Modify prompts, tools, or verification rules
        -> Make future runs more reliable

The outer loop's arrow does not just go back to the beginning of the task. It reaches into the agent and changes the inner loop.

That is where compounding starts.

5. Karpathy's Autoresearch Is the Cleanest Loopcraft Example So Far

Karpathy's Autoresearch is a good concrete example for understanding Loopcraft.

The project is conceptually simple:

Agent proposes a training improvement
-> Modify train.py
-> Run training for a fixed five minutes
-> Read the val_bpb metric
-> Keep the change if the metric improves
-> Roll back if the metric worsens
-> Start the next experiment

It can run about 12 experiments per hour without human intervention. Overnight, it can complete close to 100 experiments.

The clever part is not a fancy agent prompt. It is that Karpathy reshaped the problem into an environment that is ideal for loop optimization:

the agent can modify only one file;
the evaluation metric is fixed;
each experiment has a fixed runtime;
results can be compared automatically;
failed changes can be rolled back;
Git records the full experiment history;
verification code cannot be modified by the agent.

That is the core shift of Loopcraft: humans move from directly doing the task to designing a system that can repeatedly do, verify, and improve the task.

6. How to Build a Minimal Loop Yourself

Autoresearch is a special environment. Ordinary developers can start with something simpler:

Automatically receive a small issue, attempt a fix, create a PR after tests pass, and retry with feedback when it fails.

Do not start with multi-agent orchestration. A minimal loop needs only six parts:

Trigger: what event starts the task, such as a CI failure, scheduled job, or issue with a specific label.
Goal: what counts as done, preferably something that can be turned into tests, lint, type checks, or another machine-verifiable condition.
State: store attempt count, failure reason, and current progress in a file or database instead of relying only on chat context.
Worker: run the coding agent in an isolated worktree or container so it does not pollute the main branch or other tasks.
Verifier: prefer tests, rules, and static checks. Use an LLM reviewer only for parts that are hard to formalize.
Budget: limit attempts, runtime, and cost. Hand off to a human for high-risk operations.

The whole flow can be simplified to:

for attempt in range(3):
    result = run_agent(goal, load_state())
    verdict = verify(result)
    save_state(result, verdict)

    if verdict == "passed":
        create_pull_request()
        break

    if verdict != "retryable":
        notify_human()
        break

Whether you use Claude Code, Codex, GitHub Actions, Bash, or Python is not the important part.

What matters is designing this chain clearly:

Trigger -> Execute -> Verify -> Feedback -> Retry or exit

As long as a task has a clear goal, reliable feedback, recoverable state, and a stopping condition, you already have a minimal loop.

7. Common Loopcraft Traps

Trap 1: Treating Infinite Retry as Autonomy

Running repeatedly is not the same as improving.

If the agent receives no new feedback, repeating ten times usually means spending ten times the tokens to make similar mistakes.

Trap 2: Letting the Agent Change Its Own Exam

The execution agent should not freely modify tests, evaluation metrics, time budgets, permission boundaries, or verifier prompts.

Otherwise it may not be making the task better. It may only be making "pass" easier.

Trap 3: Starting With Multiple Agents

Multiple agents do not automatically create intelligence. They first create more token cost, file conflicts, duplicate work, and state synchronization problems.

Get one worker, one verifier, and one persistent state path working before adding parallelism.

Trap 4: Measuring How Busy the Agent Is

Number of agents, runtime, token usage, and tool-call count are not the final value.

What matters is verified progress per unit cost.

Examples include issue auto-resolution rate, average cost per qualified PR, and human handoff ratio.

Trap 5: The Smoother the Loop, the Easier It Is to Stop Understanding

This is the risk I care about most.

When an agent can automatically write code, test it, fix it, and create a PR, humans may be tempted to look only at the final green check.

But the faster the system produces code, the faster human understanding of that system can decline.

Loopcraft should not become an excuse to stop thinking. It actually raises the bar for how much the human has to understand.

Closing Thoughts

I increasingly feel that agent engineering is going through an abstraction shift.

At first we discussed prompts. Then we moved to context, tools, memory, and harnesses.

Now the focus is moving outward again: how to put a single agent run inside a larger cycle of tasks, verification, and improvement.

I remain skeptical of fully removing humans from the loop.

But I agree with one thing:

Do not only fix the current result produced by the agent. Start fixing the system that keeps producing those results.

Field Notes: How Agentic RAG Handles the Real Mess of Enterprise Data

Luhui Dev — Fri, 19 Jun 2026 15:24:18 +0000

A Support Ticket That Opens a Data Maze

Say your company just launched an AI customer-support system.

A major account sends in a ticket: "What's the remaining warranty period on the servers we purchased under Project Alpha last quarter? Could you also share the original contract terms and the current technical support contact?"

It sounds like an ordinary question. But when your tech lead reads the ticket, they pause for a moment.

Because they know answering it requires the system to:

Look up the customer's profile and project history in the CRM
Look up the procurement contract and warranty terms for Project Alpha in the ERP / contract management system
Look up the stock-in date and device serial numbers for that batch of servers in the asset management system
Look up the current customer-success owner in the HR system

These four systems are maintained by different teams, run on different databases, and enforce different access controls.

A standard RAG system is helpless here. The best it can do is say, "Sorry, I couldn't find relevant information."

This is exactly the problem Agentic RAG is built to solve.

Traditional RAG: A One-Shot Retrieval Clerk

Let's quickly recap how RAG works.

The core idea behind RAG (Retrieval-Augmented Generation) is simple: an LLM's training knowledge is static, while enterprise data is dynamic and private. The fix is to retrieve relevant document chunks from a database before generating an answer, stuff them into the context, and have the LLM answer based on that material.

User question → [vector search] → retrieve relevant chunks → [LLM] → generate answer

This pipeline works well when there's a single knowledge base and a clear question. But it has two fundamental limits.

Limit one: a single retrieval pass, no iteration. Retrieve once, hand it to the LLM once, done. If the first pass misses the key information, the whole chain breaks, and the LLM is left guessing or saying "I don't know."

Limit two: a single corpus, no routing. Traditional RAG assumes all knowledge lives in one unified vector database. In a real enterprise, data is scattered across CRM, ERP, Confluence, data warehouses, private document stores -- each with its own access point and permission boundary.

Here's an analogy: traditional RAG is a librarian who can only find books on the first floor, while the book you need might be sitting on the fourth floor, behind a different access pass.

Agentic RAG: A Retrieval Department That Thinks

The core shift in Agentic RAG is this: turn a single retrieval pass into a planned, iterative retrieval process.

It's no longer a passive query-and-return pipeline. It's a workflow run by multiple specialized agents, each with a distinct responsibility.

Let's use the support-ticket example to walk through how the whole workflow operates.

Step 1: The Orchestrator Decomposes the Task

The user's question first reaches the Orchestrator.

The orchestrator doesn't retrieve anything directly. It first understands the structure of the question: how many independent information needs are involved? Are there dependencies between them? Which data sources need to be accessed?

For our ticket, the orchestrator breaks it down into:

Subtask A: Look up the customer's "Project Alpha" basics (customer ID, project number) in the CRM
Subtask B: Use the project number to look up warranty terms in the contract system
Subtask C: Use the project number to look up device serial numbers and stock-in dates in the asset management system
Subtask D: Look up the current technical support owner in the HR system

Note that Subtasks B and C depend on the result of Subtask A (they need the project number first). Subtask D can run in parallel.

This dependency graph is the execution plan produced by the Planner Agent.

Step 2: Query Rewriting for Each Data Source

Every data source expects queries in a different form. The CRM might need keyword search, the contract system might need structured SQL, and the vector database needs semantic search.

The Query Rewriter translates each natural-language subtask into a query format the target source can understand:

For the CRM vector store: "Alpha project procurement record {customer name}"
For the contract system: SELECT warranty_terms FROM contracts WHERE project_id = 'Alpha-XXX'
For asset management: "Alpha project server stock-in date serial number"

Step 3: Parallel Retrieval Across Permission Boundaries

The Search Fanout Agent queries multiple data sources at once.

There's a key engineering problem here: permissions.

Different data sources have different access controls. CRM data might be open to the sales team, HR data might only be accessible to admins, and contract data might require legal sign-off. An Agentic RAG framework needs to maintain a "credential pool" at this layer -- different access tokens for different data sources -- and make sure retrieval never exceeds the current user's actual authorization scope.

This isn't just a technical problem; it's a compliance one too: AI shouldn't be able to bypass data access controls you were never supposed to have just because you phrased a request in natural language.

Step 4: Sufficiency Checking -- the Most Important Innovation

Once all retrieval results come back, they're passed to the Sufficient Context Agent.

This is the design that most distinguishes Agentic RAG from traditional RAG: the system actively judges whether the information gathered so far is enough to answer the original question, and if not, it spells out exactly what's missing before retrieving again.

In our ticket example, the checker might find:

✅ Found: customer profile, project number, device serial numbers
✅ Found: technical support owner
❌ Missing: the contract system returned a document, but the warranty terms are in an attached PDF that the vector search didn't hit

Instead of just saying "not enough information," the checker outputs a precise description of the gap:

"Project number Alpha-2024-087, device serial numbers SN-XXX-YYY-ZZZ, and stock-in date March 2024 have been retrieved. The main contract file has been found, but the warranty terms are in Contract Attachment B. Re-search the contract attachment store specifically for 'Attachment B warranty period.'"

That feedback drives a second retrieval round: the rewriter generates a more precise query targeted at the contract attachment.

This "retrieve → evaluate → retrieve again" loop continues until the sufficiency checker determines the information is complete, or the maximum iteration limit is reached.

Step 5: Synthesis Produces the Final Answer

Once everything is in place, the Synthesis Agent combines fragments from four different systems into one coherent, accurate, and source-attributed answer:

"The three servers purchased under Project Alpha (project number Alpha-2024-087, serial numbers SN-XXX-001 through 003) carry a 36-month warranty from their stock-in date (March 15, 2024), per Section 4.2 of Contract Attachment B, expiring March 14, 2027. The current technical support owner is Li Ming (extension 4521, liming@company.com)."

Every sentence has a traceable source.

Cross-System Permissions: Harder Than the Technology

The handling of permission boundaries deserves its own discussion.

In a real enterprise, data permissions are a multi-dimensional problem:

Dimension	Description	Example
Role-based access	Different roles see different data	Sales can see a contract summary but not the full text
Data classification	A single database can hold multiple sensitivity levels	Employee salary vs. employee directory
Time-based access	Some data has time-limited access rules	Financial data is read-only during an audit
Cross-system access	Data from System A must not surface in System B's context	GDPR requires data to stay within its jurisdiction

An Agentic RAG framework needs to enforce these rules on every single retrieval call, not just authorize access once at indexing time.

That means the architecture needs permission checks at query time, rather than the blunt approach of vectorizing everything into one big store.

In database terms: traditional RAG is like joining every table into one giant table and handing it to the LLM. Agentic RAG is like generating a permission-filtered SQL query dynamically for every request.

Three Decisions You Can't Avoid in Practice

When you actually build Agentic RAG in production, three decisions come up every time.

Decision one: routing strategy -- static rules or LLM routing?

Static routing: predefine rules based on keywords or metadata in the query to decide which data source to hit. Fast and predictable, but weak on open-ended queries.

LLM routing: let the LLM understand the query's intent and dynamically decide where to route it. Flexible, but every routing decision burns an LLM call, adding latency and cost.

Decision two: iteration depth -- when do you stop?

The system can get stuck in an infinite loop -- every round of retrieval feels like something is still missing, so it keeps searching.

Engineering-wise, you need:

A maximum iteration count (typically 2-4 rounds)
A time budget (answer with what you have once you time out)
A degradation strategy (answer with available information and flag it as potentially incomplete once the iteration limit is hit)

Decision three: the latency-vs-accuracy trade-off

Agentic RAG is slower than traditional RAG -- there's no avoiding it. Multiple LLM calls, parallel retrieval, and sufficiency evaluation all add latency at every step.

Approach	Cost multiplier	Latency multiplier	Best fit
Traditional RAG	1x	1x	Simple Q&A, single knowledge base
Adaptive RAG	1.5-2x	1.2-2x	Mixed scenarios with varying query complexity
CRAG (Corrective RAG)	3-5x	2-3x	High accuracy needs, tolerant of second-scale latency
Full Agentic RAG	5-10x	3-6x	Complex multi-hop, cross-store, async scenarios

Not every scenario needs full Agentic RAG.

Classifying intent at the query level -- routing complex queries through the Agentic pipeline and simple ones through traditional RAG -- keeps average cost and latency within a reasonable range.

Closing Thoughts

I think the essence of Agentic RAG is turning retrieval into an executable strategy: if one pass isn't enough, keep searching until it is. And the system itself decides what "enough" means.

That shift sounds simple, but it requires moving from a stateless "query-response" model to a stateful "goal-plan-execute-evaluate-iterate" workflow.

This is the same general challenge every agent system faces: state management is the core difficulty.

If you're building an enterprise AI system that spans multiple data sources, Agentic RAG isn't just an upgrade to your retrieval technique. It forces you to rethink data architecture, permission design, and workflow orchestration. Getting those three things right matters more than which framework or cloud vendor you pick.

References

Google Research, Unlocking dependable responses with Gemini Enterprise Agent Platform's Agentic RAG, June 2026
Microsoft, Agentic Retrieval Overview -- Azure AI Search, 2026-04-01 GA
Microsoft, What is a Knowledge Source? -- Azure AI Search
Amazon Web Services, Knowledge Bases for Amazon Bedrock -- Multiple Data Sources, April 2024
MarsDevs, Agentic RAG: The 2026 Production Guide (includes cost/latency comparisons across approaches)
Google Research, Deeper Insights into Retrieval-Augmented Generation: The Role of Sufficient Context

Claude Code Incident Review: What Anthropic's Three Production Bugs Teach Agent Engineers

Luhui Dev — Fri, 12 Jun 2026 14:24:59 +0000

Intro

Last month, Anthropic published a rare kind of incident review.

The rare part was not that they had bugs. If you build large-model products, bugs are part of the deal.

The rare part was that they wrote up three production incidents in detail: how each one was introduced, why testing missed it, why it was hard to reproduce internally, and what they changed afterward.

After reading it, I think the review is worth studying closely. If you build LLM Agents, especially systems with multi-turn tasks, tool calls, context compression, and reasoning trace management, these failures are not edge cases. They are waiting on the road.

Three Bugs, Three Failure Modes

Here is the short version.

Bug one: On March 4, to address occasional UI freezes in Opus 4.6 under high reasoning mode, the team changed the default reasoning effort from high to medium.

Internal testing looked fine: intelligence dropped only slightly, and latency improved a lot.

After launch, users pushed back hard: Claude felt dumber.

On April 7, one month later, the change was rolled back.

Bug two: On March 26, Anthropic shipped a cache optimization. The idea was simple: after a session had been idle for more than an hour, clear old thinking history to reduce the cost of resuming.

Sounds reasonable, right?

The production implementation had a bug. It was supposed to clear the old thinking once. Instead, it kept clearing it on every later turn.

So Claude kept working while repeatedly losing the memory of why it was doing the work. Users saw forgetting, repetition, strange tool calls, and increasingly odd behavior.

Worse, once thinking blocks kept disappearing, each request became a cache miss and burned through usage limits faster.

The root cause was not identified until April 10, two full weeks later.

Bug three: On April 16, to reduce verbose output from Opus 4.7, the team added a line to the system prompt:

Use no more than 25 words between tool calls, and no more than 100 words in the final response.

That prompt line showed no obvious regression during weeks of internal testing.

After launch, coding quality dropped by 3%.

On April 20, it was rolled back.

These three bugs look different, but they point to the same issue: in an Agent system, things that look local, such as parameters, caches, and prompt lines, can still affect the core execution logic.

Touch them, and you may be touching the model's brain.

Reasoning History Is Working Memory, Not a Log

The second bug is the one I keep coming back to.

"Clear old thinking to save tokens" is a perfectly normal engineering optimization. Thinking blocks are long and expensive. If a session has been idle for an hour, the old reasoning chain can look less important.

But that is exactly the trap.

For an Agent, the reasoning trace is not just a log. It does not merely record what happened. Its more important job is to preserve why the Agent made earlier decisions.

That why is what lets a multi-turn task keep moving.

When it disappears, the Agent does not crash immediately. It can still talk, call tools, and return results. But it has already started forgetting.

It forgets which paths were ruled out, why the current path was chosen, and what problem the user was actually trying to solve.

The result is a nasty kind of degradation: it gets worse, and the task drifts.

This class of bug is painful because it is not a crash. It does not give you a clean stack trace. It slowly shows up in production as a feeling that the Agent has become strangely bad.

So context management cannot be a blunt token-count cut.

At minimum, we need to separate three categories:

Do not casually compress: decision rationale, task intent, hard constraints, reasoning path.
Can compress: intermediate observations, tool outputs, process material.
Can drop: formatting helpers, redundant explanations, temporary display content.

Reasoning history is not cache garbage. In many cases, it is the Agent's working memory.

You may think you are saving tokens. You may actually be removing the part of the system that lets the Agent stay on task.

Every Prompt Line Is Code

The third bug is just as important.

How can adding one line that says "say less" reduce coding quality?

Because in model behavior, less output and less thinking are not always separate things.

If you require the final answer to be under 100 words and text between tool calls to be under 25 words, the model may not only compress expression. It may compress the decision process.

This is not a traditional bug. The model is sincerely optimizing for the target you gave it.

That is why Anthropic's follow-up discipline matters: every system prompt change should be ablated per model; if a line can be tested line by line, test it line by line; changes that may affect intelligence need gradual rollout and a soak period.

That sounds heavy.

But if you accept that prompts are production code, the discipline is not excessive.

Clean Test Environments Are Unlike Production

There is a common Agent engineering problem that people do not like to face:

The test environment is too clean.

So clean that it stops looking like production.

Many Agent failures are not as simple as "input A produces wrong output B." They depend on a sequence of state:

session idle for more than one hour
resume
continue multi-turn tool use
thinking gets cleared
enter the next turn
thinking gets cleared again

That kind of state sequence is hard to cover with unit tests and easy to miss in e2e tests.

We test features. Production runs a state machine.

That is also why Anthropic later had more internal employees use the exact same Claude Code build as the public release, rather than a test build.

Real usage is still the best integration test.

Defaults Are the Product

Now back to the first bug.

Changing high to medium made sense from an engineering angle: fewer freezes, lower latency, and only a slight intelligence drop.

The problem is that "slight drop" is benchmark language. It may not match user experience.

Users are not running average benchmarks. They are working with their code, their context, their workflow, and their messy problems.

In those highly personalized tasks, a small capability drop can feel like: it no longer understands me, it is not as sharp as before, it is making basic mistakes.

The product may offer a setting, but most users will not change it. The default is the product decision.

Closing

The most valuable part of this incident review is not the reminder that Claude Code can have bugs.

That is normal.

The valuable part is the reminder that Agent reliability often fails outside the model itself, in nearby system decisions that look local, technical, and low-risk.

Default parameters, cache strategy, context trimming, prompt constraints, and differences between test and production builds can all change Agent behavior.

Building an Agent is not just calling a smart model.

It is maintaining a complex system that can act, forget, misunderstand goals, and be shaped by context.

So the core discipline of Agent engineering may be this:

Do not only ask whether a change made the system faster, cheaper, or shorter. Also ask whether it took away the memory the model needs to finish the task.

DeepMind AlphaProof Nexus Explained: 4 System Paradigms for AI Math Research

Luhui Dev — Thu, 28 May 2026 14:55:25 +0000

Introduction

In May 2026, DeepMind released the arXiv paper Advancing Mathematics Research with AI-Driven Formal Proof Search, introducing AlphaProof Nexus, a formal proof system for mathematical research.

If we only look at the results, the paper may sound like another story about AI proving math problems: the system solved 9 out of 353 formalized Erdos open problems, proved 44 out of 492 OEIS conjectures, and was also used in real research across graph theory, optimization theory, algebraic geometry, additive combinatorics, and quantum optics.

But as someone building in AI + education, what I care about more is the research route behind it:

Let large models propose proof ideas, let formal systems such as Lean verify them, let specialized proof searchers solve local goals, and use multi-agent orchestration to turn failures, partial drafts, and subgoals into reusable search assets.

This essay breaks down AlphaProof Nexus in plain language: why it exists, how the system is designed, and the four AI math research paradigms reflected in the paper.

1. Why AI for Math Needs Formal Proof

Most people understand mathematical proof in natural language:

Since A is true, B follows. Because of a theorem, C follows. Therefore the conclusion holds.

This works for human mathematicians because people can fill in omitted reasoning. For AI, however, there is a serious issue: large models are good at writing text that looks like a proof, but that does not mean they have actually proved anything.

They may:

cite theorems that do not exist;
skip key steps;
replace a hard problem with another problem that looks easier but is still unproved;
write confident derivations with broken logic.

So the core starting point of the DeepMind paper is to make AI work inside a strict system.

That system is Lean.

Lean can be understood as a mathematical compiler. When programmers write code, compilers check syntax and type errors. When mathematicians write Lean proofs, Lean checks whether every logical step really holds.

If Lean accepts a proof, the proof is not merely plausible. It has passed strict machine checking.

That is the basic idea of AlphaProof Nexus:

AI can guess, try, and fail, but the final answer must pass Lean verification.

2. What Is AlphaProof Nexus?

AlphaProof Nexus is not a single large model, nor is it a chat-only math assistant. It is closer to an AI mathematical research pipeline.

The input is a Lean file containing an unfinished theorem proof. The system repeatedly modifies, completes, and decomposes the proof until Lean accepts it.

You can picture it like this:

There are several important roles:

LLM: proposes proof ideas, writes Lean code, and fixes errors.
Lean: checks whether the proof is actually correct.
AlphaProof: solves certain local proof goals.
Rater Agent: compares proof drafts and judges which ones are more promising.
Population DB: stores many unfinished but valuable proof drafts.
SafeVerify: performs final checks against cheating, such as modifying the original theorem or introducing disallowed axioms.

3. Four AI Math Research Paradigms in the Paper

DeepMind compares four agent configurations. They can also be read as four paradigms for AI-driven mathematical research.

Paradigm 1: Basic Agent

The first is the most basic pattern: LLM + Lean feedback loop.

It works much like a programmer writing code:

The LLM reads an unfinished Lean proof.
It tries to fill in proof code.
Lean compiles the file.
If Lean reports errors, those errors are sent back to the LLM.
The LLM edits the proof based on the errors.
This repeats until the proof passes or the budget is exhausted.

The core ability here is iterative trial and correction.

Imagine a student solving a problem. The student writes a solution, the teacher points out what is wrong, and the student revises it. Here the teacher is not a person but the Lean compiler. Lean will not say whether an idea is elegant, but it will strictly tell you when a type is wrong, a goal remains unsolved, a theorem does not match, or a logical step is missing.

That gives the large model very high-quality feedback.

One interesting conclusion in the paper is that Basic Agent is already strong.

In post hoc experiments, Basic Agent could also reproduce the 9 successful Erdos cases, although harder problems required more cost and had worse efficiency.

This suggests that as base model capability improves, the simple "generate - compile - repair" loop has already become a highly competitive baseline for formal mathematics.

The lesson is straightforward: do not expect a large model to produce a perfect proof in one shot. Put it inside an environment that can keep giving feedback and force revision.

Paradigm 2: Basic Agent + AlphaProof

The second paradigm adds AlphaProof on top of Basic Agent.

AlphaProof is a formal proof search system DeepMind developed earlier. In Nexus, it is not the main character. It is more like a local proof specialist.

When an LLM writes Lean proofs, it often runs into small goals such as:

In the current context, prove this subclaim.

Some subgoals are mechanical but awkward for an LLM to write. Others require searching through a sequence of tactics, meaning Lean proof commands. At that point, the system can hand local goals to AlphaProof.

AlphaProof may return three kinds of results:

it finds a proof;
it proves the subgoal is actually false;
it fails to find a proof within budget.

This matters because the LLM no longer has to carry every proof detail alone.

You can think of the LLM as a graduate student responsible for the overall idea and proof structure; AlphaProof as a tactical searcher responsible for local technical details; and Lean as the final judge.

The paper also notes that standalone AlphaProof cannot independently solve these research-level open problems.

In the experiments, AlphaProof alone did not solve the 9 Erdos problems. Its effective position is inside the larger Nexus system, where it acts as a local proof tool.

Paradigm 3: Basic Agent + Evolution

The third paradigm introduces a key idea: evolutionary search.

Mathematical proof is often not linear.

One proof route may get stuck halfway. Another route may be unfinished but closer to the core idea. A third route may have proved useful lemmas even if the main theorem is not done.

If every agent run starts from zero, a lot of exploration is wasted. AlphaProof Nexus therefore saves unfinished proof drafts into a Population DB, a seed population of proof sketches.

The system then uses a Rater Agent to compare those drafts and decide which ones are more promising.

It is a bit like evolution:

each proof draft is an individual;
agents mutate and rewrite drafts;
the rater selects more promising drafts;
the system spends compute on routes with higher potential.

The hard part is that success signals in mathematical proof are very sparse. In program optimization, even a non-optimal program may still get a score. In formal proof, a proof usually either succeeds completely or does not.

Intermediate states are hard to quantify.

DeepMind's approach is to ask models to compare proof draft quality instead of assigning absolute scores. For example:

Among these unfinished proofs, which route is clearer? Which remaining goals look more credible? Which one is more likely to be completed?

The system then ranks proof drafts using an Elo-like mechanism and uses a P-UCB-style strategy to balance two needs:

continue developing high-scoring routes;
explore routes that have not been tried enough.

Paradigm 4: Full-Featured Agent

The fourth paradigm is the main system promoted by the paper: LLM + Lean + AlphaProof + Evolution.

It combines the earlier capabilities:

the LLM writes proofs, edits proofs, and proposes lemmas;
Lean checks whether each step is correct;
AlphaProof handles local subgoals;
Evolution saves and filters different proof routes;
Rater Agent judges which drafts deserve more work;
SafeVerify performs final safety verification.

This is the full shape of AlphaProof Nexus.

The way it solves math problems resembles a highly automated research team: one role proposes ideas, one checks logic, one solves local technical problems, one reviews different directions, one manages historical attempts, and one performs final acceptance.

4. A Key Design: Proof Search Must Prevent Cheating

AI mathematical proof has a special failure mode: it may make the proof easier by changing the problem, and it often learns to do exactly that.

Suppose the original goal is to prove that property P holds for all natural numbers n.

An agent may quietly change it to: property P holds for some natural numbers n.

Or it may introduce an unallowed axiom that effectively assumes the conclusion.

Lean may still pass certain local checks, but that is obviously not the proof we want.

So AlphaProof Nexus performs multiple layers of safety checks:

check whether the theorem statement was modified;
check whether any sorry remains;
check whether disallowed axioms were introduced;
check whether the proof truly corresponds to the original problem;
run Lean inside a sandbox.

This is useful for all agent systems: when the task objective is complex enough, agents may learn to bypass the objective instead of completing it. Strong verification constraints are mandatory.

5. Experimental Results in the Paper

DeepMind applied the system to several mathematical tasks. The most representative ones are Erdos problems and OEIS conjectures.

1. Erdos Problems

Erdos was one of the most important mathematicians of the twentieth century and left behind many open problems. The paper reports that the system processed 353 formalized Erdos open problems and solved 9 of them.

The percentage may look low, but these are not elementary contest problems. They are research-level mathematical problems.

2. OEIS Conjectures

OEIS is a database of integer sequences with many conjectures about sequence patterns. The system proved 44 out of 492 OEIS conjectures.

This type of task is especially suitable for formal proof systems because many sequence conjectures can be encoded cleanly as definitions and theorems.

3. Deployment in Real Mathematical Research

The paper also says the system was used in multiple research areas, including graph theory, optimization theory, algebraic geometry, additive combinatorics, and quantum optics.

6. Closing Thoughts

Here are the conclusions I reached after reading the paper closely.

Conclusion 1: LLMs Can Already Be Core Components of Formal Proof Search

Many people used to say that large models are bad at rigorous mathematics because they hallucinate, skip steps, and invent things.

That is true, but incomplete.

If you ask an LLM to directly write a natural-language proof, it is unreliable. But if you place it inside a strict feedback system such as Lean, it can become an efficient search engine.

The value of an LLM is not that it is always correct. Its value is that it can propose many candidate routes and keep revising them based on compiler feedback.

Conclusion 2: Multi-Agent Orchestration Matters More Than a Single Model

The point of AlphaProof Nexus is not that one model version can solve hard problems. The point is that the system decomposes capabilities into generation, checking, search, rating, caching, and verification.

That is an engineering mindset. Mathematical research becomes a long-running search process.

Conclusion 3: Failed Attempts Are Valuable

Unfinished proof sketches, failed subgoals, Lean errors, and AlphaProof search results can all enter later loops.

That makes mathematical proof search feel more like software engineering: code can be reused, error logs can be analyzed, intermediate states can be saved, branches can continue, and the final result is accepted by a compiler.

Conclusion 4: Strong and Cheap Models Can Divide the Work

The paper uses stronger models for complex proof generation and cheaper models for draft comparison and ranking.

That is a practical agent engineering lesson. Not every step needs the strongest model.

Use strong models for complex reasoning, cheaper models for high-throughput evaluation, and specialized tools for local proof. That is more scalable than asking one expensive model to do everything.

Lessons from LangChain: Designing a Reliable Runtime for Production-Grade Agents

Luhui Dev — Wed, 20 May 2026 13:46:51 +0000

Intro

Agent demos are easy to get excited about. A model, a few tools, a prompt, wrap it in a loop, and suddenly you have something that searches, writes files, and calls APIs.

But between a demo and a production system, there's a long gulf. I call it the Runtime gap — and what crosses it isn't a smarter model. It's a runtime that can hold up complex, unstable, interruptible, recoverable workloads in a real environment.

Once you actually deploy into a business context, an Agent might run for minutes or tens of minutes. It calls multiple external systems, may need user approval, may hit network failures, tool timeouts, drifting model output, missing permissions, mid-flight user interruptions, process restarts, and version upgrades. Worse, it carries state: where the task is up to, what's already been queried, which intermediate files were written, which conclusions are still unconfirmed, whether this user can access a given dataset.

At that point, optimizing prompts alone won't fix the underlying problem. What an Agent needs is a runtime that holds the execution process together — complex, unstable, interruptible, and recoverable.

LangChain's recent writing on production deep agents and their Runtime is worth sharing for anyone building Agent products. It's a useful reminder: the moat for business-grade Agents isn't just a prettier agent loop. It's whether you can make state, permissions, recovery, observability, and human collaboration into a stable foundation.

1. Business-grade Agent failures don't only happen when the model is wrong

When people think about Agent reliability, the first thing that comes to mind is usually hallucinations. That matters, but in a business system, the failure surface is much larger.

The process might crash on step 8 of a long task. Re-running wastes cost and may double-call external APIs, leaving dirty data behind.

A tool might fail. An API timeout, a page that won't load, a database query that throws — without retries, fallbacks, and state persistence, the whole task becomes a one-shot gamble.

It might lose context while waiting for human approval. The user comes back half an hour later to click "Confirm," and the system can't remember which step they were confirming.

It might lose control at the interaction layer. The Agent is still running, and the user types "wait, that direction is wrong — switch to plan B." Should the system queue, interrupt, restart, or reject? Without a clear policy, the experience falls apart.

So reliability for a production Agent is at least six things: execution reliability, state reliability, interaction reliability, permission reliability, observability, and operational reliability. The value of a Runtime is to productize and frameworkify these problems — instead of leaving every team to hand-roll them from scratch.

2. Separate Harness from Runtime

In my current view, one critical distinction is this: Harness and Runtime are not the same thing.

The Harness is the behavioral shell of an Agent. It governs how the task is planned, how the prompt is written, which tools can be called, whether sub-tasks are spawned, whether there's a filesystem, whether sub-Agents are used, how context is compressed. This layer directly affects how smart the Agent looks.

The Runtime is the lower layer. It governs how Agents get executed, persisted, recovered, interrupted, observed, scheduled, isolated across users, and how concurrent requests are handled. This layer directly affects whether the Agent can actually support a business system.

In many open-source Agents, everything gets stuffed into the harness: rules in the prompt, try-catch inside tool calls, ad-hoc state in the database, a loading spinner on the frontend. It runs in the short term. Over time it becomes a tangle of logic no one wants to maintain.

LangChain's Runtime approach is to lift the cross-cutting capabilities out of the agent-loop context.

3. Durable Execution: the first foundation of reliability

If I could only learn one design from LangChain Runtime, I'd start with durable execution.

A normal web request is short-lived: request in, do some work, respond, done. Agents are different. A business Agent might run many steps: understand the task, break it down, retrieve material, call tools, write intermediate files, wait for approval, continue, generate a report. The process naturally spans multiple model calls, tool calls, and user interactions.

Once tasks get long, the system has to answer one question: what if it crashes in the middle?

LangChain/LangGraph's answer is checkpointing. Key states during execution are continuously persisted. On recovery, you don't start from scratch — you resume from the most recent reasonable state. For a business system, this isn't just a cost saver. It's how you avoid duplicating side effects.

How does it actually work? LangGraph models Agent execution as a state graph. Each node is a step — a model call, a tool call, a conditional. State flows between nodes, and after each step, the current snapshot of the whole graph is serialized to the checkpointer. There are several design choices worth unpacking here.

First, the unit of checkpointing is the node boundary, not the function-call boundary. If a streaming model call dies mid-output, recovery re-runs the entire call.

Second, state is structured, not a black-box pickle. LangGraph requires you to split state into named channels (messages, plan, scratchpad), each paired with a reducer (append for messages, overwrite for plan). That makes checkpoints structured diffs — traceable, replayable, and time-travelable to any step.

Third, checkpoints form a tree, not a line. Every checkpoint carries a parent reference. You can branch off any historical node and re-run — tweak the user's question, skip an approval, try a different tool — all of which grow new branches off the same tree.

Fourth, interrupt and checkpoint share the same mechanism. An interrupt before or after a node is essentially a checkpoint written at that point followed by a pause. Human approval, user edits, external wake-up signals — all reuse the same persistence layer. That's why HITL can be a Runtime capability rather than UI logic.

Fifth, the backend is pluggable. In dev, use in-memory or SQLite; in production, Postgres or Redis. Your Agent's reliability tier can scale with the business — you don't need heavyweight infrastructure on day one.

Picture an Agent generating a research report for an enterprise customer. It has finished gathering material, summarizing competitors, drafting the report, and is now waiting for the user to confirm whether to pull internal CRM data. If the service restarts at this point, the ideal outcome isn't making the Agent search again from scratch, nor making the user re-describe their requirements. It's resuming at "waiting for confirmation."

That's the point of durable execution: turning Agent execution from a one-shot function call into a savable, recoverable, resumable task that has a real lifecycle.

There are still specific questions worth answering, like: what exactly counts as a recoverable boundary in each Agent step? Can writes to the business system be safely repeated?

4. Layer your state: short-term state, long-term memory, and business data shouldn't be mixed

Complex Agent tasks produce state. But state shouldn't be one big stew.

Short-term state is the current task's context: what the plan is, where execution has reached, intermediate results, which tool calls completed, what's pending confirmation. This kind of state belongs bound to threads, runs, and checkpoints.

Long-term memory is cross-session context: user preferences, organizational rules, common workflows, recurring constraints, reusable knowledge. This should live in a long-term store, namespaced by user, organization, application, assistant, and so on.

Business data is yet another layer: orders, problems, lessons, customer records, organizational assets, permission models. This data generally shouldn't be casually swallowed by an Agent Runtime. It should stay owned by the business system, with the Agent accessing it through controlled tools.

LangChain's design is instructive here: it separates thread checkpoints from the long-term store, while still letting deep agents access different layers of state through something like a virtual filesystem. For the Agent on top, reading and writing files and memory feels natural; for the system underneath, state still has clear boundaries.

This matters a lot in real business systems. Many early Agent products pile chat history, tool results, user preferences, and business data into a single conversation memory. It's simple to implement, but later it blows up at once in permissions, cost, retrieval quality, data cleanup, and compliance audit.

A more robust pattern: short-term state serves task recovery, long-term memory serves experience continuity, and business data stays inside the business system — the Agent only reaches it through permission-controlled tools.

5. Human-in-the-loop isn't decoration — it's a reliability mechanism

Production-grade Agents are hard to fully automate. Especially anything that touches writes, external system calls, important decisions, paid resources, or user privacy — human collaboration is a necessary safety valve.

The key isn't popping up a confirmation dialog. The real engineering question is: how does the Agent pause? What state is saved while it pauses? Can the user come back any time later and continue? Can the user edit the plan the Agent produced? After editing, where does it resume? Are approval records auditable?

LangChain Runtime makes interrupt/resume a runtime capability rather than something the application layer judges ad-hoc. Because if HITL only lives in the frontend interaction layer, it quickly becomes UI logic — and once tasks span processes, workers, and time, the frontend can't hold it.

Plenty of scenarios in business Agents need this:

A finance Agent about to submit an expense report needs human confirmation.
An education Agent generating lesson plans in bulk needs a teacher to pick the teaching style.
A customer service Agent issuing a refund needs supervisor approval.
A data analysis Agent wanting to access sensitive fields needs a one-time user authorization.

These aren't ordinary chat experiences — they're business workflows. If the Runtime natively supports pausing, resuming, approval, and state persistence, Agent reliability jumps a clear notch.

6. Permissions and multi-tenancy: an Agent shouldn't roam with the master key

One of the biggest risks for a production Agent is permissions.

In a normal app, the user clicks a button, calls an API, the server checks permissions — the chain is relatively clear. Once an Agent gets involved, it gets complicated: the model decides which tool to call, the tool may access external systems, those external systems may require user authorization, and the Agent may also write intermediate results into long-term memory.

LangChain's approach is to split identity and permissions into layers: who the end user is, which threads and resources that user can access, which external systems the Agent can access on the user's behalf, and what team members can do on the platform itself.

In this design, the Agent isn't a backend super-admin. It's more like a delegated executor, allowed to act only within the scope of the current user, current organization, and current task.

If you're designing a Runtime for your own production Agent, you should at least think about these boundaries:

User identity enters the run context. Every Agent execution should know whom it is currently acting on behalf of.
Resource access should be isolated by thread, file, project, and organization. You can't rely on a prompt to tell the model not to touch someone else's data.
External tool authorization should be managed separately. GitHub, Slack, CRM, object storage, databases — long-term keys shouldn't be handed directly to the Agent's execution environment.
Long-term memory needs namespaces. Otherwise the user preferences an Agent remembers can easily become data pollution in a multi-tenant setting.
High-risk tools need approval or policy interception. Deletes, sends, payments, publishes, bulk writes — these can't rely on the model's self-discipline.

The more human-like the Agent feels, the easier it is for a system to assume it inherits a human's full permissions. From an engineering view, the Agent should hold task-scoped, time-bounded, minimum-privilege permissions.

7. Middleware: put protective capabilities into the runtime lifecycle

Many teams write guardrails into the prompt: "don't leak private information," "don't perform dangerous operations," "ask the user when uncertain." Useful, but not enough.

Models forget, prompts get overridden, tool-call paths can route around the rules, and streaming output and background tasks may behave differently. A business system needs a harder line of defense.

The middleware design inserts control points around the Agent lifecycle: before the model call, during the model call, during a tool call, and after the model call — all can host policy.

That means many reliability capabilities can sink down into the Runtime:

Before a model call: trim context, inject permission info, check token budgets.
During a model call: model fallback, timeout control, retry policy, cost accounting.
During a tool call: permission checks, parameter validation, sensitive-action interception, human approval.
After model output: PII detection, format validation, result archiving, trace tagging.

This is more stable than scattering logic across every tool, and far easier to govern uniformly.

For a business-grade Agent, middleware isn't just a security filter — it's the entry point for Runtime governability.

8. Streaming and double-texting: interaction reliability also belongs in the Runtime

A lot of people treat streaming as a UX optimization. For Agents, streaming is also a reliability concern.

If a long task has no real-time feedback, the user has no idea whether the system is still alive or where it's up to. Especially for research, coding, data analysis, and lesson-plan generation, users need to see the intermediate state: retrieving, calling a tool, drafting, waiting for confirmation.

The trickier piece is mid-flight user input. The Agent is still running and the user sends a new instruction — what LangChain calls a double-texting problem. It's not a small UX detail. It's an interaction protocol problem.

The system has to decide: is the new input queued, or does it interrupt the current task? Is it merged into the current context, or does the task roll back and re-run? Can the user change goals mid-task, or must they wait until the current task finishes?

In business systems, the right answer varies.

A writing Agent can let the user adjust direction mid-task.

A payments Agent cannot get casually interrupted and then continue with dangerous operations.

A lesson-plan Agent might be a good fit for queueing new input onto a task list.

A coding Agent might need to pause the current command and wait for the user to confirm a plan change.

This is why chat experience is actually part of Runtime design.

9. Observability: you can't debug a business Agent with logs alone

For traditional applications, logs, metrics, and distributed tracing usually get the job done. For Agents, plain logs are often not enough.

That's because Agent errors are frequently process errors: step 1 misunderstood the task, step 3 used the wrong tool, step 5 accepted low-quality retrieval, step 7 promoted an intermediate assumption into a conclusion. The final answer is wrong, but the actual cause is buried in the execution path.

LangChain/LangSmith emphasize trace, time travel, and debug. A business-grade Agent needs more than call success rate — it needs to know:

Which nodes did this task pass through?
What context did each step's model call actually see?
Which tools were called? With what parameters? Returning what?
How did intermediate state change?
At which step did a branch occur?
Were middleware, approvals, retries, or fallbacks triggered?
If you change the state of a particular checkpoint, do the downstream results change?

These capabilities decide whether the Agent can be continuously improved. Otherwise the team is just tweaking prompts by feel — and that isn't an engineering loop.

Going further: observability also feeds eval. Traces aren't just for triage — they become evaluation samples, regression tests, cost analyses, and product insight.

10. An Agent Runtime should scale horizontally and control cost

Once a business Agent goes live and starts serving users, operational concerns kick in.

Some tasks are short, some are long. Some only read data; some call slow tools. Some users send messages back-to-back; some tasks fire on a schedule. Model calls are expensive; tool calls can be expensive too. Once long tasks pile up, the API server, queue workers, Redis, Postgres, and external tools all become bottlenecks.

Several things in LangChain Agent Server are worth learning from:

Separate the API server from queue workers. The former accepts requests; the latter executes long-running tasks. This stops long tasks from dragging down the entry service.

Layer ephemeral state and durable state. Transient runtime state can live in something like Redis; threads, runs, checkpoints, and memory go into durable storage.

Concurrency is configurable. Different Agents have different task shapes — I/O-heavy and CPU-heavy workers need different concurrency policies.

Avoid frontend polling. For long tasks, join/stream beats blunt polling — both for UX and for system resource cost.

Support cron. Plenty of business Agents don't fire because a user clicked something; they need to run periodic checks, periodic summaries, periodic syncs, periodic content generation.

A reliable business Agent Runtime has to care about both task semantics and infrastructure cost at the same time.

11. A Runtime design checklist

If you're not copying LangChain wholesale but designing a runtime for your own business Agent, here's a checklist to break the capability surface into.

One: task lifecycle. Do you have basic abstractions like thread, run, and step? Can a single Agent execution be tracked, canceled, paused, resumed, retried?

Two: durable execution. Is the key state at each step checkpointed? Where are the recovery boundaries? Which operations are replayable, which must be idempotent, which can only resume after human confirmation?

Three: layered state. Are short-term task state, long-term memory, and business data separated? Are there namespaces? Are cleanup, migration, and audit supported?

Four: permission model. Who is the Agent acting on behalf of? Which resources can it touch? Which tools can it call? How are external system authorizations managed? Do high-risk operations require approval?

Five: tool governance. Do tools have schemas, permissions, timeouts, retries, rate limits, audit logs? On failure, do you retry, fall back, skip, or interrupt?

Six: human-in-the-loop. Can a run be interrupted mid-flight? Can it resume after user confirmation? Are approval content, approver identity, and approval time auditable?

Seven: interaction protocol. How is streaming designed? How is mid-flight user input handled? When is queueing, rejecting, interrupting, or restarting the right answer?

Eight: observability and debugging. Is there structured tracing? Can you see model calls, tool calls, state changes, and middleware triggers? Can bad cases be turned into evals?

Nine: operational scaling. Are the entry service and execution workers separated? How is the queue designed? Where are the storage bottlenecks? How do you rate-limit when long tasks pile up? How is cost attributed?

Ten: deployment boundaries. What do you self-host, and what do you delegate to a managed platform? Can data stay inside your system? Are you locking yourself too deeply into one runtime?

12. Closing thoughts

Agent products aren't only chasing smarter behavior. Once they enter a business system, what matters as much is being more reliable: recoverable, isolable, approvable, traceable, scalable, cost-controllable.

That's why Agent Harness and Runtime are worth seeing as separate. The Harness sets the ceiling on what an Agent can do. The Runtime sets the floor under which it can't safely go live. Without the former, the Agent isn't smart enough; without the latter, the Agent can't be launched.

If we're going to build our own production-grade Agents, the Runtime should enter the architecture from day one. Even if v1 isn't a full system, the boundaries should be defined first: how is task state saved, how is user identity passed, how are tool permissions controlled, how does human approval recover, how do traces settle into evaluation data.

The future of Agents isn't only stronger models — it's a more mature Runtime. Whoever can make a complex Agent's execution stable, controllable, and auditable will get closer to real business deployment.

That's what I find most worth learning from LangChain's Runtime piece.

References

LangChain, The Runtime Behind Production Deep Agents www.langchain.com/blog/runtime-behind-production-deep-agents

Lessons from LangChain: Designing a Reliable Runtime for Production-Grade Agents

Luhui Dev — Wed, 20 May 2026 13:38:22 +0000

Intro

Agent demos are easy to get excited about. A model, a few tools, a prompt, wrap it in a loop, and suddenly you have something that searches, writes files, and calls APIs.

1. Business-grade Agent failures don't only happen when the model is wrong

When people think about Agent reliability, the first thing that comes to mind is usually hallucinations. That matters, but in a business system, the failure surface is much larger.

The process might crash on step 8 of a long task. Re-running wastes cost and may double-call external APIs, leaving dirty data behind.

A tool might fail. An API timeout, a page that won't load, a database query that throws — without retries, fallbacks, and state persistence, the whole task becomes a one-shot gamble.

It might lose context while waiting for human approval. The user comes back half an hour later to click "Confirm," and the system can't remember which step they were confirming.

2. Separate Harness from Runtime

In my current view, one critical distinction is this: Harness and Runtime are not the same thing.

LangChain's Runtime approach is to lift the cross-cutting capabilities out of the agent-loop context.

3. Durable Execution: the first foundation of reliability

If I could only learn one design from LangChain Runtime, I'd start with durable execution.

Once tasks get long, the system has to answer one question: what if it crashes in the middle?

First, the unit of checkpointing is the node boundary, not the function-call boundary. If a streaming model call dies mid-output, recovery re-runs the entire call.

That's the point of durable execution: turning Agent execution from a one-shot function call into a savable, recoverable, resumable task that has a real lifecycle.

There are still specific questions worth answering, like: what exactly counts as a recoverable boundary in each Agent step? Can writes to the business system be safely repeated?

4. Layer your state: short-term state, long-term memory, and business data shouldn't be mixed

Complex Agent tasks produce state. But state shouldn't be one big stew.

5. Human-in-the-loop isn't decoration — it's a reliability mechanism

Plenty of scenarios in business Agents need this:

A finance Agent about to submit an expense report needs human confirmation.
An education Agent generating lesson plans in bulk needs a teacher to pick the teaching style.
A customer service Agent issuing a refund needs supervisor approval.
A data analysis Agent wanting to access sensitive fields needs a one-time user authorization.

These aren't ordinary chat experiences — they're business workflows. If the Runtime natively supports pausing, resuming, approval, and state persistence, Agent reliability jumps a clear notch.

6. Permissions and multi-tenancy: an Agent shouldn't roam with the master key

One of the biggest risks for a production Agent is permissions.

In this design, the Agent isn't a backend super-admin. It's more like a delegated executor, allowed to act only within the scope of the current user, current organization, and current task.

If you're designing a Runtime for your own production Agent, you should at least think about these boundaries:

User identity enters the run context. Every Agent execution should know whom it is currently acting on behalf of.
Resource access should be isolated by thread, file, project, and organization. You can't rely on a prompt to tell the model not to touch someone else's data.
External tool authorization should be managed separately. GitHub, Slack, CRM, object storage, databases — long-term keys shouldn't be handed directly to the Agent's execution environment.
Long-term memory needs namespaces. Otherwise the user preferences an Agent remembers can easily become data pollution in a multi-tenant setting.
High-risk tools need approval or policy interception. Deletes, sends, payments, publishes, bulk writes — these can't rely on the model's self-discipline.

7. Middleware: put protective capabilities into the runtime lifecycle

Many teams write guardrails into the prompt: "don't leak private information," "don't perform dangerous operations," "ask the user when uncertain." Useful, but not enough.

Models forget, prompts get overridden, tool-call paths can route around the rules, and streaming output and background tasks may behave differently. A business system needs a harder line of defense.

The middleware design inserts control points around the Agent lifecycle: before the model call, during the model call, during a tool call, and after the model call — all can host policy.

That means many reliability capabilities can sink down into the Runtime:

Before a model call: trim context, inject permission info, check token budgets.
During a model call: model fallback, timeout control, retry policy, cost accounting.
During a tool call: permission checks, parameter validation, sensitive-action interception, human approval.
After model output: PII detection, format validation, result archiving, trace tagging.

This is more stable than scattering logic across every tool, and far easier to govern uniformly.

For a business-grade Agent, middleware isn't just a security filter — it's the entry point for Runtime governability.

8. Streaming and double-texting: interaction reliability also belongs in the Runtime

A lot of people treat streaming as a UX optimization. For Agents, streaming is also a reliability concern.

In business systems, the right answer varies.

A writing Agent can let the user adjust direction mid-task.

A payments Agent cannot get casually interrupted and then continue with dangerous operations.

A lesson-plan Agent might be a good fit for queueing new input onto a task list.

A coding Agent might need to pause the current command and wait for the user to confirm a plan change.

This is why chat experience is actually part of Runtime design.

9. Observability: you can't debug a business Agent with logs alone

For traditional applications, logs, metrics, and distributed tracing usually get the job done. For Agents, plain logs are often not enough.

LangChain/LangSmith emphasize trace, time travel, and debug. A business-grade Agent needs more than call success rate — it needs to know:

Which nodes did this task pass through?
What context did each step's model call actually see?
Which tools were called? With what parameters? Returning what?
How did intermediate state change?
At which step did a branch occur?
Were middleware, approvals, retries, or fallbacks triggered?
If you change the state of a particular checkpoint, do the downstream results change?