Building agents moves software engineering up a layer, where the building blocks change but the discipline remains.
2
Agentic systems need explicit workflows, decomposition, contracts, state management, and boundaries around risky actions.
3
Code should handle exact, deterministic tasks, agents should handle judgment, and humans should retain authority over consequential actions.
Summary
Angie Jones argues that engineers do not lose the satisfaction of building when coding agents write more of the implementation. The work moves to designing systems made from agents, tools, scripts, skills, memory, and human approvals. She demonstrates this through Relocation Scout, a house-hunting agent that gathers listings, researches neighborhoods, calculates commutes, stores structured decisions, and produces ranked shortlists. The design uses familiar engineering practices: systems thinking, workflow design, decomposition, separation of concerns, modularity, algorithmic thinking, contracts, state management, idempotency, threat modeling, and maintainability. Jones assigns exact calculations and filtering to code, ambiguous judgment to agents, and authority over actions such as booking tours to humans. She is also clear about the limits of letting a coding agent design the whole system. Without deliberate structure, it may produce giant prompts and systems that are hard to change or understand.
Agent building restores the satisfaction of software work at a higher layer
Jones describes working on operational agents late on a Friday and suddenly noticing that dinner had passed and the sun had set. She recognized the familiar flow of development. Her advice to engineers who feel agents are taking away the enjoyable parts of building is to let them handle the code and move up one layer. Designing an agentic system still involves architecture and engineering judgment. The components are different, but the discipline remains familiar. She uses Relocation Scout, a house-hunting agent, to show how engineers can apply their existing skills to systems that persist knowledge and make decisions across sessions.
Relocation Scout is more useful as a reusable system than as a one-time prompt that ranks a few property listings. It needs to persist knowledge outside a session and reload or query that knowledge later, including from a fresh context. Jones treats the agent as one part of an environment that includes files, tools, humans, and other agents. It gathers listings and neighborhood signals, weighs them against her preferences, and returns a ranked shortlist. Before asking a coding agent to build it, she asks what the agent's job is, what it depends on, what happens when it breaks, and where its boundaries and responsibilities lie.
A goal such as "Review this listing" does not describe the work an agent must perform. The workflow defines the path: gather the required information, weigh the listing against the user's criteria, and act. Each run should have an explicit ending condition. Jones names three possibilities: stop, retry, or escalate. Understanding that path helps determine what context the agent needs, which work it can perform directly, and when a tool or person should take over. She compares this with familiar software workflows such as CI/CD pipelines and ticket life cycles.
Decomposition and separation of concerns prevent giant prompts
Jones compares an oversized agent prompt with a giant class, bloated function, or service with too many endpoints. In Relocation Scout, one prompt had instructions for pulling and normalizing listings, formatting the shortlist, calculating commute time, and researching neighborhoods. These are four separate jobs, and putting them together makes the agent drift from its intended script. She assigns each responsibility to a better place: normalization can become a reusable skill, output formatting belongs in a schema, commute calculation belongs in a script, and neighborhood research is suitable for a sub-agent. The point is to make each part easier to reason about and change.
Skills and sub-agents are reusable modules with different scopes
Jones treats agent skills as reusable capabilities, similar to packages or libraries. A listing-normalization skill can be loaded by agents working across three cities, so the logic is written once and reused across markets or shared with other people. She describes sub-agents as architecturally similar to functions. A sub-agent receives one specific task, has only the context needed for that task, and can be called from different workflows. Her neighborhood-research sub-agent can work in different markets. She also cautions that reuse requires judgment. Some instructions are local to one workflow, and abstracting them can cost more than it saves.
Use code for exact answers, agents for judgment, and humans for authority
Jones says an agent's ability to perform a task does not mean it is the right tool. Commute calculation and deduplicating already-seen listings have exact answers, so ordinary code can do them more cheaply and reliably. Models are better suited to fuzzy inputs, interpretation, ambiguity, and reasoning. Her rule is to use code for determinism, agents for judgment, and humans for authority. In Relocation Scout, the agent decides which listings deserve closer attention, code calculates commutes and filters duplicates, and Jones approves booking a house tour. This division keeps consequential decisions with the person who has authority to make them.
Structured contracts make agent outputs usable by later steps
Free-form text works when a person is the only reader. When another system must act on an agent's result, Jones says the output needs a contract. Relocation Scout stores a house decision in a structured shape containing a score and reason, along with other known fields such as commute information. Jones uses Compendium Wiki as the memory layer for most of her agents. Because the fields are structured, she can later query for houses with a score of four or better and a commute of 15 minutes or less. A shortlist step can read the same fields without a human in the loop. Defining the shape also forces the designer to specify what the agent should produce.
State and idempotency let a system recover without repeating actions
Useful systems must handle duplicate webhooks, incomplete runs, and crashes. The agent needs to know which actions already happened, whether inputs changed, and which parts are safe to retry. Jones emphasizes idempotency, where running an operation twice does not create a mess. Model outputs can vary on retries, so the system must enforce this rather than trusting the model. In her example, Relocation Scout emails a realtor and then crashes before blocking the viewing time on the calendar. A later lint pass checks the recorded state, sees that the email was sent, and performs only the missing calendar action. The agent avoids sending the same email again.
Security boundaries and maintainability belong in the system design
Jones applies familiar security practices to agents. Inputs from seller listings, forums, and neighborhood reviews are untrusted evidence, not instructions. The system should validate inputs, grant only the permissions needed, and limit what each action can touch. Relocation Scout can read listings and build shortlists, but emailing sellers, booking tours, and submitting offers require Jones's approval. She also rejects the idea of letting a coding agent design everything without supervision because it may create a giant prompt or poorly separated responsibilities. Her systems include an AGENTS.md file at each level, documenting workflows, policies, resources, and memory updates. That lets a human or agent enter in a fresh context, understand the system, and modify it without reverse-engineering prompts.
"Designing agents is software engineering. The primitives are different, but the discipline is the same."18:38
Who should watch
You are using coding agents and feel that they have left you with maintenance work instead of the satisfaction of building.
You are designing an agent that must persist information, coordinate multiple steps, or recover after partial failure.
You need a practical way to decide which work belongs in code, an agent, or a human approval step.
