Design agentic systems with the engineering discipline you already have — method you can copy, no trend talk.
Build Systems, Not Code - Angie Jones, Agentic AI Foundation · Angie Jones
20 min total·Actually worth watching closely: ~7 min·2 must-watch clips
- 0:00 – 3:20Listen
Core claim: designing agents is software engineering
Opens with relocation scout, a house-hunting agent, as the running example and states the thesis: the building blocks move up from code to prompts and agents, but the discipline is the same and engineers are still building.
You aren't giving up engineering — you've moved the same discipline up one layer.
Mostly framing, with nothing worth watching on screen; you lose nothing listening on a commute.▶ Jump to 0:00Speaker · Angie Jones - 3:20 – 7:02Listen
Before you let it loose: systems and workflow design
The agent is part of the system, not the system — there are also files, tools, humans and other agents — so think through its job, boundaries and failure modes, and give it a path rather than just a goal.
Every run ends one of three ways: stop, retry, or escalate — failure modes have to be designed up front.
Pure spoken argument with no demo on screen; the three-outcomes frame is the thing to take away.▶ Jump to 3:20Speaker · Angie Jones - 7:02 – 10:40Listen
Giant prompts are a smell; pick the right primitive per job
A do-everything prompt that keeps collecting exceptions makes the agent drift; the fix is pulling out the hidden jobs — a schema for structured output, a script for deterministic calculation, a skill for a reusable process, a narrowly scoped sub-agent for the meaty task.
A giant prompt is the agentic system's god object; separating the jobs is what makes each piece reasonable and testable.
The densest methodology stretch, but with no live demo — worth slowing down for and replaying if needed.▶ Jump to 7:02Speaker · Angie Jones - 10:40 – 14:06Listen
Division of labor, contracts, and structured memory
Code for what has an exact answer (cheaper, more reliable), agents for judgment and interpretation, humans for final authority; when something downstream has to act there needs to be an agreed-upon shape, and decisions and reasons get written into a memory layer in a known place rather than left in a session.
Handing the model every part of the task is the root of output that differs every day.
Argument-driven with nothing visual to depend on; what matters is remembering the code / agent / human split.▶ Jump to 10:40Speaker · Angie Jones - 14:06 – 17:00Listen
Idempotency enforced by the system: memory log and lint pass
On a retry the model can reword the same request until it looks like a brand new task, so it can't be trusted to police itself; log every action to memory and run a lint pass that spots half-done runs and completes only the missing step without repeating side effects.
Idempotency is a system mechanism — the email already went out, so only the unblocked calendar gets fixed.
A concrete walkthrough with no visuals; catching the two mechanisms — the log plus the lint pass — is enough to reuse it.▶ Jump to 14:06Speaker · Angie Jones - 17:00 – 19:37Listen
Threat modeling, the approval wall, and maintainability
Treat seller copy and forum threads as untrusted input — evidence, not instructions; reading and shortlisting can run autonomously, while emailing, booking tours and submitting offers stay behind human approval. Closes by returning to the "this is software engineering" theme.
The approval wall shrinks the blast radius: autonomy stops at any action that touches the outside world.
The security principles and the closing are spoken argument with no visual dependency — fine to just listen and note the approval-wall rule.▶ Jump to 17:00Speaker · Angie Jones