How long does an AI agent implementation actually take?

Every proposal I send has a number in it. Three to five days for the enova365 integration. Live in a week.

Both numbers are honest. Both, on their own, are nearly useless — because they measure the build, and in four years the build has almost never been the thing that decided when a client actually had a working agent.

Two clocks run on every implementation. The build clock counts days of my work. The calendar clock counts from the conversation where you decide to do it to the morning somebody in your office asks the agent a question and gets an answer. On a read-only accounting agent the first clock reads five days and the second reads two to three weeks.

That gap is not padding. That gap is the project.

What the five days actually cover

Here is the real breakdown, not the one from a sales deck. It describes a read-only agent sitting on an ERP that already exposes a REST layer — the shape I built for LUBART Keg Market.

Day one: the connector. Authentication, short-lived session tokens, and the exact endpoints the agent is allowed to see. Nothing else. This is the day that falls apart when the ERP turns out to be an older on-premise version sitting behind a VPN nobody has documented.

Days two and three: questions into queries. Everyone expects this to be the hard part, and it is — just not for the reason they assume. The work isn't teaching a model Polish accounting vocabulary. It's discovering that when your director asks "what's outstanding", he means overdue receivables minus two clients he has a private arrangement with, and that "how did yesterday go" means sales net of returns. Every office has ten to fifteen questions that generate almost all the traffic. Getting those ten right is the product.

Day four: the scheduled digests. A morning pulse at 8:00 on working days, a longer version on Monday. This is the feature that decides whether anyone still uses the agent in week four, because it removes the need to remember it exists.

Day five: deployment. One container, secrets, the messaging channel, monitoring. Deliberately boring. There is nothing novel in the architecture, which is precisely why the same pattern moves to the next company in days instead of being rebuilt from scratch.

Five days. I'll put my name to that number. Now here is why you won't be live on Friday.

The metric that predicts everything: access lag

Count the days between the meeting where you agree to do this and the moment the connector holds working read-only credentials against your live system.

Across my projects that number has run from one day to five weeks. It predicts total elapsed time better than the ERP, the scope, the size of your client portfolio, or anything else I have tried to correlate it with. Five days of build behind a five-week access lag is a six-week project. No amount of engineering speed touches it.

Whatever is sitting inside that lag, it is never technical:

• Your ERP is hosted by a partner, and the partner wants a ticket, a change window, and someone at your end authorised to raise it.
• The API module turns out to be licensed separately and nobody knew, so a purchasing decision appears in the middle of a project that had no purchasing decisions left in it.
• There is a security review — entirely reasonable — queued behind two others.
• The one person who knows the admin password is off until the 4th.

None of that is unusual and none of it is anybody's fault. Scheduling it last is the mistake. So these days I ask for read-only credentials as task number one, before anything gets built and often before the contract is signed, precisely because it is the single step neither side can compress once it starts. If you take one operational thing from this article, take this: make access task number one and time how long it takes — because that duration is your project's real speed, not mine.

The accounting office calendar eats half your options

The second structural delay is the shape of your own month. A practice filing on the 15th, 20th and 25th does not have four weeks available for anything. It has about one — and I wrote up what that quiet week can realistically carry after watching two projects slip a quarter because we pretended otherwise.

The reason this hurts more than it sounds is granularity. Miss the window between the 5th and the 14th and you do not lose three days. You lose a month, because the next slot is thirty days out. Two missed windows and a five-day build has quietly become a quarter, with nobody having done anything wrong.

The fix is trivial and almost nobody bothers: put the pilot week in the calendar before the kickoff call, not after.

Honest numbers by shape of project

What you are building	Build	Elapsed, realistic	Your team's hours
Read-only Q&A agent, one ERP with a REST API	3–5 days	2–3 weeks	4–6 h
Same, plus scheduled morning and weekly digests	+1–2 days	unchanged	+1 h
Document intake in shadow mode — agent proposes, humans book	1–2 weeks	6–8 weeks	10–15 h
Booking with write access and an exception queue	2–4 weeks	3–4 months	25–40 h
Bank statement matching across a client portfolio	2–3 weeks	2–3 months	15–25 h

Two rows in that table are worth arguing about.

The elapsed column for the shadow-mode pilot hides a full month that is not work. It is a month of the agent proposing while your team books as usual, so you can measure the real automation rate on your own documents before anything touches the ledger. You can compress it. I have never once seen that pay off.

The jump from six weeks to three months when write access appears is not a technical jump. The connector barely changes. What changes is that every disagreement about how something should be booked — the ones living in three people's heads, never written down — now has to be settled out loud, because software cannot hold an unwritten convention. From that point the reconciliation is the project. The code is the easy half.

What makes it three months instead of three weeks

Past write access, three things reliably stretch a timeline. You can diagnose all three before you start.

Master data. Duplicate contractors carrying the same NIP under three spellings. A chart of accounts that quietly drifted apart between clients. Cost centres half your team fills in and half ignore. None of it kills a project on its own; together they decide whether calibration takes a week or six. That is most of what an AI readiness audit is actually hunting for.

Several ERPs across the portfolio. Each one adds a connector and, more to the point, a different set of field conventions. Two ERPs is not twice the work. It is not 1.2× either.

The number of people who have to agree. A single owner-operator decides on a phone call. A four-partner practice needs a meeting, and meetings in accounting offices happen after the 25th.

What not to compress

If a deadline forces you to cut, cut scope — not shadow mode. Ship the agent that answers questions and drop the one that books documents. That version earns trust inside a week because the risk is structurally zero, it cannot change anything, and it buys you months to fix the data underneath while people are already using it.

Those two weeks where the agent proposes and a human still books are the cheapest weeks in the whole project. Every hour spent there removes a week of argument later. And an office that has watched an agent's proposals for a month knows something no proposal document can tell it: its own real automation rate, on its own documents, before it has spent anything on the write path.

Where to start

Want a date instead of a range? Book a free 30-minute call, tell me which ERP you run and who controls its credentials, and you get two numbers back — the build days and the realistic go-live week — plus an honest read on whether the read-only version is enough for you this year. The accounting AI agents page lists the scopes and pricing; the call is where the calendar gets real.