More Than a Chat Widget: An Agentic Communication Platform

After nearly a decade at Amazon, most of it in customer-facing roles at AWS, followed by almost two years Amazon Leo, I had hundreds of enterprise conversations about what a communication platform should do, and where customers had unmet needs. Using Modern AI tools I have been able to build this site as a working demonstration of some the concepts I have had in mind.

It is two layers:

1. Agent harness: a multi-tier AI assistant with privileges enforced by IAM rather than prompts, message pre- and post-processing for content policy, Bedrock integration, and admin observability. This is what powers agents inside every conversation and allows me to manage them.

2. Communication Hub: chat, phone, video, email, SMS, and the embeddable widget, all routing into the same persistent conversations. This is the engagement layer, where my users and I communicate on this site, but built in a way that is reusable for enterprise use cases.

Part 1: The Harness

Agents, message pre-processing, Bedrock integration, admin tooling. Every channel runs through the same pipeline.

Tiered assistants, enforced by IAM

Three tiers (guest, authenticated, admin), each in its own Lambda with its own role and model: Haiku for guest and intent classification, Sonnet for routine auth responses, Opus for complex intents (job analysis, consulting, technical depth). Though these can be adjusted for each tier to use different models per-intent to optimize cost and performance. A compromised guest cannot reach calendar, user data, or admin actions. The role does not grant them. The boundary is infrastructure, not prompt instructions.

Pre- and post-processing every message

Inbound messages are processed before any model sees them: PII is redacted (deterministic patterns with an LLM-judge fallback for ambiguous cases), intent is classified (with a fast-path bypass for greetings and acknowledgments), and prompt-injection attempts are filtered. Outbound messages get the same treatment in reverse: internal control tags stripped, and a single metadata flag on a message fans out an email or SMS so any part of the platform can trigger a notification without its own notification stack. For example, my admin conversations use this to alert me on new users and operational issues.

Admin observability

Every response from assistants is captured and scored by a two-pass evaluation pipeline (composite quality, dimension breakdowns, intent match, compliance pass rates). Results are sent to my admin conversations so I know when issues are detected.

On top of proactive notifications, my admin dashboard provides visibility into overall cost, messaging and meetings operational metrics, and evaluation at the assistant and intent level so I can see how each tier is performing on different intents and multi-turn tasks. This includes response times, measuring each leg of the message journey.

Part 2: The Communication Hub

On top of the harness, I added multiple communication channels to enable engagement.

One conversation, many channels. Many communication tools treat each channel as its own thread. The Communication Hub tracks context across every channel: messages from the widget, email threads, and meeting transcripts all land in the same conversation, shared by all parties. Users can switch from chat to a scheduled call, send a follow-up email, fire off an SMS, and the assistants and I see one continuous history across every surface.

When needed, users can also receive context specifically for them. Assistants can send targeted messages visible only to one participant. I use this when a user adds me to a conversation: the assistant gives me a quick private summary of who they are, their role, and what they want to chat about before I reply.

For enterprises

This design was driven by the need I have seen for enterprises that have already invested in CRM, ticketing, and voice systems that desire the ability to provide a consistent interface for customers and internal users without removing the ability for different business teams to use the tool of their choice. What they need is a customer-facing experience and an administrative control plane that consolidates across those tools without forcing the backend teams to move. The same shape scales: many customers each with their own persistent multi-channel thread; many backend teams each working in their existing tooling; the harness sits between, applying consistent assistant behavior and observability to every interaction.

Part 3: What it looks like in practice

A hiring team member who shared a job description signs in

Users that register and provide a job description will start with a conversation built around that role, including job fit assessment as the intro message.

The conversation drifts to a different topic

Mid-conversation, the user shifts topic from a job fit discussion to how the site itself is built. The assistant notices, names the new topic, and offers a clean thread so context does not bleed across.

When the user changes topic, like from job fit to site architecture, the assistant detects the drift and offers to create a separate conversation to keep context clean.

A user asks to talk to me

When a user asks to speak with me, the assistant adds me to the conversation. From the user's side, the assistant announces the transition and explains the new interaction model: @mention the assistant for private answers, or @all to address everyone.

From the user's side: the assistant announces when I join and explains how they can still reach the assistant privately or address everyone.

From my side, the assistant sends a targeted message visible only to me with the context I need to catch up: who the user is, what they want, the conversation so far, and a link to the thread. I reply publicly so my answer lands in the shared thread.

From my side of the same conversation, the assistant has sent a targeted briefing the user cannot see, giving me the context to catch up. I reply publicly so my answer lands in the shared thread.

Built with

AWS services: Amazon Chime SDK (messaging, meetings, PSTN), Bedrock Claude (intent classification, response generation, evaluation), Cognito, DynamoDB, Aurora PostgreSQL, CloudFront, Lambda, and CDK for infrastructure. The codebase was built using Claude Code.

Let me know what you think

If you do want to learn more about what I have built and try the features, you can sign in with LinkedIn. Provide a job description if you want the full experience.

Even if you aren't considering hiring, reach out to me directly or sign in to read and provide feedback. I would love to hear what you think.