Two weeks ago I said AI Practitioner belongs in the first three certs you sit. A few of you replied asking what the layer above that actually looks like once you have the grounding.
This week is the answer. I shipped a working example.
The task I set myself was simple to describe. Harder to pull off. I wanted a multi-agent customer service platform on Bedrock that survived the second question. Not the version that impresses in a slide and falls over in the follow-up. What came out of it is now public on aws-samples, and the full decision-by-decision build is up on AWS Builder.
The write-up runs long. Here are the seven decisions I would tell you about first.
1. Strands, not classic Bedrock Agents.
Amazon Bedrock has two ways to build multi-agent apps right now. The classic Bedrock Agents multi-agent collaboration API is entering maintenance mode. The current path is the Strands Agents SDK sitting on top of Bedrock. Plain Python, portable, testable outside the console. If you are picking a platform today, pick the one that is still being invested in.
2. Agents as tools.
There are a few patterns for multi-agent orchestration. I picked the simplest one that still scales: a supervisor agent that classifies each query and calls specialist agents as tools. Billing, scheduling, and escalation each live behind a callable tool. Routing is just the supervisor picking which one to invoke. Nothing hidden, nothing bespoke.
3. Different models for different jobs.
The supervisor runs on Claude Opus 4.6, because routing is the intelligence-hungry step. The specialists run on Claude Sonnet 4.6, where latency and cost matter more than raw depth. Tiered models is a boring optimisation that pays back on every single turn.
4. A deterministic classifier with a "don't know" floor.
Before the LLM ever sees a query, a plain keyword scorer classifies intent. If the top score is below 0.34, it returns UNKNOWN and the supervisor asks a clarifying question rather than guess. This was the smallest change that had the biggest impact on quality. Giving the system a safe way to say it does not know yet, so it does not confidently route a billing question to scheduling.
5. RAG on billing and escalation, not scheduling.
Billing and escalation questions get grounded in policy docs via a Bedrock Knowledge Base. Scheduling does not, because scheduling is stateless: check availability, book, cancel. There is nothing to retrieve. The default instinct is to put RAG on every specialist. The right instinct is to put it on the ones that need it.
6. One guardrail. Every call.
A single Bedrock Guardrail sits in front of every model call in the system. Content filters at HIGH. Prompt-attack detection at HIGH on the input side. Sensitive info like phone numbers, cards, and UK sort codes gets redacted rather than the whole answer blocked. Denied topics for the ones that would obviously go badly. It is one guardrail because if the safety configuration lives in seven places, one of them will drift.
7. Guardrails for hard safety, prompts for soft policy.
This one I only landed after trying it the wrong way. I built two custom denied topics: one for "competitor mentions", one for "other customers' data". Both went in the bin. A topic classifier cannot see whether the caller is authorised, and the 200-character topic definition budget is not enough to be precise. Both of those belong in the agent system prompts and in the tool layer, where the code can enforce authorisation properly. Guardrails do hard safety, prompts do soft policy. Do not blur the line.
Decisions beat features.
None of the seven above is a feature that would go on a slide. Each one is a choice between two plausible paths where the wrong one costs you weeks. That is the honest experience of shipping something on this stack. Features are easy. Decisions are the work.
The full build
The write-up on AWS Builder Centre walks through every decision with the code, including the ones I did not fit in here (portable runtime for demo and production, tiered CloudWatch alarms, contextual grounding at 0.7 as detect-only). The repo on aws-samples is deployable end to end if you want to clone it and run your own.
→ Full write-up: Multi-agent customer service on Amazon Bedrock AgentCore
💬 If you already have AI Practitioner or above, this is the layer to build in next. If you do not, that is your prerequisite.
Reply with AGENTS and your current AI cert level (Practitioner, Associate, MLE, none). I will tell you the smallest first build I would put on top of it. I read every reply.
Know someone who has been circling agents without shipping one? Share your referral link. 1 friend subscribes, you get a free LinkedIn Profile Optimisation Checklist.
{{rp_refer_url}}
Shola
P.S. Last three Tuesdays I said this newsletter is weekly again. This is week four of the promise. Feel free to keep counting.