The first 90 days of an agent project

You've said yes — or you're deciding whether to. Here is what actually happens, week by week, including the fortnight where it feels slower than the old way.

Every supplier will describe the destination: the inbox that empties itself, the hours handed back. Almost nobody describes the journey, which is a pity, because the journey is where projects live or die — and because two of its phases feel, at the time, like the project is failing. They aren't failure. They're the plan. Here is what a well-run first project looks like from the day you say yes, so you can tell normal turbulence from a genuine problem.

Weeks one and two: counting, not building

Nothing gets built. Whoever runs the project watches how the work happens now and writes down numbers: how many arrive each day, how long each one takes, how often something goes wrong and what it costs to put right. This is the baseline, and it feels like a delay — two weeks in, you have paid attention and received a spreadsheet.

Insist on it anyway, whoever you work with. Without a baseline, the conversation at day ninety is "it feels a bit better, don't you think?" With one, it's "this took our team eleven hours a week in March; it takes ninety minutes now." One of those sentences justifies a budget. (This counting fortnight is exactly what our free workflow review is; if you've already had one done, the first two weeks are free in a second sense — they're finished.)

Weeks three to six: the plumbing nobody claps for

Now the build — and from your side of the glass, the least satisfying month of the project. The agent gets its own login, with the minimum access the job requires, the way you'd provision a new junior rather than handing over the office master key. The logging goes in: every document read, every action taken, recorded where you can inspect it. The approval step goes in: the rule that says which actions go through on the agent's own judgement and which wait for a person. Then the agent starts doing the job on copies of real work, where a mistake costs nothing.

Visible progress during these weeks is nearly nil and the invoices are real. That's the correct shape: this unglamorous scaffolding is most of what you're paying for, and it's what separates a system you can trust — and audit — from a clever demo. One thing to demand in this phase: ask to be shown the failures, not just the highlight reel. A supplier who only ever shows you the agent succeeding is curating, and you'll meet the failures later, unsupervised.

Weeks seven to ten: the agent works, your person checks everything

The switch that matters least technically and most humanly: the agent starts doing the real job, and every single piece of its work waits for a human sign-off before anything leaves the building. In our own newsroom — the agent that drafts articles for this site — nothing publishes without a person approving it, and that rule is built into the software rather than written into a policy, because policies have busy days.

Be warned: this fortnight often feels slower than the old way. Your reviewer is doing a new kind of work — checking rather than doing — and the agent is still making mistakes. Both are supposed to be happening. Every mistake caught now is one category of mistake fixed before the supervision loosens, and every rejection with a reason attached teaches the system something. The one staffing decision that matters: the reviewer should be the person who knows the job best, not whoever had capacity. They're the only one who can tell "wrong" from "not how I'd have phrased it".

Weeks eleven to thirteen: loosening the reins, not dropping them

Review doesn't switch off; it narrows. The routine cases — the ones the agent has now handled correctly a few hundred times — start going through with spot-checks rather than sign-off on each one. The unusual, expensive or irreversible cases keep waiting for a human, and should keep waiting for a human permanently; that's not a training-wheels arrangement, it's the design.

Then you take out the fortnight-one spreadsheet and compare. Hours per week, before and after. Error rate, before and after. Time from arrival to done, before and after. The day-ninety decision isn't "is the project finished" — it's whether those numbers earn the second workflow, which will cost a fraction of the first because it inherits the logins, the logging and the approval patterns you just paid to build once.

The three things that actually go wrong

Not the robot uprising. These, in order of likelihood. The reviewer goes on holiday and the approval queue silently backs up — name a deputy in week seven, not when it happens. The exceptions outnumber the estimate — every business believes its work is 95% routine and discovers it's more like 80%, so treat the first month's "that almost never happens" list as half its true length. And the quiet drift back — the first time the agent has a bad day, somebody will start doing the job by hand again "just to be safe", and the system dies not with a decision but with a shrug. Surviving that moment needs a manager who visibly holds the line: the fix for a mistake is a rejection with a reason, not a return to the old way.

What you should be holding at day ninety

Four things. A before-and-after measured in hours and errors, not impressions. A working system with a log you've personally looked at. A reviewer who trusts the routine cases and knows exactly which ones to still read closely. And the rails — connections, logging, approval patterns — that make workflow number two cheap.

And one honest possibility to keep on the table: sometimes the day-ninety numbers say it wasn't worth it. That is a perfectly good outcome of a well-run project — ninety days and a modest build to learn a true thing beats three years of a system nobody trusts. If your supplier's process has no way of ever reaching that conclusion, it isn't a process. It's a pipeline, and you're in it.