Use casesA scale-up

Ferrant: six prompt files became one governed memory.

Ferrant is 240 people and 120 engineers in six teams, each with its own prompt file, one of them 900 lines long. The payments team ran memco first, on the Team plan. A quarter later the whole company was on a governed tenant with the same memory, and support was reading engineering's lessons.

Organisation
Payments software, 240 people, 120 engineers in six teams, a support desk and a data team
Agents in use
Claude Code, Cursor and Copilot in engineering; Claude in support
Tools connected
GitHub, Jira, Zendesk, Sentry, Slack
First team
Payments, 24 engineers, on the Team plan for a quarter
Memory networks
Ferrant, engineering, support, one per team, personal
Identity and residency
Okta single sign-on, dedicated EU tenant from the second quarter
Time to first proven value
Day nine

01Starting point

Where Ferrant started

Ferrant's six engineering teams each kept a prompt file in their own repo. The payments team's was 900 lines long and nobody knew which lines still held. The onboarding team's had not been edited in four months. The platform lead read a study that found files like these cost a fifth more in tokens and barely helped, and recognised every symptom: agents followed stale instructions faithfully, and the files were maintained in the hour before a release, if at all.

Every session started from zero. An agent on the billing repo learned that the staging database needed a warm-up query before migrations would run; the lesson lived in one engineer's terminal history. The next week an agent on the invoicing repo hit the same timeout and the same engineer wrote the same fix. Reviewers rejected a third of agent pull requests for mistakes someone else had already corrected, and the support desk's agent in Zendesk kept quoting a refund policy that engineering had changed two releases earlier.

The cost was reviewer hours and a growing distrust of the agents. The payments team measured a fortnight: 34 percent of agent pull requests returned for a known correction, a 900-line file that two engineers maintained for about ninety minutes a week, and a weekly Slack thread about what the agents had got wrong that had become the team's most-read channel.

02Day one

Day one

The payments team started on the Team plan with 24 seats and no procurement, in an afternoon. The rest of the company joined a quarter later on a governed tenant, and the memory came with it.

  • Claude Code, Cursor and Copilotmemco plugin on 24 machines and an MCP connection for Copilot, signed in through Okta from the first day so nothing had to be redone when the tenant changed.
  • GitHub, Jira and SentryPull request outcomes, tickets and incidents attach to insights as evidence.
  • SeedThe 900-line prompt file became 70 insights with scope and source. About 200 lines were found to be dead or contradictory and were dropped. The file was deleted in week two.
  • ZendeskAdded in the second quarter: the support desk's drafting agent connected over MCP so it could read the company network's policies.
  • TenantAt the end of the first quarter, Ferrant moved to a dedicated EU tenant with role-based access, audit export and promotion workflows. The payments team's networks and insights carried over unchanged.
  • SparkTeam networks administered by each team lead; the company and engineering networks by the platform team.
  1. FerrantCompany policies: refunds, data handling, incident conduct, what never enters memory.Every agent, including the support desk's.
  2. EngineeringConventions that hold across teams: idempotency, retries, the staging warm-up, how reporting reads data.Every engineer's agents.
  3. SupportDesk procedure, escalation routes, how to cite a known defect.The support desk's agent and reviewers.
  4. Team networks, one per teamRepo conventions, fixtures, dead ends, the corrections reviewers make.Engineers on that team.
  5. PersonalEach person's own preferences.That person's agents only.

fig. 01Scope map

Ferrant memory networksNested scopes: the Ferrant network holding company policies, the engineering network inside it, six team networks inside that with payments as the first team, and the support desk reading the company network only; promotion to engineering needs two teams and a named lead.FERRANTpolicies; read by support tooENGINEERINGcross-team conventionsTEAM NETWORKS, ONE PER TEAMPaymentsBillingInvoicingOnboardingBatchPlatformPersonal · one per personPROMOTIONTWO TEAMS AND A LEADReads inherit downward · Writes stay local · Support reads the company network only
Ferrant memory networksNested scopes: the Ferrant network holding company policies, the engineering network inside it, six team networks inside that with payments as the first team, and the support desk reading the company network only; promotion to engineering needs two teams and a named lead.FERRANTpolicies; read by support tooENGINEERINGcross-team conventionsTEAM NETWORKS, ONE PER TEAMPaymentsBillingInvoicingOnboardingBatchPlatformPersonal · one per personPROMOTIONTWO TEAMS AND A LEADReads inherit downward · Writes stay local · Support reads thecompany network only
Support reads policies in the Ferrant network, not engineering's working notes. The dashed route is promotion: an insight reaches the engineering network after it has held on two teams and a named lead approves it.

