Designing AI workflows with explicit boundaries

The premises

The premises, stated so you can disagree with them:

1. A1A new model call can use only the context made available to it.

   Conversation history, saved notes and memory tools can carry earlier work forward, but only when the workflow retrieves and supplies them. A convention stored somewhere is not necessarily present in the next decision.

2. A2AI can produce changes faster than I can validate them.

   A draft can arrive quickly; understanding its effects, testing its boundaries and deciding whether it solves the right problem still take work. Faster generation does not remove that work.

3. A3Errors have asymmetric costs: making one can be cheap, finding it expensive, and fixing it after other work depends on it more expensive still.

   The three costs are not merely different sizes. They point in different directions, so any process tuned for the cheap one is tuned against the expensive one.

What follows

What follows, and what each one forces:

1. T1A check is only as independent as the boundary protecting it. from A1

   A model’s self-review is not independent acceptance evidence. I also use rule engines, process exit codes and separate implementations. Their results still depend on the checks and configuration: a recorded probe disabled a guard by adding a trailing comment to the line it read, while it continued reporting zero violations.

2. T2Faster generation makes verification more important. from A2

   Building a useful product still matters. Alongside implementation, I invest in defining what counts as done, checking the result, and testing whether the checks can actually reject a broken example.

3. T3Checkpoints have to be closer together than the rate at which errors get built on. from A3

   Cheap checks move closer to the tool call so mistakes are caught before more work depends on them. But hooks see only the operations they inspect: two shell one-liners went through the same hook and the files were really written. That channel is checked with before-and-after snapshots instead—detection, not prevention.

4. T4Intent needs an execution path, not only a place to be written. from A1

   A rule in a document does not run itself. Where possible, I pair it with an executable check. Programs and configuration can also be changed or bypassed, so the check’s own inputs and execution need review.

5. T5Repeated failures without a visible signal can accumulate unnoticed. from A3

   Silence is not a signal, so nothing throttles it. A cleanup routine captured output without checking the return code. The recorded incident accumulated 2,983 leaked worktrees (about 26 GB), plus about 60 GB of pytest temporary files: roughly 86 GB in total. Failures now have to be visible even when nobody is watching.

These arguments grew from the working notebook now published with nonconstant, with examples from my other projects. Agents helped write those notes; their first-person accounts are not automatically my own observations. My contribution is the decisions, acceptance criteria and review, including rejecting earlier conclusions. Historical figures refer to the recorded phases, not current totals. Public source makes a claim inspectable; it does not by itself prove that the claim is correct.