CI/CD for ACXD: The SDK, MCP Tools, and What to Explore

If you're new to ACXD, start with the plain-English guide to what ACXD is. This article assumes you know the basics and goes a layer deeper: how you actually operationalise it. It pairs with the broader ACXD CI/CD pipeline guide, but focuses specifically on the SDK, MCP automation, and the practical limits you'll hit today.

Things Worth Exploring with ACXD

Before the CI/CD mechanics, it's worth naming the areas that reward a deeper look — the places where ACXD is more than a prettier flow builder:

• Applications as deployable artifacts. ACXD bundles your flows, knowledge bases, language settings, guardrails, and integrations into an application — a single deployable package. That packaging is what makes real release management possible.
• Immutable builds and clean rollback. A build compiles an application into an immutable snapshot; a deployment makes one build live. Only one build is live at a time, and you can roll back to any previous build. That's a proper release model, not "edit live and hope."
• Multi-channel and MCP as deploy targets. A deployment can push to chat, voice, IVR, web, mobile — and MCP clients. That last one is quietly significant: your ACXD application can be exposed as a tool other AI systems call.
• Guardrails and knowledge bases as first-class resources. They have their own lifecycle (including knowledge base publication and guardrail testing), so they can be versioned and tested like everything else — though the knowledge bases are more limiting than you might expect (more on that below).
• The SDK itself. The headline: everything you can do on the canvas, you can do in code — which is the foundation for all the automation below.

A Limitation to Know: Knowledge Base Sources

One area where ACXD is more constrained than you might assume is its knowledge bases. Per the AWS documentation, an ACXD knowledge base supports just two content types:

• Q&A — structured question-and-answer pairs, entered manually or uploaded in a supported format.
• Documents — uploaded files (PDF, TXT, DOC/DOCX, and images like JPG/PNG) that get ingested for retrieval.

That's it. Both options are fundamentally push-based: you either type the content in or upload files. There is no web crawler or URL-based data source — which is notable because most managed knowledge bases offer exactly that. Amazon's own Bedrock Knowledge Bases, for instance, include a Web Crawler that traverses seed URLs (and sitemaps) to pull in web content automatically, alongside connectors for data stores like S3 and others.

What this means in practice:

• No "point it at your help centre" shortcut. If your knowledge already lives on a public website or docs portal, you can't just hand ACXD the URL and let it crawl. You have to export or upload the content.
• Freshness is on you. With a crawler, content re-syncs on a schedule. With upload-only sources, keeping the knowledge base current is a manual (or scripted) re-upload and re-publish — which is actually a strong argument for driving it through the SDK as part of your pipeline.
• Plan your content pipeline. For sizeable or frequently-changing content, you'll want automation that pulls from your source of truth, formats it, and uploads via the SDK's knowledge base and document operations.

What the ACXD SDK Actually Is

Per AWS's own framing, the ACXD SDK is a RESTful API that gives programmatic access to all workspace resources — built explicitly to bring infrastructure-as-code workflows to Agentic CX Designer. The key promise: the same resources you design visually can be created, updated, and deployed through code, and changes made either way are immediately visible in the other.

A few concrete details that matter for CI/CD:

• Auth is via API key tied to a programmatic user (a machine identity) that an account admin creates, with role-based access (administrator, developer, content manager, read-only, or custom), scoped to the account or specific workspaces. Keys look like acxd_live_<prefix>.<secret> and are shown once.
• The client follows the Command pattern — you import the client and a command, then call client.send(command).
• The operations cover the whole surface — applications, builds, deployments, flows, guardrails, knowledge bases (and articles/documents), slot types, context variables, secrets, modalities, roles, logs, and more. Crucially for review workflows, there's a GetApplicationBuildDiff operation and resource versioning.

Here's the shape of it (illustrative, based on the documented Command pattern):

import { AgenticCXDesignerClient, CreateApplicationBuildCommand,
         CreateApplicationDeploymentCommand } from "amazon-connect-acxd-sdk";

