Loft Discuss one product area

The Loft product

Give specialists and agents one approved basis for the work.

Loft gives product design, architecture, implementation, testing, and acceptance the same product contract to work from: a human-ratified, structured specification of what the product should do, the decisions and constraints that govern it, who may change it, and what evidence matters for acceptance.

People establish the contract. Loft records it and governs change.

People designated by the customer decide and ratify product intent. Loft records the accepted state, proposed changes, decision history, authority, acceptance criteria, and linked evidence. Loft does not decide product truth or treat submitted evidence as proof by itself.

Work from the same contract across roles.

A private agent loop can make one specialist more productive. The delivery system still depends on what happens when work moves to the next specialist. Loft preserves the same product identities, decisions, requirements, constraints, and acceptance criteria across those transitions.

Product and domain work

Specialists develop and ratify outcomes, behavior, business rules, vocabulary, and priorities.

Architecture and engineering work

Specialists add technical constraints and decisions, then use the approved scope for implementation.

Testing and assurance work

Specialists add independent scenarios and evidence, preserving failures and unresolved claims for review.

Human acceptance

Authorized people review the connected intent, result, and evidence rather than relying only on the latest handoff artifact.

More precise than a document, more durable than an agent transcript.

Loft can connect capabilities, requirements, components, constraints, quality targets, architecture decisions, vocabulary, and acceptance criteria inside the contract. It takes a specification-driven development approach: coding agents implement from one approved version of the contract, and reconciliation checks the result and its evidence against that same version, so reviewers judge it against what people actually approved.

The contract evolves through review.

A team can start with one bounded area and expand it over time. Proposed changes remain separate from the accepted state until an authorized person reviews them. The record can preserve what changed and the decision made about it. Open questions and known gaps do not have to be hidden.

From contract to code, evidence, and a human decision.

  1. Author

    Define or recover the intent, constraints, decision rights, and acceptance criteria for one bounded area.

  2. Ratify

    Customer-designated people review the proposed contract and accept the state that will govern the work.

  3. Implement

    In the implementation step, use the approved version of the contract, or a reviewed snapshot of a proposed change, to derive the affected scope and implementation obligations. Loft's packaged agent skills give that work to a coding agent, which changes the selected repository and runs the engineering workflow.

  4. Reconcile

    Compare the implementation revision with the approved contract. Link requirements and acceptance criteria to reviewed test results and other executable evidence, and evaluate quality attribute measurements where applicable. Show what the evidence supports, what failed, what is missing, and what it cannot settle.

  5. Decide

    An authorized person reviews the result and accepts, rejects, or reopens the work. Passing automation can support that decision; it does not replace it.

Change what has to be rebuilt at each handoff.

The next specialist and the final reviewer can inspect the approved contract, implementation revision, mapped tests or measurements, and unresolved gaps. They still exercise judgment, and they may need to resolve incomplete evidence or stale assumptions before accepting the work.

The same authority model applies to new and existing software.

New products

Establish requirements, constraints, decisions, and acceptance criteria before or alongside implementation. Keep the ratified contract current through reviewed changes.

Existing systems

Code, tests, documents, runtime observations, and expert knowledge are evidence of the system. They do not automatically define intended behavior. Resolve conflicts and ratify one bounded area before a consequential change.

Loft connects specialist-and-agent loops; it does not replace professional roles.

Product, architecture, engineering, and assurance specialists can use agents suited to their work. Loft's packaged agent skills are the instructions and tools a coding agent loads to work with the contract. They prepare the implementation scope and define how the resulting repository revision is checked against the contract. Coding agents and engineering tools investigate, generate, test, and change the code. The contract and reconciliation record remain separate from any individual agent transcript or model runtime. Specific integrations and deployment arrangements must be confirmed for each engagement.

Loft is early, and the evidence is mostly internal.

Loft has substantial implementation work across contract authoring, packaged agent skills, and reconciliation, along with internal use. External engagements are intended to test customer value, usability, and whether the complete loop can be repeated without relying on its original operators. The site does not claim measured customer outcomes.