How AI Consulting Engagements Are Priced: Audit, Project, Retainer

How AI Consulting Engagements Are Priced: Audit, Project, Retainer

AI consulting is usually priced in one of three ways: a fixed-scope diagnostic, a project with defined deliverables, and a retainer to operate and maintain what was built. The right model depends on where your company is today, and each one must deliver something you can verify: a decision from the diagnostic, a working flow from the project, and controlled continuity from the retainer. This article explains each model, what to demand from it, and how to avoid buying the wrong format. It does not cite any figures.

Key takeaways

• The three models answer different questions: what is worth doing (diagnostic), how to do it and prove it works (project), and how to keep it working (retainer).
• Billing by the hour with no defined deliverable shifts all the risk onto the buyer. Always ask for deliverables and acceptance criteria.
• Variable costs, such as AI model usage and the WhatsApp provider, should appear separately from the consultancy's work.
• A retainer without reports, logs and periodic review becomes a fee for availability, not for operational results.
• Every contract should say how it ends: documentation, access returned, and a handover of what was built.

Why the pricing model matters so much in AI

In traditional software, scope tends to be more stable: you describe screens, rules and integrations, and the work stays close to that description. In AI, the uncertainty is real. You only know whether an agent serves customers well after testing it with real conversations, real data and real exceptions. A contract that promises everything up front usually hides risk, and a contract that bills only hours usually hides a lack of commitment.

A good pricing model splits the uncertainty into stages. First you reduce doubt about what to do, then you build a small, measurable piece, and only then do you decide whether to maintain and expand it. Each stage has a deliverable your company can check on its own, without relying on the consultant's word.

There is also the fact that the work does not end at delivery. AI agents depend on models that change, business rules that change, and customers who write in unpredictable ways. Whoever buys the service needs to know from the start who looks after this later, and under what conditions.

Diagnostic: what it is and what it should deliver

The diagnostic is a short, fixed-scope stage in which the consultancy looks at your current process and tells you what is worth automating, what is not, and where to start. It is usually sold as a package with a set timeline and deliverables, because the effort is predictable.

A serious diagnostic delivers, at minimum:

• A map of the current process: who does what, in which tools, and where the bottlenecks are.
• A baseline: how the process works today, so a future pilot has something to be compared against.
• A list of automation candidates, ranked by value and risk, with reasoning.
• An inventory of the data and systems involved, with attention to anything containing personal data and to LGPD requirements.
• A high-level architecture recommendation, including what should be a deterministic flow and what truly needs AI judgment.
• A pilot proposal: one flow, one success metric, limits on what the agent can do, and a criterion for continuing or stopping.

A diagnostic must also be honest enough to say no. If the process is rare or poorly defined, or the data does not exist, the useful answer may be that the company should not invest in AI at that point yet. Be wary of a diagnostic that always concludes with a large project.

The final document should belong to you. If you can take it to another vendor and ask for a second proposal, the diagnostic did its job. To structure that comparison, it helps to have an AI agent RFP template at hand.

Project or pilot: what it should deliver

The project is the model in which the consultancy builds something. It can be priced by fixed scope, by milestones or by phases. In AI, the healthiest format is usually a pilot of one real flow, with a start, an end and a formal decision at the close, rather than a broad project that only shows results on the last day.

What a well-contracted project should deliver:

• One real flow in operation, for example handling one class of questions on WhatsApp, not a demo built on fake data.
• Explicit limits: which data the agent can access, which actions it can take, when it hands off to a human, and what requires approval.
• Decision logs that let you audit what the agent did and why.
• A test set with real cases and hard cases, so the evaluation can be repeated after every change. Anthropic describes this approach in its engineering article "Demystifying evals for AI agents".
• A final report against the metric agreed at the start, with a clear recommendation: expand, adjust or stop.
• Documentation and training so your team understands how the system works.

The acceptance criteria must be written before work begins. An AI pilot charter template helps with that, and so does defining metrics and decision gates as described in how to measure an AI automation pilot.

Be careful with projects that charge everything up front and deliver only at the end. Prefer milestones with checkable deliverables and payments tied to them.

Retainer: what you are actually paying for

A retainer is the model for continuous monitoring and maintenance. It makes sense when the system is already in production and someone needs to look after it. The most common mistake is buying a retainer without knowing what it covers.

A useful retainer should describe, in writing:

• What is monitored: answer quality, integration failures, volume, usage costs and handoffs to humans. Observability concepts, such as those in the OpenTelemetry observability primer, help define this.
• How often the company receives a report and what the report contains.
• Which kinds of adjustments are included (rules, texts, knowledge base) and which become a new project.
• Response time for incidents, described in operational terms and without absolute promises.
• Periodic review of the agent's limits and permissions, including when the model, the provider or an internal process changes.
• Who on your side is responsible for approving changes.

