DEV Community: Manasa Reddy

Embedding Native Amazon Q Agent Assistance into a Custom Amazon Connect CCP

Manasa Reddy — Tue, 28 Jul 2026 07:35:58 +0000

Amazon Connect allows organizations to build completely customized Contact Control Panels (CCPs). Whether it's adding CRM integrations, internal dashboards, or custom workflows, many companies replace the default CCP with their own web application.

But there's one question I kept hearing:

Can we still use the native Amazon Q Agent Assistance experience inside a custom CCP?

The answer is yes.

In this article, I'll walk through the architecture and implementation approach we used to embed the AWS-managed Amazon Q experience directly into a custom Contact Control Panel without recreating any AI functionality ourselves.

The Challenge

Many organizations build a custom CCP to integrate:

CRM systems
Customer information
Internal business tools
Custom workflows

However, once you move away from the standard CCP, agents still expect access to Amazon Q Agent Assistance.

Rather than opening another browser tab or creating a separate application, we wanted Amazon Q to feel like part of the same workspace.

Solution Overview

Instead of rebuilding Amazon Q, we embedded the native AWS-managed Amazon Q interface alongside our custom CCP.

The custom application simply hosts both experiences while Amazon Connect continues to manage:

Authentication
Contact context
Amazon Q Agent Assistance

This keeps the solution lightweight while allowing agents to access AI-powered assistance without leaving the customer interaction.

Architecture

The solution follows a simple architecture:

Agents access the application through Amazon CloudFront.
CloudFront serves a static web application hosted in Amazon S3.
The application loads the custom Contact Control Panel (CCP) in the browser.
The authenticated Amazon Connect session initializes the CCP.
The same authenticated session loads the native Amazon Q experience.
During supported customer interactions, Amazon Q retrieves relevant information from configured enterprise knowledge sources.
Agents can seamlessly switch between the CCP and Amazon Q without leaving the application.

Key takeaway: The application never manages Amazon Q itself. It simply provides a place for the native AWS-managed experience to run.

Why This Approach?

Keeping Amazon Q as an AWS-managed component offers several advantages.

Minimal Custom Code

The application only initializes the Amazon Q experience instead of implementing AI features.

Native Experience

Agents receive the same interface and functionality available in the standard Amazon Connect experience.

Shared Authentication

No additional login flow is required because Amazon Q uses the existing authenticated Amazon Connect session.

Easier Maintenance

As Amazon Q receives new features and improvements, the application automatically benefits without requiring UI updates.

Implementation Highlights

The implementation was intentionally simple.

The custom CCP:

Initializes the Amazon Connect CCP.
Adds a dedicated Amazon Q tab.
Creates a responsive container for Amazon Q.
Uses environment-aware configuration to support multiple Amazon Connect instances.
Maintains accessibility and responsive layouts for agents.

Because the application is a static web application, deployment is straightforward using Amazon S3 and Amazon CloudFront.

Security Considerations

Security remains largely unchanged from a standard Amazon Connect deployment.

Since authentication is handled by Amazon Connect:

AWS credentials are never stored in the browser.
Existing IAM permissions continue to apply.
Approved application origins control where the CCP can be embedded.
Amazon Q respects the permissions configured within Amazon Connect.
Enterprise knowledge sources remain protected behind existing AWS security controls.

Benefits for Contact Center Agents

Embedding Amazon Q directly into the CCP provides several operational benefits:

Faster access to enterprise knowledge during live interactions.
Reduced context switching between applications.
A consistent agent experience.
Lower training effort.
Improved productivity.
Better first-contact resolution through quicker access to relevant information.

Lessons Learned

A few design decisions made the implementation much simpler.

Keep Amazon Q Native

Avoid recreating the interface or duplicating functionality already provided by AWS.

Separate Responsibilities

The CCP should manage customer interactions, while Amazon Q focuses on knowledge assistance.

Design for Multiple Environments

Supporting development, testing, and production becomes much easier with environment-aware configuration.

Prioritize Responsive Layouts

Agents often resize their browser windows, so both the CCP and Amazon Q should remain usable across different screen sizes.

Final Thoughts

One of the biggest advantages of Amazon Connect is its flexibility. You can build a fully customized Contact Control Panel without sacrificing native AWS capabilities like Amazon Q Agent Assistance.

By embedding the AWS-managed Amazon Q experience into a custom CCP, organizations can provide agents with AI-powered knowledge assistance while keeping the application lightweight, secure, and easy to maintain.

Rather than rebuilding AI features, let Amazon Q handle the intelligence while you focus on creating a seamless, productive agent experience.

If you're building custom experiences on top of Amazon Connect, I'd love to hear how you're extending your agent workspace. Feel free to share your thoughts or questions in the comments!

