Zero to Agent in 30 Minutes: Build a Workflow Agent with John Berryman
Michelle Smith · rss · 2026-07-20 source ↗ Reader 🖥️
An AI agent is, at bottom, simply an LLM wrapped in an outer conversation loop and an inner tool-use loop, and the right way to build one is 'outside in' — get the non-AI application working first, stub the AI, then incrementally swap in a minimal validated agent, a small fixed toolkit, and a natural-language 'skill' — because this staged sequencing both de-risks the build and produces instructions plain enough that domain experts, not just engineers, can read and correct them directly.
practical · expository — A syndicated recap/write-up of a live webinar demo, opening with a short conceptual frame (what an agent structurally is) before reporting a numbered five-step build method as it was demonstrated. Reports what John Berryman did and said rather than arguing a contested thesis, and closes with a promotional pointer to a follow-on paid/free O'Reilly event.
Structure
| Part | Role |
|---|---|
| Opening bio/context | context |
| Dual-loop definition of 'agent' | conceptual foundation |
| Natural-language payoff paragraph (SME legibility) | motivation / stakes |
| Five-step 'outside in' method (traditional software → stub → minimal agent → small toolkit → natural-language skill) | procedure / evidence |
| Closing prediction + event teaser | conclusion and commercial coda |
Key terms
- agent Agentic AI
An LLM wrapped in two loops: an outer loop that passes messages back and forth to the user (shared with plain chatbots) and an inner loop that lets the model choose and run tools — the inner loop is specifically what turns an assistant into an agent. - outside in
Berryman's name for a build sequence: get the traditional (non-AI) software working first, fake the AI with a static stub, then swap in a real but minimal agent, then a small toolkit, then a natural-language skill — moving from the deterministic outer shell inward to the AI core. - skill Agent Skills
A natural-language artifact encoding an agent's context, decision criteria, and step-by-step workflow — including self-checking checklists — written instead of a coded state machine. - structured output
Output requirements with validation (here, three fields: update type, internal notes, correspondence) imposed on the minimal agent specifically to keep the underlying model 'on track.'
Propositions
- explicitAn AI agent is fundamentally an LLM wrapped in two loops: an outer loop that passes messages back and forth to the user (the basis of all AI chatbots), and an inner loop that lets the model choose and run tools — the inner loop is what turns an assistant into an agent.conf: highrefinesStop Overengineering Your Agent Harness · p1 — Berryman's account decomposes the terser 'LLM with tools in a reasoning loop' agent definition into two explicit loops (outer message-passing / inner tool-use) — finer structure on the same definitional target, not a broadened claim; it doesn't itself address Bowne-Anderson's self-termination criterion for what distinguishes an agent from a fixed 'LLM workflow' (see g5).
- explicitThis dual-loop agent architecture is simple and has not changed since 2023; what has changed is the quality of the tools and instructions available to agents.conf: high
- explicitBecause agent behavior can be expressed in natural language, subject-matter experts can read the instructions driving the AI, diagnose faulty responses, and make updates directly — without relaying feedback through a product manager and an engineer.conf: highsupportsThis Week in AI: Rethinking the Agent Harness · p5 — Independent convergence within the same author's O'Reilly series: both credit natural-language agent logic with letting domain experts read and modify behavior directly, without a developer/engineer intermediary.
- explicitThe traditional, non-AI parts of an application — interface, data model, and a precise definition of the AI component's input and output — should be built and working before any AI component is introduced.conf: high
- explicitSubstituting a static stub for the AI component before writing any AI code confirms the rest of the system works independently of the model.conf: high
- explicitGiving a minimal agent structured output requirements with validation keeps the underlying model on track.conf: high
- explicitA small, fixed starter toolkit — read, write, edit, and shell access — is enough for a new agent, because models have already learned bash and command-line tool use during training and can use shell access to extend their own capabilities (e.g., running curl for research).conf: high
- explicitEncoding an agent's context, decision criteria, and workflow as a natural-language 'skill' — rather than as a coded state machine — is preferable, and skills should include self-checking checklists so the agent confirms each step was completed or fails fast.conf: highsupportsThis Week in AI: Rethinking the Agent Harness · p14 — Berryman's step 5 (write skills as natural language instead of coding a state machine) is a concrete building instance of the claim that a plain-English skill is itself a kind of executable code.supportsAlex Wang's Post · p2 — Berryman's tip to build self-checking checklists into skills is a concrete instance of the corpus principle that repeatable procedures/checklists/playbooks belong in skills, not scattered elsewhere.
- explicitAI product development is headed toward fewer purpose-built applications and more general agents that operate across tools and interfaces on a person's behalf.conf: medium
- implicitcorroboratedComplexity should be added to an agent build only incrementally, and only once each simpler layer is proven — the five-step order (traditional software → stub → minimal agent → small toolkit → natural-language skill) encodes a staged de-risking principle that the piece never names as such.conf: mediumsupports ←Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch · p1 — Same 'add complexity only incrementally, prove each simpler layer first' principle from a sibling episode of the same webinar series, applied here to prompting -> loop -> multi-agent-review instead of that episode's app-plumbing -> stub -> agent -> toolkit -> skill build order.
- implicitThe specific demoed application (a job-candidate review pipeline) and specific tooling (a Pydantic agent) are treated as interchangeable instances of a general, domain-independent method — the piece presents 'outside in' as if it transfers to any AI product, not just this one demo.conf: medium
- implicitNatural-language legibility — skills that subject-matter experts can read and edit — is treated as inherently a quality/governance improvement, not merely a productivity one: the piece assumes direct SME editing produces better outcomes than the product-manager/engineer relay it replaces, without demonstrating this or acknowledging what that relay used to catch.conf: medium
Arguments
A team should build AI products 'outside in' — traditional software first, stubbed AI, then a minimal validated agent, then a small toolkit, then a natural-language skill — rather than starting from the AI component. strength: medium
Explicit premises:
- Defining the AI component's exact input and output requires the surrounding non-AI system to exist first.
- A static stub confirms the rest of the system works before the model is introduced.
- Structured output plus validation keeps a minimal agent on track once it is introduced.
- A small, well-known toolkit (read/write/edit/shell) suffices because models already know these tools from training.
- Natural-language skills with built-in checklists let the agent self-verify its own workflow.
Implicit premises:
- Isolating the AI component's risk from the rest of the system's risk is generally desirable in product engineering — a de-risking-by-sequencing principle imported from ordinary software practice (e.g. walking-skeleton style incremental builds) and applied here to AI without being argued for on its own terms.
- A single demoed pipeline (candidate review) generalizes to AI products broadly.
Inferences:
- If AI is the least predictable, most novel part of the system, isolating it last — after everything else is proven — minimizes the surface area exposed to that unpredictability at any given build stage; the piece implies this risk-management logic but never states it explicitly.
Programming agents in natural language ('skills') is preferable to traditional coded logic because it makes agent behavior legible and directly editable by non-engineers. strength: medium
Explicit premises:
- Subject-matter experts can read the instructions driving the AI.
- Subject-matter experts can examine faulty responses and see where the reasoning broke down.
- Subject-matter experts can make updates directly instead of relaying feedback to a product manager and an engineer.
Implicit premises:
- Removing the PM/engineer relay step is a net improvement rather than the loss of a useful check or translation function — the piece doesn't consider that engineers or PMs might catch problems an SME would miss, or that uncoordinated direct edits could introduce inconsistency or drift.
- Natural language is a reliable enough encoding of decision criteria that reading it is equivalent to understanding what the agent will actually do at runtime — which glosses over exactly the gap ('examine faulty responses... where the reasoning broke down') the argument itself says still needs diagnosing.
Inferences:
- If SMEs can both diagnose and fix agent behavior, the traditional requirements-relay role of product managers mediating between domain experts and engineers is at least partially disintermediated for this class of AI product.
Narratives
- John Berryman live-demos a job-candidate review pipeline, building it outside-in from working non-AI software, through a stubbed AI, to a minimal Pydantic-based agent with structured output validation, a four-tool starter kit (read/write/edit/shell), and a natural-language skill with self-checking checklists.
→ Makes the abstract five-step 'outside in' method concrete and credible by showing it executed end-to-end in roughly 30 minutes; grounds the implicit staged-de-risking premise (p10) and the implicit domain-generality premise (p11) in a real, observable instance rather than pure prescription.
Questions addressed
- ✅ What, structurally, is an AI 'agent' as opposed to a plain chatbot?
An LLM wrapped in an outer message-passing loop (shared with chatbots) plus an inner loop that lets the model choose and run tools; the inner loop is specifically what makes it an agent. - ✅ In what order should a team build an AI product to minimize risk?
Traditional software first, then a stubbed AI, then a minimal validated agent, then a small toolkit, then a natural-language skill. - ✅ How much tooling does a new agent need to be useful?
Start with four capabilities — read, write, edit, shell access — because models already know bash and CLI tools from training. - ⭕ How does an organization govern or maintain natural-language 'skills' once domain experts, not engineers, are editing them directly in production?
Not addressed — the piece celebrates direct SME editing as the 'payoff' of natural-language programming without discussing version control, review, testing, or drift once non-engineers are the ones changing production agent logic.
Gaps
- incompleteThe piece never says how or when to expand the starter toolkit (read, write, edit, shell) as an agent's task grows, nor how to decide a task needs additional or different tools — the four-tool recommendation is presented as a fixed starting point with no growth path.
Read next: Corpus material on tool registries, tool sprawl, and curation (agent-tool-management) would supply the missing 'what comes after the starter four' guidance this piece lacks. - incompleteThe 'payoff' of natural-language skills — SMEs read faulty responses and edit instructions directly, skipping the PM/engineer relay — is presented as an unambiguous win with no discussion of governance: version control, review, testing, or drift when non-engineers edit the natural-language logic driving production agent behavior.
Read next: Corpus material on skills-driven harness governance and agent self-documentation would address the maintenance/oversight question this piece leaves open. - incompleteStep 3 introduces structured output requirements 'to keep the model on track' but never discusses what happens when validation fails — no retry strategy, escalation path, or evaluation criteria for judging whether the minimal agent is actually working before proceeding to step 4.
Read next: Corpus material on evals as the acceptance-gate criteria for agent quality would supply the missing validation-failure handling this piece skips over. - incompleteThe 'outside in' method implicitly assumes every AI product has a natural non-AI baseline application to build first (an interface, a data model, defined I/O) — it doesn't address AI-native products with no such deterministic outer shell to build and stub around (e.g. an open-ended research or conversational agent whose whole value is the AI reasoning itself).
Read next: None specific in this corpus yet — worth reading agent-native-design material on products designed AI-first rather than AI-as-a-swapped-in-component. - incompleteThe article's own title calls the demoed system a 'Workflow Agent,' but the piece never clarifies whether it actually meets the corpus's own sharper agent/workflow distinction — an agent, strictly, is a reasoning loop that decides for itself when a task is finished, whereas a fixed deterministic sequence of model calls is an 'LLM workflow,' not an agent. Berryman's dual-loop definition doesn't say which side of that line his own checklist-driven, structured-output demo actually falls on.
Read next: extract-stop-overengineering-your-agent-harness — supplies the sharper agent-vs-workflow definitional test this piece's own title invokes but never resolves for its own demo.
Related documents
- Agent Harness Engineering
- The Anatomy of an Agent Harness
- Building AI Agents For The Enterprise
- Google Introduces Middleware Architecture for Genkit Applications
- 12-Factor Agents: Patterns of reliable LLM applications — Dex Horthy, HumanLayer
- Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale
- This Week in AI: Rethinking the Agent Harness
- Stop Overengineering Your Agent Harness
- 11 Tips For AI Coding With Ralph Wiggum
- Software Factories, Light and Dark