How one AI agent gives key account managers 4–5 hours a day back

The client — an affiliate network — is anonymized in this write-up. The shape of the problem and the lessons are general enough that I suspect you'll recognize your own company in them anyway.

Earlier this year I built an AI agent with the team at an affiliate network in Stockholm. The brief sounded almost too plain: key account managers were spending most of their working day not managing accounts, but gathering the information they needed in order to manage accounts. Today an agent does that gathering. Each account manager gets 4–5 hours a day back.

The problem: the job before the job

A key account manager at an affiliate network sits between partners — the advertisers and publishers who make the network work — and the network's own systems. Before they can do the actual job, advising a partner, spotting a problem, preparing a review, they first have to assemble the picture: pull numbers from internal systems, check statuses, cross-reference what happened since last time, and stitch it together into something they can act on.

None of that assembly is judgment work. All of it was manual. And it was the first thing every account manager did every day, which meant the most expensive people in the commercial organization were spending the biggest block of their day on copy-paste logistics.

This pattern is everywhere once you see it. Sales engineers do it before demos. Customer success does it before QBRs. Analysts do it before anyone asks them anything interesting. I've started calling it the job before the job — and it is, in my experience, the single best first target for an AI agent, because the work is repetitive, the sources are known, and the output is checkable.

What the agent actually does

The agent does the gathering. It has tool access to the systems the account managers already used — and when an account manager needs the picture for a partner, the agent assembles it: the relevant numbers, the recent changes, the things worth reacting to. The account manager starts from an assembled picture instead of an empty one, asks follow-up questions in plain language, and spends their day on the part of the job that actually needs a human: the relationship and the judgment.

Notice what the agent does not do. It doesn't message partners. It doesn't change anything in any system. It reads, assembles and drafts; the human decides and acts. That boundary was a deliberate design decision, not a technical limitation — and it's a large part of why the rollout worked.

How it was built — the high-level version

I won't go into the client's systems, but the build followed a shape I now use in every engagement of this kind:

1. Shadow the users first. Before writing any code, we sat with account managers and wrote down the actual questions they answer in a day and where each answer comes from. That list — not a model choice — became the specification.
2. Give the agent tools, read-only. The agent got tool-calling access to the same sources the humans used, with read-only credentials. Read-only is not just safer; it changes the conversation with security, IT and the users from "what could go wrong?" to "worst case, it reads something and is wrong — like a new hire."
3. Build the eval suite from real questions. The questions from step one, with known-correct answers, became a graded test suite. Every change to the agent — prompt, tools, model — ran against it. When the agent failed a case in the wild, that case went into the suite. The eval suite is the spec, the regression test and the acceptance criteria in one.
4. Build on site, with their team. The client's own engineers worked on the agent with me. By launch, the integration patterns and the failure modes lived in their heads, not mine — which is the point. They own the system now.
5. Iterate where it fails, in front of the users. The first version was wrong in ways only account managers could see. Because they had been in the loop since step one, they reported failures instead of quietly abandoning the tool — the fate of most internal AI rollouts.

Five lessons that transfer

1. The workflow beats the model

Almost none of the project's difficulty was model choice. The work was understanding a workflow deeply enough to hand it to an agent: which sources, in which order, and what "correct" looks like. Teams that start from "which LLM should we use?" are starting at the least important decision.

2. Evals from day one, or you're doing vibes

Without a graded set of real questions, every iteration is an argument about anecdotes. With one, improvement is a number. This is the single practice I would keep if I had to drop everything else.

3. Read-only first buys you the rollout

An agent that can only read is easy to approve, easy to trust and easy to debug. Write-access can come later, workflow by workflow, once the agent has earned it.

4. Build with the users, not for them

The account managers weren't stakeholders to be demoed at; they were co-builders. That's why adoption happened. Nobody abandons a tool they helped design.

5. The handover is the product

A consultant-shaped dependency is a failure state. The engagement ends when the client's team runs the evals, reads the monitoring and extends the agent without me. That's what "owning the system" means, and it should be in the definition of done from the first day.

The result, and what it's really worth

4–5 hours a day per account manager is the headline, and it's a real, measured-in-the-calendar effect. But the more interesting change is qualitative: the day now starts at the judgment, not at the gathering. What a company does with the recovered hours — more partners per manager, deeper work per partner — is a strategy question, and a much better one to be arguing about than "can AI help us?"