Pelago Shipped a Serverless AI Care Assistant in Two Weeks
Cloud Platform EngineeringTwo weeks is not a timeline most teams associate with shipping a production AI system into a HIPAA-regulated environment. Pelago, a digital clinic for substance use disorder care, did exactly that — and the AWS Architecture Blog’s writeup of how they did it is a clean example of what a fully serverless, event-driven architecture buys you when the constraint isn’t compute, it’s speed of iteration under compliance pressure.
How It Works
Pelago’s care coaches manage dozens of concurrent member conversations, each requiring a response grounded in weeks of prior interaction history. Drafting those responses by hand was slow. Automating them without a human in the loop was a non-starter — clinically and legally. As the post puts it: “Every piece of feedback must be read, evaluated, and adapted by a human coach before it reaches a member.” The system had to generate suggestions, not send messages, and Protected Health Information could never leave Pelago’s AWS environment.
The architecture that came out of that constraint is entirely event-driven. A member message arrives through AWS AppSync, gets written to a Lambda function, and is simultaneously stored in Amazon DynamoDB (chosen for high-throughput writes — 100+ per second at peak — with single-digit-millisecond retrieval) and published to Amazon SNS, which fans it out to four separate Lambda subscribers: metadata storage, analytics, push notifications, and AI suggestion generation.
The suggestion-generation Lambda is where the AI work happens. It retrieves the relevant conversation history from DynamoDB and invokes a Claude model through Amazon Bedrock over VPC endpoints — keeping PHI off the public internet entirely. The generated suggestion is stored in Amazon RDS (MySQL), chosen specifically for its relational structure and suitability for analytics queries, rather than DynamoDB’s key-value model. Coaches then pull pre-generated suggestions through Amazon API Gateway when they open a conversation, and Amazon CloudWatch captures audit logs and performance metrics across the whole pipeline.
The team split languages deliberately: Python for the Lambda functions that call Bedrock, since Boto3 has native SDK support there, and TypeScript for the retrieval functions, to stay consistent with Pelago’s existing codebase. They also built in idempotency checks to prevent SNS’s at-least-once delivery guarantees from triggering duplicate model invocations — a detail easy to skip in a two-week build and expensive to discover in production.
The build itself broke into four short phases: two days on architecture and model selection, three days on core Lambda development, three days on integration testing and prompt refinement, and two days on deployment and monitoring. Performance held up under load — suggestion generation typically completes in under 4 seconds, coach retrieval in under 100 milliseconds, and the system absorbed an 8x message volume spike without any configuration changes.
What This Means for You
The interesting part of this case study isn’t that Bedrock can generate clinically useful drafts — it’s that the surrounding serverless plumbing is what made a two-week timeline realistic at all. Nobody on Pelago’s team was provisioning EC2 capacity, tuning autoscaling groups, or managing a message queue cluster. SNS fan-out plus Lambda subscribers gave them parallel processing of four independent workflows without writing any orchestration logic themselves, and DynamoDB’s automatic scaling absorbed an 8x traffic spike with zero intervention.
The polyglot Lambda choice is also worth noting for platform teams standing up their own AI-integration layer: there’s no requirement to force a single language across a serverless AI pipeline. Using Python where the SDK support is strongest (Bedrock via Boto3) and TypeScript where team familiarity matters more is a pragmatic split, not a compromise.
The compliance pattern generalizes past healthcare, too. Any team handling regulated or sensitive data that wants LLM-generated output needs the same core guarantee Pelago built: model calls that never touch the public internet, via VPC endpoints into Bedrock, combined with an architecture where the AI’s output is a suggestion a human reviews, not an action the system takes autonomously. That human-in-the-loop boundary was a design decision as deliberate as any service choice on the diagram.
The So What
The headline number here is two weeks, but the durable lesson is what serverless removed from that timeline: no capacity planning, no cluster management, no infrastructure decisions blocking the build. What was left to decide was entirely about the problem domain — which model to call, how to structure conversation retrieval, where the compliance boundary had to sit, and how to keep a human coach as the final checkpoint before anything reaches a member. For platform and cloud engineers evaluating serverless-first AI architectures, that’s the transferable takeaway: the fastest path from concept to a production AI feature in a regulated environment isn’t a leaner infrastructure stack, it’s an infrastructure stack you don’t have to think about at all, so the two weeks go entirely into the parts of the system that are actually novel.
Source: AWS Architecture Blog
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →