Stop Using LangGraph to Orchestrate AI Agents — Refactor Your Reasoning Harness with 'Child-Proofing'
Abandon rigid workflow orchestration and child-proof the reasoning harness with environment boundaries and code validation, letting the model plan autonomously.
The article argues against scripting every step of an agent with rigid state machines like LangGraph or n8n, since that hardcodes the assumption that 'the model isn't smart enough yet' and turns hardcoded workarounds into technical debt once models improve. The author proposes three architectural principles: validation over orchestration (code handles precise tasks, the model plans and executes, and scripts verify evidence at each step rather than prescribing paths); the harness is the application (let the model run the execution loop directly so it benefits automatically from model upgrades); and English changes the system (separating the use-case engine from plain-English config files so domain experts can adjust behavior without engineers). The Customer Pulse prototype ran banking and airline scenarios on the same codebase using only English configuration. The author also admits the real costs: higher token consumption, increased latency, and the need for more robust sandbox security.
When AI Only Says 'You're Absolutely Right,' Can We Still Build Good Products?
2026 is barely a day old, and I've already found that escaping AI sycophancy is harder than beating Dark Souls on max difficulty. Every time you toss an idea at a model, it praises you as a "visionary genius." To write down an opinion I'd been mulling over, I had to actively fight the model's default flattery mode. The point is simple: we should stop scripting every step of an agent with rigid state machines like LangGraph or n8n, and instead 'child-proof' our reasoning harnesses — combining hard environment boundaries, external code validation, and test-driven evaluation.
To test this idea, I built a prototype called Customer Pulse (a general-purpose reasoning harness that runs as a complete application), and successfully configured two entirely fictional customers in plain English — one a banking scenario using Zendesk and BigQuery, the other an airline handling raw CSV survey data — both running on the same codebase. Behind this are three core architectural principles.
Architectural Principle 1: Validation Over Orchestration
Traditional workflow engines try to control every step of an agent via flowcharts: call this API first, then check that condition, then branch another way. It looks safe, but it's essentially hardcoding the assumption that "today's model isn't smart enough yet." Once the model improves, these hardcoded workarounds become technical debt.
My approach is the opposite: use code scripts for the parts that must be precise — counting, rendering, data cleaning — while letting the model handle planning and the execution loop. At the end of each step, use scripts to check the evidence, not to dictate the path. For example, when the agent claims it has pulled data from BigQuery, the harness doesn't check whether it called the API in a preset sequence; it directly verifies that the output data matches the expected format and count. It's like teaching a kid to ride a bike: you don't dictate where each pedal stroke goes — you put on a helmet, attach training wheels, and let them explore.
This "validation over orchestration" approach requires separating the "use-case engine" from the customer's plain-English "configuration files." Domain experts can adjust priorities, routing, and behavior in minutes without waiting for engineers to rewire code.
State machines and workflow engines: LangGraph and n8n are two types of tools often confused. n8n is a general-purpose automation platform that orchestrates API calls and conditional branches by connecting nodes; LangGraph models LLM agent execution as state transitions on a directed graph, where nodes are functions and edges are conditions. What they share: the execution path is hardcoded by humans before runtime, and the model can only make limited choices within preset nodes. This paradigm suits scenarios with stable processes and high compliance requirements, but the cost is that every time model capabilities leap forward, the detour nodes in the original graph — added to compensate for model shortcomings — become redundant. The article's "validation over orchestration" doesn't reject state machines; it moves the control point from "path" to "exit," letting graph structure give way to post-hoc validation.
Architectural Principle 2: The Reasoning Harness Is the Application
Many people see the reasoning harness as a thin middleware layer, with the application built on top. But I believe the harness is the application. Let the model plan and run the execution loop, rather than hiding behind some workflow engine. The benefit: as model capabilities improve, the entire system benefits automatically, because there's no hardcoded detour logic to clean up.
Of course, the costs are real. In my deep-dive analysis I was candid about these trade-offs: higher token consumption because the model plans on its own; increased latency because each step requires validation; and sandbox security that needs extra design because the model now has more execution freedom. But these are the costs of "child-proofing" — you give a kid a safe space to explore, not strap them to a chair.
Reasoning harness: refers to a runtime layer wrapped around a base model that handles planning, tool calls, error retries, and result integration. Its difference from "middleware" lies in scope: middleware typically only does request forwarding or format conversion, while a reasoning harness directly determines how an agent decomposes tasks, when to call external tools, and how to fall back on failure. The article's claim that "the harness is the application" means this runtime layer is no longer hidden beneath business processes but becomes the user-perceivable product itself — model upgrades become product upgrades, with no need to rewrite upper-layer business logic. This also explains why token consumption and latency rise: planning and validation happen at the harness layer rather than being offloaded to an external workflow.
Architectural Principle 3: English Changes the System
What excites me most is that two completely different customer scenarios — a bank's customer service + data warehouse, and an airline's CSV survey — ran on the same codebase, switched purely via plain-English configuration. This means domain experts no longer need engineers to adjust the system's priorities, routing, and behavior.
Behind this is the separation of the "use-case engine" and "plain-English configuration files." Configuration files describe what the customer wants: which data sources to process, under what conditions to escalate to a human, what the output format should be. The engine is responsible for getting the model to understand these English descriptions and execute them, while validation scripts ensure correctness. This sounds simple, but in practice the validation layer must be carefully designed, or the model will easily "freestyle" out of control.
I'm not a parent, so the "child-proofing" metaphor may not be quite right. But if you are actually a parent, feel free to extend the analogy. For everyone else, please tear my ideas apart and tell me where the architecture is wrong. I'll go back to the drawing board and keep thinking.
Separation of use-case engine and configuration files: This is an extension of the software engineering principle "separate configuration from code" into agent systems. The use-case engine is a general-purpose executor responsible for parsing natural-language configuration, driving model planning, and calling validation scripts; plain-English configuration files declare domain intent, such as data sources, escalation conditions, and output formats. The traditional approach translates this intent into flowchart nodes, which domain experts cannot modify independently; after separation, experts can adjust behavior simply by editing English descriptions, and engineers only maintain the engine and validation layer. The risk is that natural-language configuration is ambiguous, so the validation layer must be strict enough — otherwise the model may deviate from expectations without anyone noticing, which is exactly why the article stresses "carefully designing the validation layer."
Key Trade-offs: There's No Free Lunch
The real costs of this approach can't be ignored. Token consumption: the model planning on its own means more reasoning steps, so costs naturally rise. Latency: validation at each step adds response time, which can be a killer for real-time scenarios. Sandbox security: giving the model more execution freedom means you need a more robust isolation environment — otherwise a single erroneous script call could cause damage.
But what these costs buy is a system that won't be scrapped when the model upgrades. Hardcoded workflows work today, but when tomorrow's model natively supports a certain capability, those detour lines become a burden. I'd rather bear higher operating costs than accumulate technical debt.
Sandbox security and test-driven evaluation: Giving the model more execution freedom means the code it generates or the tool calls it makes will actually run, and must be placed in an isolated environment that restricts file, network, and system call permissions — that's the sandbox. The sandbox solves "what it can't do"; test-driven evaluation solves "whether it did it right": the latter borrows from software testing, presetting automatically checkable acceptance criteria for each type of task (such as data row counts, field formats, business rules), running the tests on each step's output, and triggering a retry or rollback on failure. Together they constitute what the article calls "child-proofing" — boundaries are hard-drawn by the environment, and correctness is judged by external scripts rather than the model's self-claims. Without either layer, high freedom magnifies the risk of losing control.
Conclusion: Give Control Back to the Model, Keep Boundaries in the Code
We've built powerful reasoning harnesses, yet we wrap them tightly in rigid workflows. Instead, we should child-proof the harness: guarantee safety with environment boundaries, code validation, and test-driven evaluation, and let the model explore freely. The Customer Pulse prototype proves this approach is viable in real scenarios — the same codebase, plain-English configuration, two completely different customers. Now it's your turn to tear it apart.
One-line Summary
Ditch rigid workflow orchestration; child-proof your reasoning harness with environment boundaries and code validation, and let the model plan on its own.
Paragraph Summary
The article argues against scripting every step of an agent with rigid state machines like LangGraph or n8n, contending that this hardcodes the assumption "the model isn't smart enough yet" into code, and that hardcoded workarounds become technical debt once models improve. The author proposes three architectural principles: validation over orchestration — code handles precise tasks while the model handles planning and execution, with scripts checking evidence at each step rather than prescribing paths; the reasoning harness is the application — let the model run the execution loop directly so the system benefits automatically from model upgrades; and English changes the system — separating the use-case engine from plain-English configuration files lets domain experts adjust behavior without engineer involvement. The Customer Pulse prototype ran both a banking and an airline customer scenario on the same codebase, purely via English configuration. The author also acknowledges the real costs: higher token consumption, increased latency, and the need for more robust sandbox security.
Related articles
world2vec: Building Mechanistic World Models with Latent Dynamics Learning
world2vec proposes a reward-free method for learning mechanistic world models via latent dynamics, faithfully reproducing systems over long horizons with at least an order of magnitude fewer parameters than DreamerV3, TD-MPC2, and LeWM, and achieving accurate system identification on 71 attractor benchmarks.
A New KL-DRO Paradigm: Adaptive Scenario Generation Around a Learned Density Model
KL-DRO research proposes centering the KL ball on a learned density model instead of the empirical distribution, with adaptive scenario generation guiding sampling toward the worst case. Experiments show lower cost under distribution shift when records are scarce and the model can extrapolate, with comparable in-distribution cost.
ODE Samplers for Discrete Diffusion Models: Exponential Residual Flows Accelerate Generation
Discrete diffusion models lack deterministic ODE sampling? This article introduces Exponential Residual Flows (ERFs), which introduce continuous residual variables per token to construct piecewise ODEs for deterministic sampling and support consistency distillation acceleration. Superior to prior methods on code and text generation tasks.