Case study
A governed AI agent that finds at-risk customers — and waits for a human to say go.
Built for a SaaS company's customer success team: a Slack-native AI agent, backed by a governed MCP server, that reasons over customer risk data in plain business language — and never writes anything without explicit approval.
A normal business question
A customer success manager can ask exactly what they'd ask a teammate — in Slack, in plain language.
“Find enterprise customers with a risk score above 70, explain the two highest-risk accounts, and propose follow-up tasks. Do not create anything until I approve.”
What the system does
- 01Searches customer data through MCP.
- 02Ranks accounts by risk.
- 03Retrieves detailed risk evidence only for relevant customers.
- 04Explains the findings in business language.
- 05Proposes specific follow-up tasks.
- 06Waits for an explicit Slack-button approval.
- 07Creates only the approved task.
- 08Writes the task to storage and prevents duplicates.
Architecture
The model never touches backend data directly. It sees five stable, model-friendly business capabilities — the MCP server owns validation, lookup, recommendations, error handling, duplicate detection, and persistence.
search_customersget_customerget_customer_riskcreate_followup_tasklist_followup_tasksWhy it's useful
Most business systems expose many low-level API endpoints. Without a governed interface, the AI would need to figure all of this out itself:
Without MCP, the AI needs to know
- –Which endpoints contain customer data
- –How risk data is represented
- –How records relate to one another
- –Which fields are safe to display
- –How to create tasks correctly
- –How to avoid duplicate writes
- –Which operations require approval
With MCP
- ✓Less context is sent to the model.
- ✓Backend implementation details remain hidden.
- ✓Tool inputs are validated before execution.
- ✓Read operations are separated from write operations.
- ✓Errors are returned in a consistent structured format.
- ✓Sensitive actions have an explicit approval boundary.
- ✓Backend systems can change without rewriting the AI workflow.
Safety design: the approval boundary
During normal Slack conversation, the model cannot access the task-creation tool. It only receives read-only MCP tools and a proposal function — proposed tasks become Slack approval buttons. The actual write tool is available only to the button handler, which verifies every one of these before anything is created:
The approver is the person who requested the proposal.
Approval occurs in the original conversation.
The proposal has not expired.
The proposal has not already been used.
The same open task does not already exist.
This is stronger than prompting the model to “wait for approval.” The restriction is enforced in the application architecture, not the prompt.
How a SaaS company could use this in production
The same MCP interface can point at real systems. The Slack experience and tool contracts stay stable — only the backend adapters change.
| Current demonstration | Production implementation |
|---|---|
| customers.json | CRM or customer platform |
| followup-tasks.json | Salesforce, HubSpot, or task system |
| Local risk fields | Data warehouse or health-score service |
| Local account owners | Identity and territory system |
| In-memory proposals | Durable approval database |
Where this fits
- Daily risk-account reviews
- Renewal preparation
- Usage-decline detection
- Support escalation
- Executive-sponsor outreach
- Customer health summaries
- Follow-up task coordination
- Manager approval workflows
Same capabilities, every role
CSM
“Which strategic accounts need attention this week?”
Manager
“Show critical accounts renewing in the next 60 days.”
Executive
“Summarize the revenue at risk and the proposed recovery actions.”
The reusable pattern
Expose customer-success workflows as stable, governed MCP capabilities so an AI agent can reason over customer risk and safely coordinate follow-up.
The value isn't just conversational access to data — it's the combination of:
Before production use
This demonstrates the pattern, not a finished platform. A production deployment would still need:
Want an agent like this for your team?
If your team has data spread across systems and repetitive judgment calls to make from it, this is the pattern: governed tools, human approval, working software in weeks.
Start a conversation