The Customer Promise Control Plane
Inspiration
Customer trust is often lost after a support conversation ends. A representative says, “we will refund you by 5 PM,” “your replacement will ship tomorrow,” or “I will call after approval,” but the promise remains ordinary text. The customer follows up, the next agent lacks context, and the organization cannot prove whether the outcome happened.
Support systems are excellent systems of conversation and ticket record. We wanted to add the missing control plane for the promises inside those records.
Problem
A customer promise has operational semantics: an actor, beneficiary, action, object, amount, deadline, conditions, and evidence that defines success. Treating it as a note creates three gaps:
- Nobody consistently checks whether policy permits the promise.
- Execution may be late, duplicated, or blocked without a visible recovery path.
- “Done” is often an agent statement rather than independently verified provider evidence.
Solution
KEPT converts every written or spoken promise into a typed, executable, monitored commitment:
Conversation → Commitment → Policy → Action → Verification → Proof
KEPT captures the promise, derives a machine-verifiable success contract, evaluates deterministic policy, pauses high-risk actions for a human, executes allowlisted tools idempotently, retrieves independent provider/ticket evidence, marks the promise KEPT only after every criterion passes, closes the loop with the customer, and preserves a hash-linked audit trail.
How it works
Our golden case starts with an ElevenLabs-ready voice transcript: Ananya Rao says order ORD-4821 was charged twice and a representative promised a ₹3,499 refund before 5 PM today.
The running Local Demo application:
- Captures the transcript and consent.
- Extracts customer, order, action, ₹3,499 INR, 17:00 IST deadline, preconditions, success criteria, evidence requirements, 97% confidence, and risk.
- Runs seven deterministic policy checks: duplicate evidence, active refund policy, identity, ticket relationship, amount, currency, and prompt-injection isolation.
- Builds an explicit five-step DAG.
- Reserves an idempotency key and executes the KEPT local refund ledger action.
- Writes the local ticket checkpoint.
- Independently retrieves the refund record and compares five success criteria.
- Transitions
VERIFYING → KEPT, resolves the ticket record, and delivers the Local Demo customer confirmation. - Displays seven tool calls, five evidence records, nine hash-linked audit events, timestamps, policy reasons, and notification receipt.
A ₹12,499 branch enters NEEDS_APPROVAL. No refund call exists before a human decision. Rejection moves to ESCALATED with a concise billing handoff and still zero refund calls.
Agentic architecture
KEPT uses six functionally distinct specialists rather than one omnipotent assistant:
- Conversation Agent establishes identity, ticket, consent, and the promise; it never promises unsupported outcomes.
- Commitment Architect performs schema/date normalization and defines proof predicates; it cannot execute.
- Policy Guardian evaluates deterministic policy and treats ticket text as untrusted data.
- Resolution Orchestrator builds the DAG, reserves idempotency, checkpoints, retries safely, and cannot override policy.
- Verification Agent retrieves external evidence and is the only role that can authorize
VERIFYING → KEPT. - Recovery & Handoff Agent handles timeout, rejection, and evidence mismatch without creating a new unsupported promise.
Every role has a distinct prompt, typed input/output, narrow tool allowlist, explicit stop condition, maximum tool budget, and a visible trace.
Freshworks integration
The repository includes a Freshworks Platform 3.0 AI Actions package with five actions: capture, assess risk, execute verified refund, check status, and escalate at-risk commitment. The live adapter is designed to read the configured test ticket and add private execution/verification notes linked to the KEPT commitment ID.
The package passed our structural contract test. Because no Freshworks tenant credentials or FDK binary were available in the build environment, we do not claim an authenticated Freshworks call or official FDK validation in the current demo.
ElevenLabs integration
KEPT includes the browser/agent prompt and tool schemas, a signed post-call webhook using the official ElevenLabs JavaScript SDK, consent validation, actual transcript/source ingestion, failure behavior, integration health, and the official outbound-call path for the final customer confirmation.
Because no ElevenLabs API key, Agent ID, phone configuration, or voice was supplied, the visible demo is explicitly labelled Local Demo and the narration/integration is not claimed as live. Configuring these user-only values unlocks the sponsor-integrated path without changing the control graph.
Dodo Payments integration
The LIVE_SANDBOX adapter uses only Dodo Payments Test Mode. It retrieves the configured payment, posts a refund with KEPT idempotency metadata, retrieves refund status, verifies Standard Webhooks signatures, deduplicates webhook IDs, and stores the provider refund ID as evidence. The policy engine and MCP server enforce the ₹5,000 ceiling in code before the connector is callable.
No Dodo Test Mode credential/payment ID was supplied, so the current demo does not claim a Dodo transaction.
Technical implementation
- TypeScript-first Next.js/Vinext application on Cloudflare Sites.
- Drizzle/D1 persistence with 18 normalized tables, workflow snapshot, idempotency reservation, outbox, evidence, and audit chain.
- Zod runtime schemas at domain, route, webhook, AI Action, and MCP boundaries.
- Official Model Context Protocol TypeScript SDK server with nine tools and stdio integration tests.
- Official ElevenLabs SDK, Dodo Test Mode REST adapter/SDK package, and Standard Webhooks verifier.
- Bounded exponential retry, HTTP abort timeouts, safe
AT_RISKrecovery, PII-safe traces, role-backed approval, and SHA-256-linked audit events. - Vitest, official MCP client integration test, versioned 14-case eval, production artifact test, and cloud-browser QA.
Challenges
The most important design challenge was separating “the action API accepted a request” from “the customer promise was kept.” We made the executor structurally unable to mark its own work successful and gave the verifier only read/evidence tools.
We also had to make demo realness inspectable: connector mode is a domain value, the health page cannot show Connected without an authenticated request, and Local Demo uses the same graph/database/policy/idempotency/verifier/UI code without pretending to be a sponsor API.
Accomplishments
- A complete promise lifecycle and functional multi-agent graph, not a visual simulation.
- A money-moving tool that cannot bypass policy or a recorded Refund Manager approval.
- Zero duplicate executions across replay in tests/evaluation.
- A verifier that correctly refuses
KEPTon amount mismatch and provider timeout. - A premium single-screen resolution workspace that makes conversation, contract, agents, policy, action, evidence, and notification understandable together.
- Actual build/test evidence: 15/15 tests, 14/14 evals, clean typecheck/lint/security scan, production build, and browser-verified golden/approval flows.
What we learned
Agentic customer experience is less about adding more conversational intelligence and more about placing authority, evidence, and stopping rules in the correct parts of the system. “Who may act?”, “what proves success?”, and “what happens when proof is missing?” need deterministic answers around the model.
We also learned that honesty is a product feature: mode labels, authenticated health, provider IDs, and criterion-level proof make judges/operators trust what the agent is actually doing.
Potential impact
KEPT could help support leaders measure and improve promise reliability rather than only response time. Production KPIs would include Promise Kept Rate, verification time, at-risk recovery rate, approval turnaround, duplicate-action prevention, and customer follow-up avoided.
These are future pilot targets, not claimed business traction. Current numbers are labelled evaluation results or Local Demo results only.
What is next
- Authenticate the Freshworks, ElevenLabs, and Dodo Test Mode path and record the same evidence contract with real sandbox IDs.
- Add a durable deadline scheduler and proactive at-risk alerts.
- Expand structured extraction to multilingual voice and policy-specific action types.
- Add production reconciliation after ambiguous provider timeouts.
- Pilot Promise Kept Rate with a support team and validate customer/agent experience.
Built With
- agentic-ai
- ai-actions
- auditability
- cloudflare
- customer-experience
- d1
- dodo-payments
- drizzle-orm
- elevenlabs-agents
- freshworks
- freshworks-agent-studio
- model-context-protocol
- next.js
- playwright
- react
- typescript
- vitest
- workflow-automation
- zod
Log in or sign up for Devpost to join the conversation.