Add agent-to-agent calling to Amazon Connect agent workspace with a 3P app. Improve collaboration, reduce handle time, and set up smarter AI workflows.

Agent-to-Agent Calling in Amazon Connect Workspace
Most contact centers spend months tuning bots, IVR flows, and knowledge bases—then agents still end up shouting across the floor (or spamming Slack) when a live call gets tricky.
Agent-to-agent calling inside Amazon Connect agent workspace fixes a surprisingly expensive problem: internal collaboration latency. When an agent can’t quickly pull in a specialist, a supervisor, or a bilingual teammate, your customer feels the delay. Handle time rises, transfers get sloppy, and the “AI-powered customer service” story starts to crack.
This post breaks down a practical pattern: enabling agent-to-agent calling as a third-party (3P) app embedded directly in the workspace. It’s not just a telephony feature. It’s an internal workflow upgrade that makes every other automation initiative (AI assist, summarization, routing, QA) land better.
Why agent-to-agent calling is an AI enabler (not a side feature)
Agent-to-agent calling matters because it’s the human “escalation API.” If you’re building a modern AI contact center, you’re already optimizing:
- Deflection (bots handle routine)
- Assist (AI helps agents during complex)
- Routing (customers land with the right skill)
But none of that eliminates the messy middle: edge cases, policy exceptions, fraud flags, VIP saves, or “this customer is escalating fast.” In those moments, speed beats perfection.
A fast internal call path does three things AI initiatives often need:
- Preserves context: The agent stays in one workspace instead of bouncing between tools.
- Reduces rework: Fewer cold transfers and fewer “let me check and call you back.”
- Creates cleaner operational data: You can track internal collaboration events and correlate them with customer outcomes.
A contact center with great automation but poor internal collaboration still feels slow to customers.
What you’re building: a 3P “call a coworker” panel inside the agent workspace
The AWS approach (from the source article) uses a lightweight widget embedded into the Amazon Connect agent workspace. Agents can:
- Search peers
- See optional availability/presence
- Initiate a call without leaving the workspace
Architecture at a glance
Here’s the core pattern, simplified into responsibilities:
- Amazon Connect: Runs the voice channels and the internal contact flow.
- Kinesis (optional but common): Streams agent events / contact trace records.
- DynamoDB: Stores agent presence records.
- AppSync + Lambda resolver: Provides a simple presence API (read/write).
- API Gateway + Lambda: Provides a secure “initiate internal call” endpoint.
- React 3P app: The embedded UI panel in the workspace.
This design is popular because it keeps the user experience tight (one screen) while letting you extend the workspace with your own logic.
How it works end-to-end (the call path in plain English)
An agent clicks “Call” next to a coworker.
- The React widget calls your API Gateway endpoint.
- API Gateway triggers a Lambda function.
- Lambda uses Amazon Connect’s API to start an outbound voice contact that points at an internal contact flow.
- The contact flow looks up the destination agent and uses Transfer to Agent (or Transfer to Phone Number, depending on your design).
- Meanwhile, presence data (optional but powerful) is read from DynamoDB via AppSync, so the widget can display who’s available.
The key idea: the widget doesn’t “call the agent” directly. It asks Amazon Connect to start a controlled internal call through a contact flow, which keeps routing and governance in the contact center platform.
Implementation blueprint (what to build, what to decide)
If you want this working in a real contact center, treat it like a product feature. The AWS steps are solid; what most teams miss is the decision layer: what counts as available, who can call whom, and how you’ll audit it.
1) Presence model: decide what you actually need
The reference build stores presence in a DynamoDB table keyed by business unit and agent login (example fields include AgentARN, AgentStatus, names, timestamp).
A practical presence model for internal calling should answer:
- Is this agent logged in?
- Are they Available or in an After Call Work / Busy state?
- Are they in the same queue / skill group (optional)?
If you keep it too detailed, you’ll waste time chasing “perfect” presence accuracy. If you keep it too simple, agents will spam unavailable peers.
My stance: start with a minimal presence indicator (Available vs Not Available) and add nuance only if it changes behavior.
2) AppSync + Lambda resolver: keep the API clean
The source uses a Lambda resolver pattern where fieldName routes to getAgentStatus or updateAgentStatus.
That’s a good fit when you want:
- Simple CRUD on presence records
- Low operational overhead
- Easy extension later (e.g., adding “last status change”)
If you already run a broader agent desktop backend, you can also serve presence via your existing API layer. The important part is the contract: the widget needs fast reads and predictable fields.
3) Amazon Connect contact flow: treat it like a policy engine
The contact flow that routes internal calls is where you control safety and consistency.
Add checks here, not in the UI:
- Only allow calls within the same business unit
- Block calls to certain roles (or require supervisor-only)
- Route to a fallback queue if the agent isn’t reachable
This is also where you can inject AI-adjacent enhancements later, like:
- Auto-tagging “internal assist” interactions
- Storing a short “reason for call” field for analytics
- Triggering a real-time supervisor alert on specific categories
4) API Gateway + Lambda initiation: secure it like it’s customer-facing
The example Lambda uses startOutboundVoiceContact with environment variables such as instance ID, contact flow ID, and a source number.
This endpoint becomes part of your agent tooling surface area, so lock it down:
- Require workspace authentication and enforce agent identity
- Validate the target agent ID (no arbitrary dialing)
- Apply throttling to prevent accidental call floods
Rule of thumb: if the API can start a call, treat it as sensitive as payment workflows.
5) The React 3P app: keep it boring and fast
The widget should feel native: quick search, obvious availability, one click to call.
A few UX patterns that reduce chaos:
- Sort by availability first, then by team
- Add a short “Call reason” dropdown (3–6 options)
- Show “Already on a customer call” as distinct from “Offline”
Also: don’t let this turn into a second CRM inside the workspace. It’s a collaboration nudge, not a new platform.
Operational impact: where you’ll see the numbers move
Agent-to-agent calling improves customer experience indirectly—by improving agent execution.
Here are the metrics I’d expect to move first if you implement this well:
- Average handle time (AHT): tends to drop when agents can get answers quickly instead of searching or transferring.
- First contact resolution (FCR): rises when specialists can be pulled in at the moment of need.
- Warm transfer rate: improves because agents can coordinate before transferring.
- Supervisor interruption load: becomes more controlled if you gate calls and build escalation paths.
Even if you can’t attribute every improvement to the widget, you’ll feel it in daily operations: fewer “where do I send this?” moments and less customer dead air.
How this connects to AI in customer service (the next steps that actually matter)
Agent-to-agent calling is a foundation move. Once you have a reliable internal collaboration surface inside the agent workspace, you can add AI and automation in ways that feel practical instead of flashy.
AI enhancement ideas you can add without re-architecting
-
AI-generated “assist request” summary
- When the agent clicks Call, auto-generate a 1–2 sentence summary of the customer situation and attach it to the internal interaction record.
-
Smart suggestions for who to call
- Based on contact reason, sentiment, language, and queue, suggest the top 3 experts.
-
Post-call collaboration analytics
- Track how often internal assist happens, for which intents, and whether it reduces repeats.
-
Quality and coaching triggers
- If an agent initiates internal calls unusually often for a certain issue, that’s a coaching signal (or a knowledge base gap).
The broader theme for an AI contact center is simple: automation works best when humans can coordinate quickly when the automation reaches its edge.
Common questions teams ask before rolling this out
“Should we just use chat instead of calling?”
Chat is great for low urgency. Internal calling wins when the customer is live, emotions are rising, or the issue is multi-step. You’ll likely want both, but calling is the fastest path to resolution.
“Do we really need presence?”
You can launch without it. But even a basic “Available” indicator reduces failed attempts and frustration. Presence is a small build with outsized UX payoff.
“Will agents abuse it?”
They’ll overuse it if you don’t set rules. Put guardrails in the contact flow and measure internal call volume by queue/team. If one group spikes, it’s either a training gap or a process gap—both fixable.
Next steps: make internal collaboration part of your AI roadmap
If you’re building AI into customer service, don’t treat internal workflows as an afterthought. Agent-to-agent calling in Amazon Connect agent workspace is one of those unglamorous upgrades that makes everything else—AI assist, routing, and knowledge—work better under pressure.
A practical rollout plan for January (when many teams reset goals and staffing models) looks like this:
- Pilot with one business unit and a small set of agents
- Start with search + click-to-call, then add presence
- Add audit logs and simple reason codes
- Review internal call analytics monthly and tune skills, knowledge, and routing
If you want internal collaboration to feel like part of an intelligent contact center, build it into the workspace, instrument it, and treat it like a first-class customer experience feature.
Where in your current agent workflow do customers feel the “hold please” pause most often—and what would change if an agent could pull in the right teammate in under 10 seconds?