---
title: "The 90-day adoption plan: from first pilot to a measurable agentic system"
description: "A practical six-step framework to assess, pilot, and operate an AI agent in a controlled manner, with KPIs, decision gates, governance, and stopping criteria."
canonical: https://i8.ro/en/blog/the-90-day-adoption-plan-from-first-pilot-to-a-measurable-agentic-system
---

# The 90-day adoption plan: from first pilot to a measurable agentic system

> A practical six-step framework to assess, pilot, and operate an AI agent in a controlled manner, with KPIs, decision gates, governance, and stopping criteria.

Source: https://i8.ro/en/blog/the-90-day-adoption-plan-from-first-pilot-to-a-measurable-agentic-system

A 90-day program can turn a vague idea about AI agents into an evidence-based business decision. However, it can’t guarantee that every process will be automated, that integration will be simple, or that the system will be ready to scale. For an SME, a healthy outcome at the end of this period could mean a controlled launch, narrowing the use case, redesigning the solution, or even shelving it entirely.

This article proposes a practical framework for the first 90 days. The timeline is a **working scenario**, not an official standard or an implementation promise. The real duration depends on the data, integrations, vendors, contractual requirements, and risk level. In regulated fields or for systems classified as “high risk”, legal reviews, evaluation, and approvals may take longer.

## What a measurable agentic system means

An AI agent is more than just a chatbot. Operationally, it’s a system that receives a goal, interprets context, chooses steps, and can use tools like the CRM, email, a knowledge base, or the billing app.

A **measurable agentic system** has at least seven components:

1. a clear process, with a defined start, finish, and known exceptions;
2. a process owner accountable for the outcome;
3. data and tools with controlled access;
4. explicit rules for what the agent can and cannot do;
5. an escalation path to a human;
6. logs that allow you to reconstruct decisions and actions;
7. indicators that compare results to the starting situation.

“Measurable” doesn’t just mean counting API calls or conversations. It means you can answer business questions: how many correct results did you get, how much human time was saved, how much did an accepted result cost, what errors occurred, and whether the residual risk is acceptable.

## Before day 1: minimum conditions

Don’t start the clock just because you have a subscription to an AI model. Before starting the project, confirm five conditions.

### 1. There’s a process, not just a complaint

“The team is losing time” is an observation, not a use case. A better case: “employees manually check incoming requests, search for data in two apps, and prepare a response for approval.” The process must be described concretely enough that the same team can tell a correct execution from a faulty one.

### 2. There’s an owner

The process owner defines what a good result means, validates exceptions, and can stop the pilot. The technical vendor can’t assume this business responsibility.

### 3. There’s a baseline for comparison

Measure the current situation before automation: volume, processing time, cost, correction rate, delays, complaints, and incidents. If you lack historical data, your first step should include manually tracking a representative sample.

### 4. Data and integrations are legally and technically available

Check who owns the data, what personal or confidential information is involved, where it’s processed, how long it’s kept, and whether vendors use it for training. Decide who can authorize access to each tool.

### 5. The initial case has a manageable risk

