Use casesAn enterprise

Build shared memory
for the agentic enterprise.

Greyfriars Mutual is modernising a twenty-year-old policy administration estate with 600 engineers, a third of them from a systems integrator. The agents were already on the programme. An eight-week pathfinder on one named workflow, in the insurer's own UK cloud, measured what they learned and converted to a programme licence.

Organisation: UK life and pensions insurer, 9,000 staff
Programme: Policy administration modernisation, 600 engineers including a systems integrator's teams
Agents in use: Claude Code, Copilot and Codex in engineering; Claude on the service desk's runbooks
Tools connected: GitHub, Jira, Confluence, ServiceNow, the CI platform
Pathfinder: Eight weeks, the policy servicing batch migration, written baseline and success criteria
Memory networks: Programme, platform, one per workstream, service desk, personal
Residency: Customer-hosted in the insurer's UK cloud. Nothing leaves the programme boundary.

01Starting point

Where Greyfriars started

Greyfriars is moving two million policies off an administration platform built twenty years ago, where the code and the business logic are the same thing: COBOL batch jobs, a Java layer bolted on in 2011, and a service team of fourteen people who know why each exception exists. Six hundred engineers work on the programme, a third of them from a systems integrator. Agents were already on every machine before anyone asked whether they were learning anything.

They were not. An agent migrating a batch job rediscovered, every session, that the annuity run has to finish before the valuation extract starts, that three fields in the policy record mean different things before and after a 2014 product change, and that the integrator's own tooling expects a particular branch layout. The service team corrected the same assumptions in review week after week. The programme director counted a fortnight on the batch migration workstream: 37 percent of agent changes returned for a correction the service team had already given, and the team's two most senior members spent half their week in review.

The cost was the one the programme already had too much of: the service team's time, which the migration depended on and which retired with them. Two of the fourteen were leaving within the year. The CIO's question to finance was not whether memory was a good idea. It was what a licence bought that the integrator's internal tool did not, and nobody could answer it without measuring. The pathfinder was shaped to answer it.

02Day one

Day one

memco was deployed into the insurer's own UK cloud in the first week, with the integrator's teams inside the same boundary and nothing else. The pathfinder clock started once the baseline fortnight, the success criteria and the route to production were written down and signed.

DeploymentCustomer-hosted memco in the insurer's UK cloud account, behind its identity provider, inside the programme's existing security boundary. The integrator's engineers use the insurer's identities.
Claude Code, Copilot and Codexmemco plugin on every programme machine and an MCP connection for the hosted agents, with reads scoped by workstream membership.
GitHub, Jira and the CI platformPull request outcomes, tickets and pipeline results attach to insights as evidence. A lesson about a batch job links to the run that proved it.
ServiceNow and the service deskThe service desk's runbook assistant connected over MCP, so incidents and known errors become insights the engineering agents read.
SeedThe service team spent three days turning its tacit knowledge into 120 insights: the batch dependencies, the 2014 field semantics, the exceptions and why they exist. Each carries the name of the person who vouched for it.
Baseline and criteriaA fortnight measured before connection: repeated corrections, tokens per accepted change, review rounds, rework. Written success criteria, a comparison against the integrator's internal tool and a production conversion route agreed before week one.

ProgrammeProgramme standards, the migration method, security rules, what never enters memory.Every engineer and agent on the programme, insurer and integrator alike.
PlatformThe legacy estate: batch dependencies, field semantics, environment quirks, the integrator's tooling conventions.Every engineering workstream.
Workstream networksEach workstream's conventions, fixtures, dead ends and the service team's standing corrections for its subsystems.Engineers on that workstream.
Service deskRunbooks, known errors, incident patterns and what the desk may promise.The desk's assistant and the platform network through promotion.
PersonalEach engineer's own preferences.That engineer's agents only.

fig. 01Scope map

The programme is the boundary: the integrator's engineers use the insurer's identities and see only this. The dashed route is promotion, with one approver from each organisation.

03The first weeks

The first weeks

The seed meant week one was not empty, but reads still added nine percent to token use before they paid. The first reuse of a lesson learned from live work came on day eight, from an integrator engineer's agent reading an insurer engineer's correction.

fig. 02Deployment timeline

Spacing is proportional to elapsed days. The filled mark is the first reuse: an insurer engineer's correction applied by an integrator engineer's agent.