03The first weeks

The first weeks

Week one on the payments team added about four percent to token use and returned the seed. The first live reuse came on day nine, and the lesson that taught the company how to promote came on day twenty.

fig. 02Deployment timeline

Ferrant: one team on the Team plan to everyone on a tenantTimeline across two segments: the payments team's first weeks from the baseline fortnight to its first reuse on day nine and the wrong promotion on day twenty, then weeks twelve to sixteen when the company moves to a dedicated tenant, the refund policy reaches support and the error tracker is replaced.BASELINE FORTNIGHTPAYMENTS TEAM, TEAM PLANDEDICATED TENANT, SIX TEAMS AND SUPPORTDAY 9First reuse, invoicingteamDAY -14Baseline on thepayments teamDAY 0900-line prompt filebecomes 70 insightsDAY 4Staging warm-up lessonDAY 20Wrong promotion;two-team ruleDAY 28Warm-up promoted toengineeringDAY 84Moved to the tenant;memory unchangedDAY 98Refund policy reachessupportDAY 112Error trackerreplaced; nine retired
Ferrant: one team on the Team plan to everyone on a tenantTimeline across two segments: the payments team's first weeks from the baseline fortnight to its first reuse on day nine and the wrong promotion on day twenty, then weeks twelve to sixteen when the company moves to a dedicated tenant, the refund policy reaches support and the error tracker is replaced.Baseline fortnightPayments team, Team planDedicated tenant, six teams and supportDAY -14Baseline on the payments teamDAY 0900-line prompt file becomes 70 insightsDAY 4Staging warm-up lessonDAY 9First reuse, invoicing teamDAY 20Wrong promotion; two-team ruleDAY 28Warm-up promoted to engineeringDAY 84Moved to the tenant; memory unchangedDAY 98Refund policy reaches supportDAY 112Error tracker replaced; nine retired
Two segments with a break between them. The filled mark is the first reuse: the staging warm-up one engineer rewrote every week, run unprompted by another team's agent.
  • Day 4. An agent's migration against staging times out, the fourth time that month.Run the warm-up query in scripts/warm.sql before any migration against staging, or the first statement times out.Day nine: an agent on the invoicing repo runs it unprompted and cites the insight. First reuse. By week four it has held on four teams and is promoted to the engineering network.
  • Day 7. An agent builds a retry loop by hand for an outbound webhook.Outbound webhooks retry with exponential backoff capped at five attempts. The helper in lib/retry handles it.Hand-rolled retries stop appearing in review. The helper's owner attaches its test suite as provenance.
  • Day 12. A revenue report reads from the nightly snapshot and the numbers are a day stale in front of the CFO.Revenue reporting reads from the live replica. Every other reporting query reads from the nightly snapshot.Scoped to the data team's reporting repos. The data lead approves it herself.
  • Day 20. A payments-team insight about idempotency keys is promoted to the engineering network, where it is right for the API services and wrong for the batch jobs.Every endpoint that creates a record accepts an Idempotency-Key header and returns the original result on a repeat. Batch jobs use the run id instead.Two batch pull requests fail and a reviewer on the batch team says he has stopped reading the agent's reasoning. Scoped by service type. The platform team writes the promotion rule: nothing reaches the engineering network until it has held on two teams and a named lead approves it. The batch reviewer is one of the two approvers for the next month.
  • Week 14. The support desk's agent, newly connected, quotes the refund rule from two releases ago.Refunds within 30 days are automatic. After 30 days, route to the billing queue with the order id.Written as a policy in the company network by the billing lead. Support's agent reads it the same day. For the first time, a rule engineering changed reached support without a Slack announcement.
  • Week 16. Ferrant replaces its error tracker.Search Jira for the error string before opening a ticket. Attach the tracker link to the ticket, not the pull request.Nine insights naming the old tracker are retired in a day with the migration ticket as provenance. The prompt files would have carried its name for a year.

04Governance

Governance

  • Team leads own team networksEach team's validation rules are its own. The platform team owns the engineering and company networks and the rule for reaching them.
  • Promotion needs two teams and a leadAn insight reaches the engineering network after it has held on two teams and a named lead approves it. The day-twenty incident is the reason. Company policies are written by people and never promoted from below.
  • Support reads policies, not engineering's working notesThe support desk's agent reads the company network and its own. It does not read team networks, and engineering does not read the support network.
  • Provenance on every insightEach insight links to the pull request, ticket, incident or policy it came from, with a record of where it has held.
  • Identity, residency, audit and retentionOkta groups map to networks, so access follows the org chart. Memory sits in a dedicated EU tenant from the second quarter. Every read, write, promotion and retirement is exportable. Insights without reuse in a quarter are reviewed by their team lead.

