October 13, 2026AWS Builder Loft, San Francisco

Not so long ago I had a customer who needed to serve an open model inside their own AWS account. They already ran ECS for everything, so the question was whether that was enough, or whether they had to bring in Kubernetes or a managed ML platform first. It was enough. In this talk I will show how we put Qwen2.5-7B behind an ALB on ECS GPU instances with vLLM, and what broke on the way to production. The build was the easy part. Three things surprised us, and in each case the measurement disagreed with the obvious answer. Distribution: a scale-out has to get 15 GB of weights onto every node. A peer-to-peer swarm looked like the clever answer, so I built a test rig and ran it at 4, 8, 16 and 32 nodes. Plain S3 in the same region beat it by 11.7x at 32 nodes. Disk: downloads plateaued at 1.05 Gbit/s and we blamed the network. The network was fine at 4.4 Gbit/s. A default gp3 root volume caps at 125 MB/s, and that number decides your cold start. Autoscaling: the GPU scaling policy sat in INSUFFICIENT_DATA and never fired. On Amazon Linux 2023 a CloudWatch agent running as a sidecar cannot see the GPU, so nvidia-smi never runs and the metric never publishes. I will show the numbers behind each one and the fixes we shipped in our open source Terraform module, and close with a checklist you can run against your own service.

Most data platforms assume someone will operate them. Plenty of organizations do not have that person. No dedicated platform team, no on-call rotation, and no budget to create either. Whatever gets built has to run itself or it stops running. That constraint shaped every decision I made. This talk covers how I automated the data lifecycle of an enterprise data lake on AWS, what I deliberately left manual, and what broke along the way. I walk through what got automated, in the order I built it: ingestion that absorbs schema changes from systems nobody controls, cataloging and classification on landing, partitioning and compaction on a schedule rather than on a ticket, and retention and expiry driven by the actual records schedule. Then the honest part: what I chose not to automate, and why some approvals should stay human no matter how good the tooling gets. Attendees leave with a reference architecture built on AWS native services, a clear view of which lifecycle stages are worth automating first, and a realistic account of what a very small team can actually keep running.

Fashion color trend forecasting has traditionally relied heavily on qualitative expert judgment, making it difficult to consistently determine which emerging colors will achieve broader consumer adoption. This project delivers an AI-powered fashion color trend forecasting system that combines computer vision, NLP, machine learning, and automated visual intelligence to support earlier, data-driven retail decisions. PyTorch-based computer vision detects garments and extracts dominant colors, standardized in the CIELAB color space. NLP analyzes Instagram and X content to identify color mentions, themes and social momentum, while Google Trends provides additional indicators of consumer interest. The solution runs on AWS with Amazon S3 as the data lake and Amazon RDS for PostgreSQL storing structured metadata, engineered features and model outputs. Logistic Regression, Random Forest and Gradient Boosted Trees estimate the probability that an emerging color becomes a high-impact trend, and the system automatically generates AI-powered mood boards from predicted colors and harmonized palettes.

You can build a petabyte scale lakehouse that AI agents can safely query using nothing but AWS services. This session covers how we did it at UC Irvine, what AWS gave us out of the box, and the gaps we had to fill ourselves. Student records, research data, and operational systems land in the same lakehouse, owned by departments that do not report to each other, under rules that differ per dataset. We walk through cataloging and classification in AWS Glue, Apache Iceberg on S3, fine-grained row and column permissions in Lake Formation, and how partitioning and compaction had to be reworked around how agents query rather than how dashboards were built. We close with where AWS native services ended, what we built to cover the gap, and the readiness checks we run before any agent touches sensitive data.

One AWS account buys the Savings Plans and Reserved Instances for an organisation of 177. The discount lands wherever the usage is; the invoice lands in one place. Allocating that fairly has an unforgiving property: a number that's three cents wrong doesn't look wrong. It looks like a number, and it goes to Finance. This is how I built that allocation system with Kiro over ten months, using its spec workflow rather than conversational prompting. Every change went through requirements.md, design.md and tasks.md. 16 specs and 356 tasks later, eight months of allocations have published balanced to the cent. I'll show real artifacts from the repo, then the honest half: six AWS billing traps that were live in production and balanced perfectly while being wrong, and the one the process missed, which became a Kiro steering rule that caught the same mistake one level down eight months later.

Every AI demo starts from scratch. That's the easy part. How do you use AI to build new features in a large, legacy, complex codebase? After all, that is what most production software is: years of accumulated decisions, sparse documentation, and context that only exists in the heads of the people who wrote it. This session covers tips, tricks and the thinking behind getting agents to do useful work. We'll explore what goes wrong when an agent lacks the right context, or is given more decisions than it can handle. Let's get things back in balance.

The Topology Composer (tc) open source tooling started its life before the agentic AI era to better design, build, and deploy complex serverless systems. It describes a system as a composable tree of topologies whose elements map to AWS serverless services: API Gateway routes, EventBridge rules, SQS queues, AppSync resolvers and channels, Step Functions, Lambdas, and DynamoDB/S3 stores. It turns out this level of abstraction fits the agentic age: it gives developers and agents a shared way to describe and reason about a system, and, like strong typing, keeps the agent honest and aligned with the developers' intent. Separating the abstract representation from deployment mechanics means we can deploy via Terraform, CloudFormation/CDK, or direct SDK code. The talk gives a quick overview of tc, its abstractions and workflows, then dives into how it works with LLMs and agentic systems across a system's lifecycle.

AI agents fail differently from traditional software. Production traces can tell us what happened, but they cannot tell us whether changing a model, prompt, tool, or agent harness will fix the problem without introducing another regression. In this talk we move from passive agent observability to executable simulations and build a continuous AgentOps evaluation loop on AWS. We start with patterns for turning real-world agent failures into repeatable benchmark tasks with isolated environments and explicit verifiers, show how to represent those tasks in the open-source Harbor task format, and map the lifecycle onto an AWS reference architecture: Amazon Bedrock AgentCore Runtime for production agents, AgentCore Observability and CloudWatch for traces, Harbor with isolated EC2 environments for simulations, and versioned agent configurations for controlled experiments and releases.

Every agent demo works. The demo is not the hard part. The hard part is the Tuesday three weeks later when the same agent, on a real user's request, calls the wrong tool, hallucinates a confident answer, loops forever, or quietly does something it wasn't authorized to do. We'll share a defense-in-depth playbook for reliable agents on AWS, structured as two reinforcing halves. First, containment: content safety with Amazon Bedrock Guardrails, tool-use authorization so an agent can only do what the user could, and why you guide an agent back on track rather than hard-block it. Second, verification: LLM-as-judge for the semantic checks guardrails can't express, the fail-open vs fail-closed call, and evaluation: offline eval sets, online sampling, and how teams move from a 15-20% false-reject rate to 95%+ by measuring instead of guessing. You'll leave with a layered reliability checklist you can apply to any agent, and a candid map of what's production-ready today versus still frontier.