Lecture 01 · 2 min read

Why Capable Agents Still Fail

Hand a top-tier model a real job and it still goes sideways. The problem isn't brains. It's that raw smarts with no system around them have nowhere to stand.

💡A racing driver with no pit crew

A world-class driver still loses the race if nobody changes the tyres, reads the telemetry, or calls the strategy. The car is fast, but a race is a system. A capable model is the driver. The harness is the pit crew, the telemetry, and the rules that turn raw speed into a finished lap.


The capability gap is not an intelligence gap

Benchmarks measure a model answering a bounded question in one shot. Real work is the opposite: it is open-ended, spans hours, touches dozens of files, and depends on a runtime the model cannot see. A model that aces the benchmark can still leave you with a broken build, because the benchmark never asked it to keep a hundred moving parts coherent over a long session.

So the interesting question is not "which model is smartest" but "what system makes this model reliable on this codebase." That system is the harness.

flowchart LR
  M["Capable model"] --> T["Real task, hours, many files"]
  T --> Fail["Goes sideways, lost context, false done"]
  M2["Same model"] --> H["Inside a harness"]
  H --> Win["Reliable, verified result"]
  linkStyle 1 stroke:#e0493f,stroke-width:2.5px,color:#e0493f
  linkStyle 3 stroke:#2ea043,stroke-width:2.5px,color:#2ea043
Same model, two outcomes. The difference is the system around it.

The failures repeat

Across teams and tools, the same handful of failures show up again and again:

  • Lost context, the agent re-derives or contradicts decisions it already made once the conversation rolls over.
  • Premature victory, "Done!" while the build is red and half the work is untouched.
  • Overreach, asked for one fix, it rewrites three modules into an unreviewable diff.
  • Runtime blindness, no logs, no live terminal, so it guesses at why the program behaves as it does.
  • No durability, the laptop sleeps, the process dies, and long tasks never get their hours.

None of these is solved by a bigger model. They are solved by structure around the model.

Where Agentum starts

Agentum is a Rust control plane that turns the harness into infrastructure. Your agents are ordinary CLIs, Claude, Codex, Gemini, Opencode, spawned in tmux panes on a host you control, so closing the lid does not kill the work. A per-session watchdog watches each pane, and the Harness Engine drives one feature at a time behind a verification gate that decides done, not the model.

The rest of these lectures take the failure modes above one at a time and show the structural fix, and how Agentum implements each one concretely.

Key takeaways

  • A better model raises the ceiling; it does not remove the failures, those are structural.
  • The useful unit of reliability is the system around the model, not the model alone.
  • The recurring failures (lost context, false "done", overreach, blindness, no durability) each have a concrete fix.
  • Agentum makes the harness real: tmux substrate, safe-tunnel access, verification-gated loop.

Exercises

  1. Spot the failure mode. Take your last agent session that went wrong and label it with one of the five failures above. Which structural gap let it happen?
  2. Name the missing system. For that failure, write one sentence describing the piece of harness that would have caught it.

Further reading

This lecture reframes the matching chapter of the open Walking Labs course for Agentum. Read the original ↗