fig. 03The write path

From one team's terminal history to the engineering networkSwimlane showing a payments agent timing out on a staging migration, proposing the warm-up lesson, memco serving it to the payments team after three reviewed pull requests, the invoicing team's agent running it unprompted on day nine, and a named lead promoting it to the engineering network once it has held on four teams.PAYMENTS AGENTmemcoINVOICING AGENTPLATFORM LEADTimes out on astaging migrationday 4, fourth timeProposes: runwarm.sql firstServed to thepayments teamRuns itunprompted oninvoicingday 9TWO TEAMS, A LEADHeld on fourteams; promotedServed to everyengineer
From one team's terminal history to the engineering networkSwimlane showing a payments agent timing out on a staging migration, proposing the warm-up lesson, memco serving it to the payments team after three reviewed pull requests, the invoicing team's agent running it unprompted on day nine, and a named lead promoting it to the engineering network once it has held on four teams.PAYMENTS AGENTTimes out on a staging migrationday 4, fourth timePAYMENTS AGENTProposes: run warm.sql firstmemcoServed to the payments teamINVOICING AGENTRuns it unprompted on invoicingday 9PLATFORM LEAD · TWO TEAMS, A LEADHeld on four teams; promotedmemcoServed to every engineer
Solid fill is the reuse that counts. The dashed node is the promotion rule written after day twenty: two teams and a named lead before anything reaches the engineering network.

05What compounded

What compounded

The payments team's quarter was the case for the rest of the company. The second quarter's readout covered all six teams and the support desk.

MetricMovementWhy
First-pass acceptance66% to 84%The five teams still on prompt files moved by one or two points in the same period.
Cross-person or agent learning gainFour teams in a monthFour teams reused the staging warm-up in a month. The lesson one engineer had rewritten every week was learned once. By the second quarter, a third of reused insights came from a different team.
Repeat-error rateOne in three to one in twelvePull requests returned for a known correction, on the payments team by day thirty. The weekly Slack thread about agent mistakes went quiet in week five.
Time to an accepted resultDown 27%On tickets touching staging, retries or reporting, measured from ticket open to merge.
Adaptation speedSame dayThe refund rule reached support the day it changed. Before memco, engineering announced policy changes in Slack and support found out when a customer complained.
Improvement with experienceClimbing, six teamsMoving from the Team plan to the governed tenant changed nothing in the memory. The scopes and insights carried over.

fig. 04Connected and unconnected

First-pass acceptance, baseline to the end of the quarterSlopegraph: the payments team rises from 66 to 84 percent of agent pull requests accepted without a known correction, while the five teams still on prompt files move from 67 to 68.BASELINEEND OF Q167%66%84%68%Payments team, connectedFive teams on prompt files
Agent-opened pull requests accepted without a known correction. Baseline fortnight and the end of the first quarter.

fig. 05Costs before it pays

Pull requests returned for a known correction, week by weekLine chart: pull requests returned for a correction someone had already made fall from 34 per hundred at baseline to 8 by week four, with week one nearly unchanged.010204034BASELINE318WK 1WK 2WK 3WK 4Q2Returned for a known correction, per 100
Agent pull requests returned for a known correction, per hundred, on the payments team. Reads added four percent to tokens in week one and returned the seed.

06What it cost

What it cost

  • Setup timeA fortnight of baseline on the payments team. One afternoon to connect Okta, the plugin, GitHub and Jira. One day to turn the 900-line prompt file into 70 insights. Half a day in the second quarter to move to the dedicated tenant.
  • Who ran itTwo platform engineers part-time in the first quarter, one from the second. Team leads spend about an hour a week on their review queues. No new hires.
  • Plan and tokensThe Team plan for 24 seats at $50 a member for a quarter, then an enterprise agreement for 120 engineers and the support desk with the EU tenant, role-based access and audit export. Reads added four percent to token use; the bill per merged pull request fell 22 percent in the first quarter because agents stopped rediscovering fixes and reviewers stopped sending work back.
  • What it replacedSix prompt files, the ninety minutes a week two engineers spent on the longest of them, a Confluence page nobody updated, and the weekly thread on what the agents got wrong.

See how your teams' lessons compound.

Join the waitlist

More deployments.

All use cases