Our engineering perspective. Examples are illustrative, not client results or claims of measured model performance. Primary resources are linked in the text.
A useful way to audit an AI project is to ignore its demo for a moment. Find one piece of work it produced last week. Follow that work into the business. Was it reviewed? Implemented? Used by a customer? Measured against anything? If the trail ends at a chat transcript, the project has delivered an output. Its commercial effect is still an open question.
This is the gap we want Looqus to close. The argument is not that AI creates no value. That would be an extraordinary claim requiring extraordinary evidence. The narrower, more useful question is whether a particular company can trace its AI activity to a completed intervention and a credible result.
Output is the beginning of the value chain
Consider a landing-page critique. A model identifies that an advertisement promises a digital journal while the destination page leads with the physical edition. That observation may be correct. It has not changed the experience of a single visitor.
The remaining work includes checking the product facts, preparing a revision, preserving approved assets, getting a decision, implementing the right version, choosing an evaluation window and checking the result. Each step can fail independently. A persuasive analysis cannot compensate for a broken release process or a test whose groups were never comparable.
This is why the unit of delivery should be a completed workflow. Define its input, owner, destination and completion evidence before deciding which model to call. “Create ten campaign ideas” is an output target. “Prepare one evidence-backed test that the brand lead can approve and the delivery team can implement” is an operating target.
Keep three ledgers
The first ledger records activity: drafts, analyses, classifications and model calls. It helps understand demand and technical cost. The second records execution: reviewed artifacts, deployed changes, resolved exceptions and completed customer journeys. It shows whether work is reaching the business.
The third records outcomes. For a commerce workflow, that might include net revenue per eligible visitor, conversion, returns and contribution after direct costs. A manufacturing workflow may primarily affect exception age or delivery reliability. Those are valuable operating measures, but they must not quietly be relabeled as revenue.
| Layer | Evidence | What it does not prove |
|---|---|---|
| Activity | A draft and its source context | That anyone used it |
| Execution | A versioned change with an owner | That it caused growth |
| Outcome | A reconciled result and comparison | That the effect will persist forever |
A revenue story needs a comparison
Suppose a store earns more after a page change. A promotion, seasonal demand, a different traffic mix or better stock availability might explain the movement. A timestamp saying “AI deployed” does not isolate any of those effects.
Where practical, design a randomized comparison, define the eligible population before the test and retain its assignment. Where that is impractical, document the baseline and the limits of inference. Avoid changing the measurement window after seeing a favorable result. Refunds and returns also need time to mature; the first order total is not the final economic result.
A hypothetical evaluation record might contain the following fields. This is a design example, not a report of a Looqus client result.
workflow_id: landing_page_format_test artifact_version: 2 eligible_population: specified before launch comparison_method: agreed before launch primary_measure: net_revenue_per_eligible_visitor checks: refunds, conversion, contribution measurement_owner: named business owner status: awaiting sufficient outcome data
The missing product is continuing ownership
A system can be technically correct and still lose the handoff. The reviewer is unavailable. The source data is stale. A partner rejects a proposed resolution. The next useful capability is an accountable person who can carry the task, with its evidence, rather than a louder notification.
That also changes engineering priorities. Durable state, retries that do not duplicate actions, explicit permission boundaries and a visible record become central features. Anthropic’s engineering guidance on agents describes the usefulness of simple workflows, environment feedback and stopping conditions. Those mechanics matter because completion has to be checked outside the model’s answer.
Start with one commercial path
Choose one recurring task with usable data, a clear destination and an owner. Write down what counts as completion and what counts as improvement. Run the process in review mode first. Record human corrections and operational failures alongside model errors.
Expand when the path works repeatedly. A company does not need a larger collection of impressive transcripts. It needs a reliable route from an observed problem to finished work, and an honest account of what changed afterward.
Try this with your team.
Pick one recurring task. Write down the source information, the reviewer, what counts as finished and how you will check the result.
Explore real workflow examples