YuLife wrote the knowledge down before it let people build agents

A licence can be on for every desk and the answer can still live in someone's head. The question is asked. The file it needs is in a chat, or it was never written down. The tool answers. The person then checks a source the tool never saw.

Jonathan Roomer and Giles Boon-Williams's account is from the Workforce track at aiblLIVE London on 20 October 2026. Roomer co-founded YuLife, the insurer that rewards healthy behaviour. Boon-Williams, principal engineer, leads the engineering behind the rollout. They describe a company of about 140 people in which 94 percent use AI in a given week. The rest, they say, is roughly the share on leave or ill, about 6 percent. The page says those figures are as stated on stage.

The order is the part most rollouts invert. People began by asking everyday questions, then received answers grounded in the company's own knowledge, then built skills of their own. Agents came last. Champions sat in every team, with Slack channels, team workshops and one enablement role beside them. Boon-Williams's line is the dependency. "Agents are only as good as the foundations that they're built upon: the technology, the skills, and the people that really understand how they work."

What the tool could read had been scattered across Drive, Slack, email, meeting notes and people's heads. YuLife moved that into Markdown files in Git, with GitBook on top, so a person and the tool share one source. A weekly bot drafts updates from code changes, and the documentation goes live with the product. They want less content, written better, not a pile of transcripts. A semantic layer, the page says, is what helps the tool read the data correctly. The layer itself is not shown.

Building is not reserved for engineering, and it is not unreviewed. Staff package a way of working as a skill. Engineering reviews it before publication to a Claude plugin marketplace organised by team. Predictable work runs as fixed steps and code. Experiments stay in a sandbox. Reviewer judgment is treated as a skill, so a builder can check the work first. "We wanted to make the predictable parts boring and the clever parts safe." The clock they attach is legal. A contract review that took a week now takes hours. A marked-up contract returned within a day has pulled cycles from months down to weeks. In engineering, a shared strategy base lets people propose ideas that fit the company's direction. The page names two failures the longer note takes up, reviews that did not scale and data that lacked meaning, and does not describe either one here.

1. Keep agents at the end of the sequence they used. Questions first, then answers drawn from the company's own knowledge, then skills, then agents. Champions in every team belong in that sequence. A note sent after the agents are already live is a different programme.

2. Put the knowledge where a person and the tool read the same file. Markdown in Git, GitBook on top, and a weekly bot drafting from code changes. Drive, Slack, email, notes and memory were the map they left.

3. Let someone outside engineering package a way of working, and review it before the marketplace. Predictable work stays as fixed steps and code. The trial stays in a sandbox. In this account, reviewer judgment is a skill, not a courtesy added at the end.

4. Keep the legal clock on the legal work. Hours, where a review had taken a week. Weeks, where a cycle had taken months, because a mark-up can come back within a day. The 94 percent is weekly use in a company of about 140. The page does not turn it into a saving, and it does not say the other desks moved.

An AI training session is a practical place to take one workflow a team already repeats, write the knowledge it depends on into a single source, and name who reviews a skill before anyone is allowed to publish it.