Shipping AI, Not Designing Around It

The viewer-services team answers letters, emails, and social messages — often long, often emotional, sometimes in crisis. I built them a copilot: paste in the message, get a draft grounded in the service handbook — its wording, its formatting, its standard phrases.

Three decisions defined it. Restricted-topic rules are enforced in the output, not left to the agent to remember. Crisis messages don't get drafted at all — they escalate to a person. And every send decision stays human; the tool never sends.

Rollout was designed as carefully as the tool. I tested it on myself first, then ran one-on-ones — no group demo, no mandate. It stayed fully optional, with the team lead asking only that people try it and share feedback. The tool then earned its place on the hard cases rather than the easy ones: one of the most sceptical senior agents tried it on a letter that would normally cost hours — multiple parallel topics, strongly argued criticism — and shipped a good response in minutes.

Where it landed: complex multi-topic letters answered in minutes instead of hours. Temporary staff write in the company's voice from day one. The sceptics use it daily and told me so unprompted.

Bibel TV runs bi-monthly fundraising campaigns, and each one needs supporting material across several formats — in-app notifications, web banners, short video scripts — all carrying the same message in the same voice, produced under time pressure by people who aren't copywriters.

I built a web application that generates them. The interesting part isn't the generation; it's what the generation reasons from. The organisation's formatting guidelines, its accumulated fundraising knowledge — much of it previously held in people's heads rather than written down — and its house voice became the system's context. The interaction is a multi-turn clarifying-question loop rather than single-shot prompting: the tool asks what it needs to know about the campaign before producing anything, which is what makes the output usable rather than merely fast.

Analysis, prompt architecture, prototype, production skill — no engineering hand-off at any stage.

The institutional knowledge was always the asset. AI just made it addressable.

That's the pattern across both systems. Neither tool is clever on its own. Each works because the organisation's own knowledge — the service handbook, the fundraising guidelines, the things people knew but had never written down — became the context the model reasons from.

I stopped shipping specs. The new experience was designed first as a working web prototype, then as an Android prototype, both built with AI-assisted coding against real production APIs. Engineering now consumes that prototype code directly — roughly 70% of it reaches production with minor modification, and iteration collapsed from days through spec-and-handoff to hours in working code.

One token repository — DTCG standard, three tiers from global primitives through semantic to component, built with Style Dictionary, synced live to Figma and Android with iOS and web ready, architected to support server-driven UI. One commit propagates to every platform. Consistency enforced by structure rather than coordination.

None of this was a mandate. It worked because adoption was voluntary and the tools were introduced where they'd face the hardest case first. The constraint lives in the tool; the choice stays with the person. That's the model I'd bring to any organisation trying to become AI-native — the technology is the easier half.