When Every Role Gets Faster, Why Doesn't Software Delivery?

A product manager asks an agent to refine a feature. An architect uses another agent to test a design. Engineers generate code in their IDEs. An assurance specialist produces test cases with a model.

By the end of the week, each person has finished more work. The release meeting can still stall on basic questions. Which behavior did the product owner approve? Does the code follow the architectural decision? Do the tests cover the intended outcome, or only the implementation that was built?

AI is good at speeding up work inside a role. Software delivery depends on what happens between roles. If those transitions still rely on separate documents, private agent context, and repeated interpretation, faster local loops can feed a slower review queue.

That is the gap between local acceleration and organizational multiplication.

DORA's findings show why the distinction matters. Its 2024 research (cloud.google.com) associated a 25% increase in AI adoption with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. Its 2025 report (cloud.google.com) found that the relationship with throughput had turned positive, while the relationship with stability remained negative. The direction changed from one year to the next. AI adoption alone does not determine delivery performance.

Faster work creates a new queue

A coding agent can produce a candidate change quickly. It cannot establish which product behavior has authority, whether someone accepted an architectural exception, or whether a passing test covers the intended outcome.

People still make those decisions. When generated output arrives faster, reviewers may face more alternatives, more material, and more unresolved questions. The bottleneck moves from production to interpretation.

The problem appears when each tool works from a different prompt, file, transcript, or snapshot of the product.

The organization now has several capable assistants, but no shared answer to one basic question: which intent governs this change?

One small feature, four versions

Imagine a team adding a "pause subscription" feature.

The product workspace says a customer may pause for one billing cycle. An architecture note proposes a generic account-status event. The engineering ticket describes a new API endpoint. The QA plan treats pause as a reversible form of cancellation.

Each artifact makes sense on its own. Their differences surface during review:

• Does a pause stop billing immediately or at the end of the cycle?
• Which status reaches downstream systems?
• What happens to a scheduled renewal?
• Who decided that pause and cancellation should share behavior?
• Which tests check the accepted product rule rather than mirror the code?

Agents can expand all four versions. They cannot choose the authoritative one unless the organization gives them an accepted source and a clear decision boundary.

The reviewer becomes the integration layer. A product owner compares the ticket with the intended behavior. A senior engineer reconstructs the architectural reasoning. QA works out whether the tests encode policy or simply mirror the implementation. What looks like code review is often interpretation work.

From local acceleration to organizational multiplication

Work compounds when one discipline leaves the next with a better-defined problem, not another artifact to decode.

A shared product contract provides that connection. A product contract is a human-ratified, structured record of the product outcome for a defined scope. It connects vocabulary, behavior, constraints, decisions, responsibilities, and acceptance conditions. It separates proposals from accepted state and records where each part came from.

Human ratification gives the contract its authority. An agent can draft a proposal, find a contradiction, or expand a scenario. Generated text does not become organizational truth by itself. People designated by the organization retain authority over product intent, technical decisions, and acceptance.

Specialists also keep their professional judgment. Product and domain experts define outcomes and business rules. Architects and engineers add system constraints and implementation decisions. Assurance specialists add independent scenarios and evidence requirements. Their agents can work differently while referring to the same accepted identities and decisions.

The next role starts with accumulated context instead of reconstructing it from the previous role's output.

The contract must follow the work into code

A source of truth that ends at documentation is likely to drift once implementation starts. The contract needs to stay connected to the delivery loop:

1. Author. People and agents develop proposed outcomes, rules, constraints, and acceptance conditions.
2. Ratify. Authorized people decide which proposed state becomes the governing product contract.
3. Implement. Engineers and coding agents work against a specific approved version and bounded scope.
4. Reconcile. The team maps the implemented result and its evidence back to the contract. Reconciliation can return evidence that supports the contract, evidence of failure, missing evidence, or an indeterminate result. It does not prove complete conformance automatically.
5. Decide. Authorized people accept the result, reject it, or request another change.

This connects what the organization agreed to build with what the implementation can show about the result.

It also keeps responsibilities clear. A coding agent performs engineering work. The contract supplies the accepted scope and obligations. Tests and other evidence support a decision. A person with the relevant authority makes that decision.

New products and existing systems start in different places

A new product can establish vocabulary, decisions, and acceptance conditions before much code exists. The contract grows alongside the implementation.

An existing system rarely offers such a clean starting point. Its behavior may be scattered across code, tests, tickets, documents, production signals, and the memory of experienced people. The team first has to recover what the system does, find disagreements between sources, and identify the unknowns that matter for the proposed change.

Recovery gives the team evidence. Ratification is a separate decision. Code is strong evidence of current behavior, but code alone cannot say whether that behavior is intended, accidental, obsolete, or constrained by an external promise. A recovered description becomes authoritative only after the right people review and accept it for the stated scope.

Once that happens, new and existing systems can use the same loop: author, ratify, implement, reconcile, and decide.

Measure the multiplier instead of assuming it

A shared product contract is meant to reduce repeated reconstruction and give specialists a consistent starting point. Whether it improves handoffs, removes avoidable review loops, or exposes gaps earlier has to be measured.

A team can test the mechanism on one bounded change. Start by recording:

• the roles and agents involved;
• the artifacts each role treats as authoritative;
• the points where people ask for clarification or recreate context;
• the review effort spent resolving intent rather than judging the result;
• the acceptance conditions and evidence missing when a decision is due.

Then run comparable work with one ratified contract and a visible evidence chain. Compare the result with the baseline. If the contract is incomplete or stale, the exercise should expose that too. A shared source helps only when the organization maintains it and uses it to make decisions.

Start with one product boundary

Encoding an entire company would turn the method into a transformation program before anyone has shown that it works. Start with one change that crosses product, engineering, and assurance.

Name the person who can ratify the intended behavior and the person who can accept the result. Capture the governing rules, constraints, and acceptance conditions. Give the participating agents the same bounded contract. Reconcile the implementation and evidence to that contract before the final decision.

Count more than AI licenses or generated output. Look at whether one person's work improves the next person's starting point, or whether every handoff produces another version of the truth.

Loft is being built for that handoff problem: connecting specialist-and-agent loops through a shared, human-governed path from intent to accepted software. The organizational multiplier still has to be demonstrated in real workflows, one bounded product contract at a time.