The approach · Design method
Boundary Engineering
Boundary Engineering is how Stoa Labs designs agentic systems: five questions, asked capability by capability and answered with evidence. Its thesis is bounded autonomy. The method is in development, and applying it well still depends on open research.
The thesis of the method
Bounded autonomy
Autonomy should be allocated capability by capability and earned through evidence. Engineering that allocation is the discipline agentic AI needs.
Not every problem needs an agent.
Some work is stable, enumerable, and better expressed as deterministic software. Adding a model to it introduces uncertainty without creating enough value. Other work depends on interpretation, synthesis, planning, or recovery across cases that resist enumeration. That is where model judgment can earn its place.
The first design decision is therefore not how autonomous an agent should be. It is whether each capability should use model judgment at all.
The second decision is how much authority that capability should receive. A system may be trusted to read a record, classify it, and draft a response while remaining unable to send the response, change authoritative data, or spend money. Treating the whole agent as either trusted or untrusted hides the decisions that matter.
The thesis of Boundary Engineering is bounded autonomy: useful agentic behavior exists inside explicit limits on information, authority, time, tools, and side effects. Those limits are enforced where possible, verified continuously, and paired with a credible recovery path. Better models can move a boundary, but they do not remove the need to decide where it belongs.
The principle at the center is simple:
Autonomy is earned per capability, not granted per agent.
Stoa Labs calls the discipline of making that principle operational Boundary Engineering. It asks five questions:
- Suitability: Should this capability use model judgment at all?
- Authority: What may it observe, propose, approve, and execute?
- Execution: Which limits must the runtime enforce deterministically?
- Verification: What evidence establishes that it performed acceptably?
- Recovery: What happens when it is uncertain, wrong, unavailable, compromised, or outside its authority?
The answers have a concrete shape. Model judgment is reserved for the work that benefits from it. Typed contracts, permission checks, state rules, and policy gates protect the consequential edges. Outcome-level evaluations determine whether the work succeeded. Escalation, rollback, and containment limit what happens when it does not.
These decisions are recorded per capability. Authority expands only when explicit evidence supports it, and it contracts when a regression, boundary violation, security event, invalidated evaluator, or changed operating context makes the earlier evidence insufficient. A model upgrade alone never silently grants more authority.
This is not a maturity ladder whose destination is maximum autonomy. Some capabilities should remain deterministic. Some should always require approval. Some should never be automated. The goal is not to remove people or controls from a system. The goal is to place judgment where it creates value and make the authority around it legible, enforceable, and recoverable.
The frontier will keep moving. Models, harnesses, tools, policies, threats, and business processes all change where a boundary belongs. That is precisely why boundaries must be measured rather than assumed and revisited rather than declared once.
That is this discipline’s wager: lasting value with agentic AI goes to the teams that can explain, enforce, verify, and revise the authority of every consequential capability, not to the ones that simply maximize autonomy. Boundary Engineering is how Stoa Labs is developing that ability, one version at a time, each claiming only the evidence it has.
The working artifacts
The method records its decisions in three artifacts, so authority is legible instead of assumed.
Boundary Profile
The decision record for one capability: why it uses model judgment or not, its authority mode, the controls the runtime enforces, how it is verified, its recovery path, and the evidence it has.
System Boundary Map
An architecture view of how judgment, deterministic control, human authority, data, and side effects connect across a system, drawn for the system that exists rather than an aspirational one.
Capability Ledger
The live operational record of what each capability may do, why, under what evidence, and with which rollback rules.
Blank schema
Open questions
What the method still has to learn
Applying it well depends on questions that are still open research, pursued across the lab’s research areas rather than in one:
- Evidence for authority. What evidence justifies granting, expanding, or contracting a capability’s authority, and how much is enough for a given consequence?
- Advancement and rollback. What do expanding and reducing authority look like in real harnesses, and which parts can the runtime enforce instead of leaving them to a reviewer’s memory?
- Changing conditions. How should authority be revisited when models, tools, policies, or the operating context change?
- Evaluator validity. When is an evaluator trustworthy enough to rest an authority decision on?
- Suitability. Where does model judgment outperform deterministic software at acceptable cost and risk?
The answers draw on the research map: evidence design from evals and observability, enforcement from harness engineering and agent tooling, recovery from orchestration and durable execution, data trust from context and memory, and suitability from frontier research on the prompting and programming boundary.
Where the method stands
The method is version 0.1 and in development. Its first proving ground is Stoa’s own systems, and the lab will publish how those systems are designed, evaluated, and limited as evidence accrues, including what does not work. Until then the method is described as what it is: designed to make authority explicit and evidence-driven, not yet proven.