How to Hire AI Development by Outcome Instead of by the Hour

Many companies have already tried AI in a chat, seen that it works, and now want AI working inside a real process: sorting orders, checking documents, giving the first answer in customer support. When it is time to hire, the proposal usually arrives in development hours. The trouble is that hours measure effort, and the buyer wants to know whether the process will actually run better at the end.

This guide shows how to hire AI development tied to an outcome: how to define that outcome, what to put in the scope, how to write acceptance criteria for an AI agent, what to ask the vendor and where to start without committing to a large project on day one. If your main question is what drives the cost, see also how much an AI agent in production costs.

What does hiring AI by outcome mean?

It means the contract describes what has to be working at the end, and how that will be checked, instead of only the number of hours the vendor will put in. An example of an outcome: "the agent reads orders that arrive by email, fills in the sales system and sets aside for a person the ones with a price or stock mismatch". Acceptance criteria come with it and say how to tell whether that was delivered.

What gets agreed is a defined process, with a beginning, middle and end, and a way to test it. Promises of financial gains and fees based on a share of the savings are outside this model.

Hourly, fixed scope or by outcome: what is the difference?

Question	Hourly	Fixed scope	By outcome
What the contract describes	Hours and profiles	A feature list	A working process and acceptance criteria
Who carries the risk of delays	The buyer	Shared	Mostly the vendor
How you know it is done	When the hours run out	When the list is delivered	When the agreed tests pass
Handles uncertainty	Yes, but with no clear limit	Poorly, every change becomes an amendment	Yes, if the outcome is well defined
Best for	Ongoing evolution of a product	Systems with stable rules	Agents and automations in a known process

In AI projects, a traditional fixed scope tends to stall. A model's behavior only becomes clear when it is tested with real data, and a rigid feature list cannot anticipate that. An hourly-only contract, on the other hand, leaves the buyer without knowing when the agent will be ready to use.

When does hiring by the hour still make sense?

Hiring by the hour or with a dedicated team makes sense when the work is continuous and priorities change every week, such as evolving a product that is already live. In that case, a dedicated squad or ongoing support fits better. It also makes sense in research, when nobody knows yet whether the idea is viable and the goal is to find out.

Hiring by outcome works best when the process already exists, someone in the company can explain how it is done today and there are real examples to test with.

How do you define the outcome of an AI project?

A well-defined outcome answers four questions:

1. Which process? One, with a name and an owner. "Checking supplier invoices" works; "using AI in finance" cannot be tested.
2. How is it done today? Who does it, how long it takes, how many times a week, where it usually goes wrong. That is the baseline for comparison later.
3. What changes once the agent is live? What it does on its own, what it prepares for a person to approve and what stays entirely with people.
4. How will it be measured? Time per item, items handled without rework, cases sent back for correction. The metric comes from the process itself and does not need to be sophisticated.

AI already helps at this stage: it reads spreadsheets, emails and records from the current process, organizes the baseline and points out the most common case types and the ones that cause the most exceptions. The people who do the work every day confirm whether that reflects reality.

What needs to be in the scope of an AI project?

• The process and its boundaries. Where the agent starts, where it ends and what is left out at this stage.
• The systems and data involved. Where the agent reads from, where it writes and with what permission. Starting with read-only access is a common and safe choice.
• The autonomy rules. What the agent can do on its own, what requires approval and what it never does. The levels of AI agent autonomy help write this down.
• The set of test cases. Real examples, including the hard ones, that will be used to accept the delivery.
• What happens when the agent is unsure. Where the case goes, who is notified and how quickly.
• Logging and follow-up. What is recorded for each agent decision and how the company looks it up.
• Who looks after it afterwards. Whether the internal team takes over or operations continue with the vendor, and what that includes.

How do you write acceptance criteria for an AI agent?

An acceptance criterion is a condition that must hold for the delivery to be accepted. In regular software it is binary: the button saves or it does not. With an AI agent, answers vary, so the criterion has to be measured across a set of cases rather than a single one.

A good set of criteria for an agent usually includes:

• Accuracy on the test cases. The agent correctly handles an agreed share of the real cases set aside for testing. The number is defined together, based on today's baseline, and is never copied from another project.
• Mistakes that do not slip through. In the cases it gets wrong, the agent flags the doubt and hands the case to a person instead of moving on with confidence.
• Rules that are never broken. For example: never approve a payment, never answer a customer about pricing, never change a record without confirmation. Here the criterion is zero occurrences.
• Response time. How long the agent may take to handle an item.
• Traceability. For each item, you can see what the agent received, what it decided and why.
• Behavior when something fails. If the AI model or an integration goes down, the process keeps going, even if manually, and someone is notified.

AI also helps write these criteria. In the GTS project, AI structured the requirements document with modules, business rules, user stories, acceptance criteria and test cases, and the team validated each part. The requirements stage, which would have taken days or weeks, dropped to a few hours, up to 80% less time. For the basics behind this, see software requirements.

