Operating Hypothesis

Operating Hypothesis

Owner: Bill Eisenhauer Last Updated: August 7, 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.

Intake rule: Work enters committed flow only when it has a named owner, clear acceptance conditions, a plan for producing evidence, and a reason it belongs in this system. Otherwise, it stays upstream for shaping or bounded discovery instead of becoming an unowned delivery problem.

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.

Three places to create leverage

Most software organizations can intervene in three broad ways. Each works on a different part of the same delivery system.

Intervention	What it changes	When it becomes leverage	Common failure
Shared foundations	Reusable frameworks and services remove repeated work	Teams adopt them and repeated effort falls	Unused capability becomes inventory or creates migration work
Builder experience	The path from intent to validated software, including how humans and agents divide judgment, execution, and verification	Accepted outcomes become faster, safer, or easier to produce	More implementation output overwhelms context, review, or integration
Elastic partner capacity	Outside teams add temporary production capacity	Relationship and work-item kitting makes the result reviewable, integrable, and transferable to a long-term owner	Scoping, review, integration, and handoff consume more capacity than the partner adds

These are not separate systems. Shared foundations can improve the builder path; partners must work through that path; and all three consume scarce attention. Any of them can create negative net leverage when it increases output without increasing accepted and owned outcomes.

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