const client = new AgenticCXDesignerClient({
  apiKey: process.env.ACXD_API_KEY,       // from your secrets store
  workspaceId: process.env.ACXD_WORKSPACE,
});

// 1. Build an immutable snapshot of the application
const build = await client.send(new CreateApplicationBuildCommand({
  applicationId: "app-123",
}));

// 2. Deploy that build to the live channel(s)
await client.send(new CreateApplicationDeploymentCommand({
  applicationId: "app-123",
  buildId: build.buildId,
}));

That three-step rhythm — change → build → deploy, with diff and rollback available — is exactly what a pipeline needs.

What CI/CD Looks Like for ACXD

With the SDK in hand, a pipeline for ACXD looks much like one for any other application — the artifacts are just conversational instead of containers. A workable shape:

  ┌──────────────────────────────────────────────────────────────┐
  │  SOURCE   Application config / flows exported & versioned in git │
  └───────────────────────────────┬──────────────────────────────┘
                                  ▼
  ┌──────────────────────────────────────────────────────────────┐
  │  CI   On PR:                                                    │
  │   • push changes to a NON-PROD workspace via the SDK           │
  │   • GetApplicationBuildDiff → post the diff on the PR          │
  │   • CreateApplicationBuild → run adversarial + eval tests      │
  │   • TestGuardrail on safety rules                              │
  └───────────────────────────────┬──────────────────────────────┘
                                  ▼
  ┌──────────────────────────────────────────────────────────────┐
  │  REVIEW   Human approves the diff + test results on the PR     │
  └───────────────────────────────┬──────────────────────────────┘
                                  ▼
  ┌──────────────────────────────────────────────────────────────┐
  │  CD   On merge:                                                 │
  │   • CreateApplicationBuild in PROD workspace                   │
  │   • CreateApplicationDeployment (one build live at a time)     │
  │   • smoke test → on failure, roll back to previous build       │
  └────────────────────────────────────────────────────────────────┘

The pieces that make this real, all available through the SDK:

• Version control. Treat the application's flows, prompts, guardrails, and knowledge base config as source. Store them in git; the SDK's resource versioning and GetApplicationBuildDiff give you a reviewable change.
• Environments as workspaces. Use separate workspaces (or accounts) for dev, test, and prod. A programmatic user scoped per workspace keeps blast radius tight.
• Automated testing in CI. Build, then run your evaluation suite against the non-prod build — adversarial prompts, hallucination checks, and TestGuardrail for safety rules. This is where the AI agent metrics and security hot topics (prompt injection, guardrails) become test cases.
• Promotion and rollback. On approval, build and deploy to prod. Because only one build is live and rollback is one call, your recovery path is clean.
• Continuous monitoring. Feed QueryLogs and conversation data into your observability so quality regressions surface fast — the loop from the self-service flywheel.

Idea: ACXD MCP Tools + Claude or Kiro Pushing the Code

Here's where it gets fun. If the SDK can do everything, you can wrap its operations as MCP (Model Context Protocol) tools — and then let an AI assistant like Claude or Kiro drive deployments through natural language. "Build the current version of the billing app in the test workspace and show me the diff from what's live" becomes a thing you can just ask.

How it fits together

   You / Kiro / Claude
          │  "build & deploy the billing app to test"
          ▼
   ┌─────────────────────┐     wraps      ┌──────────────────────┐
   │   ACXD MCP server    │ ─────────────▶ │   ACXD SDK commands   │
   │  (tools you define)  │                │ Build / Diff / Deploy │
   └─────────────────────┘                └───────────┬──────────┘
          ▲                                            ▼
          │  structured result                 ACXD workspace (AWS)
          └────────────────────────────────────────────┘

You'd define a small set of MCP tools that map onto the SDK — for example:

• acxd_list_applications → ListApplicationsCommand
• acxd_build_application → CreateApplicationBuildCommand
• acxd_diff_build → GetApplicationBuildDiffCommand
• acxd_deploy_build → CreateApplicationDeploymentCommand
• acxd_rollback → deploy a previous build
• acxd_test_guardrail → TestGuardrailCommand

