Operating Hypothesis

Operating Hypothesis

Owner: Bill Eisenhauer Last Updated: August 6, 2026 Status: 🚧 Hypothesis under test Contributors: Bill Eisenhauer

---

Hypothesis: When implementation becomes cheaper and more parallel, software-delivery performance becomes increasingly governed by scarce context, evaluation, integration, adoption, and human attention. Organization-wide leverage comes from repeatedly finding and improving the active constraint—not from maximizing local output.

Why the unit of value matters

Code generated, pull requests opened, foundations shipped, and partner deliverables completed are useful intermediate signals. They are not the final unit of value.

For this operating model, an outcome counts when it is:

1. accepted against evidence;
2. integrated into the product and operating environment;
3. used by its intended consumer; and
4. assigned to a durable owner.

That boundary prevents inventory from being mistaken for leverage.

flowchart LR
    O["Local output"] --> A["Accepted"]
    A --> I["Integrated"]
    I --> U["Used"]
    U --> W["Durably owned"]
    W --> V["Realized value"]

Loading

In prose: every intermediate output must cross acceptance, integration, use, and ownership boundaries before the model calls it realized value.

Constraint, bottleneck, and loud queue

A large queue is evidence of pressure, but it does not by itself prove which stage governs whole-system throughput. TameFlow explicitly distinguishes a bottleneck visible in workflow from the system constraint that controls throughput. A slow-looking activity may add elapsed time without setting the rate at which work exits the system.

This distinction matters more when agents increase one stage's production quickly. The loudest activity can attract investment even while a less visible stage—often verification, integration, or adoption—sets the outcome rate.

The causal claim

flowchart TD
    A["Agent, platform, or partner capacity"] --> B["Implementation output"]
    C["Context quality"] --> B
    B --> D["Verification demand"]
    B --> E["Integration demand"]
    B --> F["Adoption demand"]
    G["Human judgment"] --> C
    G --> D
    G --> E
    G --> F
    D --> H["Accepted and owned outcomes"]
    E --> H
    F --> H
    H --> I["Learning evidence"]
    I --> J["Next constraint decision"]

Loading

In prose: added build capacity raises output and also creates downstream demand. Context quality and human judgment influence whether that output survives verification, integration, and adoption. Accepted outcomes produce evidence for the next constraint decision.

Relationship to Scrum and Kanban

This hypothesis is not a replacement for either framework.

Approach	Primary contribution	What the constraint layer adds
Scrum	A cadence for transparency, inspection, adaptation, and delivery toward a Product Goal	A system-level question about where added capacity can change total throughput
Kanban	A pull-based flow strategy with explicit workflow, WIP control, and flow metrics	A focusing mechanism for deciding which part of the broader value system to improve now
Constraint learning	A repeated locate–intervene–measure loop	Needs Scrum, Kanban, or another delivery mechanism to execute the work

The useful combination is often: Scrum or Kanban for execution; constraint learning for portfolio focus; outcome evidence for investment decisions.

What would weaken the hypothesis

The claim should be revised if repeated evidence shows that:

• local capacity increases create proportional accepted outcomes without downstream cost;
• adoption and ownership do not affect realized platform or partner value;
• missing telemetry does not change intervention selection;
• human evaluation capacity scales automatically with agent output; or
• the governing constraint remains stable after successful interventions.

---

Related: Kitting and Wait States · Constraint Learning Loop · Simulator Model