A recommendation is a claim about a future that has not happened
The gap between a good recommendation and a working system is usually described as execution, which suggests the recommendation was right and execution weak. The more accurate description is that a recommendation is a claim about decisions not yet made, and each must be made by someone with the authority to make it. The sequence below is the order in which those decisions can be taken without stranding the ones that follow.
Step one: turn the requirement into a process design
A requirement says what should happen. A process design says who does it, with what information, in what order, and what they are accountable for. Some requirements are met by a rule or a changed approval threshold, and the honest first finding of a discovery engagement is sometimes that no system is needed. The gap between the two is where most projects fail quietly, because the requirement can be handed to an engineering team who will build exactly what was asked, in a form nobody intended. The output is a described process, with the decisions marked as rule-based or judgement-based, the exception path defined, and a named owner who has agreed it, typically the chief operating officer for a process crossing functions. The method is in mapping a business process before building the agent.
Step two: build the structured data the process will run on
The data work follows the process design, not the other way round. What matters is a small set of records the process requires, each with a defined meaning, an authoritative source and a named owner. Deciding which system is authoritative for each field is where the value is, because it removes a class of argument, not a class of typing.
Two failures are common here. Building a complete data model before delivering anything produces a model nobody uses; and delivering without definitions produces a system that is technically correct and commercially ambiguous. The unit of delivery should be the record the step requires, with its definition, owner and source agreed.
Step three: build the smallest application that carries the work
The application is the part most recommendations understate. It is not a chat interface; it is the screen where the work happens, the queue of items needing attention, the form in which a person confirms or corrects a suggestion, and the record of the decision.
- What does a person see, and at what point? A suggestion presented without context gets rejected, because rejecting is the cheapest response available.
- What can the person change, and what happens if they do? A system that accepts corrections and records them is one that improves; a system that discards them will meet the same errors for ever.
- Who is accountable for the outcome? The screen should show the person who owns the decision, and the record of it should exist somewhere other than in a message.
Step four: connect it to the systems that hold the truth
Integration is where working systems quietly become unreliable ones. The pattern to avoid is a system that reads from a source of truth without writing back, so the two disagree by the following day and nobody can say which is current. The requirements are unglamorous: an explicit owner on both sides, a record of what was written and when, defined behaviour when the source changes underneath the system, and a way to replay the last operation if something goes wrong. The approach is in our application engineering practice.
Step five: put the controls inside the flow of work
Controls written as a policy document are not controls. A control enforced by the software is a design constraint; one that depends on a person remembering is a hope. The practical requirements are small: every consequential action has an approval or a documented reason for not needing one; every action leaves a trace readable later by someone absent; limits on what the system may do are enforced rather than described; and the case outside the routine path reaches a named person within a defined period.
One control question is worth deciding explicitly, because it shapes the whole design: is the output reversible? Where it is, the first release can act directly and be corrected. Where it is not, it should propose and a person should confirm. The exception mechanisms are in designing AI workflows with human approval and exception handling.
Step six: build the operating workflow that keeps it alive
A system that works on the day it launches and drifts afterwards is the standard outcome. The operating workflow prevents it: named routines with an owner and a frequency.
- Assign a named owner for the system in the operating organisation, with the time to do it written into their role.
- Review the exception queue weekly, counting what arrives, what is resolved and what returns repeatedly.
- Re-test a fixed sample each month after any change to the model, the rules or an upstream system.
- Track the discovery-phase baseline measures on the same basis as the original measurement, and publish them where the business can see them.
- Agree in advance what would make the system stop, and who can call that.
This step is usually skipped because it has no visible deliverable. It is also the step that determines whether the recommendation was right. A recommendation that reaches production but cannot be maintained is not one that was implemented; it is one that was suspended. The conditions for keeping such a system running are in how to make enterprise AI maintainable after the pilot ends.
Read as a whole, the sequence is not a technical plan. It is an argument that implementation is mostly the work of making decisions explicit, in order, by the people entitled to them. That is why an engagement inside the operating environment produces different results from one conducted outside it, and it is the argument in why enterprise AI requires people who know the business from the inside.