Because the ACXD SDK is a Node/TypeScript package, writing an MCP server around it is straightforward — the official MCP TypeScript SDK is a natural fit, so the MCP layer and the ACXD layer share the same runtime. The assistant then has a safe, well-scoped set of actions: it can propose and execute a build, fetch a diff for you to review, deploy on your say-so, and roll back if a smoke test fails.

Done well, this is a genuinely useful pattern: the same MCP-accelerated delivery idea applied to ACXD, where an assistant handles the mechanical build-diff-deploy steps and you stay in the approval loop.

Reality Check 1: There's Still Some Click-Ops

The SDK's promise is "everything you can design, you can code." That's powerful, but in practice a fully hands-off pipeline still runs into a few manual steps today — the kind of click-ops that stop you from going 100% automated:

• Bootstrapping credentials. Programmatic users and API keys are created by an account admin in the workspace UI (Admin Hub → Programmatic Users). Your pipeline can't fully self-provision its own identity from zero — someone clicks to create the user and generate the key first, then stores it as a secret.
• Initial workspace and account setup. Standing up workspaces, connecting the ACXD application to a Connect Customer flow (via the Agentic CX block), and wiring up channels often involves console steps the first time around.
• Design-heavy iteration. The canvas is still the best place to author complex conversational logic. Teams tend to design visually, then use the SDK to version, test, promote, and deploy — rather than hand-writing flows in code from scratch.
• Some integrations and approvals. Connecting certain backend systems, secrets, or org-level permissions can still need a human in the console.

None of this breaks CI/CD — it just means the honest picture is mostly automated with a thin layer of one-time or occasional manual setup. Plan for a short "click once, then automate" bootstrap rather than expecting a cold-start, zero-touch pipeline on day one.

Reality Check 2: The SDK Is Node/TypeScript

The ACXD SDK is distributed as a JavaScript/TypeScript package (amazon-connect-acxd-sdk), using the familiar Command pattern. If your team already lives in Node, this is frictionless. If you don't, it's a real consideration:

• If your stack is Python, Java, .NET, or Go, there isn't a first-class native client in your language today. You either add a Node toolchain to your pipeline just for ACXD, or call the underlying REST API directly from your language of choice.
• Calling the REST API directly is viable — it's a RESTful service with API-key auth — but you give up the ergonomics of the typed command classes and have to maintain your own request/response handling.
• CI runners need Node. Your build agents will need a Node runtime available to use the SDK (and to run an MCP server built on it), which is a minor but real dependency to standardise.

For most teams this is a non-issue — Node is everywhere, and the TypeScript types are genuinely helpful. But if you're a Python-first shop, factor in either a small Node sidecar for ACXD operations or a thin REST wrapper in your own language.

Where to Start

If you want to explore ACXD CI/CD without boiling the ocean:

1. Create a workspace-scoped programmatic user (not account admin) and store its key in your secrets manager.
2. Write a small TypeScript project that can list, build, diff, and deploy one application.
3. Wrap those four calls as MCP tools and try driving them from Kiro or Claude — build in test, review the diff, deploy on confirmation.
4. Add evaluation and TestGuardrail to the build step before you let anything reach prod.
5. Only then wire it into your git workflow for automatic non-prod deploys on PR, with human approval gating prod.

ACXD is young, and the SDK is younger still — but the direction is clear. Agentic conversational applications are becoming real software artifacts, with builds, diffs, versioning, and rollback. Combine that with MCP and an AI assistant, and the gap between "I changed the flow" and "it's safely live" gets very short indeed.

Designing the ACXD application itself first? Map the flows, tools, and guardrail checks visually with the free IVR Design Tool before you build — then let the SDK handle the delivery.

Technical details referenced from the AWS developer documentation: ACXD SDK, API reference, getting started, and application deployments. ACXD is a preview-era service; confirm current capabilities against the official docs. Content was summarised and rephrased from these sources.