The problem

“Harness engineering” isn’t a term anyone standardized yet, but the evidence for it is scattered everywhere — a benchmark buried in a conference talk, a postmortem in a newsletter, a YouTube teardown of someone’s agent observability stack. Nobody had pulled it into one place with a shared vocabulary, so most people (including teams making real infrastructure bets) were still thinking about this as “prompt engineering” when the actual lever had moved somewhere else. That gap costs money at company scale, not just personal frustration: a team that picks Claude Code vs. Codex as if it were a tool choice, rather than an architectural commitment, ends up compounding six months of workflow automation on the wrong foundation — the same mistake companies made picking AWS vs. Azure in 2010 before anyone understood the divergence. Klarna is the sharper version of the same failure: they optimized their support agent for ticket-resolution speed, saved $60M, and broke the actual business, because nobody had built the layer that tells an agent what the organization is really trying to accomplish.

The approach

This project is a research corpus and synthesis engine, not a standalone app — it runs on top of my own content pipeline (the same Playwright-scrape-plus-Claude-CLI system I built for course intelligence work) pointed at one topic instead of a general reading list. It has pulled in roughly 40 full Substack articles and close to 90 YouTube deep-dives on agent harnesses, coding-agent architecture, and multi-agent orchestration, and for every single one it writes a structured bundle: a tone/audience read, the core argument, the main concepts broken into named sub-sections, the concrete numbers and case studies, and — critically — a “routing log” that automatically maps the piece against my existing course curricula (multi-agent-orchestration, ai-up-skilling, prompt-architecture, observability-masterclass) and flags whether it’s course-worthy material or whether a new course needs to exist. So it’s doing two jobs at once: building a searchable evidence base, and doing the curriculum-placement work a human editor would otherwise have to do article by article.

The output isn’t just a pile of summaries — it converges into an actual point of view. The project’s synthesis distills the field into six concrete engineering concerns (the agent loop and its completion signaling, orchestration topology, shared state and memory scoping, feedback and verification gates, context engineering, and observability/cost control), and takes a stance on each: harness quality dominates model choice, role differentiation has to live in dispatch code rather than be decorative in a system prompt, and a single well-harnessed agent beats a poorly-harnessed swarm almost every time. That’s usable directly as course content or blog material for cogniflow-ai.com, not just personal notes.

What I learned

The single clearest data point in the whole corpus is the CORE benchmark: the exact same Claude Opus 4.5 weights scored 78% inside Claude Code’s harness and 42% inside Smolagents — nearly double the performance from harness design alone, with zero change to the model. That’s the concrete proof for something I’d suspected but hadn’t seen measured: almost every public benchmark compares brains, and the variable that actually determines whether an AI system works in production is invisible in all of them. The Klarna case taught me the adjacent lesson — a harness can be technically flawless (fast, cheap, verifiably correct) and still be strategically wrong, because “verification” only checks what you told it to check, and nobody had encoded what the business actually wanted into anything the agent could read.

Where this could go

The routing-log mechanism is the part I’d generalize first: an automated “does this belong in curriculum X, or does it justify a new one” classifier is exactly the kind of due-diligence tool an engineering org could point at its own internal postmortems, incident reports, or architecture-decision records instead of published articles — turning scattered institutional knowledge into a maintained body of doctrine the same way this project does for public sources. The harness-lock-in analysis buried in one of the sourced articles (an audit of which workflow layers a team has already built on top of a specific coding agent, scored across five divergence dimensions) is close to a ready-made framework for the exact conversation a CTO has before standardizing tooling org-wide — I’d want to turn that into a repeatable audit rather than a one-off read. And the underlying pipeline itself — paywalled-source scraping plus a file-writing LLM adapter that never touches raw API stdout — is reusable for any topic I want to build a defensible point of view on, not just this one.