Day 3. An agent schedules the valuation extract before the annuity run and the test environment produces a wrong valuation.The annuity run must complete before the valuation extract starts. The dependency is not in the scheduler; it is in the data.Vouched for by the service team lead. Day eight: an integrator engineer's agent reorders the jobs unprompted and cites it. First reuse across the two organisations.
Day 6. An agent treats the policy status field the same for policies written before and after the 2014 product change, and a reviewer catches it for the ninth time that month.For policies written before March 2014, status code 4 means paid-up. After, it means suspended. Branch on the inception date.The correction that defined the programme's review load stops recurring. It had never been written anywhere an agent could read.
Day 12. An insight about the integrator's branch layout is promoted to the programme network, where it is wrong for the insurer's own repos.The integrator's branch layout applies to the integrator's repos. Insurer repos use trunk and release branches. An insight that names a convention names whose repos it holds for.Two pipelines fail and an insurer engineer says the agents have started making the integrator's mistakes. Scoped by repo owner. The programme office writes the promotion rule: nothing reaches the programme network without an approver from each organisation.
Day 19. The service desk closes an incident whose root cause was a batch job the engineering agents had been changing.The premium collection job fails silently when the bank file arrives empty. Check the file size before the run, not the return code after it.Promoted from the service desk network to the platform network by the desk lead. The engineering agents read it the next day; the fix ships with the insight as provenance.
Week 5. The programme's approved model changes.Every insight serves to the new model exactly as it did to the old.Nothing is retuned. The 120 seeded insights and the 90 learned since are read by the new model from its first session. The CIO notes it in the readout as the answer to a question procurement had asked about lock-in.
Week 7. A subsystem is decommissioned as the migration passes it.The old commission calculation subsystem is retired from 1 December. Lessons about it are archived, not served.Forty-three insights are archived in a day with the decommission ticket as provenance. They remain in the audit record and leave the agents' reads.

04Governance

Governance

The programme is the boundarymemco is licensed for one named programme and runs inside its security boundary in the insurer's own cloud. The integrator's engineers use the insurer's identities and see only the programme. Nothing is readable outside it.
Promotion needs both organisationsAn insight reaches the programme or platform network only with a named approver from the insurer and one from the integrator. Workstream networks serve automatically after three reviewed changes.
The service team vouchesSeeded knowledge carries the name of the service team member who vouched for it. When one of them leaves, what they knew stays, with their name on it.
Retirement follows the migrationWhen a subsystem is decommissioned, its insights are archived with the ticket as provenance. They stay in the record for audit and leave the agents' reads.
Residency, audit and exitCustomer-hosted, UK only, exportable audit of every read, write, promotion and archive. If the licence ends, the programme's memory exports in a portable format and remains the insurer's.

fig. 03The write path

Seeded and learned insights carry the name of the service team member who vouched for them. The dashed node is the promotion rule: one approver from each organisation.

05What compounded

What compounded

The week-eight readout set the pathfinder workstream against its baseline fortnight, against the two unconnected workstreams, and against the integrator's internal tool on the same tasks. The programme licence followed, and two further programmes joined under the same agreement in the following quarter.

Metric	Movement	Why
First-pass acceptance	63% to 81%	On the batch migration workstream. The two unconnected workstreams moved by under two points. The success criterion was 75 percent.
Repeat-error rate	37% to 6%	Service-team corrections repeated, as a share of agent changes. The 2014 status-code correction alone accounted for a fifth of the baseline. It recurred zero times after day six.
All-in cost per accepted result	Down about two-fifths	Tokens per accepted change, counted after reads. Against the integrator's internal tool on the same tasks, the connected agents needed fewer review rounds and less of the service team's time, which was the comparison finance had asked for.
Cross-person or agent learning gain	Day eight, both organisations	Insurer and integrator agents reused each other's lessons from day eight. By week eight, half of reused insights crossed the organisational line in one direction or the other.
Safe autonomous completion	Zero, by design	On the batch migration. Every change to a batch job still has a human approval. The programme's metric is review rounds per accepted change, which fell from 2.4 to 1.3.
Improvement with experience	Unchanged, model changed	The approved model changed in week five and nothing was retuned. Two service team members retired in month five and their vouched insights are still served.

fig. 04Connected and unconnected

Agent changes accepted without a known correction. Baseline fortnight and week eight. The dashed rule is the pathfinder's written criterion.

fig. 05Costs before it pays

Index, baseline fortnight = 100, counted after reads. Week one cost nine percent more than the baseline even with the seed.

06What it cost

What it cost

Setup timeA week for the customer-hosted deployment and identity. A fortnight of baseline measurement. Three days of the service team's time to seed 120 insights. The criteria, the comparison and the conversion route were agreed before any of it.
Who ran itOne insurer platform engineer, one integrator lead and the programme office, with the service team lead approving platform insights for about three hours a week in month one.
Licence and tokensA paid eight-week pathfinder, then a named programme licence with unlimited users and agents inside the programme, paid annually. Reads added nine percent to token use in week one; by week eight tokens per accepted change were down two-fifths, and the service team's review hours were down by half.
What it replacedFourteen people's heads as the only record of why the estate behaves as it does, the integrator's prompt packs, and the review afternoons the migration could not afford.