Putting an AI agent in your product:
the decision framework before the first prompt

Every quarter, the same question comes up in leadership meetings: "So when do we put an AI agent in the product?" A competitor has announced one, an investor brought it up, a demo impressed everyone. The question arrives phrased as an obvious next step, with a date attached rather than a reason.

It is the wrong starting point.

The right question is not "when", it is "for which task, and what happens when it gets it wrong". An AI agent is an excellent tool for a small family of problems, and a generator of debt and incidents for everything else. The decision is made before the first line of prompt, on one page, with three conditions. Here is the framework I use to make it.

In the no-code, low-code and automation guide, I already set one rule: generating code is not maintaining it. Agents are the next floor up. They no longer just generate code, they make decisions inside your product, on behalf of your users. All the more reason to scope before you build.

1. What is an AI agent, and how is it different from a workflow?

An AI agent is a program that receives a goal rather than a sequence of steps, chooses by itself which actions to chain (look something up, call a tool, draft, try again) and decides when it is done. A workflow, even one full of AI, follows a path someone drew in advance: if this, then that.

The difference is not technical, it is about accountability. In a workflow, you decided the sequence, and every step can be tested on its own. In an agent, the model decides, on every run, and two runs with the same input can take two different paths.

Put simply: a workflow is predictable and rigid, an agent is flexible and unpredictable.

Neither is better. They do not solve the same problem, and most "agent" projects you see are in fact workflows in disguise, more expensive and less reliable than if they had been built as workflows.

2. What an agent genuinely does better than a workflow

An agent wins when the path cannot be drawn in advance. Not because nobody can be bothered to draw it: because it changes with every case. Three situations keep coming back.

• The input is fuzzy and varied. A support request written in free text, a document whose structure changes from one customer to the next, a question that can be about ten different topics. A workflow needs the input classified before it can process it; an agent can read it as it is.
• The number of steps depends on what you discover. Diagnosing a problem, gathering the pieces of a file, searching several sources for one answer: you cannot know in advance how many round trips it will take. That is an agent's natural ground.
• The expected result is a synthesis, not a calculation. Summarising, comparing, proposing a first version. Where a human would have needed judgement, and where that judgement can be reviewed.

Notice what these three situations share: variability on the way in, and a human able to judge what comes out. Keep that in mind, it is half of the framework.

3. What a workflow does better than an agent (which is almost everything else)

As soon as the path can be written down, write it down. A workflow costs less per run, can be tested, can be debugged, and behaves tomorrow the way it behaves today. An agent makes more calls to the model to reach the same result, and charges you for its flexibility even when you do not need it.

Cases where a workflow wins outright:

• The task is repetitive and its rules are known. Sending a reminder, creating a record, routing a ticket on three criteria. An explicit rule beats a model guessing it.
• An error is expensive or cannot be undone. Invoicing, refunding, deleting, messaging your whole customer base. Unpredictability is not a detail here, it is the main risk.
• The result must be identical every time. A calculation, a compliance check, a regulatory document. What you want is reproducibility, not creativity.

The most robust answer is often hybrid: a workflow that holds the structure, and one call to the model at a single, well-bounded step, for instance to classify a request or extract three fields from free text. That is not an agent, and that is perfectly fine.

The question is not "can we do this with an agent?". You almost always can. The question is "what does the agent bring that a written path would not?".

4. The three conditions to meet before writing a prompt

When a case survives that first sort, three conditions remain. If a single one is missing, I do not start the project; I reframe it until the condition is met, or I shelve it.

• Condition 1: a verifiable output. Someone must be able to say, without ambiguity, whether the result is right or wrong. In practice: you can assemble a set of real cases with the expected answer, and replay it every time the prompt or the model changes. If nobody can say what a good answer is, the agent will never be "done", only "impressive in a demo".
• Condition 2: a recoverable error. The agent will get things wrong; that is a property of the system, not a bug to be fixed later. So the question is: who sees the error, when, and what does it cost? If the error is visible before it reaches the user, or reversible afterwards, the condition is met. If it goes straight to a customer, or triggers a final action, it is not.
• Condition 3: a closed scope of action and a named owner. The agent only reaches the tools and data it needs, with the lowest possible permissions, and one person on the product team owns it: its quality, its cost, its incidents. An agent that belongs to everyone belongs to no one, and it drifts.

These three conditions have one thing in common: none of them is about technology. They are about organisation. That is why they are settled at the decision-maker's level, not by the engineering team.

5. When is an AI agent a bad idea?