A retainer also needs an exit. If you decide to bring the work in-house or switch vendors, the contract must guarantee access to documentation, prompts, configurations, logs and tests. Without that, the retainer turns into dependency.

When the operation is run through a platform, as in the operations delivered by Be Human, ask exactly what each party is responsible for, including permissions, approvals and traceability.

Which model should you choose? A decision guide

Use the questions below to see which model fits your company now.

• If you do not yet know which process to automate, or are not sure the data exists: start with the diagnostic.
• If you already have a clear process, a defined owner and a workable metric, but have never tested AI on it: buy a project in pilot format.
• If the pilot reached the agreed metric and you want to keep the flow running without building an internal team: buy a retainer.
• If you have a technical team and only need occasional guidance: consider standalone advisory sessions, with an agenda and a record of decisions.
• If a vendor asks for a retainer before any pilot: ask what would be monitored. With no system in production, there is nothing to maintain.
• If a vendor proposes a large project without a diagnostic: ask how the scope was defined and which assumptions have not been tested yet.

This guide does not remove the need to compare vendors. For that, the scorecard for evaluating an AI agent development company helps organize technical and commercial criteria.

Illustrative scenario: a distributor that wants to handle orders on WhatsApp

This is an illustrative scenario, unrelated to any real customer. A distributor receives orders and delivery questions on WhatsApp, and the sales team spends much of the day answering repeated questions. The owner wants to "add AI" but does not know where to begin.

In the diagnostic, the consultancy maps the support flow, separates order status questions (repetitive, with data in a single system) from price negotiations (sensitive, better handled by people), and records how support works today. The recommendation is a pilot for order status only, with read access to data and no write actions.

In the project, the team builds that flow with clear limits: the agent only looks things up, never changes orders, and hands off to a person when a question falls outside its scope or the customer shows frustration. Every decision is logged, and there is a set of real conversations for testing. At the end, the report compares the result with the baseline and recommends adjusting, expanding or stopping.

Only then, if the decision is to expand, does the retainer begin: monitoring of answers, a monthly review of failures, and approval of any increase in permissions. Each stage has its own deliverable, and the company could stop at the end of any of them without being tied to the next.

If you are working on this kind of flow, it is also worth reading how to integrate AI into your company's WhatsApp.

How to read a proposal: checklist and method

Before signing, check whether the proposal answers these questions:

• What is the deliverable for each stage, and how will I verify it?
• Which success metric was agreed, and who measures it?
• Which data and systems will the agent access, and with what permissions?
• What happens when the agent makes a mistake or does not know the answer?
• Which variable costs exist (AI models, WhatsApp provider, infrastructure), and are they shown separately?
• What does maintenance include, and what becomes new scope?
• What do I receive if I end the contract?

On variable costs, the unit economics idea described by the FinOps Foundation is useful: instead of looking at an opaque total, relate cost to the volume of work delivered, such as each resolved conversation. That makes any discussion about expansion far more objective.

It is also worth asking the proposal to say how risks will be managed. The NIST AI Risk Management Framework is a good source of vocabulary for that conversation, without requiring the company to adopt a heavy formal process.

The working method we follow has the same logic as the stages above: map the current process and baseline, limit data and actions, pilot one real flow with logs and an agreed metric, and hand over what was built before deciding whether to expand, adjust or stop. The contracting models are simply the commercial form of those stages.

Frequently asked questions

How long does each engagement model last? There is no universal timeline. The diagnostic tends to be the shortest stage, the project or pilot depends on the complexity of the flow and its integrations, and the retainer continues for as long as the system is in production. What matters is that each stage has a written start date, deliverables and decision point.

Can I skip the diagnostic and go straight to a project? You can, if the company already has a mapped process, a defined owner, a metric, and clarity on data and systems. If any of those is still open, the diagnostic keeps the project from spending its time discovering what should have been settled beforehand.

Does the consultancy bill separately for AI model and WhatsApp costs? In general these costs are variable and depend on usage volume, so the healthiest arrangement is for them to appear separately from the consultancy's work and for you to have access to consumption data. Also confirm in whose name the provider accounts and contracts are held, so you do not lose access when the engagement ends.

How do I avoid vendor lock-in on a retainer? Require the contract to include delivery of documentation, configurations, tests, logs and access, plus a reasonable transition period. Prefer architectures in which accounts and credentials belong to your company, and check periodically that someone on your side understands what is running in production.

Sources

• Anthropic: Demystifying evals for AI agents
• FinOps Foundation: unit economics
• NIST AI Risk Management Framework
• OpenTelemetry: observability concepts