Agentic AI: A 6-Step Framework to Reduce Error

Industrialization through agents amplifies the impact of a poor hypothesis. A structured framework consisting of six short documents aims to align stakeholders and systems, make decisions at the right level, and ensure traceability of trade-offs. The goal is to reduce uncertainty before implementation, where correcting mistakes is least costly.

Governance and Explicit Decisions Frame Change

Disagreements must be arbitrated by a decision owner, rather than remaining unanswered. The fifth step of the framework formally establishes this essential decision-making organization for construction, launch, and operation, in the form of an explicit agreement. This mechanism operates sequentially without following a waterfall model: a discovery occurring later can challenge a previously made decision, in which case the relevant artifact is updated, and the new decision is explicitly recorded. The aim is not to block evolution but to eliminate changes that would go unidentified. Each step generates a short document, usable by both humans and agents, that makes decisions explicit and durable. These elements form a shared record that stakeholders can consult, including hypotheses, interpretations, and reasoning.

With Agents, Errors Spread Quickly and Further

The introduction of agents amplifies risks: where a day of error from an isolated engineer has a limited impact, the same error deployed by a fleet of agents spreads faster and wider. An incorrect hypothesis can be duplicated in every generated modification affecting the same model before any human review. The bottleneck thus shifts upstream, towards the precise definition of the problem, context, and validation: moving quickly in the wrong direction simply leads to the wrong outcome faster. The increased capacity for implementation allows for hundreds of erroneous changes at low cost if the initial need is poorly framed.

When to Apply the Framework and at What Intensity

It is not necessary to produce six documents for every change: a minor correction, a limited internal script, or a prototype intended to be discarded generally do not require such a level of preparation, which would then become a source of administrative burden if applied to every change. This framework makes the most sense when the impact of a directional error becomes significant: coordination among multiple teams, ambiguity regarding the problem or outcome, marked dependencies on existing systems and data, difficult-to-reverse architectural or data choices, simultaneous work conducted by multiple people or agents, financial, operational, regulatory, or reputational stakes, or the scale of the project making material adjustments costly in case of error. The level of detail is adjustable: a few pages are sufficient for a small scope, while a complex program will require substantial discoveries and discussions. The goal is not to check six boxes but to reduce the uncertainty that matters before implementing, when coordination and the cost of error justify it. The framework does not exclude experimentation: in the case of an uncertain hypothesis, a prototype or a spike may be the fastest way to reduce uncertainty, provided that the result is then integrated into the relevant step rather than silently deviating from the trajectory.

Focus Efforts Where Errors Are Costly

The central principle is to proportion the analysis to the reversibility cost of decisions. A button label is highly reversible and can be decided quickly, then adjusted. In contrast, a data contract, a system boundary, or an integration architecture are costly to correct and therefore require thorough examination. It is not about predicting everything but investing preparation on points where a poor decision would be costly, while deliberately keeping the rest flexible.

The Six Deliverables Structure Problem, Solution, Roles, and Sequence

The framework revolves around six artifacts. Business prerequisites (PID.md) align on the problem, scope, organization, and objectives. Technical prerequisites (discovery-report.md) shed light on data, systems, feasibility, risks, and constraints. Functional requirements (functional-requirements.md) define what the solution must do, and technical requirements (technical-requirements.md) outline how it will function. Governance (governance.md) specifies who is involved, who decides, and who is responsible. Planning (roadmap.md) sets when, in what order, and by whom. The first four steps establish what is known and what is intended to be built, already involving decisions and their ownership.

Examples: Avoiding False Needs and Testing Upstream Feasibility

The first step aims to avoid the costly failure of addressing the wrong problem. In one case, a client urgently requested a webhook; the team complied, only to discover that the real need was an API. An impeccable solution thus targeted a non-existent problem. The lesson: the client owns the problem, the provider the solution; a brief discussion about objectives would have revealed the gap. Therefore, PID.md must formalize the problem, objectives, users, and success indicators. Regarding feasibility, almost any solution must integrate with existing systems. One team spent several sprints on a real-time dashboard, only to find that the source delivered a batch every 12 hours: the upstream constraint rendered real-time unavailable. Hence the importance of early discovery on data, systems, and dependencies, so that everyone knows what is possible before coding.

A GitHub Repository Centralizes Sheets and Feedback

The framework reduces uncertainty by addressing one decision domain at a time, with each step building on the previous one as long as the cost of change remains low. A GitHub repository, Project Preparation Framework Repository, offers one-page sheets for each step and feedback, with the intention of making it a community project open to contributions. The stated ambition is twofold: to build the right thing, in the right way, and as efficiently as possible, while creating sustainable alignment between humans and agents to avoid conjectures, rework, and unpleasant surprises.