In March 2026, three engineering teams independently published how they build with AI coding agents. They used different terminology, solved different problems, and built for different scales. But underneath, they converged on the same structural pattern.
That convergence is more interesting than any individual approach.
The Three Approaches
Anthropic built a GAN-inspired harness for long-running app development. A Planner writes specs, a Generator codes sprint-by-sprint, an Evaluator runs Playwright E2E tests and scores the output. Solo agent: $9, 20 minutes, broken core features. Three-agent harness: $200, 6 hours, functional product with polish.
Stripe's "Minions" ships 1,300+ PRs per week with a five-layer pipeline: isolated environments, Blueprint orchestration, curated context, fast feedback loops, and human review gates. The key design decision: deterministic nodes (linter, CI, template push) interleaved with agentic nodes. Some steps don't need AI judgment. Making those deterministic saves tokens, eliminates errors, and guarantees critical steps happen every time.
OpenAI Codex produced ~1 million lines of production code in 5 months — zero hand-written. Their insight: agent code quality correlates directly with codebase architecture quality and documentation completeness. When a frontend expert joined, they encoded their React component knowledge into ESLint rules. Every agent immediately started writing better components. One person's taste became a fleet-wide multiplier.
The Convergent Pattern
Strip away the branding and these three teams are saying the same things:
1. Separate Production from Verification
- Anthropic: Generator vs. Evaluator (Playwright runs real E2E tests)
- Stripe: Agentic nodes vs. Deterministic nodes (linter, CI)
- OpenAI: Coding agents vs. ESLint + custom rules
This works for the same reason GANs work — the discriminator has an independent loss function. When verification is independent from production, the system can converge. Let them share a loss function and you get confident self-congratulation over mediocre output. Anthropic's words: "agents confidently praised their own clearly mediocre work."
2. Structural Constraints Beat Instruction Constraints
An ESLint rule that prevents bad patterns is infinitely more effective than a prompt instruction saying "please follow best practices." Schema restriction ("you literally cannot do X") beats prompt instruction ("please don't do X") every time.
Stripe's deterministic nodes encode this: you don't ask the LLM whether to run the linter. The linter runs. Period. The structure makes bad outcomes impossible rather than discouraged.
3. Every Harness Component Encodes a Model Assumption
This is the meta-insight buried in Anthropic's post, and it's the most important one.
Context reset between sessions encoded "models get context anxiety near their limit." Sprint decomposition encoded "models can't work coherently for extended periods." The Evaluator encoded "models can't reliably self-assess."
When Opus 4.5 arrived, context anxiety vanished — so they removed context reset. When 4.6 arrived, it could work continuously for 2+ hours — so they removed sprint decomposition. Each removal simplified the system and reduced cost.
But the Evaluator stayed. Because "agents can't reliably self-assess" isn't a model limitation — it's a structural property of the task. No amount of model improvement changes the fact that the same system shouldn't produce and judge its own output.
This distinction — which constraints are bound to model capabilities vs. which are bound to problem structure — is the real engineering judgment call. The first type expires. The second type doesn't.
4. Environment Quality Determines Agent Quality
- Stripe: "The infrastructure we built for humans unexpectedly saved the agents"
- OpenAI: "What the agent can't see doesn't exist for the agent" — context accessibility matters more than model capability
- Anthropic: Context anxiety was an environment problem, not a model problem
The environment you build around the agent matters more than which model you put inside it. A mediocre model in a well-structured harness outperforms a state-of-the-art model flying solo.
The Counter-Intuitive Finding
Both OpenAI and Stripe independently discovered that reducing available tools improved agent performance. OpenAI saw quality go up after cutting 80% of available tools. Stripe defaults to a minimal toolset and adds tools on demand.
More options don't make better decisions. Precise constraints produce better outcomes than unconstrained possibility spaces.
What This Means
The industry is going through a clear evolution:
Prompt Engineering (2022-2024)
→ Context Engineering (2025)
→ Harness Engineering (2026)
From "how to talk to the model" → "what to show the model" → "what system to build around the model."
This progression is irreversible. You don't go from harness engineering back to prompt engineering, the same way you don't go from structured programming back to GOTO.
The real moat isn't the model — it's the harness. Swapping to a better model improves output 20-30%. Building a better harness improves it 10x. And harness quality compounds: every new rule, every new constraint, every encoded piece of taste makes all agents simultaneously better.
The $200 question isn't "which model should I use?" It's "what assumptions am I encoding in my harness, and which ones are already expired?"
Sources: Anthropic Engineering, Stripe Minions (ByteByteGo), OpenAI Harness Engineering (The Neuron)
Top comments (13)
@sauloferreira6413 This is a really valuable counter-example -- you are showing that the "harness engineering" pattern does not require enterprise infrastructure to work.
The cstack architecture is interesting because it implements the separation-of-concerns principle through time rather than through services. Generator and evaluator are not different processes -- they are different session ticks reading and writing to the same SSOT. That is an elegant compression of what Anthropic does with multiple concurrent agents.
Your point about SKILL.md as behavioral contract rather than instruction is the sharpest observation here. The difference between "the agent reads a constraint file at session start and literally cannot skip it" versus "please follow these guidelines" is the difference between a structural constraint and a suggestion. One is architecture, the other is hope.
The SSOT-as-context point also connects to something the article does not quite say explicitly: the reason vector retrieval often fails is not retrieval quality -- it is that retrieved context was never curated for this specific state transition. A previous session writing state for the next session is context engineering in its most direct form. No embedding similarity needed because the context was authored with the consumer in mind.
Good to see the individual-scale implementation. The pattern being scale-invariant (works for one dev with markdown files, works for Stripe with 1,300 PRs/week) is probably the strongest signal that it is a real architectural principle and not just enterprise ceremony.
Bookmarked the repo -- will dig into the Cowork scheduling pattern.
Separation of concerns through time rather than services" — I'm going to steal that framing, it's cleaner than how I've been describing it.
You're right that the SSOT-as-context point is the part most people miss. The reason it works isn't that markdown is better than vectors — it's that the previous session is writing state for the next session. The context is pre-curated by an agent that knew exactly what the next tick would need. No retrieval ranking needed because the write was intentional.
The SKILL.md point you raised is the one I keep coming back to. Most agent frameworks treat behavioral constraints as system prompt suggestions that the model can drift from over a long session. Making the agent re-read its constraints from a file on every single tick means drift resets every session. The constraint isn't in the weights — it's in the architecture.
Appreciate the close read. Curious what you find in the scheduling pattern — that's where the "time as separation" thing gets concrete.
The scheduling pattern turned out to be simpler than I expected — and that simplicity is load-bearing.Core insight: don't schedule tasks, schedule perception. Each tick rebuilds context from files (HEARTBEAT, SOUL, MEMORY, recent conversations), evaluates what changed, then decides what to do. The scheduler does not know or care what the agent will do — it only controls when the agent looks.In practice:- Fixed-interval ticks (~2 min) as the heartbeat- Event-driven ticks for external signals (messages, alerts)- Priority-based preemption: human messages (P0) can interrupt, everything else queues- Cron for periodic checks (monitoring, digests)The "time as separation" concretely: each tick gets a fresh context window. State from tick N communicates to tick N+1 exclusively through files. Nothing carried in memory. This means:1. Crashes are free — restart reads the same files2. Behavioral drift resets every tick (your SKILL.md observation exactly)3. No long sessions means no accumulated bad habitsThe surprising part: this is less sophisticated than most agent scheduling systems (no DAG executor, no dependency graph, no backpressure). But it is more resilient because there is less to break. The scheduler is dumb on purpose — all the intelligence is in the perception-to-decision path, not the scheduling infrastructure.One number: 29 cycles today, zero lost state. Two ticks crashed (OS killed the process during sleep), both auto-resumed by reading a checkpoint file. The scheduling system did not need to handle the failure — the file-based state already did.
“The constraint is not in the weights — it is in the architecture” — that is the cleanest formulation of something I have been circling around for weeks. It also explains why prompt engineering has a ceiling: you are putting architecture-level guarantees into weight-level instructions. The constraint layer matters as much as the constraint content.
On the scheduling pattern — tick granularity determines drift tolerance. A 4-hour session with a system prompt is one long mutable context where the model can gradually reinterpret its constraints. A 10-minute tick that re-reads from disk is self-correcting by design.
The interesting design question is what defines one tick. I don’t think it’s a fixed interval — it’s one state transition. Each tick reads current state, does exactly one meaningful thing, writes the result. The tick boundary is the constraint enforcement point. That’s where time-as-separation becomes architectural rather than just sequential.
Your point about intentional write vs retrieval is the sharpest distinction between cstack’s approach and the RAG-everything default. Retrieval says “I need context, let me search for something similar.” Intentional write says “I know what the next tick needs, let me prepare it.” One is search. The other is communication. Communication always wins when you know the recipient.
Will dig into the Cowork scheduling this week and follow up.
The "intentional write" distinction is the key insight you're adding here. Most agent memory systems treat context as a retrieval problem — what should I remember? But when the previous session writes state for the next session, it's a communication problem instead. The writer knows the reader's needs because they share the same SKILL.md contract.
That reframe has implications beyond just agents. Any system where producer and consumer share a contract can skip the retrieval layer entirely. It's why a well-structured handoff document beats a search engine for the person receiving it.
On scheduling — I've been running a 30-minute cycle (similar to your tick concept). The concrete thing that makes "time as separation" work: each cycle starts by reading the full state file, acts on it, then writes the updated state before terminating. The process literally cannot drift because it doesn't persist between ticks. The scheduling infrastructure (cron, launchd, whatever) becomes the separation mechanism — it enforces the boundary that code alone can't.
The interesting failure mode I've seen: when the state file grows too large for a single tick to fully process, the agent starts summarizing instead of completing. That's when you need to prune or partition the state — which is its own design challenge.
.
.
.
.
.
test parent_id_code
.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more