The problem
A SaaS company with about 1,400 active accounts had renewal data spread across a CRM, a data warehouse, a product-usage store, and the support tool. Churn was usually visible in hindsight — the signals were all there, just not in one place and not in time. The revenue team wanted a weekly read on which accounts were drifting, early enough to act.
The design principle
The agent produces a brief for a human; it does not take an action. It never emails a customer, never opens a task on their behalf, and never changes a field in the CRM beyond appending a note. The account team decides what to do. That constraint is also what made the system safe to run unattended.
Architecture
The system runs in TaskBreaker's infrastructure on a schedule, with event triggers for big signal changes (a support escalation, a usage cliff).
- Scheduled and event-driven workers evaluate accounts in batches.
- MCP servers for the CRM, the warehouse, and the product-usage store — all read-only except a single "append note" capability on the CRM.
- A fixed eval suite: a few hundred past accounts labelled with what actually happened — renewed, churned, expanded — that the agent is scored against on every change.
- OpenTelemetry tracing: one trace per account-evaluation, holding every signal pulled, the model's reasoning, and the risk call.
What the agent watches
Per account: license utilisation and its trend, active-user change, feature adoption against the plan, support ticket volume and sentiment, escalations, invoice history and payment lateness, executive-sponsor activity, and days to renewal. It weighs them into a risk level with a short rationale that names the two or three signals doing the work.
The risk brief
For each at-risk account the AE and CSM get: the risk level and trend, the signals behind it, what changed since last week, and a suggested play drawn from a playbook — not sent, just suggested. Briefs post to the account team's channel with a thumbs-up/down so we learn which ones were useful. Median lead time on a brief that correctly called an at-risk account was about 38 days before the renewal date.
How we know it works
This is the part most agent projects skip. The eval suite of labelled past accounts is scored on every prompt or model change, and the score is alerted on — a drop blocks the release. Against the back-test the agent runs about 0.6 precision and 0.8 recall, deliberately tuned to catch most real risk and tolerate false positives, because a human triages every brief. The dashboards the team actually watches are: lead time on correct flags, precision and recall against closed outcomes, brief-usefulness rating, and cost per account per month. Every churn the agent missed becomes a new labelled case in the suite, so the same miss is caught next time.
Guardrails
Read-only everywhere except appending a CRM note. No customer contact path exists in the system. A spend cap per evaluation run and a step budget per account. Every brief carries its trace, so an AE can see exactly why an account was flagged. An operator can pause the schedule without a deploy.
What it costs to run
Roughly ten to twenty cents per account per month in model and infrastructure cost, plus the managed fee. For a 1,400-account book that is a rounding error against one saved churn.
How we rolled it out
For six weeks the agent evaluated every account and we scored its risk calls against what actually renewed or churned — with no one on the revenue team seeing a brief. Then briefs went to CSMs only. Then to AEs, with the feedback thumbs that still feeds the eval suite.
This is the kind of system we build
If your churn signals are real but scattered, we can put a weekly brief in front of the people who own the account. Book a call, or see Evals & Monitoring.
Publishing note: a representative composite of revenue-operations work, not a single named client. Account counts, lead times, and model metrics are illustrative of the range we see.