Escaping the Containment Trap: Building Agentic Contact Centers with Amazon Connect and Bedrock

Manasa Reddy — Wed, 29 Apr 2026 04:06:23 +0000

If you look at the operational dashboards of most modern contact centers, the metrics often paint a comforting picture: high containment rates and deflected calls. But beneath the surface of those green dashboards, customer trust is quietly draining away.

This is the "Containment Trap."

Organizations frequently design contact flows to trap callers in automated loops, heavily weighting their KPIs toward reducing cost-per-contact. While the math might look favorable to finance, it forces repeat contacts, frustrates users seeking nuanced help, and ultimately degrades the brand experience.

It is time to shift our architectural mindset from containment to resolution.

With the latest capabilities introduced to Amazon Connect—specifically its native synergy with generative AI—we can build systems that optimize for intelligent handoffs. By integrating Amazon Connect with Amazon Bedrock and leveraging the Model Context Protocol (MCP), cloud engineers can deploy an Agentic AI workflow that respects the user's time.

Here is a breakdown of how to engineer this solution at scale.

Moving from Static Routing to Agentic Routing
Traditional IVRs rely on rigid, decision-tree contact flows. If a user's intent doesn't perfectly match a pre-defined slot, they hit a dead end. By placing Amazon Bedrock at the front of the queue, we can analyze the customer's intent dynamically using natural language. The critical difference here is self-awareness: if the AI agent determines it cannot resolve the issue with high confidence, it immediately initiates a context-rich handoff to a human queue.
The Power of the Model Context Protocol (MCP)
Intelligent routing is only half the battle; the agent needs data. MCP is the game-changer for this architecture. It allows the Connect AI agent to securely and seamlessly query your external enterprise systems of record (like a DynamoDB table or a third-party CRM). The AI fetches the exact transaction history before the handoff. When the human agent accepts the call, they aren't asking, "How can I help you today?" They already have the complete context, the user's recent actions, and the likely resolution path on their screen.
Automating the Wrap-Up
The efficiency gains shouldn't stop when the call connects. Post-call documentation (After Call Work) is a massive drain on operational efficiency. Implementing Connect’s AI-powered case summarization means key details, customer sentiment, and required action items are automatically captured, structured, and logged back into the system of record.
Securing the Pipeline with Infrastructure as Code
Because this architecture spans multiple advanced AWS services—from Connect queues to Bedrock integrations and custom Lambda logic—environment consistency is paramount. This entire pipeline must be provisioned systematically. Using Terraform to define these resources ensures that your staging environments perfectly mirror production, and updates to the AI logic can be deployed via standard CI/CD pipelines.

To make this concrete, here is how you provision the integration layer using Terraform. This snippet ensures your Connect instance can securely trigger the intelligence routing logic while adhering to the principle of least privilege for Bedrock model invocation:

# 1. IAM Role for the Integration Lambda
resource "aws_iam_role" "connect_bedrock_integration_role" {
  name = "connect-bedrock-mcp-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })
}

# 2. Granting Lambda Permission to Invoke Bedrock Models
resource "aws_iam_policy" "bedrock_invoke_policy" {
  name        = "BedrockInvokeModelPolicy"
  description = "Allows Lambda to invoke Bedrock for intent analysis and MCP routing"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ]
      # Scoped down to the specific foundational model (e.g., Claude 3)
      Resource = "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-sonnet-*" 
    }]
  })
}

resource "aws_iam_role_policy_attachment" "bedrock_attach" {
  role       = aws_iam_role.connect_bedrock_integration_role.name
  policy_arn = aws_iam_policy.bedrock_invoke_policy.arn
}

# 3. The MCP Integration Lambda Function
resource "aws_lambda_function" "mcp_routing_logic" {
  filename         = "mcp_logic.zip"
  function_name    = "ConnectAgenticRouting"
  role             = aws_iam_role.connect_bedrock_integration_role.arn
  handler          = "index.handler"
  runtime          = "python3.12"
  timeout          = 15
}

# 4. Allowing Amazon Connect to trigger the Lambda
resource "aws_lambda_permission" "allow_connect" {
  statement_id  = "AllowExecutionFromConnect"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.mcp_routing_logic.function_name
  principal     = "connect.amazonaws.com"
  source_arn    = aws_connect_instance.main_contact_center.arn
}

# 5. Associating the Lambda directly with the Connect Instance
resource "aws_connect_lambda_function_association" "bedrock_integration" {
  instance_id  = aws_connect_instance.main_contact_center.id
  function_arn = aws_lambda_function.mcp_routing_logic.arn
}

When we build systems optimized for resolution rather than deflection, everyone wins. The AI handles the heavy lifting of data gathering, humans step in when empathy and complex judgment are required, and the customer experiences a frictionless journey.