Amazon Quick's No-Code Retention Pipeline: MCP Actions as Orchestration Glue

Amazon Quick’s customer retention workflow shows how MCP Actions function as orchestration primitives in production business processes. The pipeline ingests unstructured call transcripts and CSAT scores, calculates retention priority through a custom MCP Action, and triggers personalized letter generation. Response time dropped from days to minutes. The architecture exposes how no-code tools handle state transitions and failure boundaries when agents drive financial interventions.

Pipeline Architecture

The workflow runs in four stages:

1. Ingestion: Call transcripts and CSAT data land in Amazon Quick’s data layer
2. Correlation: Workflow builder joins transcript sentiment with CSAT scores by customer ID
3. Scoring: Custom MCP Action calculates retention priority (0-100 scale)
4. Generation: Agent drafts personalized retention letter based on score and context

The MCP Action sits between unstructured analysis and structured business logic. It receives transcript snippets, CSAT deltas, and customer metadata. It returns a numeric score and a risk category (low, medium, high, critical). The workflow builder uses these outputs to route customers into different intervention tracks.

MCP Action as State Boundary

The scoring action defines the contract between data processing and business rules. Input schema:

{
  "customer_id": "string",
  "transcript_summary": "string (max 500 chars)",
  "csat_current": "number (1-5)",
  "csat_previous": "number (1-5)",
  "account_tenure_months": "number",
  "lifetime_value": "number"
}

Output schema:

{
  "retention_score": "number (0-100)",
  "risk_category": "enum [low, medium, high, critical]",
  "intervention_type": "enum [none, email, call, executive_review]",
  "reasoning": "string (optional, for audit)"
}

The action enforces validation at the boundary. If csat_current is missing or lifetime_value is negative, the action returns an error and the workflow pauses that customer record. Failures do not cascade to other records in the batch.

Scoring Logic and Guardrails

The MCP Action calculates retention score using weighted factors:

• CSAT drop (40% weight): (csat_previous - csat_current) * 20
• Transcript sentiment (30% weight): Negative keyword density scaled to 0-30
• Account value (20% weight): min(lifetime_value / 10000, 20)
• Tenure risk (10% weight): Accounts under 6 months get +10, over 36 months get -5

The action caps the score at 100 and floors it at 0. A score above 70 triggers the high risk category. Above 85 is critical.

Guardrails prevent false positives:

• Customers contacted in the last 30 days are excluded
• Scores below 40 route to none intervention
• Critical scores require human review before executive outreach

The workflow builder stores the score and category in a DynamoDB table. If letter generation fails, the record remains in scored state and retries on the next run.

State Management and Failure Recovery

Each customer record moves through discrete states:

State	Trigger	Next State on Success	Next State on Failure
ingested	Data arrives	correlated	ingestion_error
correlated	Join completes	scored	correlation_error
scored	MCP Action returns	letter_generated	scoring_error
letter_generated	Draft approved	sent	generation_error

Error states persist in DynamoDB with a retry_count field. After three failures, the record moves to manual_review. The workflow builder polls error states every 15 minutes and retries with exponential backoff.

The MCP Action itself is stateless. It does not store customer history or previous scores. All context arrives in the input payload. This keeps the action idempotent and simplifies horizontal scaling.

Observability and Audit Trail

Amazon Quick logs every MCP Action invocation to CloudWatch. Each log entry includes:

• Request ID
• Input payload (sanitized)
• Output score and category
• Execution time (p50, p99)
• Error type if failed

The workflow builder emits custom metrics:

• retention_score_distribution (histogram)
• intervention_type_count (counter by type)
• false_positive_rate (gauge, updated weekly)

False positives are tracked when a customer marked high or critical does not churn within 90 days. The team reviews these cases monthly and adjusts scoring weights in the MCP Action.

Deployment Shape

The MCP Action runs as a Lambda function behind API Gateway. The workflow builder calls it synchronously with a 30-second timeout. If the action exceeds 25 seconds, the workflow retries with a fresh invocation.

Scaling limits:

• Lambda concurrency: 100 (reserved)
• API Gateway throttle: 500 requests/second
• DynamoDB write capacity: 1000 WCU (provisioned)

The pipeline processes 10,000 customer records per hour during peak periods. Average MCP Action latency is 1.2 seconds. The bottleneck is transcript summarization, not scoring.

Code Example: MCP Action Handler

import json

def lambda_handler(event, context):
    body = json.loads(event['body'])
    
    # Extract inputs
    csat_drop = (body['csat_previous'] - body['csat_current']) * 20
    sentiment_score = calculate_sentiment(body['transcript_summary'])
    value_score = min(body['lifetime_value'] / 10000, 20)
    tenure_score = tenure_adjustment(body['account_tenure_months'])
    
    # Calculate weighted score
    retention_score = max(0, min(100, 
        csat_drop * 0.4 + 
        sentiment_score * 0.3 + 
        value_score * 0.2 + 
        tenure_score * 0.1
    ))
    
    # Determine risk category
    if retention_score >= 85:
        risk_category = 'critical'
        intervention = 'executive_review'
    elif retention_score >= 70:
        risk_category = 'high'
        intervention = 'call'
    elif retention_score >= 40:
        risk_category = 'medium'
        intervention = 'email'
    else:
        risk_category = 'low'
        intervention = 'none'
    
    return {
        'statusCode': 200,
        'body': json.dumps({
            'retention_score': retention_score,
            'risk_category': risk_category,
            'intervention_type': intervention,
            'reasoning': f'CSAT drop: {csat_drop}, Sentiment: {sentiment_score}'
        })
    }

def calculate_sentiment(transcript):
    # Placeholder for actual sentiment analysis
    negative_keywords = ['cancel', 'frustrated', 'disappointed']
    density = sum(1 for word in negative_keywords if word in transcript.lower())
    return min(density * 10, 30)

def tenure_adjustment(months):
    if months < 6:
        return 10
    elif months > 36:
        return -5
    return 0

Likely Failure Modes

Scoring drift: If CSAT scales change or transcript quality degrades, the action produces stale scores. The team monitors false positive rate weekly and retrains the sentiment model quarterly.

Timeout cascades: If the MCP Action slows down (due to cold starts or external API latency), the workflow builder queues up retries. This can exhaust Lambda concurrency. The solution is to set a hard timeout at 25 seconds and fail fast.

State corruption: If DynamoDB writes fail after the MCP Action succeeds, the customer record stays in correlated state but the score is lost. The workflow builder detects this by checking for records older than 1 hour in correlated state and re-runs the action.

Guardrail bypass: If the 30-day contact exclusion list is stale, customers receive duplicate outreach. The team syncs the exclusion list from the CRM every 6 hours and caches it in ElastiCache.

Technical Verdict

Use this pattern when you need to inject custom business logic into a no-code workflow without building a full orchestration engine. MCP Actions work well for scoring, classification, and routing decisions that sit between data ingestion and agent-driven outputs. The stateless design keeps scaling simple and failure recovery predictable.

Avoid this approach if your scoring logic requires iterative refinement or multi-step reasoning. The MCP Action runs once per customer record. If you need to loop back and adjust scores based on downstream results, you will need a more complex state machine (Step Functions or Temporal). Also avoid if your action latency exceeds 10 seconds regularly. The workflow builder’s synchronous call pattern does not handle long-running tasks gracefully.

The retention pipeline shows how MCP Actions function as contract boundaries in production workflows. The input and output schemas enforce validation. The stateless design simplifies scaling. The failure modes are predictable and recoverable. For business processes that need agent-driven interventions without custom orchestration code, this is a solid reference architecture.

Source Links

• Amazon Quick Customer Retention Workflow