An agent is a bad idea as soon as the cost of an error exceeds the value of the flexibility it brings. That is the threshold. It does not depend on how good the model is, it depends on your business.

A few signals that tell you the line has been crossed:

• You keep adding guardrails until you have rewritten the workflow. Every incident brings one more rule, every rule narrows the agent's freedom, and three months later you have a fragile workflow that runs through a model. You might as well write it plainly.
• Nobody knows what one task costs. An agent that loops, retries a tool or rereads ten documents can cost far more than planned on some cases. If nobody tracks the cost per task, the bill arrives before the diagnosis. It is the same logic as the bill that grows with usage described in the no-code guide, one floor up.
• Human review becomes a rubber stamp. You put a human in the loop, but they approve a hundred proposals a day without reading them. They no longer catch anything; they only carry the responsibility.
• The agent talks to your users without them knowing. That is a trust risk, and now a regulatory question too. According to the European Commission's page on the regulatory framework for AI (checked on 14 October 2026), the transparency rules of the EU AI Act come into effect in August 2026, and people using a chatbot should be made aware that they are interacting with a machine. Have your legal adviser confirm exactly what that means for your product; but the decision on how to display it is made at scoping time, not after launch.

The most common trap is not the agent that fails outright. It is the agent that succeeds eight times out of ten: enough to put it in production, not enough to trust it. The other two cases always land on someone: your support team, your engineers, or your customer.

6. The page to write before the first prompt

Everything above fits on one page, and that page is the real deliverable of the decision. It is written before choosing a model, a vendor or a framework. Here is what it contains.

• The task, in one sentence. Not "a smart assistant for our customers": "answer billing questions from the account history".
• The success criterion. What "a good answer" means, and the set of real cases that will measure it.
• The cost of an error and its safety net. Who sees it, at what point, how you roll back.
• The scope of action. The closed list of tools and data the agent can reach, and the permissions granted on each.
• The owner. One person, not a team.
• The budget per task and the monthly ceiling. Including what happens when the ceiling is hit.
• The fallback. What the product does if the agent is switched off tomorrow: a simple workflow, a form, a human. If the answer is "nothing works any more", you have created a dependency, not a feature.

This page has a valuable side effect: it makes disagreements visible. Product thinks the agent should do everything, support thinks it should send nothing on its own, leadership thinks it will cost next to nothing. Better for those three views to meet on a page than in an incident.

7. How do you introduce an agent without betting the product?

By granting autonomy in stages, and only moving to the next stage when the measurements justify it. It is the same logic as the approach described on this site, with its pilot sprint: small, measured, then widened.

• Stage 1: the agent proposes, a human decides. It prepares an answer, a draft, a summary; nothing goes out without approval. This is where you build the set of cases and measure how many proposals are accepted as they are.
• Stage 2: the agent acts alone on simple cases. Once the measurements are stable, you hand it the most predictable part of the flow, and everything else goes up to a human. You track the cost per task and the errors caught.
• Stage 3: the agent acts alone on a wider scope. Only if the first two stages held, and always with the fallback in working order.

Many projects never need stage 3. An agent that prepares well and that a human approves in ten seconds often creates more value, with less risk, than an autonomous agent that has to be watched constantly. Stopping at stage 1 is not a failure: it is often the right architecture.

What actually matters here

Putting an AI agent in your product is not a technology decision, it is an accountability decision: who judges the output, who catches the error, who pays the bill. The models will change every six months; those three questions will stay.

• Start with the workflow: if the path can be written down, write it down. An agent only makes sense where the path changes with every case.
• Meet the three conditions: a verifiable output, a recoverable error, a closed scope with a named owner.
• Know your threshold: as soon as the cost of an error exceeds the value of the flexibility, the agent is a bad idea.
• Write the page before the prompt: task, success criterion, safety net, scope, owner, budget, fallback.
• Move up in stages: propose, then act on simple cases, and only then widen. Stopping at the first stage is often the right answer.

A well-scoped agent is one of the most useful things a product can add today. A badly scoped agent is a demo that was put into production. The difference is not in the prompt: it is on the page written before it.

Further reading

• No-code, low-code and automation: the 2026 guide for decision-makers, the floor below: what these tools actually do, what they cost, and where they trap you.
• A team coding with AI: which Scrum rituals to adjust, the same shift seen from inside the team: when AI produces, verification becomes the real work.

This scoping is exactly the technical side of the 360° product audit: looking at an AI project before it costs anything, sorting what belongs to an agent and what belongs to a workflow, writing the page that makes the decision hold. The choice of model comes afterwards, and it is almost always the easy part.