A suitable first pilot is frequent, repeatable, valuable, and reversible. Avoid starting with decisions that are hard to contest, large payments, layoffs, medical or legal assessments, or actions that can’t be undone. For sample processes and selection criteria, see also [7 processes where an AI agent can deliver measurable results](https://i8.ro/en/blog/where-to-start-seven-suitable-processes-for-ai-agents-in-an-sme).

If there’s no owner, no data, or no baseline, then the realistic goal for the first 90 days is discovery and preparation, not production.

## Days 1-15: define the problem and benchmark the starting point

The first stage should deliver a one-page project brief and a map of the current process.

The brief should include:

- the problem and who benefits;
- process inputs and outputs;
- monthly volume and seasonal variation;
- systems and data sources involved;
- actions that are allowed, prohibited, or require approval;
- initial indicators and pilot targets;
- the owner, sponsor, and technical lead;
- reasons for immediate stoppage.

Then, map the actual flow, including exceptions. Observe a few cases from beginning to end and talk with the people who handle them. Written procedures often skip shortcuts, informal checks, and rare situations that matter precisely when a system starts acting up.

At this stage, the minimum alternative is also defined. Sometimes the issue can be handled more safely with a rule, a better form, a regular integration, or an assistant that suggests a response without taking action. The agent should be compared to these options, not just to manual work.

**Decision Gate 1:** proceed only if the process is clear enough, the result can be verified, data is accessible, and risk can be limited.

## Days 16–30: design control before autonomy

Now define the minimum architecture. For the first pilot, reduce the number of tools and privileges. If the agent only needs to check inventory and prepare a response, don't grant it access to change prices or issue refunds.

### Permissions matrix

For each tool, note:

- data that can be read;
- fields that can be written;
- value and volume limits;
- actions that require human approval;
- the technical identity used;
- session duration and revocation method;
- what is logged.

Use the principle of least privilege and separate reading from writing. Dedicated accounts, permission lists, rate limits, and short-lived credentials reduce the impact of an error. For the full control model, see [Permissions, identity, and audit for AI agents](https://i8.ro/en/blog/permissions-approvals-and-audit-the-rules-for-a-trustworthy-ai-agent).

### Pre-tuning evaluation set

Build a set of cases before optimizing prompts. Include:

- normal and frequent cases;
- edge cases and ambiguous requests;
- missing or contradictory data;
- tool unavailable or slow response;
- repeating a request that could duplicate an action;
- missing required permission;
- unverified content attempting to alter the agent’s instructions;
- situations that need escalation or refusal.

Attacks via instructions hidden in emails, documents, or web pages are a practical risk for agents reading unverified data and using tools. The study [AgentDojo, published at NeurIPS 2024](https://proceedings.nips.cc/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html), evaluates this type of interaction through 97 tasks and 629 security tests. The useful takeaway for an SME isn’t that there’s a universal test, but that success with ordinary cases doesn’t prove resilience against adversarial content.

### Pilot thresholds

Set thresholds before seeing the results. For example:

- minimum 90% accepted outcomes on eligible cases;
- 100% escalation for declared sensitive categories;
- no action outside the permission list during testing;
- median processing time at least 30% lower;
- cost per accepted outcome below the agreed value;
- the ability to reconstruct every action from the log.

The values above are just examples. The actual thresholds are set based on error cost, baseline, and risk tolerance.

**Decision gate 2:** do not build the pilot until permissions, test cases, thresholds, and the owner of each decision are all explicit.

## Days 31-45: build the prototype in an isolated environment

Implement the smallest flow that can confirm or refute the hypothesis. Use a separate test environment, masked or synthetic data where possible, and simulated tools for impactful actions.

During this period, the team must be able to see both the final outcome and the relevant pathway: what data the agent consulted, which tool it called, which rules were applied, where it asked for help, and why it failed. The pathway should not unnecessarily expose personal data, and it is not the same as the model's internal explanation. Its purpose is operational audit.

Compare three options:

1. the rule or deterministic automation;
2. the assistant that suggests but does not execute;
3. the agent with limited autonomy.

If the first or second option delivers nearly the same value with less risk and cost, the simpler choice is usually better.

Do not add new features for every demo. Temporarily lock the model version, instructions, and tool configurations; record every change. Otherwise, you won't know if an improvement or degradation is caused by the product, the data, or the model.

**Decision gate 3:** the prototype moves forward only if it meets minimum thresholds in the isolated environment and there is a compensatory control for every critical failure.

## Days 46-60: validate offline and in shadow mode

Offline evaluation uses historical, synthetic, and specifically error-oriented cases. Don’t measure only the final answer. Also check whether the agent used the correct tool, in the permitted order, with the right arguments, and without forbidden steps.

This distinction between **result** and **trajectory** is important. An apparently correct result can hide an unauthorized source, a double entry, or a shortcut that would be unacceptable in production. The technical guide [Demystifying evals for AI agents, published by Anthropic on January 9, 2026](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents), recommends combining result evaluation, pathway tracing, and human review. It is a vendor recommendation, not a legal standard, but the distinction is useful regardless of model.

After offline testing, use the parallel or shadow mode. The agent receives real cases and produces a recommendation, but does not modify systems or communicate directly with the client. The operator resolves the case through the normal workflow, and the evaluator compares the results.

Record:

- the percentage of proposals accepted without changes;
- the percentage accepted after corrections;
- human review time;
- types of errors and their severity;
- correct detection of ineligible cases;
- cost and latency per accepted result;
- differences between customer groups, products or relevant languages.

A good average score can hide a category that consistently fails. Segment results by case type and track rare, high-impact events separately.

**Decision gate 4:** the real-impact pilot starts only if the parallel mode data meets thresholds, the team can intervene, and the stop mechanism has been tested.

## Days 61-75: launch a limited and reversible pilot

At this stage, the agent can act on a small sample, with clear limits. For example, a single type of request, an internal group, a product category, or a low value cap.

Use controls such as:

- human approval before actions with external impact;
- list of eligible clients, products or actions;
- value limits and frequency caps;
- deduplication and idempotency keys for retries;
- rapid shutdown and fallback to manual process;
- alerts for exceeding cost, latency or error rates;
- daily sampling of results, including those marked as successful.

**Idempotency** means that repeating the same request does not have a double business effect. It’s essential when a connection times out and the agent doesn’t know whether the first attempt succeeded.

Decide in advance who can stop the pilot and what happens after stopping. Shutdown should not depend on the same model or service that failed.

Review incidents and declined cases daily in the first week. Only reduce frequency once behavior stabilizes. Do not change the model, instructions, data sources, and access rights at the same time, as you will lose track of the cause of any changes.

**Decision Gate 5:** the pilot continues only if the observed value remains positive after including review time and if incidents stay within agreed limits.

## Days 76-90: turn the pilot into an operational decision

The final stage isn’t a celebratory demo, but a comparison with the starting point.

### Calculate value per accepted result

Include the cost of the model, infrastructure, integrations, licenses, evaluation, human review, incidents, and maintenance. For full methodology, use [How much is an AI agent worth: total cost, KPIs, and return on investment](https://i8.ro/en/blog/how-much-is-an-ai-agent-worth-total-cost-kpis-and-investment-returns).

A useful operational formula is:

`Cost per accepted result = total period cost / number of accepted results`

Compare with the previous process, but keep quality and risk separate. A lower cost doesn’t justify an unacceptable error rate or greater legal exposure.

### Choose one of four decisions

1. **Expand in a controlled way** if thresholds are consistently met, controls are effective, and the business case remains positive.
2. **Restrict** if the agent is only good for certain categories. Keep the rest in the manual flow or in a simple automation.
3. **Redesign** if value exists but data, interface, permissions or process create too many corrections.
4. **Stop** if the outcome doesn’t outperform the alternative, the risk isn’t manageable, or the review cost eliminates the benefit.

Stopping is a valid result of the pilot. It prevented scaling a solution that does not deliver value.

### Prepare for operation, not just launch

If you expand, document:

- service owner and on-call responsibilities;
- procedure for incidents, shutdown and fallback;
- model, instructions and tool versions;
- re-evaluation frequency and production sampling;
- alert thresholds and budgets;
- how to handle complaints and disputes;
- provider switch and data export plan;
- criteria for system decommissioning.

## Minimum team for an SME

A large department isn’t needed, but roles must be clearly defined. The same person can hold several roles, but responsibility cannot be sidestepped.

- **The sponsor** allocates the budget and unblocks obstacles.
- **The process owner** defines the outcome and takes operational risk.
- **The technical lead** handles integrations, observability, and controls.
- **The evaluator** creates test cases and tracks errors.
- **Security, data protection, and legal** step in in proportion to the data and the impact.
- **Operational users** validate exceptions and flag when the system shifts work instead of reducing it.

In small firms, role conflict is worth offsetting. The person who builds the flow shouldn’t be the only one to declare it safe and profitable.

## Governance framework and current obligations

[NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is voluntary and structures work in four functions: Govern, Map, Measure, and Manage. For a pilot, the practical translation is simple: set responsibilities, understand context and risks, measure behavior, then manage risk for the operational period. [NIST Profile for Generative Artificial Intelligence, published on July 26, 2024](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), adds risks specific to generative systems. These documents are guides, not certifications, and do not replace legal obligations.

In the European Union, [the Artificial Intelligence Act, Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), came into force on August 1, 2024, and is generally applicable as of August 2, 2026, with exceptions and specific timelines. AI literacy obligations apply from February 2, 2025. At the time of writing, a company must check its place in the chain, the specific purpose, the risk category, and the related legislation, including data protection, consumer rights, labor law, and sector-specific rules. Classification must not be inferred only from the product’s commercial label.

When training the team, combine theory with internal procedure: which tools are approved, which data must not be entered, how to verify a result, who approves an action, and how to report an incident. AI literacy is not about ticking off a generic course.

## Pilot dashboard

A compact dashboard should separate four dimensions.

### Outcome

- eligible cases processed;
- results accepted without correction;
- results accepted after correction;
- total time to completion;
- effect on the client or the team.

### Quality

- accuracy by case category;
- correct escalation rate;
- rate of human correction;
- factual, procedural, and tool errors;
- cases that appear successful but were executed via an unauthorized path.

### Economy

- total cost and cost per accepted result;
- human minutes of review;
- integration and maintenance costs;
- savings or incremental revenue, avoiding double-counting.

### Risk and exploitation

- actions blocked by policy;
- attempts outside of permissions;
- incidents and severity;
- median latency and 95th percentile;
- availability, rollbacks, and version changes.

“Zero incidents observed” does not mean “zero risk.” Also report test coverage, sample volume, and categories not yet encountered.

## Common mistakes in the first 90 days

### Automating an unclear process

The agent amplifies ambiguity. Clarify the rules and ownership of decisions first.

### Choosing the model before the use case

The product should be selected based on requirements, data, integrations, and risk. For criteria, see [How to choose an AI platform for your company](https://i8.ro/en/blog/build-buy-or-integrate-how-to-choose-your-ai-agent-platform).

### Optimizing for demonstrations

A demonstration is cherry-picked. A pilot includes typical, failed, and awkward cases.

### Building tests around the outcome

Setting thresholds after seeing the scores favors outcome confirmation. Define them beforehand and keep an unused set of cases for tuning.

### Granting write permissions too early

Start with read, simulate, and human approval. Extend rights only based on evidence.

### Measuring activity instead of value

Message, step, or token counts are not business outcomes. Measure accepted results, time, cost, quality, and risk.

### Lack of a change management plan

Models, prices, tools, and data change. Any material change should be recorded and may require reassessment.

## What should exist at the end of day 90

Regardless of the decision to scale, the project should leave behind:

- the use case documentation and owners;
- the process map and benchmark;
- register of data, tools, and permissions;
- risk and controls register;
- evaluation set and results by category;
- log of model and configuration changes;
- incident, shutdown, and rollback procedure;
- dashboard for cost, quality, outcome, and risk;
- a written decision: expand, scale back, redesign, or halt.

This is the difference between an experiment and an operational capability. The experiment shows that the agent can produce an outcome. The capability shows when it produces it, at what cost, within what limits, and who is responsible when it does not.

## Sources and further reading

- [Regulation (EU) 2024/1689 on artificial intelligence, Official Journal of the European Union](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
- [European Commission: AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [NIST AI RMF: Generative Artificial Intelligence Profile, July 26, 2024](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence)
- [OECD AI Principles](https://oecd.ai/en/ai-principles)
- [OECD Due Diligence Guidance for Responsible AI, 2026](https://www.oecd.org/en/publications/oecd-due-diligence-guidance-for-responsible-ai_41671712-en.html)
- [AI Playbook for the UK Government, February 10, 2025](https://www.gov.uk/government/publications/ai-playbook-for-the-uk-government)
- [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents, NeurIPS 2024](https://proceedings.nips.cc/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html)
- [τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains, 2024](https://arxiv.org/abs/2406.12045)
- [Generative AI at Work, Quarterly Journal of Economics, 2025](https://academic.oup.com/qje/article/140/2/889/7990658)