The method
Boundary Engineering · v0.1 · In development
Boundary Engineering
Not every problem needs an agent, and not every capability inside an agent deserves the same authority. Stoa Labs calls the discipline of deciding where autonomy belongs Boundary Engineering.
The result is bounded autonomy made operational: each capability receives only the authority its evidence supports, deterministic controls protect the consequential edges, and explicit recovery paths limit failure. Autonomy is earned per capability, not granted per agent.
The five questions
The working artifacts
The method records its decisions in three artifacts, so authority is legible instead of assumed.
System Boundary Map
An architecture view that distinguishes model judgment, deterministic control, human authority, data trust, side effects, verification, and recovery, so every crossing in the system is explicit.
Boundary Profile
A capability-level evidence card: authority mode, enforced controls, verification state, and last review date.
Capability Ledger
An operational table recording what each capability may do and why, with its evidence state, advancement conditions, and rollback triggers.
Where the method stands
The framework is in development, version 0.1. We are validating it first on Stoa-owned systems, and we will publish how those systems are designed, evaluated, and limited as the evidence accrues, including what does not work. Until then we describe the method as what it is: designed to make authority explicit and evidence-driven, not yet proven.