Rolling out an AI agent in 90 days at a 50–200 person company

What fits into 90 days, and what does not?

In 90 days a company of 50 to 200 people can put one narrowly scoped process into production with an AI agent, with a human approving every irreversible step. What does not fit: three processes in parallel, full autonomy, replacing the ERP, and anything where the data currently lives on paper or in people’s heads.

Ninety days is not a magic number. It is one budget quarter, which happens to be the longest horizon a managing director can fund without having to defend the project to finance halfway through. A nine-month plan gets eaten by the first reorganisation or the first weak quarter.

Live means real users doing real work on real data on a real weekday, with a documented way back. It does not mean a demo, and it does not mean a slide for the board.

The team is small. One decision maker who defends the scope, one process owner who genuinely knows the exceptions, one engineer, and one approver from the business side. Four people, a few hours a week each. Make the committee bigger and three of the thirteen weeks disappear into alignment meetings while the scope doubles in month one. What we see is that a missing process owner delays projects more often than missing engineering capacity does.

Why do most enterprise AI pilots die?

Three reasons keep coming back. There is no success criterion written down in numbers before the work starts. The system runs outside the workflow where the work actually happens, so nobody uses it. And the cost is invisible while it runs, showing up only on the monthly invoice. None of the three is a technology problem.

The 95% figure comes from the MIT Project NANDA survey published in summer 2025, which covered more than 300 announced enterprise deployments, 52 interviews and 153 leadership questionnaires. Its conclusion was that the models are not the weak link, the management of the rollout is. That is 2025 data, and it should be dated as such when you quote it.

The gap between adoption and results shows up in German data too. According to the ifo Institute survey published on 5 June 2026, 54.5% of German companies now use AI, up from 40.9% a year earlier, but only 18.7% of users build anything themselves. The DMB KI-Index Mittelstand 2026 (published 9 March 2026, survey of roughly 700 mid-sized German firms) puts autonomous AI usage at 16.6%, close to double the 8.7% of 2024. So the agents are arriving, mostly as bought products, and the failure rate above applies to them as much as to anyone.

1. No success criterion written down

Most pilots start with “let us see what it can do”. Which means that at the end there is nothing to compare against. Write it down in week zero, in a single sentence: what the cycle time is today, what the error rate is, and what improvement makes you continue. If you cannot write that sentence, the pilot should not start. For the numbers, the AI ROI calculator is a decent way in, since it produces a payback month and a three-year net benefit.

2. The agent sits outside the workflow

If the only way a colleague can reach it is by opening a separate screen, pasting text in and copying the result back out, they will stop using it in week three. The agent has to show up in the system where the person already works: the ERP approval screen, the ticket, the mailbox. That is integration work, not model selection. Our article on AI integration into existing systems has the four to twelve week breakdown for that part.

3. Runtime cost is invisible

A TechCrunch report from 5 June 2026 described Uber burning through its entire 2026 AI coding budget by April, and the executive director of the FinOps Foundation reporting companies that had overshot their full-year token budget threefold by spring. At a 50 to 200 person company this is not a nine-figure line item, but it costs the project its credibility just as effectively. A monthly spending cap does not protect you, because it fires after the fact. You need a hard per-run token ceiling plus a step limit.

Weeks 1 to 2: which process should you start with?

The first two weeks are one decision: which process becomes the pilot. Score the candidates on five criteria, 1, 3 or 5 points each. Volume, how rule-governed it is, the cost of an error, whether the data is reachable by machine, and whether anyone measures it today. Together those five tell you where the work pays back and where it does not.

Start with anything above 21 points. The 13 to 20 range belongs in the second round, because there you have to fix the data or the rules first. Below 12, do not point AI at it: what is missing there is not automation, it is the process itself. For a catalogue of candidate use cases, our corporate AI guide is the starting point.

At this stage our most frequent piece of advice is not to build an agent at all. If the order of steps is known in advance, a deterministic workflow is cheaper, faster and testable. That is not our idea: Anthropic’s Building Effective Agents (19 December 2024) makes the same point, that for most tasks a hardcoded workflow beats an autonomous agent. Agents earn their place where the number of steps varies from case to case.

Weeks 3 to 4: data access and permissions

This is where most projects fail, and it is the least impressive-looking work in the quarter. Two questions have to be closed: where the data comes from by machine, and what permissions the agent runs with. Skip these two weeks and the pilot stops in week six, when the field you need turns out to exist only inside a PDF.

