Published June 23, 2026
Recovery is a two-step job — earn the attention back, then convert it — and a general-purpose CRM stack is built for neither. Inside the two engines, and how the model that runs them is built.
1
The recovery problem a CRM stack cannot solve
Recovery is not the same job as Grow or Protect, and treating it as one is why most win-back fails. By the time a customer is in the lost column, the attention is gone. The channel is still technically open — the email still delivers — but the customer has stopped listening. Sending a sharper offer down a channel no one reads does not recover anyone; it just trains the customer to ignore you faster.
A general-purpose CRM stack is built to do one thing well: send. It pushes batch campaigns through owned channels and measures opens and clicks. That is delivery, not recovery. Asked to win back the lost, it does the only thing it knows — it sends, and when nothing happens it discounts harder, which accelerates exactly the loss it is trying to reverse.
Recovery is two steps, in a fixed order: attention first, transaction second. Earn the right to be heard again, then ask for the sale. A delivery tool skips the first step entirely, because it has no engine for it. Lined up against what recovery actually requires, the gaps in a send-first stack are structural, not incidental:
| What recovery requires | What a CRM stack does instead |
| Re-earn attention before asking | Built to send the next campaign |
| Sequence attention, then transaction | Optimised for immediate response |
| Decide customer-by-customer | Runs on rules and broad segments |
| Learn across many brands | Each brand isolated in its own instance |
| Be paid on the recovery it proves | Charges a fixed fee regardless |
You cannot retarget your way back into a relationship. You have to earn the attention first — and that is a job for two purpose-built engines, not one general-purpose stack.
2
Atrium — the engine that earns the attention back
Atrium is the attention engine, and in recovery it is pointed at the lost. It has three parts. NeoMails are the Relate vehicle — relationship content that stands on its own, independent of any transaction; email today, extensible to WhatsApp and beyond. ActionAds are the monetising unit that can sit inside a NeoMail. NeoNet is the cooperative network that places those ActionAds across brands.
Recovery is a two-step job: Atrium earns attention back; Meridian converts it.
On a lost customer, Atrium does the opposite of what a CRM stack does. It does not lead with an offer. It leads with utility, recognition and relevance — a reason to open that is not a discount — because the first job is to rebuild reachability, not to extract a sale. Only once a customer is opening and engaging again has Atrium produced anything worth converting.
Atrium is also designed to pay for itself, and it is worth being honest about the status of that claim. The intent is that ActionAds fund the NeoMails on a ZeroCPM basis. That is a design goal the early pilots must prove, not a fact to assume — the first real test is simply whether attention yield covers a meaningful share of sending and content costs. The output of Atrium is not a sale. It is a customer who is reachable and paying attention again — the raw material the second engine needs.
3
Meridian — the engine that converts restored attention
Meridian is the conversion engine. It is a proprietary model paired with an Alpha Agent that turns earned attention into transactions. It is the part of Progency that is never sold and never shown — but it is not magic, and it is worth being precise about what it does even while keeping how it does it closed.
Meridian decides. It prioritises which lost customers are worth recovering at all; it decides, for each one, whether the next move is to ask for more attention or to ask for a transaction; it selects the content, the offer, the channel and the timing; it learns from what happened across cohorts; and it writes every decision and every outcome back to the Context Graph. That last habit is what makes the system improve rather than merely run.
What ships to the brand and what stays inside are two different things. The in-house team, on CRM 2.0, gets the M-Agents — Insights, Audience, Content and Decisioning — visible, useful, and theirs to run. Meridian itself stays in the black box. The analogy is a quant fund: the model is the secret the fund is paid for, not a product it ships. A brand buys Meridian’s results through Progency; it does not licence Meridian, any more than an investor licences the fund’s strategy.
4
Building Meridian — the data substrate
Recovery is a per-customer sequential decision problem: for each lost customer, a series of choices over time, each depending on what happened before. A campaign tool has none of the three things that problem needs — state, per-customer models, and a memory of outcomes. Meridian is built around supplying all three.
State and memory live in three Context Graphs, with the intelligence substrate above and the Alpha Agent on top.
State and memory live in three Context Graphs. The Customer Context Graph holds who each customer is. The Product Context Graph holds the catalogue, affinities and substitutes. The Decision Trace Graph holds every decision the system has made, with its context and its outcome. The Decision Trace is the important one: it is both the recovery memory and the auditable record of actions to outcomes that the commercial model depends on.
Beneath the graphs sits the intelligence substrate that lets recovery reason about one customer at a time. BrandTwins are per-customer models, maintained at scale by TwinFactory and built on ArtificialPeople — the world-model behavioural archetypes that give a twin its priors before much first-party data exists. This is the layer that makes N=1 recovery possible: a decision tuned to this customer, not to the segment they happen to fall in.
5
Training the Alpha Agent
The Alpha Agent is a decision policy, not a content generator. Its output is choices: who to work, when to ask for attention versus a transaction, what to send, when, and through which channel. Building it is a question of how a policy like that is trained — and the honest answer has four parts.
First, the cold start. With no history, the agent is bootstrapped by behavioural cloning — it learns to imitate the best human operators. This is the quiet purpose of the Martech Growth Engineer pilots: every decision an MGE makes, and the outcome it produced, is a training example. The humans running today’s recoveries are writing the training set for the machine.
Second, the reward. The agent is not trained to maximise opens or clicks, which are easy to game and weakly tied to money. It is trained against measured Alpha — the holdout-verified lift, the same three-arm control that prices Progency commercially. The number that pays Progency is the number that trains its agent. That makes this closer to offline reinforcement learning and contextual bandits than to ordinary supervised learning.
A compounding loop: act, measure the lift against a holdout, write the outcome, update the policy — a little better each time.
Third, simulation. Live experiments are slow and costly, so candidate policies are rehearsed offline first. ArtificialPeople provide a sandbox to score a policy before it is deployed, and BrandTwins let the agent ask ‘what would this specific customer do if…?’ at N=1. Simulation reduces the cost and risk of the cold start — but it only approximates reality, so the live holdout remains the ground truth that overrides any simulated result.
Fourth, cross-brand learning. Because every brand’s recoveries write to the same kind of Decision Trace, the agent learns patterns that hold across many brands — more brands make recovery sharper for all of them, done privacy-by-design with federated patterns rather than raw personal data crossing brand boundaries. That single design choice is both the moat and the privacy answer: the network effect lives in the learned patterns, not in shared customer lists.
| The build, in one line. The same holdout that prices Progency is the reward that trains the agent — and the MGEs running today’s pilots are writing tomorrow’s training set. |
6
Why two engines beat one stack
A general-purpose CRM stack is asked to acquire, grow, protect, recover and report — and is therefore optimised for none of them. Progency does one job with two engines tuned for exactly that job, and the two-step sequence is the whole reason it works. Atrium does the step the stack skips — re-earning attention. Meridian converts what Atrium restores. Neither engine alone is enough; sequenced, they recover customers a delivery tool cannot.
| Old win-back | Progency recovery |
| Send the offer | Earn the attention first |
| Discount harder | Rebuild relevance |
| Measure campaign response | Measure attention restored, then conversion |
| Retarget through paid if no response | Recover before falling through to adtech |
And the honest limits travel with the design. Recovery needs enough lost-customer volume to run a control group. It works where customers are identifiable. Atrium’s self-funding economics are a goal the pilots must prove, not a settled fact. NeoNet is emerging, not finished. And recovery sits between CRM and adtech — it replaces neither.
* * *
The CRM stack was built to send. Progency was built to recover — and recovery, it turns out, is a different machine: one that earns attention before it asks for a sale, decides one customer at a time, and is paid only for what it can prove it brought back. Never Lose Customers. Never Pay Twice. Never Pay Fixed.
