Harness engineering for AI agents: origins and sources

Where did the term "harness engineering" come from, and which primary sources define it? AR Labs traced the term in May 2026, and the findings inform our page on harness engineering. We use harness to mean everything around the model that shapes what an agent does: the agent program, its instructions, skills, hooks, tools and checks. The sources below define it in closely related terms, several as everything in an AI agent apart from the model itself. The report examines writing by Mitchell Hashimoto, Simon Willison, Anthropic, LangChain, Thoughtworks, Stripe, Cognition, Andrej Karpathy and others, scoring each source for currency, relevance, authority, accuracy and purpose (CRAAP).

Method: standard depth, two passes, 10 searches, 28 sources analysed (19 scoring 4.0 or higher on CRAAP).

Summary

"Harness engineering" crystallised as a named discipline in early-to-mid 2026, though the underlying ideas had been building since at least 2023. The term has two distinct but related lineages: (1) a practice coined by Mitchell Hashimoto (Feb 5, 2026), engineering the environment so agents cannot repeat past mistakes, and (2) a formula popularised by LangChain/Vivek Trivedy (Mar 10, 2026) and Gabriel Chua/OpenAI: "Agent = Model + Harness." These two threads converged into a minor genre of authoritative engineering writing between February and April 2026.

Of the five voices examined, Simon Willison has the most substantive primary writing on harnesses as a technical concept. Anthropic has published two engineering posts that go well beyond "Building Effective Agents." Cognition/Devin has a strong infrastructure post. Karpathy's contribution is foundational framing (LLM-as-OS, context engineering) rather than harness-specific writing. Omar Khattab/DSPy connects through the Stanford Meta-Harness paper. The richest practitioner-level primary sources are Hashimoto, Willison, Böckeler/Fowler, Trivedy/LangChain, Stripe, and Anthropic's engineering blog.

Part 1: Provenance of the term "harness engineering"

Mitchell Hashimoto: coinage of the practice

Source: "My AI Adoption Journey", https://mitchellh.com/writing/my-ai-adoption-journey (February 5, 2026). Mitchell Hashimoto (co-founder HashiCorp, creator Terraform). CRAAP: 4.8 (Currency 5, Relevance 5, Authority 5, Accuracy 4, Purpose 5)

Hashimoto is the originating practitioner source for the discipline of harness engineering, though he uses it descriptively rather than as a formal term. His definition:

"The idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."

He describes two mechanisms:

• Better implicit prompting (AGENTS.md files): documented corrections to behavioural patterns
• Programmed tools: scripts and automated utilities that make incorrect paths structurally unavailable

The core thesis is that agents are "much more efficient when they produce the right result the first time, or at worst produce a result that requires minimal touch-ups." Hashimoto approaches the harness as a ratchet: each error becomes a permanent structural improvement, not a one-time correction.

Confidence: High. Directly cited as origin source in 6+ secondary sources.

Gabriel Chua (OpenAI): the "Agent = Model + Harness" formula

Source: "Harness Engineering: Leveraging Codex in an Agent-First World", https://openai.com/index/harness-engineering/ (February 11, 2026). Ryan Lopopolo wrote the published piece; Gabriel Chua contributed the formula in related OpenAI materials. CRAAP: 4.6 (Currency 5, Relevance 5, Authority 5, Accuracy 4, Purpose 4)

The OpenAI post returned a 403 on direct fetch. Based on multiple secondary sources citing it, the key claim is the formula:

"Codex = Model + Harness + Surfaces"

Where the harness comprises "the collection of instructions and tools," and is "shaped around how the model plans, invokes tools, and recovers from failure." The post was built on the experience of shipping a production application with zero manually written lines of code, and frames harness engineering as the successor to context engineering.

Confidence: Moderate. Could not directly verify via WebFetch (403). Formula is consistently cited across multiple independent sources with attribution.

Vivek Trivedy (LangChain): the anatomy