Permissions have to be solved outside the model. OWASP LLM01 states plainly that the system prompt is not a security control: authorisation is deterministic and belongs in a layer outside the model. In practice that means the database user or API key is restricted at the tool level, read-only, and scoped to a single tenant. You do not ask the model politely, in the prompt, not to look at another customer’s data.

Simon Willison’s lethal trifecta framing from 16 June 2025 works well as a checklist. If the agent simultaneously has access to private data, reads untrusted content (incoming email, customer messages, web pages) and can communicate outwards, then one poisoned block of text can turn into a data leak. The defence is architectural: break up the trio. Put the writing tools in a separate agent that never reads external content.

Data in a language other than English needs its own measurement

If the process runs on German, Hungarian or Czech documents, global model leaderboards tell you almost nothing. Péter Harang’s January 2025 measurement on 2,132 Hungarian sentence pairs found substantial overlap between the similarity distributions of related and unrelated pairs, meaning embedding-only search separates less cleanly in that language. On non-English corpora we treat hybrid search, keyword and semantic together, plus a reranking model, as the default rather than an option.

There is a measured number for what that is worth. In Anthropic’s contextual retrieval work, retrieval failure dropped from 5.7% to 2.9% by combining lexical and semantic search, and to 1.9% once reranking was added. That is a 67% improvement on the same corpus with no change of model.

Weeks 5 to 8: building the pilot

Four weeks of building go into the narrowest version that works. One case type, one channel, two or three tools, human approval before every risky step. The goal is not an impressive demo. It is that by the end of week eight you have 100 to 300 real cases you can measure.

Tool calls should go through a structured schema rather than being parsed out of free text. The model calls tools described by a JSON schema, and the response is processable by construction. The old text-parsing ReAct pattern throws a runtime error on a formatting mistake, and a production system is not where you want to debug that. The concept survived, the delivery layer changed.

Keep the tool set as narrow as it can be. The agent should see only what the pilot case type requires, the code execution tool should run in an isolated container with an egress allowlist, and write operations belong in a separate run. If you wire systems in over a protocol, the MCP specification of 28 July 2026 ships with a stateless core, header-based routing and an enterprise authorisation extension, which means it maps onto your existing API gateway and logging. That matters because an integration written this way is written once and stays model-independent afterwards.

How much human approval should you plan for?

More than feels comfortable, everywhere, at the start. On irreversible steps it stays at 100% throughout: money movement, anything that goes out to a customer, deletions or edits in a production system, legal or compliance output.

CV screening is a special case. Under Article 22 of the GDPR a data subject has the right to human intervention against a decision based solely on automated processing that produces legal effects, and Annex III point 4(a) of the AI Act classifies applicant screening as high-risk use. Our article on the EU AI Act and GDPR breaks down the compliance calendar.

Set the cost ceiling before week eight

What determines the price of an agent is not the model, it is the number of loops. Using the official Anthropic price list, the same 1,000 documents cost roughly 8.70 dollars with a single-step extraction call, and 232 dollars with an eight-step agentic loop on the same model family. Twenty-seven times the price for the same task. That is why you need a hard per-run token ceiling, a step limit and a per-step timeout, during the pilot rather than after it.

Weeks 9 to 10: what should you measure?

Track four numbers, plus cost. Accuracy on a golden dataset, hallucination rate, task completion rate and human override rate. Those four decide whether the system can go live. They are also what lets a management team make a decision instead of trading impressions.

The golden dataset is the cheapest thing you can build, and most teams skip it. Take 100 to 300 closed, real cases, write the correct output for each by hand, and you have a regression test. From then on you run it before every prompt change, model switch and tool swap. Without it, the engineer will say “I think it got better”, and that is not enough to go live on.

Do not let the engineer assemble the golden dataset. The process owner and the approver know what the correct output is and which cases are hard. Two days of work, typically at the start of week nine. Put deliberately awkward cases in there: an incomplete document, a badly formatted date, an unknown supplier. Every system performs well on the easy cases. The hard ones make the decision.

The human override rate teaches you the most. If the approver rewrites every third suggestion, the problem is usually not the model but a rule that nobody ever wrote down. In our projects this number is what has most often sent the work back to rethinking the process, and that is a good outcome rather than a failure.

Observability does not need an expensive tool. Langfuse is MIT licensed and costs nothing in licence fees when self-hosted; its cloud tier starts at 29 dollars a month according to the official price list. Anyone who bills you an order of magnitude more for monitoring is selling you convenience.

