FIELD_GUIDE//AGENTIC_ENGINEERING
Agentic Engineering in Practice
I’ve spent the last year trying to work out where software should end and agents should begin. These are the ideas that survived contact with reality.
After throwing a fair amount of shit at the wall, this is the split that has actually held up: models should own judgment and adaptation; software should own guarantees and repeatability; people should own the decisions that carry consequences. It isn’t a universal architecture. It is a practical way to decide who should own the control loop for the problem in front of me.
When I say agentic engineering, I don’t mean handing an entire system to a model. I mean designing the seams deliberately: matching the harness to the work, using MCP as a boundary between conversation and durable execution, and keeping people in the decisions that carry consequences. This page is the map.
Dude, how does this help me?
The shortest route from the theory to my daily work: the recurring patterns, where they fit, and how they become tools I actually use.
Start with the synthesis
The reading path
The posts build on one another, but you don’t have to read them in publication order. Follow the path below, or jump to the question closest to the system you’re building.
The principles
Decide what should be probabilistic before deciding how to build it.
Stop Asking LLMs to Be Deterministic
Why model judgment belongs inside bounded nodes, with ordinary code enforcing the workflow properties that need to hold every time.
Read the principle PRINCIPLE_02The Division of the Local Harnesses
A framework for deciding whether software or a conversational agent should own the control loop, based on the nature of the work.
Choose the control loop PRINCIPLE_03Risk and Judgement: A Pattern for Agentic System Design
Break the work into functions, classify each by the reasoning it needs and the risk you can tolerate, then decide what belongs to software, a model, or a person.
Weigh the riskThe architecture
Give adaptive conversation and repeatable execution a clear seam.
The Harness Within the Harness
Using MCP as a portable application boundary: a swappable coding harness outside, a bounded and durable agent application within.
Find the seam ARCHITECTURE_02Context as a Control Surface
How the outer harness can steer successive executions without taking the guarantees or the execution loop away from the inner system.
Open the control surface ARCHITECTURE_03Kernel-Level Agent Sandboxing
Constraining what a local agent can read, write, run, and reach with macOS Seatbelt policies, and the quirks of Xcode, Homebrew, and links along the way.
Draw the boundaryField Research
Coming soon. Notes from work that is still in progress.
STATUS//FIELD_RESEARCH
Observability & Tracing
STATUS//FIELD_RESEARCH
Evals & Failure Modes
Putting it into practice
Apply the boundary to work that needs both judgment and operational discipline.
Runtime QA: Give the Agent the Loop, Not the Last Word
Let the agent own a bounded investigative loop while software makes the mechanics reviewable and a person retains the consequential decisions.
Run the investigation PRACTICE_02PR Council: A Runnable Experiment in Agentic Engineering
Explore a durable PR review workflow that combines independent model perspectives with deterministic orchestration, bounded tools, and human approval.
See the workflowSystems built from these ideas
REVIEW_WORKFLOW // MCP
PR Council
A local PR review system combining independent quality and security reviews, bounded model calls, sandboxed tools, durable workflow state, and a human-approved publishing step.
salesforce-misc/pr-council-mcpRUNTIME_CONTROL_PLANE // PYTHON
Switchplane
A Python runtime control plane for local, long-running agent workflows. It provides supervised execution, durable task state, CLI/TUI operation, and MCP integration.
salesforce-misc/switchplane