Source: "The Anatomy of an Agent Harness", https://www.langchain.com/blog/the-anatomy-of-an-agent-harness (March 10, 2026, updated May 14, 2026). Vivek Trivedy. CRAAP: 4.6 (Currency 5, Relevance 5, Authority 4, Accuracy 5, Purpose 4)

Trivedy gave the formula its cleanest expression and provided the most complete structural breakdown of what a harness contains. Key quotes:

"Agent = Model + Harness. If you're not the model, you're the harness."

"A raw model is not an agent. But it becomes one when a harness gives it things like state, tool execution, feedback loops, and enforceable constraints."

"The model contains the intelligence and the harness is the system that makes that intelligence useful."

The six harness components Trivedy enumerates:

1. Filesystems for durable storage and multi-agent coordination
2. Bash + code execution as general-purpose tool access
3. Sandboxes for isolated execution at scale
4. Memory and knowledge access (AGENTS.md, web search, MCP)
5. Context management (compaction, progressive disclosure, tool-call offloading)
6. Long-horizon execution (planning loops, Ralph Loops, durable state via filesystem + git)

Benchmark evidence cited: Claude Opus 4.6 moved from outside Top 30 to Top 5 on Terminal Bench 2.0 leaderboard solely through harness optimisation, without model change (52.8% → 66.5%). This is the strongest quantitative claim in the genre.

Confidence: High. LangChain is an authoritative practitioner source; benchmark claim is independently corroborated by MindStudio and other sources.

Birgitta Böckeler (Thoughtworks) on Martin Fowler's site

Source: "Harness Engineering for Coding Agent Users", https://martinfowler.com/articles/harness-engineering.html (April 2, 2026). Birgitta Böckeler (Distinguished Engineer, Thoughtworks). CRAAP: 4.9 (Currency 5, Relevance 5, Authority 5, Accuracy 5, Purpose 5)

This is arguably the most citable source in the genre: a named expert practitioner on Martin Fowler's site (the canonical destination for software engineering patterns). Böckeler frames harness engineering through a systems/cybernetics lens.

Definition: "Everything in an AI agent except the model itself" (citing LangChain). For coding agent users specifically: systems of guides and sensors built around the agent to increase output quality.

Core dual-control architecture:

"A well-built outer harness serves two goals: it increases the probability that the agent gets it right in the first place, and it provides a feedback loop that self-corrects."

Two control mechanisms:

• Guides (feedforward): Anticipate and prevent unwanted outputs: AGENTS.md, custom linters, architecture fitness functions, LSP integration
• Sensors (feedback): Observe after execution and enable self-correction: automated test runs, code review hooks, CI integration

Two execution types within the harness:

• Computational: Deterministic, fast (CPU-run linters, structural tests)
• Inferential: Semantic analysis, AI code review; slower and more expensive

Three regulation categories:

1. Maintainability harness: internal code quality
2. Architecture fitness harness: structural characteristics (Ashby's Law of Requisite Variety applied)
3. Behaviour harness: functional correctness (noted as the least developed category)

Confidence: High. Thoughtworks/Martin Fowler site is the gold standard for software engineering patterns. Author has named credentials.

Addy Osmani (Google): the ratchet principle

Source: "Agent Harness Engineering", https://addyosmani.com/blog/agent-harness-engineering/ (April 19, 2026). Addy Osmani (Software Engineer, Google; author of "Learning JavaScript Design Patterns"). CRAAP: 4.5 (Currency 5, Relevance 5, Authority 4, Accuracy 4, Purpose 5)

Osmani synthesises and amplifies the Hashimoto/Trivedy framework with additional engineering framings:

"The gap between what today's models can do and what you see them doing is largely a harness gap."

"A decent model with a great harness beats a great model with a bad harness."

Novel framings:

• The Ratchet Principle: Every agent mistake becomes a permanent rule in harness design
• Harnesses Don't Shrink, They Move: As models improve, harness complexity doesn't decrease; it shifts to address higher-ambition tasks
• Model-Harness Training Loop: Post-training now couples to specific harnesses, creating feedback where useful primitives (filesystem ops, bash execution) become standardised
• Harness-as-a-Service (HaaS): Shift from building on LLM APIs (completions) to building on harness frameworks (full runtime environments)

Confidence: High. Osmani is a recognised engineering voice at Google; cites primary sources; consistent with other authoritative sources.

Part 2: Simon Willison, harness as the defining structure

Source: "How Coding Agents Work" (chapter of the Agentic Engineering Patterns guide), https://simonwillison.net/guides/agentic-engineering-patterns/how-coding-agents-work/ (March 16, 2026). Simon Willison. CRAAP: 4.9 (Currency 5, Relevance 5, Authority 5, Accuracy 5, Purpose 5)

Willison provides the cleanest technical definition of what a harness is from a practitioner's perspective:

"A coding agent is a piece of software that acts as a harness for an LLM, extending that LLM with additional capabilities that are powered by invisible prompts and implemented as callable tools."

"The defining feature of an LLM agent is that agents can call tools. But what is a tool? A tool is a function that the agent harness makes available to the LLM."

The tool loop: "LLM + system prompt + tools in a loop" is the core mechanism. "A simple tool loop can be achieved with a few dozen lines of code on top of an existing LLM API," though "a good tool loop is a great deal more work."

System prompt as harness foundation: The harness begins every conversation with a system prompt providing "instructions telling the model how it should behave," with these prompts "often hundreds of lines long."

Willison announced the guide on his Substack on Feb 27, 2026 (https://simonw.substack.com/p/agentic-engineering-patterns) as "coding practices and patterns to help get the best results out of coding agents like Claude Code and OpenAI Codex."

Confidence: High. Willison is a canonical voice in Python/Django engineering with 20+ years of credibility. This is a comprehensive technical guide, not opinion.

Evidence gap: Most of Willison's earlier writing (2023-2025) is tool-review and capability-assessment rather than harness architecture. The March 2026 Agentic Engineering Patterns guide is his primary harness-engineering source.

Part 3: Anthropic's engineering blog, beyond "Building Effective Agents"

Post 1: Effective Harnesses for Long-Running Agents

Source: "Effective Harnesses for Long-Running Agents", https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents (November 26, 2025). Justin Young (primary) and twelve co-authors. CRAAP: 5.0 (Currency 5, Relevance 5, Authority 5, Accuracy 5, Purpose 5)

This is the earliest explicitly harness-focused engineering post from Anthropic (predating the term's popularisation by about two months). It addresses multi-context-window agents and proposes a two-agent architecture:

1. Initializer Agent: First session; establishes shell scripts, progress documentation, initial repository state
2. Coding Agent: Subsequent sessions; incremental feature advances, maintains system cleanliness

Key technical claims (with high confidence):

• Context compaction alone is insufficient for production-quality long-running agents
• Agents exhibit a tendency to attempt complete implementations in one pass, exhausting context mid-feature; structured JSON feature lists prevent premature completion
• Incremental, feature-by-feature approaches dramatically improve quality
• Structured artefact formats (JSON over Markdown) reduce inappropriate model modifications
• Browser automation (Puppeteer MCP) required explicit prompting to use: "agents needed explicit prompting to use browser automation tools and do all testing as a human user would"

Key framing: Human engineering practices directly informed these architectural choices. The harness mirrors established software engineering disciplines: clear documentation, staged progress, comprehensive testing.

Confidence: High. First-party Anthropic engineering post with named authors and specific technical claims.

Post 2: Scaling Managed Agents: Decoupling Brain, Hands, Session

Source: "Scaling Managed Agents: Decoupling the Brain from the Hands", https://www.anthropic.com/engineering/managed-agents (April 8, 2026). Lance Martin, Gabe Cemaj, Michael Cohen and colleagues. CRAAP: 5.0 (Currency 5, Relevance 5, Authority 5, Accuracy 5, Purpose 5)

This post introduces Managed Agents and articulates the most architecturally sophisticated harness framework in the genre. The central insight:

"Harnesses encode assumptions that go stale as models improve"

The three-layer decoupled architecture:

1. The Brain: Claude and its harness (the inference loop)
2. The Hands: Sandboxes and tools performing actions
3. The Session: An append-only, durable event log external to the harness

What makes this novel: Earlier single-container designs created "pets", fragile systems requiring hand-nursing that lost state on failure. The decoupled architecture makes containers "cattle", interchangeable and disposable. The harness calls sandboxes via a standardised interface: execute(name, input) → string. The harness functions as the agent loop that calls Claude, routes tool calls to infrastructure, and maintains state continuity through durable event logs.

The session outside the context window: The session log lives "completely outside the harness" and is accessible via getEvents(). Context management decisions become reversible rather than destructive.

Key verbatim quotes:

"Each became an interface that made few assumptions about the others" "The harness no longer lived inside the container" "Unopinionated about the specific harness that Claude will need"

Drawing on OS design (virtualising hardware abstractions), this post frames Managed Agents as a "meta-harness": a general interface accommodating future harnesses including Claude Code and task-specific agents.

Confidence: High. Anthropic engineering team; specific architectural claims; independently covered by InfoQ and KenHuang substack.

Part 4: Andrej Karpathy, foundational framing rather than harness-specific writing

Source: X post, https://x.com/karpathy/status/1707437820045062561 (September 28, 2023). CRAAP: 4.5 (Currency 3, Relevance 4, Authority 5, Accuracy 5, Purpose 5)

The foundational framing that most harness engineering writing implicitly or explicitly builds on:

"A more complete picture is emerging of LLMs not as a chatbot, but the kernel process of a new Operating System."

He describes LLMs orchestrating input/output across modalities, a code interpreter, file/memory access and process spawning (spawning subagents). This is the conceptual ancestor of "the harness is the OS around the model kernel."

2025 LLM Year in Review (https://karpathy.bearblog.dev/year-in-review-2025/, late 2025 / early 2026). Karpathy describes LLM applications like Cursor as bundling and orchestrating multiple model calls:

"They orchestrate multiple LLM calls under the hood strung into increasingly more complex DAGs, carefully balancing performance and cost tradeoffs."

"They do the 'context engineering'"

On Claude Code as the reference implementation:

"Claude Code (CC) emerged as the first convincing demonstration of what an LLM Agent looks like — something that in a loopy way strings together tool use and reasoning for extended problem solving."

Evidence gap: Karpathy has not written specifically about "harness engineering" as a discipline. His contribution is architectural framing: the LLM-as-kernel analogy, the context engineering concept, and agent architecture by example (Claude Code, LLM Council). Writers citing "Karpathy on harness engineering" are extrapolating from his broader systems framing. Karpathy is correctly cited as the originator of the LLM-as-OS metaphor and the emphasis on context engineering, not as a harness engineering practitioner.

Confidence: High (for what he has actually said). Evidence gap confirmed.

Part 5: Practitioner primary sources

Thorsten Ball (Amp/Sourcegraph): minimal scaffolding

Source: Changelog Podcast Episode 648, "Agent, take the wheel with Thorsten Ball", https://changelog.com/podcast/648 (July 2, 2025). CRAAP: 4.2 (Currency 4, Relevance 4, Authority 4, Accuracy 4, Purpose 5)

Ball articulates a deliberate counter-position to heavy harness engineering: build minimal scaffolding and let the model do the work.

"Built light scaffolding, wooden scaffolding around the model, so when the model gets better and bigger and stronger, the scaffolding falls away."

On the core agent loop:

"It's just a for loop... you send that up to the provider... the response comes back... 'The assistant wants to call a tool.' Then you execute the tool... and send the result back up."

Key architectural insight: Agent infrastructure must remain adaptable to rapid model improvements. Harnesses that lock into specific orchestration patterns become technical debt as models improve. This is the practitioner argument for harness minimalism, contrasting with Hashimoto's ratchet/hardening approach. Ball and Quinn Slack also run the "Raising an Agent" podcast (ampcode.com/podcast), with ongoing practitioner discussion.

Confidence: Moderate. Podcast rather than written post; strong practitioner credentials; represents a legitimate dissenting view on harness complexity.

Cognition (Devin): cloud agent infrastructure

Source: "What We Learned Building Cloud Agents", https://cognition.ai/blog/what-we-learned-building-cloud-agents (April 23, 2026). The Cognition Team. CRAAP: 4.7 (Currency 5, Relevance 5, Authority 5, Accuracy 4, Purpose 4)

Cognition's post is the most detailed published account of what enterprise agent infrastructure actually requires to build. Three-layer orchestration stack:

1. Orchestration Layer: Provisions and manages environments (microVMs, not containers); demand prediction for warm VM pools; session routing. "Took over three quarters of dedicated engineering to build and can manage thousands of concurrent VMs."
2. Governance Layer: Inherits engineer permissions, maintains tamper-evident audit trail, handles identity chaining at enterprise scale.
3. Integrations Layer: CI, monitoring, registries, documentation, source control. Stripe maintains "internal MCP server with over 400 tools."

Key security architecture claim:

"Containerized agents share a kernel, which means one compromised session can access every other container's filesystems, credentials, and network connections."

Solution: microVMs requiring "over a year of hypervisor engineering." State snapshotting at hypervisor level captures "memory, process trees, and filesystem", enabling agents to pause during CI waits and resume exactly where they left off.

Confidence: High. First-party Cognition engineering blog; specific engineering claims with named complexity.

Stripe: Minions

Source: "Minions: Stripe's one-shot, end-to-end coding agents", https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents (February 9, 2026). Alistair Gray. CRAAP: 4.7 (Currency 5, Relevance 5, Authority 5, Accuracy 4, Purpose 4)

Stripe's Minions system is the most-cited production-at-scale example in the harness engineering genre:

"Over a thousand pull requests merged each week at Stripe are completely minion-produced, and while they're human-reviewed, they contain no human-written code."

Harness architecture:

• Execution environment: Isolated "devboxes" pre-warmed in 10 seconds with Stripe's full codebase
• Agent core: Customised fork of Block's open-source "goose" coding agent
• Context layer: MCP connectivity to internal "Toolshed" with 400+ tools
• Feedback loops: Automated linting under 5 seconds plus selective CI testing with automatic fixes

Design philosophy: One-shot (agent runs start to PR with no interaction), with an "at most two CI runs" policy balancing speed against diminishing returns.

Part 2 of the series (https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2, Feb 19, 2026) covers the "blueprints" concept referenced by Böckeler: structured task specifications that constrain what the agent attempts.

Confidence: High. First-party Stripe engineering blog; independently covered by InfoQ, ByteByteGo, and multiple engineering publications.

Omar Khattab / DSPy / Stanford: Meta-Harness

Source: DSPy framework (ICLR 2024 paper), https://github.com/stanfordnlp/dspy; Meta-Harness paper (arXiv preprint 2603.28052, not peer-reviewed). CRAAP (DSPy ICLR paper): 4.8 (Currency 4, Relevance 5, Authority 5, Accuracy 5, Purpose 5)

Khattab's contribution to harness engineering is the automated optimisation angle: rather than hand-engineering harnesses, DSPy and Meta-Harness demonstrate that harness design can be framed as an optimisation problem.

DSPy (ICLR 2024): "Compiling Declarative Language Model Calls into State-of-the-Art Pipelines" establishes that structured signatures plus optimisers outperform hand-crafted prompts. This is the foundation for treating the harness as an artefact that can be searched and optimised, not just designed.

Meta-Harness: Yoonho Lee, Roshen Nair, Qizheng Zhang, Kangwook Lee, Omar Khattab and Chelsea Finn, Meta-Harness: End-to-End Optimization of Model Harnesses (arXiv preprint, 2026). An agent searches over harness code, reading earlier candidates' code, scores and traces. On TerminalBench-2 a discovered harness reached a 76.4% pass rate with Claude Opus 4.6, above the hand-engineered Terminus-KIRA (74.7%); with Claude Haiku 4.5 it reached 37.6%, the best reported Haiku 4.5 result. On online text classification it improved on a state-of-the-art context management system by 7.7 points while using a quarter of the context tokens.

Key claim for citation: the abstract's opening point, that a language model system's performance depends on its harness as well as on its model weights.

Confidence: Medium-high. DSPy is a peer-reviewed ICLR 2024 paper. Meta-Harness is an arXiv preprint, not yet peer-reviewed; its figures are the authors' own.

Evidence gap: Khattab's work is primarily research and framework rather than practitioner blog writing. DSPy is best cited for the "harness as optimisable artefact" claim; Meta-Harness for the quantitative performance claims.

Harrison Chase (LangChain): indirect contribution

Evidence gap confirmed: No primary blog post by Harrison Chase specifically about "harness engineering" was located. LangChain's harness engineering contributions come through Vivek Trivedy's "Anatomy of an Agent Harness" post (March 2026) and the LangChain Better-Harness framework, not through Chase directly. The formula "Agent = Model + Harness" is associated with LangChain as an organisation, not Chase personally.

Part 6: An emerging framing, harness engineering as the "fourth paradigm"

Multiple sources (TechTimes, SmartScope, Atlan) describe harness engineering as the "fourth paradigm of AI engineering," following:

1. Prompt engineering (2022–2024)
2. Fine-tuning / RAG (2023–2024)
3. Context engineering (2025)
4. Harness engineering (2026)

This framing is secondary synthesis, not primary source material.

Evidence gaps

Beyond the gaps noted against Karpathy, Harrison Chase and the OpenAI post above:

1. Amp/Quinn Slack written primary source: no formal written post from Quinn Slack on harness architecture. The Amp perspective comes mainly through the Changelog interview with Thorsten Ball and the "Raising an Agent" podcast.
2. Devin/Cognition on harness theory: Cognition's post covers cloud infrastructure in depth but does not use "harness engineering" as a conceptual frame. Its contribution is infrastructure-layer evidence, not theoretical framing.
3. Pre-2026 harness writing: "harness" in agent contexts appears sporadically before 2026 (Willison uses it in passing in 2024), but without the discipline framing that Hashimoto and Trivedy gave it. No authoritative 2024 source was found that uses "harness engineering" as a named practice.

Recommended citation hierarchy

For anyone writing about harness engineering as an emerging discipline, the research ranked the sources in this order of authority:

Tier	Source	Why
1: Foundational	Hashimoto, mitchellh.com (Feb 5, 2026)	Coins the practice
1: Foundational	Willison, simonwillison.net (Mar 16, 2026)	Canonical engineering voice; cleanest technical definition
1: Foundational	Böckeler, martinfowler.com (Apr 2, 2026)	Most citable venue; systems/cybernetics framing
2: Institutional	Trivedy/LangChain (Mar 10, 2026)	Coins "Agent = Model + Harness"; benchmark evidence
2: Institutional	Anthropic Engineering, Nov 2025 + Apr 2026	First-party; two complementary posts
2: Institutional	Stripe dev blog (Feb 9 + Feb 19, 2026)	Production at scale; 1,000+ PRs/week
3: Research	Khattab/DSPy (ICLR 2024) + Meta-Harness (arXiv:2603.28052)	Quantitative performance claims
3: Practitioner	Osmani, addyosmani.com (Apr 19, 2026)	Google voice; ratchet principle
3: Practitioner	Ball/Amp, Changelog (Jul 2, 2025)	Contrasting minimalism view
4: Background	Karpathy, X post (Sep 28, 2023)	LLM-as-OS foundational metaphor
4: Background	Cognition, cognition.ai (Apr 23, 2026)	Infrastructure depth; cloud agent harness

Methodology

Search strategy: 10 searches across five vectors: (1) Karpathy agent framing, (2) Willison harness writing, (3) Anthropic engineering blog, (4) "harness engineering" term origin, (5) Amp/Thorsten Ball. Pass 2 targeted: Mitchell Hashimoto original post, LangChain anatomy post, Stripe Minions, Cognition infrastructure, DSPy/Khattab.

Confidence distribution: 14 high, 3 moderate, 0 low, 3 insufficient evidence (Harrison Chase, OpenAI direct text, Karpathy harness-specific).

Triangulation applied: The "Agent = Model + Harness" formula was confirmed across Trivedy/LangChain, Gabriel Chua/OpenAI, Böckeler/Fowler, and Osmani/Google (4 independent sources, different institutions). Hashimoto as coinage source was confirmed across 6+ secondary sources citing his Feb 5, 2026 post.

Scope limitations: English-language sources, primarily blog posts and technical writing. Academic papers covered only where directly relevant (DSPy ICLR 2024, Meta-Harness arXiv). Conference talks are not covered (except Karpathy's YC AI Startup School talk, available on YouTube but not fetched).

Full source list with CRAAP scores

#	Source	URL	Date	CRAAP
1	Hashimoto: My AI Adoption Journey	https://mitchellh.com/writing/my-ai-adoption-journey	Feb 5, 2026	4.8
2	OpenAI: Harness Engineering (Lopopolo/Chua)	https://openai.com/index/harness-engineering/	Feb 11, 2026	4.6*
3	Stripe: Minions Part 1 (Gray)	https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents	Feb 9, 2026	4.7
4	Stripe: Minions Part 2	https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2	Feb 19, 2026	4.7
5	Willison: Agentic Engineering Patterns (Substack)	https://simonw.substack.com/p/agentic-engineering-patterns	Feb 27, 2026	4.9
6	Trivedy/LangChain: Anatomy of an Agent Harness	https://www.langchain.com/blog/the-anatomy-of-an-agent-harness	Mar 10, 2026	4.6
7	Willison: How Coding Agents Work	https://simonwillison.net/guides/agentic-engineering-patterns/how-coding-agents-work/	Mar 16, 2026	4.9
8	Böckeler/Fowler: Harness Engineering for Coding Agent Users	https://martinfowler.com/articles/harness-engineering.html	Apr 2, 2026	4.9
9	Anthropic Eng: Managed Agents (Martin, Cemaj, Cohen)	https://www.anthropic.com/engineering/managed-agents	Apr 8, 2026	5.0
10	Osmani: Agent Harness Engineering	https://addyosmani.com/blog/agent-harness-engineering/	Apr 19, 2026	4.5
11	Cognition: What We Learned Building Cloud Agents	https://cognition.ai/blog/what-we-learned-building-cloud-agents	Apr 23, 2026	4.7
12	Anthropic Eng: Effective Harnesses for Long-Running Agents (Young et al.)	https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents	Nov 26, 2025	5.0
13	Ball/Amp: Changelog Podcast Episode 648	https://changelog.com/podcast/648	Jul 2, 2025	4.2
14	Karpathy: LLM as OS (X post)	https://x.com/karpathy/status/1707437820045062561	Sep 28, 2023	4.5
15	Karpathy: 2025 LLM Year in Review	https://karpathy.bearblog.dev/year-in-review-2025/	Late 2025	4.7
16	Khattab/Stanford: DSPy (ICLR 2024)	https://github.com/stanfordnlp/dspy	2024	4.8
17	Amp: Raising an Agent Podcast	https://ampcode.com/podcast	Ongoing 2025	3.8
18	Willison: Fireside Chat Pragmatic Summit	https://simonw.substack.com/p/fireside-chat-about-agentic-engineering	2025/2026	4.4
19	Anthropic: Building Effective Agents	https://www.anthropic.com/research/building-effective-agents	Dec 2024	5.0

*403 on direct fetch; CRAAP score based on secondary source corroboration. All other URLs were verified via WebFetch or confirmed live via WebSearch.