Weeks 11 to 13: going live and the rollback plan

The last three weeks are a graduated expansion of permissions. The agent reads first, then writes with every write approved, and finally works without approval on the lowest-risk case types. Before each step you look at the four measured numbers, and any step can be reversed.

Do not switch the old process off on day one. Keep it alive in parallel for 30 days, with tools that can be disabled individually, so one bad output cannot stop the working day. Write down in advance who is entitled to pull the plug and what happens to half-finished cases. One sentence, but without it nobody dares to hit stop on day seven.

The team needs preparing too. The approver role is new work, and done badly it degrades into rubber-stamping: a glance and a click on OK. That is the worst possible outcome, because responsibility is formally human while the decision is not. Half a day of team AI training where approvers walk through real failure cases is worth the calendar time.

Compliance deadlines close here as well. Article 50 transparency obligations under the AI Act apply from 2 August 2026: if the system interacts with a natural person, you have to disclose that they are talking to an AI. The deadline for high-risk Annex III systems moved to 2 December 2027 under Regulation (EU) 2026/1744. The transparency date did not move.

What happens in month six?

Three things most proposals do not budget for. The model gets updated and the output changes. The prompts drift, because five people edited them. And the real operating cost turns out not to be the token bill but human time.

A model update is not only a quality question. Anthropic introduced a new tokenizer with Claude 4.7 that produces roughly 30% more tokens for the same text, so the run gets more expensive even at an unchanged per-million price. Google’s official price list shows the Gemini 3.6 and 3.7 Flash introductory rates holding until 31 December 2026 and doubling afterwards. If your 2027 operating plan uses today’s prices, it is wrong.

The defence against prompt drift is the same as the defence against model updates: the golden dataset. Prompts go into version control, every change goes through a pull request, and the regression run is a merge condition. The same discipline you apply to any other code. Skip it and in six months nobody will be able to say why the system got worse.

On cost, the international figures published by development agencies put monthly operations at 3,200 to 13,000 dollars for an enterprise agent (Azilen, 18 February 2026), and the single largest line in that range is prompt tuning at 1,000 to 2,500 dollars, which is human work rather than infrastructure. Treat those as one vendor’s published pricing, not as market statistics. Our own list puts operations for process automation at 30,000 to 150,000 Ft a month, roughly EUR 78 to 390 at 385 HUF/EUR, with the build at 1,000,000 to 3,000,000 Ft (EUR 2,600 to 7,800) for a chatbot or process automation and 3,000,000 to 8,000,000 Ft (EUR 7,800 to 20,800) for a RAG knowledge base system. Model usage is the smaller part of that. The larger part is somebody looking at the failed cases every week.

When should you not start an AI agent project?

There are five situations where we say not now. If the process runs a few dozen times a month. If the data does not exist in machine-readable form. If there is no named internal owner. If the process is going to change within a quarter anyway. And if the real goal is announcing a headcount decision.

• Low volume. Below 50 cases a month the rollout and the maintenance cost more than the time saved. Write that process down properly instead and automate it with rules.
• The data is on paper or in people’s heads and nobody is available to fix it. Data preparation is a project in its own right. Without capacity for it, the AI layer just hides the problem.
• No internal owner. You need a named person whose weekly work includes reviewing failed outputs. The gap between 22% and 67% in the MIT NANDA numbers is exactly about this.
• The process changes within three months. An agent built during an ERP migration, a reorganisation or a regulatory change has to be written twice.
• The goal is communicating redundancies. In that case colleagues do not hand over their knowledge, approvers do not report errors, and the project dies quietly. That is a human problem, not a technical one.

There is a sixth case that is not a failure, it just needs a different solution. If the order of steps is always the same, you do not need an agent, you need a coded workflow with one or two AI calls inside it. Cheaper, faster, testable, and it will not run forty pointless loops overnight. For the wider framing, the eight-step method in our digital transformation guide covers where this sits in a larger programme.

Summary and frequently asked questions

If you have a process that scored above 21 on the table, we can tell you in 30 minutes what fits into 90 days and what does not. What comes out of the first two weeks with us is a written scope, a measurement plan and a price range, not a presentation. We run this work from Budapest, in the same working hours as Munich and Vienna, which matters more than it sounds when the approver has a question at nine in the morning. The delivery model is described on our nearshore development page.