Agentic Build / Deploy Boundary
The agentic build / deploy boundary is the distinction between using an AI agent to design, debug, and improve a workflow while building it, versus deploying deterministic code, tools, and triggers that run without the agent present.
Key points
- In the 10-hour Claude Code course, Nate emphasises that self-healing is real during interactive build and iteration: Claude Code can read failures, adjust tools, and continue [src-016].
- Once the workflow is deployed on a schedule, webhook, or cloud runtime, the builder is usually deploying code and tools, not the live reasoning agent [src-016].
- This is not a weakness if handled deliberately: production automations should be predictable, deterministic, logged, and battle-tested before go-live [src-016].
- The boundary explains why WAT Framework (Workflows-Agent-Tools) separates Workflows, Agent, and Tools. The Agent accelerates construction; the Workflows and Tools are what can be deployed or handed over [src-016].
- Client delivery should therefore include QA, test data, error handling, logs, and maintenance expectations rather than promising magical self-repair in production [src-016].
- [src-086] generalizes the boundary into Agent Deployment Modes:
/loopand routines keep a live Claude Code agent in the run path, while Modal and trigger.dev usually run deployed code/workflows unless an agent SDK is added deliberately. - The practical question is not "is it an agent?" but "which parts of Workflows, Agent, and Tools survive deployment, and where do state, secrets, logs, and cost controls live?" [src-086].
Related entities
- Claude Code — the interactive agentic build environment
- Nate Herk — explains the boundary in the course
Related concepts
- Agentic Workflows
- WAT Framework (Workflows-Agent-Tools)
- AI Project Delivery and Handover Playbook
- Boring is Beautiful Automation
- Agent Deployment Modes