AI, data and automation enablement across a global agency

Built with their teams, not around them

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.

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. We build the other way round, so the people who will own each system help to shape it.

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.

We measure an engagement like this by what the client can still maintain, change and build on once we 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. Today it spans four finance systems, the identity and provisioning pipelines, the Cloud Run and BigQuery estate, and the plumbing beneath a skill platform carrying around 600 production skills.

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. Where the skills packages fit in a wider rollout is covered in our guide to rolling out Codex and Claude Code across an engineering organisation. If your engineers work in GitHub Copilot rather than Claude Code, our side-by-side of Claude Code and GitHub Copilot compares where each runs, how each is billed and the admin controls each offers.

Verifier-gated automation

Managed-agent workflows for finance-critical and high-stakes operational tasks, built so deterministic checks decide what proceeds, the pattern behind our agentic workflow design.

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. We modelled it on token consumption, and a member of the client's finance team reviewed and accepted it.

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.

It was not in a brief. It is the kind of problem you only see from inside the system, and we raised it before it became 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. A skill's description is what tells the assistant when to load it, which our guide to turning a chat into an AI skill explains for Claude and ChatGPT.

The rebuild followed the structure the Anthropic SDK already defines, rather than a shape of our own. Building on the vendor's structure rather than beside it is the approach described in our AI harness and platform engineering work.

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.

Dry runs and rollback paths are also among the controls our guide to deciding where AI agents fit in a business sets out for any agent that touches a real system.