An agent that works in a demo and an agent you can leave running are different systems. The difference is almost entirely failure handling, and that is what this track teaches.
For engineers giving a model tools, a loop, and the ability to affect something outside itself.
The loop is four lines of pseudocode and every production incident involving agents is about what those four lines do when a step fails. Reason, act, observe, repeat — and the word doing the damage is 'repeat'.
The ReAct Agent Loop
A real production failure, reproduced, with its evidence: traces, logs, state, tool calls and cost. You diagnose the cause and then evaluate a proposed remediation — approve it or challenge it. You are not asked to implement the fix, because diagnosis is the skill that transfers.
None as a dependency. The failures being taught happen underneath every framework, and an agent you have built once yourself is one you can debug when a framework hides the loop from you.
They are drawn from documented production incidents and from published agent failure taxonomies, then reproduced so they can be examined safely. Each lab names the failure pattern it belongs to.
No, but agents that retrieve are the common case, and the two tracks are usually taken together. If your agent's problem is that it retrieves the wrong thing, start with RAG.
Because most agent bugs that look like reasoning failures are memory failures — an instruction that fell out of the context window, or state kept across a boundary where it should not have been.