Deep Agents from Scratch: A 6-Session Field Guide to Shipping Agents You Can Trust

I am a big fan of Data Science Dojo and the way they run their workshops — hands-on, code-first, no hand-waving. Their Deep Agents from Scratch series (with SambaNova) is a perfect example: six sessions that take you from a bare ReAct loop to a multi-agent system you can actually evaluate and deploy. Every notebook is public, so you can run the whole thing yourself.

The repo: github.com/snova-kwasia/dsd-agents-webinar

This post is my distillation. The arc across the six sessions is one line worth memorising: think → build → remember → capable → scale → ship.

The whole series in one table

Session 1-2: An agent is a while loop

The most useful de-mystification in the whole series comes early. Strip away the frameworks and an agent is a while loop: the model reasons, calls a tool, observes the result, and repeats until it decides it is done. That is the entire ReAct pattern. Every framework — LangGraph, CrewAI, the OpenAI Agents SDK — wraps that same loop; the difference is what they add on top.

Session 2 introduces a vocabulary that pays off for the rest of the series:

The key insight: production agents are harnesses, not just "an agent using a framework." And you improve a harness with three knobs, without changing the model: system prompts, tools and capabilities, and middleware. The proof the series cites is worth quoting:

The LangChain team went from 52.8% to 66.5% on TerminalBench 2.0 purely through harness engineering — same model, better prompts, tools and middleware.

The notebook runs the same task on the same model under three harness configurations (bare agent, add a system prompt, add tools and state) and you watch the quality climb each time.

Session 3: Context is the operating system

Session 3 borrows Andrej Karpathy's framing: the LLM is the CPU, the context window is RAM, and you are the operating system. The job is loading the right information into the window at the right time. The session names five context types — input, runtime, compression, isolation, and long-term memory — and focuses on the two hardest and highest-impact: compression and isolation.

The pattern to internalise is context offloading: a search tool saves its full result to a file and returns only a short summary, so the model never drowns in raw dumps. The deepagents library then makes this automatic — it compresses any tool output over 20K tokens to a file, and summarises the whole conversation at 85% of the context window. You describe the pattern; the library does the wiring.

Session 4: Skills and MCP — capability as open standard

This is the session most relevant to enterprise work. Agent Skills (a SKILL.md folder — frontmatter plus a markdown standard-operating-procedure plus optional bundled scripts) were created by Anthropic and published as an open spec. Since then OpenAI, Google, GitHub, Cursor and the deepagents library have adopted the same pattern — so the same skill folder runs unchanged across every major agent platform. That is the opposite of vendor lock-in.

The mechanic that makes it scale is progressive disclosure:

You can install 50 skills and pay well under 5K tokens of overhead — a skill only costs real tokens the moment it fires. MCP (Model Context Protocol) is the complement: skills package procedures, MCP servers package tools that live in a separate process. Most production agents use both — a SKILL.md says what to do, an MCP server gives it the actions to take. Swap in a real Postgres, Slack or SAP MCP server and the pattern is identical.

Session 5: From solo agent to a crew

One agent always hits a wall — the context fills, errors compound, and no single model is expert at everything. The state-of-the-art answer is a supervisor coordinating specialised sub-agents, each with an isolated context and a scoped tool set.

The running example is an Incident Postmortem Crew investigating a checkout latency spike, with each role on a different model:

Three patterns cover most systems: supervisor plus workers, parallel fan-out (the supervisor delegates to several analysts at once), and the writer-plus-critic loop (draft, review against a rubric, revise until approved or a cap is hit). A hard-won production lesson from the series: match the model to the role, including its tool-calling reliability — a model that generates great text is not always a reliable tool driver. And the number one multi-agent failure is an un-capped loop, so always cap it.

Session 6: The part that separates a demo from a product

Agents are non-deterministic — the same input can produce different valid outputs — so you cannot unit-test them like a function. You need evaluation: criteria, datasets and judges. And you do not evaluate a toy; the finale carries the Session 5 crew forward and tests it with a tool that fails like production — a web_search that returns HTTP 503 on its first call every run.

The harness uses four kinds of evaluator:

Two ideas from current research make it rigorous. pass^k measures how often the crew gets a task right on all k attempts — because passing once flatters a flaky agent. Recovery rate turns "does it handle failures?" into a tracked number, the resilience equivalent of an SLO. The whole discipline is one loop: evaluate → catch → diagnose → fix → re-evaluate, run in CI on every prompt, model, tool or architecture change — so your agent can only get better, never silently worse.

Production then wraps that harness with four concerns: cost and latency (model routing — a small model for easy steps, a strong one for hard reasoning), observability (trace every run, standardise on OpenTelemetry GenAI conventions, send to LangSmith or self-hosted Langfuse/Phoenix), guardrails and human-in-the-loop (an approval gate for high-stakes actions — exactly what Claude Code's plan mode is), and deployment.

Why this matters for SAP and ERP work

Strip the incident-response framing and this is the exact blueprint for an enterprise agent. A supervisor delegating to scoped sub-agents maps cleanly onto a procurement or finance workflow. Skills encode your SOPs as portable markdown; MCP connects the agent to SAP, a ticketing system or a data warehouse; context isolation keeps a long-running process from drowning in its own history; and the evaluation harness is the only honest way to know an agent is safe to put in front of a business process. The 503-recovery test is not academic — every real integration overloads eventually.

Try it yourself

The best part is that none of this is a slide deck — it is runnable code. Clone the repo, drop in a free SambaNova and Tavily key, and work through the notebooks in order:

github.com/snova-kwasia/dsd-agents-webinar

Hats off to Data Science Dojo and SambaNova for a workshop series that teaches the mechanics before the abstractions — exactly how this material should be taught. If you want to talk about bringing agentic patterns like these into an SAP or procurement context, that is what I do.