What's the Same, What's Different, and Where to Go From Here

Picture three teams at the same company. One builds a research agent that summarizes competitor filings. One builds an agent that triages support tickets before a human touches them. One builds an agent that assembles evidence for a loan-approval decision. Different code, different stakeholders, different stakes, but ask each team "what stops your agent from quietly failing," and the honest answer is the same short list: a manifest, a verifier, a human gate at the right point, and a trace of what happened. That's the whole thesis of this lesson. An archetype, as this course uses the word, just means which of those three project shapes you're building: research and synthesis, process integration, or decision support. This lesson lines the three archetypes up side by side and shows the one discipline running underneath all of them.

Three archetypes, one discipline

You've now walked through three shapes of agent project (research and synthesis, process integration, decision support) and it would be reasonable to leave thinking you've learned three separate disciplines. You haven't. You've seen the same small set of primitives configured three different ways, and this lesson exists to make that explicit, because the discipline only transfers to a fourth project you've never seen if you can see the primitives underneath the surface differences.

What's the same across all three

The patterns from earlier repeat, with different fields and different gates each time, but the same underlying discipline:

• A manifest per unit of work — a research entry, a work item, a case file. Different fields, same discipline.
• A verifier in deterministic code — different checks, same role. No verifier, no shipping.
• Structured input over AI-generated input — different sources, same principle. The seed is human; the expansion is agentic.
• Human-in-the-loop at the right altitude — different gates, same logic: cost-of-wrong against cost-of-asking.
• Trace everything — JSONL is JSONL is JSONL. Audit trails win arguments.
• Boring tools win — different stacks, same principle. The thing has to outlive you.
• Just-in-time context beats frontloading, credited to Ryan Lopopolo — error messages are prompts, in all three archetypes.
• Fresh sessions for high-stakes work, credited to Dex Horthy — trajectory poisoning hits archetypes B and C directly; sub-agent decomposition prevents its equivalent in A.
• The week-1 deliverable matters more than the week-12 deliverable — different artifacts, same urgency.

Three different problem shapes. One shared discipline.

What's different across the three