What does hiring look like, step by step?

1. AI map

Before hiring an agent, it helps to know which process brings the most return for the least effort. The AI opportunities map is free and online: you answer a short questionnaire and get the opportunities ranked by effort and impact. When several departments are asking for automation, the AI map with a specialist goes deeper with interviews and a plan for the first agent in production.

2. Outcome and baseline

Once the process is chosen, AI reads the available history and builds a picture of today: volume, time, case types, exceptions. The process owner checks and corrects it. That picture becomes the yardstick.

3. Scope and acceptance criteria

AI drafts the rules, permissions and test cases from what was gathered. The company reviews and approves them. This is where you decide what the agent does on its own and what goes through a person.

4. Pilot on real cases

The agent first runs on the test cases and then in parallel with the current process, without changing anything. A person compares its answers with the team's. If the criteria pass, it moves on; if not, it gets adjusted before going to production.

5. Production

The agent joins the real process, with the agreed approvals. At UEEK, once the process is defined, the agent in production is ready within 4 weeks, connected to the company's tools.

6. Operations

Once live, the agent needs follow-up: the process changes, new cases appear and AI usage costs need to stay under control. In agent operations, AI logs and summarizes what happened in the month, and a person reviews mistakes, adjusts rules and decides on the next flows.

What should you ask the vendor before hiring?

1. What outcome are you committing to deliver, in one sentence?
2. How will we test it? Who sets aside the test cases and who checks them?
3. What happens if the acceptance criteria do not pass in the pilot?
4. What can the agent do on its own and what goes through a person?
5. What permissions will the agent have in our systems?
6. Where are its decisions recorded and how do we look them up?
7. Who looks after the agent once it is live, and what is included?
8. If we change vendors, what stays with us: code, rules, prompts, test cases?

What are the warning signs in an AI proposal?

• A vague outcome. "Deploy AI in customer support" without saying which part of support or how to measure it.
• Only hours, no deliverable. The proposal lists profiles and hours but does not say what will be working at the end.
• No testing with real data before production.
• Full autonomy from day one, including actions that affect customers, payments or records.
• Nothing about what happens when the agent gets it wrong or when the AI model is down.
• Nothing about afterwards. The agent is delivered and nobody is responsible for follow-up.

UEEK examples with AI and people in control

At Itaú, the Itaú Mulher Empreendedora platform was delivered with continuous delivery and automated security analysis in the CI/CD pipeline, plus external pentests, following banking-sector standards. Each release only moves forward when it passes the agreed tests, the same logic as the acceptance criteria described here.

At GTS, AI took part in the whole development cycle, from requirements with acceptance criteria to unit tests, always with continuous validation by the team.

At Wellu, AI checks activity photos, summarizes the day for the team and gives the first answer in support. A person decides when in doubt, and if the AI fails the entry goes through normally, which is exactly the kind of rule worth writing into the scope.

Frequently asked questions

Can you hire AI by outcome without organized data?

Yes, as long as there is a minimal history of the process, even if it is scattered across spreadsheets and emails. Organizing that data is part of the baseline stage, and AI helps a lot with it.

Does by outcome mean paying only if it works?

Not always. The contract describes what has to work and how to test it. How payment is spread across the stages is a separate conversation, but the delivery is tied to the acceptance criteria.

What is the difference between an acceptance criterion and an outcome metric?

The acceptance criterion says whether the delivery can be accepted, for example, the agent correctly handles the agreed share of the test cases. The outcome metric tracks the effect on the process over the months, such as time per item and rework.

What if the AI makes mistakes after it is accepted?

Mistakes will happen, and the design has to account for them: doubtful cases go to a person, high-impact actions require approval and everything is logged. In operations, each mistake becomes a rule adjustment or a new test case.

How long does it take from contract to a working agent?

It depends on the process and the integrations. At UEEK, once the process is defined, the agent is in production within 4 weeks. The AI map with a specialist, when needed, takes 2 to 3 weeks.

Do I need a technical person in the company to hire this way?

It helps, but it is not required. What you cannot do without is the process owner, who knows how the work is done and checks the tests. For the technical side, UEEK as your CTO can represent the company in those decisions.

Where should I start?

With the AI opportunities map. In about 10 minutes you see which processes bring the most return and you arrive at the vendor conversation already knowing what to ask for.

How UEEK can help

UEEK has worked for 14 years with digital products, for more than 200 clients, in 6 countries, on more than 500 projects. In AI, we work with hybrid squads, with agents on the repetitive work and people deciding and validating, and we start with the process and the acceptance criteria before talking about hours. The journey goes through the AI opportunities map, the agent in production and agent operations. For a technical example of how an agent is built, see how to build an AI agent for operations.

Take the free AI opportunities map