THE AI RUNTIME · COURSE 001 · FREE · OPEN SOURCE
Engineering Long-Running AI Agents
Build an agent that keeps making correct progress after the request ends, the process dies, a tool times out, a human disappears for three hours, and the context window fills up.
Most agent tutorials end when the first answer appears. Production engineering starts there.
A long-running agent is not defined by taking ten minutes or ten hours. It is defined by execution continuity:
A long-running agent performs useful work whose lifecycle may outlive a single request, process, context window, worker, deployment, or human interaction.
RUN course-001 STATUS ready → 00 mental model ○ 01 naive agent ○ 02 state ○ 03 durable execution ○ 04 side effects ○ 05 work ownership ○ 06 failure handling ○ 07 human control ○ 08 context ○ 09 observability ○ 10 security ○ 11 evaluation ○ 12 deep agents ○ 13 industry architectures ○ 14 deploy ○ 15 production gauntlet
This course trains an FDE
The role this course trains is the Forward Deployed Engineer: the person who ships an agent into someone else's messy production reality and is accountable for it still running next week. An FDE cannot say "the demo worked." An FDE has to answer, in the customer's conference room, what happens after failure, and show the evidence.
So the standard for completing this course is not "the demo works." The standard is:
I can explain what happens after failure, prove the system preserves correct progress, and show the evidence.
Practitioners who operate at that standard are the people we interview on FDE Talks.
What you will learn
By the end, you should be able to explain and implement:
- durable state that survives process loss
- checkpoint and replay semantics
- idempotent and reconciled external side effects
- work claims, leases, heartbeats, cancellation, and orphan recovery
- failure taxonomies instead of retry(3) everywhere
- human approval that can wait for hours or days
- context rebuilt from durable artifacts rather than accumulated chat
- operator, engineer, and audit views of the same run
- tool permissions, SSRF controls, prompt-injection boundaries, and tenant isolation
- trajectory evals and regression gates
- a Deep Agents/LangGraph harness without confusing framework features for guarantees
- a public deployment whose reliability claims can be reproduced
The application
One deliberately boring application, for all sixteen modules: a Vendor Review Agent. It receives a vendor URL, researches a fixed checklist, records evidence, identifies unknowns and contradictions, waits for approval, and publishes one review.
The application stays constant so the engineering gets harder.
VendorRequest(
name="Acme",
root_url="https://vendor.example",
)
CHECKLIST = [
"product",
"customers",
"pricing",
"security",
"developer_experience",
"unknowns",
] The output is not "a good report." It has a contract
Vendor: Acme Coverage: 5/6 verified Unknown: enterprise pricing Claims: 11 Claims with resolvable evidence: 11/11 Contradictions surfaced: 1 Pages fetched: 14 Retries: 2 Human review rounds: 1 Published reports: 1 [Approve] [Research missing items] [Reject]
Every verified claim points to stored evidence. Every unknown remains unknown. Every irreversible side effect is auditable.
The six surfaces
Use this model throughout the course. It is intentionally framework-independent.
LONG-RUNNING AGENT
│
┌─────────────────┼─────────────────┐
↓ ↓ ↓
STATE EXECUTION CONTEXT
│ │ │
durable facts replay working set
evidence ownership artifacts
progress recovery handoffs
└─────────────────┼─────────────────┘
↓
CONTROL
approval · budgets
permissions · cancellation
↓
OBSERVABILITY
↓
EVALUATION Syllabus
Sixteen modules, each built around one production question. Read is always live. Watch turns on as each Failure Lab ships on YouTube, Notes as each longform ships on Substack.
- 00
Long-Running Agents: The Mental Model
When is a long-running agent justified?
- 01
- 02
- 03
- 04
Idempotency & External Side Effects
How do we survive ambiguous external writes?
LAB 04 The Duplicate Report
- 05
Work Ownership: Claims, Leases & Orphans
Who is allowed to execute a run right now?
LAB 05 Two Workers, One Run
- 06
Failure Handling, Retries & Recovery
Which failures retry, reroute, pause, or stop?
LAB 06 The Failure Matrix
- 07
Human-in-the-Loop & Long Waits
How do runs wait for people without holding compute?
LAB 07 The Three-Hour Approval
- 08
Context Engineering Across Long Runs
How do we prevent context accumulation and drift?
LAB 08 Context Rot
- 09
- 10
Security: The Hostile Vendor
What can untrusted content make the agent do?
LAB 10 The Hostile Vendor
- 11
Evaluating Long-Running Agents
How do we prove B is better than A?
LAB 11 The Judge That Agreed With Everyone
- 12
The Deep Agents Bridge
What does a production harness add above the runtime?
LAB 12 Replace the Harness
- 13
Industry Architectures & Case Studies
How do real systems instantiate the same primitives?
- 14
Deploying the Agent Publicly
Can the public system survive restarts and redeploys?
LAB 13 The Redeploy
- 15
What makes this course different
FAILURE BEFORE ABSTRACTION
You lose a run before learning checkpointing. You create a duplicate external write before learning idempotency. You watch two workers claim the same run before learning leases. The primitive arrives after the failure has made it necessary.
EVIDENCE OVER AGENT CLAIMS
"Done" is not a fact. "I published it" is not a fact. "I checked pricing" is not a fact. The runtime records what can be independently verified.
EVALS ARE THE DEVELOPMENT LOOP
The final module is not the first time quality appears. Every module adds an invariant and an evaluator. By the end, the gauntlet is simply all those invariants running together.
Every module follows the same rhythm: BUILD BREAK DIAGNOSE FIX PROVE
Prerequisites and readiness
You should be comfortable reading Python, calling an HTTP API, using Git, and running PostgreSQL-backed applications. You do not need prior LangGraph or Deep Agents experience.
Expect roughly 15-20 focused hours if you build every lab. Reading alone is useful, but the course is designed around breaking and repairing the running system.
- Python
- comfortable reading and writing it
- Git
- clone, branch, commit
- HTTP APIs
- you have called one from code
- PostgreSQL
- a free Neon account by Module 03
- Model API key
- any provider, by Module 01
- Docker
- optional, only for local Postgres
Start
Clone the course repository, run the deterministic fixture server, and begin with Module 00.
git clone https://github.com/ogkranthi/air-course-long cd air-course-long && make fixtures # deterministic vendor sites on :8001