:::tabs{labels="Primary work and stakeholders,Risk and HITL placement}

:::

Find the row that matches your project. That's your archetype, and the week-one deliverable from that lesson is your actual starting point. Watch the calibration row in particular: Archetype C is the one where calibration isn't optional. In A you can ship with rough confidence labels; in B confidence mostly helps with routing; in C the confidence number is a legal promise. That distinction identifies which archetype you're in faster than anything else on this page.

The failure catalogue

Every failure mode covered across the three archetype lessons, in one place, attributed to whoever in the practitioner community first named it:

| # | Failure mode | Source | Where it hits | Defense |
|---|---|---|---|---|
| 1 | Hallucinated facts | Universal | A | mark_unknown + verifier requires sources |
| 2 | Stale data | Universal | A | Manifest records accessed_at; flag old sources |
| 3 | Lost provenance | Universal | A, B, C | Source pointer required for every claim |
| 4 | The dumb zone (past ~40% context) | Horthy | A, B, C | Fresh window per item; sub-agent decomposition |
| 5 | Frontloaded context forgotten | Lopopolo | A, B, C | Just-in-time context — error messages as prompts |
| 6 | Trajectory poisoning | Horthy | B, C | Fresh session per case; never continue a rejected loop |
| 7 | Bullied agent | Lopopolo | B, C | Priority labels on feedback; permission to defend |
| 8 | Cross-session context bleed | Krenel / OpenClaw | B, C | Sessions-as-processes; OS-grade isolation |
| 9 | Lost liveness — no sense of time | Krenel / OpenClaw | B, C | Cron plus heartbeat; design the hooks even if unused |
| 10 | Brittle integration | Universal | B | Schema validation per call; alert on drift |
| 11 | Wrong stakeholder | Universal | B | Identify the actual end-user in week 1 |
| 12 | No deployment path | Universal | B | Map the deployment plan in week 4 |
| 13 | Automation bias | Universal | C | Show contradicting evidence prominently |
| 14 | Calibration drift | Universal | C | Monthly bucket analysis; alarm on drift |
| 15 | Liability ambiguity | Universal | C | Crystal clear: AI prepared, human decided |
| 16 | Hidden bias amplification | Universal | C | Bias audit on samples; demographic parity testing |
| 17 | Permission leaks | Universal | — | Permission gate at query time, audited weekly |
| 18 | Adoption death spiral | Universal | — | Quality bar held before broad rollout |
| 19 | Operability failure | Universal | All | Boring tools, a runbook, written for the junior analyst |

Nineteen failure modes, six broad categories, three archetypes, one discipline. "Universal" means this failure has shown up in essentially every kind of agent project regardless of archetype. The cited rows (Horthy on the dumb zone and trajectory poisoning, Lopopolo on frontloaded context and the bullied agent, Krenel's OpenClaw analysis on cross-session bleed and liveness) are failure modes named first by other practitioners and carried into this course's archetype framework; their original work goes deeper on each than a single lesson can.

The fourth column tells you which archetype you're most exposed to. Research synthesis: hallucinated facts, lost provenance, the dumb zone. Decision support: automation bias, calibration drift, trajectory poisoning. Different archetypes carry different exposure. The fifth column, the defense, is what the harness gives you: source pointers, fresh sessions, priority labels, schema validation, bias audits. None of these is individually hard. The discipline is knowing which ones your project actually needs.

Four conversations converging on the same primitives

Step back further, and the pattern gets bigger than this course. Multiple practitioner communities, working on what look like unrelated problems, have independently converged on the same small set of building blocks:

The primitives repeat across all four: manifests, sub-agents, traces, verifiers, just-in-time context, process isolation. Different problems, same underlying vocabulary. Mitchell Hashimoto gave this vocabulary a name, harness engineering, in a blog post that seeded much of this discourse, and it's the term this course has used throughout.

One caveat worth stating plainly. Krenel's OpenClaw analysis includes the observation that, inside a single maintainer's self-modifying experimental agent, "code quality is dead": the agent is its own maintainer, so conventional code hygiene matters less. For an organizational project, that's exactly the wrong takeaway. You're shipping to a team that has to operate what you built after you leave. They need to read the code, debug it when it breaks, and trust the documentation. Borrow the architectural insight (sessions as processes, cron and heartbeat) and leave the maintenance philosophy behind.

So, why do AI agents fail?

Back to the question this course opened with:

AI agents fail because someone forgot to build the harness, or built one that doesn't match the failure modes their archetype actually faces.

Models will keep improving. The failure modes in the table above mostly won't move, because they're properties of the loop the model sits inside, not properties of the model itself. That's the durable part, and it's why the discipline outlasts any particular model generation.

The model is interchangeable. The harness is the project.

Monday morning, do this

Five hours, end of day Monday, and you have a harness skeleton: a manifest, a verifier, an HITL gate, and one failure mode actively defended against. The model is the last thing you wire in.

The model is interchangeable. The harness is the project.

Checking the synthesis

Where to keep learning

This course built directly on public work by four practitioners, cited throughout rather than folded in silently:

• Ryan Lopopolo, OpenAI — on building software with coding agents, including the harness-engineering framing this course borrows for just-in-time context and the "error messages are prompts" pattern.
• Dex Horthy, 12-Factor Agents — on advanced context engineering for coding agents: the dumb zone, the research-plan-implement loop, intentional context compaction.
• Mitchell Hashimoto — who coined "harness engineering" in a blog post, giving this whole discipline its name.
• Alex Krenel, UC Berkeley — for the OpenClaw architecture analysis this course draws sessions-as-processes and cron-plus-heartbeat from.

If you build something using what this course covered (at work, on a side project, anywhere) write at sovereignagents.co, where longer failure post-mortems and the discipline as it evolves get published, or follow @profrodai on LinkedIn and X for what comes next in this course series. Both are first-party channels, not a mailing list or a waitlist. There's nothing to sign up for here, just somewhere to keep reading.