Implementing AI is like implementing software… except where it’s not. Let me map out an AI project end to end, so you can see where the two part ways.

Most guidance on enterprise AI projects borrows its shape from traditional software delivery: gather requirements, design, build, test, deploy, support. That progression is comfortable (whether waterfall or iterative agile) because it has worked for decades. But it is wrong to apply it out of the box to AI projects, because AI projects have different types, sets and degrees of unknowns going in. The parts you can specify up front and the parts you can only find by experiment are not the same as in traditional software projects.

So here’s a WIP model of an AI project scoped to a single application. It comes from long experience with enterprise software implementation combined with current AI practice, not from a large sample of delivered AI deployments (such information is scarce at this early point in time.) Treat this as a basically sound framework with the specifics that need to be adjusted against your own reality.

One assumption up front: this model picks up after a specific workflow has been chosen. Deciding which job, queue, decision, or handoff is worth improving, and what a win is worth, is a prior step with its own value and risk analysis. Here the target is already selected and the question is how to build it.

The Phases

1. Feasibility Probe

Before committing anything, spend a few hours seeing whether the model can plausibly do the task at all. A cheap, throwaway prompt-and-eyeball test. The output is a go or no-go signal, nothing more. Manually experiment with prompts, engineering and data and information added to the context.

The discipline that matters here: clearing this bar proves feasibility of interest, not feasibility of production. A promising probe is the beginning of the work, not evidence that the work is nearly done.

2. Set the Implementation Guardrails

Early, while the capability is still unknown, specify the things that are knowable and non-negotiable:

• The data the AI app may read and what data it may change
• The boundary between what the AI does and what a human decides
• The acceptable error profile, and the plan for when the model is wrong
• The integration points, both internal systems of record and external services and APIs
• Compliance, audit, and traceability requirements
• Some awareness of likely running costs

One note on that error item: it is rarely a single acceptable rate, it is a profile, because not all errors are equal. In an order-intake workflow a wrong delivery date, a missed hazardous-material note, and a slightly awkward summary are very different failures. Decide which error types matter and how much, not one blanket number.

These are decided and documented up front and enforced throughout, exactly as your instincts from serious engineering projects would tell you. This is the half of an AI project where traditional discipline still applies cleanly.

3. Technical Approach Discovery Loop

This is the phase that is different from traditional software projects. You cannot specify up front which AI technique will work, or whether the model can do the task well enough on your data. You discover it by trying, measuring against the error profile you set in Phase 2, and adjusting. This phase is a loop, not a step with a fixed deliverable.

What gets discovered here is which technical approach clears the error bar. The techniques roughly form a ladder from lightest to heaviest. The sensible default is to try the cheapest thing that could work first and add complexity only when you have to. (The ladder is detailed in the Technique Ladder section below.)

A narrowed scope discovered in this loop is a win, not a failure. Finding the real shape of what the model can do is the point of the phase. If even the expensive approaches cannot clear the bar affordably, a narrower scope or a no-go is the right call.

4. Build and Integrate

Discovery proved the technique can work, and also determined what you are about to build. This is the phase your traditional software development experience applies: implement the integrations into the systems of record and external services, build the tools the model calls, handle errors and retries, wire in security and access control, and construct the actual application around the model. Most of what you threw together during discovery was meant to test feasibility, and here you build the production-grade version.

How much you build, and what kind, depends heavily on which rungs of the technique ladder the discovery loop proved out. If it’s a prompting-and-validation solution then it’s mostly application glue you need to put together. If it’s a retrieval solution then that adds an ingestion, embedding, and vector-store pipeline. An agentic solution adds orchestration, tool definitions, and controls on what those tools may do. A fine-tuned solution adds a data-preparation and training pipeline. This is the other half of why the ladder rewards restraint: every rung used is more to build and maintain, plus additional risk.

This is largely conventional software engineering, and it should be run like it. The AI-specific parts (the prompt, the retrieval, the model wiring) are now assets to be built cleanly and version-controlled, not experiments. One important difference: prompts and retrieval logic are code-like assets that will need ongoing maintenance, so treat them from the start as assets rather than leaving them as loose strings.

Important design consideration for AI implementation: design in thorough logging from the start. It matters in production above all, but you will want it in development and QA too, because a probabilistic system cannot be debugged, evaluated, or trusted after the fact without a record of what it actually did. Typical things to log: the full prompt sent (including retrieved context and system instructions), the model and version used, the raw model output, any tool calls and their results, token counts and cost, latency, the final action taken, whether a human reviewed or overrode it and why, any validation or guardrail failures, and errors or timeouts. Capture enough that you can reconstruct a single case end to end months later, because when something goes wrong in production, that trail is the difference between a fix and a guess.

A note on AI coding tools, since it comes up: they genuinely speed this phase, because most of it is ordinary software (integrations, plumbing, app code) and AI assistance accelerates that the way it accelerates any development now. It compresses the effort, but it does not change the shape.

