Skip to content

Recover an Amazon Connect AI assistant association

Status: Current | Last reviewed: 2026-10-05

Use this runbook when the Amazon Connect AI agents page reports that its AWSServiceRoleForAmazonConnect_* role cannot call wisdom:GetAssistant or wisdom:ListAIAgents. Check whether the referenced assistant exists before changing permissions: a stale association to a deleted assistant can surface as an authorization error.

Diagnose with the intended account

Confirm the caller identity, account and Region before inspecting the instance. A remote AWS integration can use an instance role while your local AWS profile uses a different identity. An access denial from the diagnostic identity does not establish the state of the Connect service role.

  1. Call Connect DescribeInstance and record its ServiceRole.
  2. Call ListIntegrationAssociations with IntegrationType=WISDOM_ASSISTANT.
  3. Use an authorized diagnostic identity to call Q Connect GetAssistant, ListTagsForResource and ListAIAgents for the associated assistant.
  4. If the assistant exists, check its AmazonConnectEnabled tag. The value is case-sensitive and must be True for the corresponding conditional allow in AmazonConnectServiceLinkedRolePolicy.
  5. Inspect the role's attached policy and current default policy version. Retrieve inline policies as well if the managed policy and tags do not explain the denial.
  6. If the assistant does not exist, inspect CloudTrail DeleteAssistant events and match their requestParameters.assistantId. An instance association can remain after deletion of the underlying assistant.

Repair the association

Record the existing instance association, assistant configuration, knowledge base associations and relevant flow definitions in private local files.

Choose the intended replacement using its configuration and ownership. Check other Connect instances before reusing an existing assistant. Preserve custom agents, prompts, guardrails, encryption settings and knowledge sources.

The assistant-count quota reported by Service Quotas on the review date is five per account and Region (wisdom, L-5558F50C, Adjustable=false). CreateAssistant can therefore fail even when the instance's current association is stale. Check both applied and default quota listings; the assistant-count entry was present only in the default listing during diagnosis. Do not delete another assistant merely to free a slot.

Prepare the replacement and its knowledge-base association first. If Connect rejects a second assistant association because of the instance association limit, recheck that the old target is still missing, remove that stale association, then associate the replacement using CreateIntegrationAssociation with IntegrationType=WISDOM_ASSISTANT.

Re-read the instance association, assistant status and tags, and knowledge-base association. Run GetAssistant and ListAIAgents, then refresh the Connect AI agents page to verify access through Connect's service role. Successful reads using an administrator identity alone do not verify that service-role path.

IAM simulation is supplementary evidence. During this diagnosis, wisdom:ListAIAgents returned implicitDeny even for an isolated policy with Action: "*" and Resource: "*". Treat that result as inconclusive rather than changing a service-linked role to satisfy the simulator.

Current dcc-dev-main-connect configuration

The instance is in account 465572510980, Region us-east-1.

Resource Identifier
Connect instance 9156b961-eb34-4d3a-92ad-f770d8f8b282
Active assistant Self_Service_Domain — d11cb40a-8cd4-4d2f-8076-b935696b54db
Connect assistant association e7bf73f1-3b1e-4b21-839c-464ec08a4798
Knowledge base ts-insurance-knowledge-base — 295a409a-4a6e-4c09-a7b2-b9f67d24ea65 (eight synthetic telco articles)
Assistant knowledge-base association e22641f7-2df5-49f3-9bdb-8cef1a0623eb
Deleted assistant 663b85a5-1c03-46ff-9d18-55958150ad04

CloudTrail records successful deletion of the old assistant on 2026-08-17 at 08:51:55 UTC. The replacement has AmazonConnectEnabled=True and now has four custom Consumer Cellular feature agents plus an assistance orchestrator. Its existing encryption configuration is preserved. Direct API reads pass; Connect browser verification remains a separate check. An isolated native chat flow also successfully created and attached a session under the replacement assistant. A separate tool-generation error remains under investigation in the demo runbook. The initial insurance KB link was replaced with a previously empty custom KB for the telco scenario; insurance content was preserved.

Flow recovery remains separate

An inspection of 98 current flow definitions found 19 referencing the deleted assistant. Their content was not changed by the association repair. Inspect both executable actions and editor metadata, plus saved drafts and flow modules when preparing a flow migration.

Six of those flows also reference custom AI agents under the deleted assistant: FNOL-IVR-Demo, FNOL Multimodal Agentic Journey Dev, Triwest-benifits-coverage-agent-main-flow, TakedaDemo, HumanaHealthPlus QuickStart and Flight-Service-Assistant.

Recover the intended custom-agent configuration and versions before replacing those references. Changing only the assistant UUID inside a custom-agent ARN does not recreate the agent. Preserve flow backups and validate the intended call behavior before publishing migrated flows.

The later Consumer Cellular deployment created a separate native human-agent flow and moved +1 800-990-7974 to it. The backed-up original TakedaDemo remains active because +1 866-955-2247 still uses it. Other legacy flows still need their own recovery.

See also