AI, data and automation enablement across a global agency

Built with their teams, not around them

Worth stating plainly, because case studies routinely blur it: the AI programme at this agency is theirs. Their leadership set the direction, their teams author the skills, and adoption across the business is their achievement. 1AYM is engaged on the engineering underneath, working alongside their finance, systems, data warehouse and AI tooling teams.

That is the point rather than a caveat. A supplier who builds in isolation leaves behind a system only they understand, and the client discovers the dependency the first time something breaks after the invoice is settled.

Building alongside their people means upskilling them as the work goes. The finance director who shaped the semantic layer with us can defend and extend its definitions himself, and the team maintaining the provisioning system understands why it resolves identity the way it does rather than treating it as a box that must not be touched.

The measure of this kind of engagement is not what runs while you are there. It is what the client can still maintain, change and build on once you have gone.

How the scope grew

The engagement started as integration work. It expanded because the problems worth solving kept turning out to sit between teams rather than inside one: a finance reconciliation issue that was really a data contract issue, an identity request that was really a provisioning architecture issue.

The value of being forward-deployed is being able to follow a problem across those boundaries instead of handing it off at each one. Over time the role became a bridge between finance, systems, the data warehouse, and the internal AI tooling teams.

What the work covered

Finance systems enablement

Data warehouse and finance systems work across Xero, NetSuite, Zoho and QuickBooks: financial detail, mapping, reconciliation, management-accounts and trial-balance checks, and year-end rollover workflows.

Identity and provisioning

Integration pipelines with deterministic identity resolution, dry-run modes, diff-based writes, auditability and safe rollback patterns.

Internal AI skill platform

Engineering contributions to an internal Claude Code skill platform that now carries around 600 production skills. The skills themselves are authored across the business by the people who do the work; our part is the plumbing and reliability beneath them.

Verifier-gated automation

Managed-agent workflows for finance-critical and high-stakes operational tasks, built so deterministic checks decide what proceeds.

Grounded analytics

AI-enabled analytics workflows, including MCP-style patterns connecting the data warehouse and BI layer so AI answers resolve against canonical business metrics.

Platform reliability

Production support across Cloud Run and BigQuery/Airflow, deployment fixes, and the ongoing reliability work that keeps daily runs predictable.

Optimisation nobody asked for

The skills library lives in Notion. As written, every user's client fetched from the Notion API directly, which works perfectly at ten users and becomes a problem at a thousand, because the request volume scales with people multiplied by how often they work, against an API with rate limits and an availability budget that was never sized for it.

We replaced that with a single synchronisation running every ten minutes, so the platform reads from a local copy rather than every client hitting the source. Request volume stopped scaling with headcount, and the dependency on Notion being fast and reachable at the exact moment someone works went away with it.

The forecast saving from that one change is £2–4 million over a year, alongside a system that is materially more reliable. A number that size deserves its provenance: we modelled it on token consumption, and it was reviewed and accepted by a member of the client's finance team rather than asserted by the person who made the change.

The arithmetic is not complicated. Under the old pattern, consumption scaled with users multiplied by working sessions multiplied by fetches per session, and at roughly a thousand people that product grows fast, because every one of those fetches pulled content into a context window that someone was paying for. Under the new pattern the cost is fixed: one sync every ten minutes, whatever the headcount is doing.

This was not in a brief. It is the kind of thing you only see from inside the system, and the kind of thing worth raising rather than waiting for it to become an incident.

Phase two: re-architecting the skills estate

Sessions on the platform now come back faster and, by our own measurement, cost 60% less on average than they did before the rebuild. Across the number of people using it and the sessions each of them runs in a day, that compounds into a substantial annual saving. 1AYM now holds the lead architect role for the Brainlabs platform, in addition to the sync described above.

Phase two happened because phase one worked. Adoption spread, the estate of skills grew with it, and the platform slowed under its own success. The skills had been written as flat, monolithic files, and over 80% of them exceeded the description limits, so every session carried far more context than the task in front of it ever used.

The rebuild followed the structure the Anthropic SDK already defines, rather than a shape of our own.

Skills split to the SDK's structure

Each skill is split the way the SDK expects, with reference files the model loads on demand instead of one file loaded in full at the start of every session.

Context injected, not carried

Custom MCP servers that inject the targeted context a task actually needs, in place of whole files travelling through the session whether or not anything reads them.

End-to-end sync

One pipeline from the authoring tool to the running platform, so what an author publishes is what a session gets.

Simpler to use than it was

We worked directly with the client's team on how people interact with the platform, so the rebuild left it easier to work with rather than only cheaper to run.

Why finance work sets the standard

Finance-critical automation is the most demanding environment to build in, because there is no acceptable error rate that gets waved through. A reconciliation that is nearly right is a reconciliation that is wrong, and it will be found by an auditor rather than a user.

Everything built here inherits that constraint: idempotent operations, dry-run modes, diff-based writes, audit trails, and rollback paths as defaults rather than hardening added later.