Good Amazon Connect ACXD documentation does two jobs at once. It covers the usual project deliverables any contact centre build needs — design documents, test docs, runbooks, change control. And it adds a second layer that agentic AI specifically demands, because an ACXD application doesn't follow a fixed script; it reasons, generates language, and acts. A traditional contact flow diagram simply can't describe that behaviour on its own.
This guide lists every documentation item for an ACXD project, grouped into the two layers, with what each one is for.
Why ACXD Documentation Needs Two Layers
On a traditional Amazon Connect build, the contact flow is the behaviour — document the flow and you've largely documented what the system does. ACXD breaks that assumption. An agentic application decides what to do at runtime based on instructions, knowledge, tools, and guardrails. So you still need the traditional design and governance documents, but you also need artifacts that capture how the AI is meant to behave and how you verify it does. Miss the second layer and you have a system nobody can fully explain, safely change, or prove is working.
Layer 1: Traditional Project Documentation
These apply to any Amazon Connect project, ACXD or not. They establish scope, design, quality, and operability.
Vision & scope statement
What the application is for, who it serves, the business outcomes it targets, and the guiding principles that frame decisions. The reference everything else hangs off.
Functional Design Specification (FDS)
What the application does from the business/user perspective — the use cases, journeys, and expected outcomes, in language stakeholders can sign off.
Technical Design (TDS / HLD / LLD)
How it's built — the high-level and low-level technical design: the ACXD workspace/application structure, how it fits the Connect instance and wider AWS landing zone, and the integration architecture. Often split so specialist reviewers can sign off their section.
Integration & API specifications
Every data request / API the application calls — endpoints, contracts, auth, latency expectations, environments, and owners. (This is also where the classic "are the APIs even ready?" lesson lives.)
Security & compliance design
Access control (IAM and Connect security profiles), data protection, PII handling, PCI scope if payments are involved, and detection — reviewed and signed off independently of the main design.
Test documentation
Test strategy, test cases, and UAT scripts across unit, integration, functional, and acceptance testing. (For ACXD this links tightly to the eval set in Layer 2.)
Runbooks
Step-by-step procedures for the incidents that actually happen. ACXD adds AI-specific runbooks (guardrail breach, hallucination, bad-build rollback, fallback-to-human) on top of the usual ones.
Change control, release notes & lessons learned
How changes are approved and recorded, what each release changed, and a living log of lessons so the same mistakes don't recur. Plus training and operational/BAU documentation and a knowledge base for agents and support.
Layer 2: Agentic-Specific Artifacts
These are what make ACXD documentation different. They capture the behaviour of an application that reasons — the parts a flow diagram can't express. They draw on how leading AI labs document their own agents, applied to ACXD.
Application purpose & scope statement
A sharp statement of what this specific agentic application is allowed to do and explicitly not do — its remit, its autonomy level, and the boundary where it must escalate to a human.
Instructions / prompt specification
The instructions that drive the application's behaviour — specific, unambiguous, grouped by topic, and human-readable. This is a first-class design document in ACXD, not an afterthought buried in a node.
Tool & data-request catalogue with contracts
Every tool and data request the application can invoke, named and described "like onboarding a new hire" — designed around workflows, with unambiguous parameters, expected behaviour, and helpful error handling. This is what tells you (and the AI) what it can actually do.
Guardrail specification
The input and output guardrails, the detection methods (regex, keyword, LLM-judge), the enforcement actions (override, mask, redirect, flag), and their evaluation order. This document defines the safety and compliance boundaries the AI must stay within — arguably the most important single artifact.
Knowledge sources
What knowledge the application draws on, where it lives, how it's kept current, and how answers are grounded in it — because a knowledge base problem is a direct cause of wrong answers.
Context & handoff design
What context the application carries, how it manages its context window, and exactly how and when it hands off to a human agent (and what it passes over). The handoff design is also your safety net.
Evaluation set
The grounded set of test cases — built from real scenarios and production failures — that proves the application behaves correctly and catches regressions. For an application that can fail silently, the eval set is the closest thing to a test plan that actually works, and it's where test documentation and quality assurance really live for ACXD.
The two that matter most: the guardrail specification (the safety boundary) and the evaluation set (the proof it works). If you're short on time, these are the agentic artifacts to get right first — they're what let you deploy with confidence and change safely.
The One-Page Checklist
| Document | Layer | Purpose |
|---|---|---|
| Vision & scope statement | Traditional | Why we're building it |
| Functional Design (FDS) | Traditional | What it does (business view) |
| Technical Design (TDS/HLD/LLD) | Traditional | How it's built |
| Integration & API specs | Traditional | What it connects to |
| Security & compliance design | Traditional | How it's protected |
| Test documentation | Traditional | How it's tested |
| Runbooks | Traditional + AI | How it's operated when things break |
| Change control / release notes / lessons learned | Traditional | How it's governed over time |
| Training & operational docs / knowledge base | Traditional | How people run and use it |
| Application purpose & scope | Agentic | What the AI may and may not do |
| Instructions / prompt spec | Agentic | How the AI is told to behave |
| Tool & data-request catalogue | Agentic | What the AI can do |
| Guardrail specification | Agentic | The AI's safety boundary |
| Knowledge sources | Agentic | What the AI knows |
| Context & handoff design | Agentic | Memory & escalation to humans |
| Evaluation set | Agentic | Proof it works; regression safety net |
Keeping ACXD Documentation Living and Versioned
The biggest documentation failure on agentic projects isn't missing documents — it's documents that went stale. Because ACXD applications change through immutable builds, and because a model or prompt change can shift behaviour, the agentic artifacts in particular must be living and versioned alongside the build they describe.
- Version it with the application. Instructions, guardrails, tool contracts, and the eval set should be in version control, tied to the build.
- Re-review after model/prompt changes. A behaviour shift can invalidate what the docs say.
- Feed production failures back in. Every real incident becomes a new eval case and, where relevant, a documentation or guardrail update.
Reminder: ACXD was introduced as a preview, so specifics can change — confirm current capabilities in the official AWS documentation. The discipline of documenting these items, though, holds regardless of version.
Frequently Asked Questions
What documentation does an Amazon Connect ACXD project need?
An Amazon Connect ACXD project needs both traditional project documentation and agentic-specific artifacts. Traditional: vision/scope, functional design (FDS), technical design (TDS/HLD/LLD), integration and API specifications, security and compliance design, test documentation, runbooks, change control, release notes, and training/operational docs. Agentic-specific: the application purpose and scope, the instructions/prompt specification, a tool and data-request catalogue with contracts, the guardrail specification, knowledge sources, context and handoff design, and an evaluation set.
Why does ACXD documentation differ from a normal Amazon Connect project?
Because an ACXD application reasons rather than follows a fixed script, a traditional flow diagram no longer fully describes it. ACXD projects still need the normal design and governance documents, but must add agentic artifacts — the instructions, tool contracts, guardrails, knowledge sources, and especially the evaluation set — that capture how the AI is meant to behave and how you verify it does.
What is the most important ACXD document?
Two stand out. The guardrail specification, because it defines the safety and compliance boundaries the AI must stay within, and the evaluation set, because it is how you prove the application behaves correctly and catch regressions — for an agentic application that can fail silently, the eval set is the closest thing to a test plan that actually works.
Should ACXD documentation be version-controlled?
Yes. ACXD documentation should be living and versioned alongside the application itself, not written once and left to rot. Because ACXD applications change through immutable builds and because model and prompt changes can shift behaviour, the instructions, guardrails, tool contracts, and eval set in particular need to be kept current and version-controlled with the build they describe.
Conclusion
Amazon Connect ACXD documentation is the traditional project documentation set plus an agentic layer that captures how a reasoning application behaves and how you prove it. Cover both, prioritise the guardrail specification and the evaluation set, and keep everything living and versioned with the build. Do that and your ACXD application is one anyone can understand, change safely, and trust in production.
Related: how to document an agentic self-service experience, ACXD guardrails, ACXD runbooks, evals for high-performing self-service, and the ACXD hub.