Building Multi-Agent AI Systems on AWS Bedrock with Convogent

Barge-in remains the hardest unsolved piece: when a customer interrupts mid-response, Bedrock's supervisor has no built-in signal to cancel an in-flight collaborator invocation, so Convogent handles interruption at the telephony and WebRTC layer instead of inside the agent graph. Bedrock's multi-agent collaboration is also bound to the regions where Bedrock Agents itself runs, which constrains residency options for customers whose AWS account sits in an unsupported region. Cost attribution is a third open question, since an escalation-worthy call can trigger several collaborator invocations plus a connector call, and per-call cost tracking across that chain is still manual today.

‍

Key takeaways
‍

1. Map agent roles to architecture layers, not to features. Convogent's four collaborator agents correspond to distinct rows in the intelligence engine, which is why adding a channel does not require adding an agent.
   ‍
2. MCP connectors turn action groups into reusable integration points. A new CRM behind the same connector-agent role needs a new schema, not a new agent.
   ‍
3. Dual memory needs two different Bedrock mechanisms. Session state handles a single call; AgentCore's managed memory handles continuity across calls and channels.
   ‍
4. Gate actions before they execute, not after. Running the compliance-agent as a pre-action check on every connector call matches Aivar's ReVAct governance model and avoids irreversible mistakes on a live call.
   ‍
5. Provider slots isolate the reasoning model from the agent graph. Changing the LLM behind an agent role is a configuration change, the same abstraction Convogent applies to STT and TTS vendors.

Convogent's seven provider slots cover text-to-speech, speech-to-text, and the LLM itself, with Claude, Llama, and Qwen as configurable options behind the same intent-nlu-agent and knowledge-agent roles. We run Claude through Bedrock as the default reasoning model for both agents, since the supervisor pattern depends on precise tool-selection and Claude's function-calling accuracy directly determines how often the intent-nlu-agent routes a turn to the wrong collaborator. Swapping the underlying model is a slot configuration change, not an agent graph rewrite, which is the same abstraction Convogent gives customers for STT and TTS vendors.

Convogent's integrations layer exposes CRM, EHR, and payments systems as MCP connectors rather than one-off API integrations per customer, and we wired those connectors into Bedrock as action groups with OpenAPI schemas behind AWS Lambda functions. That pairing means a new customer with a different CRM does not require a new agent, only a new connector definition behind the same connector-agent role.

‍

yaml

paths:

  /crm/customers/{customerId}/reschedule:

    post:

      operationId: rescheduleAppointment

      parameters:

        - name: customerId

          in: path

          required: true

          schema:

            type: string

        - name: newDate

          in: query

          required: true

          schema:

            type: string

            format: date

      responses:

        "200":

          description: Appointment rescheduled

‍

Bedrock Agents parses this schema and decides when a conversation has gathered enough slots to call rescheduleAppointment, which replaces the slot-filling state machine we would otherwise have had to hand-build for every one of Convogent's supported use cases: appointment scheduling, collections and payment reminders, outbound lead qualification, and BFSI onboarding.

‍

‍

Figure 2: The action group schema is the single translation point between a spoken request and a backend API call.

Convogent's intelligence engine documents a dual memory architecture, and in practice that means two different Bedrock mechanisms doing two different jobs. Short-term memory persists slot values and turn history for the life of a single session through Bedrock's sessionState, so a customer who says "reschedule that to Thursday instead" three turns after naming an order number still has that order number available. Long-term memory persists across sessions and channels, so a customer who called about a claim yesterday and opens a chat today does not repeat context, and we back that layer with Bedrock AgentCore's managed memory rather than a custom database, since AgentCore already handles episodic recall across sessions.

‍

python

response = bedrock_agent_runtime.invoke_agent(

    agentId=SUPERVISOR_AGENT_ID,

    agentAliasId=SUPERVISOR_ALIAS_ID,

    sessionId=call_session_id,

    inputText=transcribed_utterance,

    sessionState={"sessionAttributes": {"customerId": customer_id}}

)

Convogent's validated production capabilities, sub-500ms latency without a tool call, under 1.2 seconds with one, and 1,000-plus concurrent sessions, hold across the four-agent topology because narrowing each collaborator's tool list keeps its planning step short enough to stay inside that latency budget. The built-in QA framework runs synthetic test personas with configured moods and languages against every agent before a flow ships, comparing expected against actual responses with reasoning attached, which catches a misrouted collaborator before it reaches a live call. We do not publish per-customer completion rates externally, but the QA regression suite is what gives us confidence to change a collaborator's prompt without re-validating the entire graph by hand.

Convogent's architecture runs in five layers: a channel layer for voice, chat, in-app, and email; a telephony and WebRTC layer handling SIP, Twilio, and LiveKit; a speech processing layer for voice activity detection, speech-to-text, and diarization; an intelligence engine; and an integrations layer for connectors and knowledge retrieval. The Bedrock agent graph lives entirely inside the intelligence engine, which is where intent classification, dual memory, graph reasoning, and the compliance engine sit. Everything below that layer, telephony and speech processing, stays provider-agnostic through seven configurable slots per flow, so the same agent graph can sit behind ElevenLabs or Cartesia for text-to-speech without any change to the Bedrock configuration.

‍

json

{

  "supervisorAgent": "convogent-intelligence-engine",

  "collaborators": [

    { "name": "intent-nlu-agent", "role": "classify utterance, extract slots" },

    { "name": "knowledge-agent", "role": "answer from RAG knowledge base" },

    { "name": "connector-agent", "role": "call CRM, EHR, payments via MCP" },

    { "name": "compliance-agent", "role": "gate actions, mask PII, escalate" }

  ],

  "collaborationMode": "SUPERVISOR_WITH_ROUTING"

}

‍

‍

Figure 1: The Bedrock agent graph occupies one layer of five, not the whole platform.

Convogent's compliance engine handles PII scrubbing and sits inside the same intelligence engine layer as the agent graph, and we run it as a pre-action gate rather than a post-hoc filter. Every time the connector-agent proposes an action group call, the compliance-agent validates the parameters against masking rules and escalation criteria before Bedrock invokes the underlying Lambda function, which mirrors Aivar's ReVAct governance model of synchronous reasoning, validation, and action rather than logging a violation after the API call already ran. On a live voice call that ordering matters more than it would in a batch process, because there is no undo once a Lambda function has sent an SMS or updated a CRM record.

‍

‍

Figure 3: The gate sits before execution, not after it — the same ordering ReVAct applies across every Aivar accelerator.

Bedrock's supervisor and collaborator pattern let Convogent scale the number of things a single call can accomplish without scaling the complexity inside any one agent's prompt. Mapping collaborators directly onto Convogent's existing intelligence engine layers kept the agent graph from becoming a second architecture layered on top of the first, and the unresolved work sits at the boundary between that graph and the telephony stack. Convogent's implementation service is listed on AWS Marketplace for teams that want this pattern deployed inside their own AWS account rather than built from scratch.

A voice call from a banking customer can move from an order status check to a KYC document request to a callback confirmation inside ninety seconds. A single-agent chatbot pattern degrades under that path because every tool definition, every knowledge base chunk, and every prior turn compete for the same context window, and a model juggling twenty tool schemas picks the wrong one more often than a model choosing between four. Bedrock's multi-agent collaboration feature, generally available since March 2025, gave us a managed way to split that load: a supervisor agent classifies each turn and routes it to a narrow, specialized collaborator agent instead of asking one agent to hold every capability at once.