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 loopThe 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 surfaceField Research
Coming soon. Notes from work that is still in progress.
STATUS//FIELD_RESEARCH
Sandboxing
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.
Switchplane
Switchplane was an experimental Python runtime control plane for local, long-running agent workflows. It put deterministic flow around model calls and provided supervised execution, durable task state, CLI/TUI operation, and MCP integration. The project yielded a ton of learnings, but I’ve since switched gears. I now put agentic systems behind an MCP boundary, letting the conversational harness drive bounded systems rather than treating a standalone runtime as the primary interface.
Explore the experiment on GitHub