Where you can, design the AI function so it can be switched on and off at will. A clean on/off, or a fallback to the previous human-only path, is worth real design effort, because it is what makes a cautious rollout possible: you can pull the AI back the moment a pilot goes wrong, dial autonomy down as well as up, and fall back to safety when a model upgrade or drift degrades quality. The ability to turn it off is what lets you turn it on carefully. How feasible this is depends on the integration; a read-only advisory function is easy to toggle, while something woven into a transactional write path may be much harder to disable cleanly. So treat it as a design goal to pursue, not a guarantee.

And from another perspective, where applicable and feasible, design in the capability to reverse actions that the AI agent may have taken. This puts post go-live support on much firmer ground and de-risks the proejct.

5. Test and Evaluate

Test the build the way you would test any production software: unit tests, integration tests, does the plumbing hold under bad input, does security behave, does nothing regress. That part is familiar.

What is different for AI is that conventional testing is not enough, because the model has no single correct output to assert against. Alongside the usual QA you need evaluation: run the system against a representative set of cases (normal, edge, known failure modes, and cases where the right answer is “escalate” or “I don’t know”) and measure results against the error profile you set in Phase 2. This is statistical, not pass/fail. You are checking how often and how badly it is wrong, and what happens when it is wrong. Red-team it for prompt injection and for the confident-but-wrong answers that ordinary tests sail past. Capture all aspects of all results for later analysis, which you will almost certainly need.

Building a well-documented evaluation set is a crucial project step. It is what lets you re-check quality after every later prompt, model, or retrieval change, and it is the thing most teams skip and later regret.

6. User Training and Acceptance

Conventional software UAT asks whether the system does what users need. That still applies, but AI adds a twist: users have to accept a system that is sometimes wrong, and that changes what acceptance means. Can the people who do this work actually use it, trust it appropriately, catch its mistakes, and fold it into their real process? Do they know when to override it? They will need help figuring out how to work with the new AI capability. UAT here is as much about calibrating human trust and designing the human’s role as it is about validating features. If users either rubber-stamp the output or reject the tool wholesale, the project fails regardless of how well the model scored in evaluation. With AI workflow projects, user training may be a bigger, or at least different, part of UAT than it typically is.

7. Pilot in Workflow

Now run it live, but limited: inside the real workflow, on real cases, with a human checking every output. Run it long enough to build genuine trust and to gather real error data. And again, by this point, everything should be logged.

This is not a demo and not a sandbox. It is the real job with a human backstop. Success at this stage is measured in calibrated trust, not in a passing test.

“A human checks every output” is easy to say and easy to get wrong. Review fails quietly unless the reviewer’s job is thoughtfully designed: they need to see the evidence behind an answer, not just the answer; they need to override easily, with the override logged and its reason captured; and they need to be measured on catching problems, not on throughput. A reviewer rewarded only for speed becomes a rubber stamp, and a fluent wrong answer is exactly the kind that slips past a rushed check.

8. Widen Autonomy

As the error data justifies it, let the human step back on the low-stakes, high-confidence paths, while staying firmly in charge of the decisions marked human-owned back in Phase 2. Autonomy is a dial that turns gradually as trust is earned, not a switch that flips at go-live.

“High-confidence” here means the track record shows the system performs reliably on that kind of input, not that the model sounded sure. A fluent, confident-sounding answer is not the same as a correct one, and a model’s self-reported confidence score is not a calibrated probability. Widen autonomy where the evidence earns it, not the tone.

9. Operate and Maintain

A traditional project stabilizes into steady-state support. An AI project does not, because the model and the data underneath it keep changing. Keeping watch and maintaining is continuous:

• Monitor output quality in production
• Detect drift
• Re-evaluate when the model version changes, since upgrades can regress
• Maintain prompts and retrieval as living assets
• Watch inference cost, which is variable and usage-driven
• Consider automating analysis of the logs

A drift or a model-version change can re-open the discovery loop. The line in the diagram from Phase 9 back to Phase 3 is real, not decorative.

The Technique Ladder

Inside the discovery loop sits a decision that deserves its own map: which AI techniques to use. Sometimes the answer is known going in (“this is clearly a retrieval problem”), and you enter the ladder at that rung and skip the other ones. When it is not known, you start at the top, the cheapest rung, and descend one rung only when the error bar forces you down.

The ladder, cheapest and lightest at the top, most costly and most involved at the bottom:

1. Prompting — crafted instructions, which may include few-shot examples, authored at design time.
2. Structured output plus validation — constrain the model to a schema (JSON or a fixed format) and check the result against business rules before anything downstream uses it. Often the cheapest reliability move in a workflow project, and easy to overlook because it feels like plumbing rather than technique.
3. RAG (retrieval in various forms) — fetch relevant content at runtime and put it in the prompt. The retrieval underneath ranges from simply supplying the known document, to keyword search, to embeddings and vector search.
4. Tool use / function calling —the model can call out to tools: look something up, fetch or write a record, run a function, call an API. This gives the model reach beyond its own LLM capabilities. It is an added capability, used both on its own and inside agentic loops.
5. Single-agent agentic — an intelligently controlled loop where the LLM’s own output drives the next-step decisions. It plans, acts, observes the result, and decides what to do next, repeating until done. It is an agentic loop, rather than a traditional deterministic code loop, because the control decisions come from LLM response data, not from pre-written rules. It typically calls tools along the way, and usually runs inside defined guardrails such as iteration limits, validations, approval gates, etc., that contain what the loop can do.
6. Multi-agent orchestration — several specialized agents executing and coordinating with each other. Frontier work, still rare in production, various architectures have evolved.
7. Fine-tuning — adapter fine tuning methods, such as LoRA, first, because they are small, less costly and reversible. Move to a full fine-tune only if that will not do. Availability depends on the LLM and hosting you are using.

Two important things about the ladder:

The rungs combine, they do not replace one another. RAG plus tools, agentic plus RAG, fine-tuning sitting underneath one of the others: all normal. Descending the ladder means adding capability – and cost and complexity – not swapping one technique for another.

Deployment location is a separate axis, not a rung. Where the system runs (cloud versus on-premise or open-weight) is pretty much separate from which techniques you use. It can matter at every rung, whenever prompts, retrieved content, logs, embeddings, tool payloads, or training examples contain restricted data. Prompting already exposes case data to a model provider; retrieval exposes documents and embeddings; tool use exposes transactional data. It becomes most visible at fine-tuning, but it should be decided from the data guardrail fixed up front, not deferred to the bottom of the ladder. Cloud-managed approaches are the usual path; on-premise or open-weight becomes necessary when residency rules demand it.

There is also a rung below the bottom rung, the one most often skipped: maybe the model does not belong here at all. A lot of successful “AI workflow” projects are mostly ordinary work, better forms, cleaner rules, deduplication, search, queue routing, a redesigned handoff, with the model reserved for the one part that genuinely needs language judgment, ambiguity handling, or summarization. If deterministic code, a rules engine, or better UX solves the task reliably, use that. The discipline is not “which AI technique,” it is “the least machinery that clears the bar,” and sometimes the least machinery is no model.

A note on prevalence, offered as directional judgment rather than measured data: prompting is near-universal, RAG is very common, tool use is rising fast, single-agent agentic is growing but less mature in production, multi-agent is still frontier, and fine-tuning is comparatively rare despite how much it is discussed. Most teams that ask about fine-tuning would be better served by exhausting the cheaper rungs first.

Cross-Cutting Concerns

The phases are sequential. The concerns below are not. They run alongside the whole project, with different intensity at different phases, and treating them as steps to be completed and checked off is a mistake. Each note says where the concern is heaviest, but they all need continuous attention and management.

• Data Privacy & Security — front-loaded. Set data scope, PII handling, access, and prompt-injection defense early, then enforce every phase.
• Governance & Oversight — decision rights plus go/no-go gates at each phase boundary. Proactive, not gatekeeping. Includes naming who owns automated decisions.
• Testing & Evaluation — shifts from pass/fail to statistical evaluation, red-teaming, and regression on quality. Heaviest in the discovery loop, build, test, and pilot phases, and tending.
• Compliance & Audit — meeting the regulatory, contractual, and policy obligations that apply to automated decisions, and being able to demonstrate you met them. Which rules bind you, what must be explainable or defensible, who signs off, and what you must be able to reconstruct if challenged. The logging below is part of how you satisfy this; the obligation itself is the point here.
• Logging & Observability — design it in during the build, you will rely on it everywhere after. A probabilistic system cannot be debugged, evaluated, or trusted after the fact without a record of what it actually did: prompts, outputs, tool calls, model versions, human overrides, failures. Heaviest in test, pilot, and operation, but you have to build it in from the start.
• Risk Management — the high pilot-to-production mortality rate is real, but the cause shifts to trust and accuracy rather than scope creep. Watched throughout.
• Cost Management — variable, per-inference spend. Light early, becomes a live operational concern from the pilot through tending.
• Change Management & Training — training people to verify and override, and managing the perceived threat to expertise. Ramps up at user acceptance and the pilot and continues into ongoing maintenance.

The One Idea Most Worth Keeping

If you take a single thing from this post, take this as the shape of AI workflow projects: fixed at the edges, discovered in the middle, continuous at the end. The guardrails are knowable, and mostly up to you to define, and belong up front. But the capability is not knowable in advance and has to be found by experiment. And the work never fully closes, because the ground underneath it keeps moving. A plan that treats those three parts the same way will fail in one of three predictable directions.

---

This is a practitioner’s model synthesized from enterprise software implementation experience and current AI practice. The phase logic and the sorting of concerns are reasoned judgment, not a methodology validated across a large sample of AI deployments, and the technique-ladder ordering is a sensible default rather than a rule. Details of what can be fine-tuned, and how, shift quickly; verify current provider specifics before relying on them.

AI Workflow Project – Master View of Phases

 

AI Technique Ladder