THEORY · 30 minutes
Name the skills you gained building the triage assistant, choose the next learning path that fits your current limitation, and keep only the resources worth keeping open
When I built my first system that mattered at work — an internal dashboard that helped a support team find answers faster — I had no idea it would become the spine of everything I do now. That dashboard grew into a de-identified support-automation RAG service that real people depended on, and it taught me the exact loop you have spent this path building: read an incoming message, answer it from what you know, route it when you can't, and escalate the moment you are unsure.
I want you to notice that you have now built that same loop yourself. Across the last few modules you stood up a de-identified customer-support triage assistant: it takes a customer message, answers from a small knowledge base, classifies and routes it, and hands off to a human when its confidence is low. That is not a toy pattern I invented for a lesson — it is the shape of the first system I ever shipped that real users relied on.
In this final module I want to do three honest things with you: name what you actually built, point you at the paths I would take next, and hand you only the resources I genuinely keep open while I work.
You built a working loop, not a demo. The triage assistant you assembled follows the same core pattern behind a great deal of real support tooling — answer, route, escalate. Almost everything past here is refinement of that loop.
I want you to be precise about your new skills, because vague confidence fades while specific competence compounds.
You can make a real call to a language model. You wrote client.messages.create(...) against the Anthropic SDK with a real model id and read the response back — no abstraction layer pretending on your behalf.
You can expose data and actions through an MCP server. You learned why a resource (read-only knowledge the assistant can look at) is a different thing from a tool (an action the assistant can take), and you split your triage assistant along that line on purpose.
You can wire a model and a server together into an agent that decides. Your assistant does not just echo text back — it classifies the incoming message and chooses whether to answer it or escalate it.
Now notice what is not on that list. You did not fine-tune a model, run a cluster, or ship to thousands of users, and I am not going to pretend you did. What you have is the honest foundation I had when I started — and it is more than enough to build the next thing.
Before you read on, answer this for yourself: in the assistant you built, which single decision most determines whether a frustrated customer gets helped or ignored? Hold your answer — the final quiz comes back to it.
These are real paths on this site, and I have ordered them the way I would actually learn them.
Go deeper on the server layer first. Your triage assistant leaned on a single, simple MCP server. MCP Server Fundamentals rebuilds that server properly — resources, tools, and the patterns I reach for when a server has to do real work.
Then make the agent reason, not just react. Agentic AI Workflows is where your "escalate when unsure" instinct becomes a real design discipline: planning, reliability, and keeping a human in the loop on purpose.
Then learn to keep it maintainable. 12-Factor Agent Development is the path I wish I'd had early. It is about writing agents you can still understand in six months instead of clever code you cannot.
Give your assistant a memory. Agent Memory Systems tackles the obvious next limitation: your triage assistant forgets every customer the instant the conversation ends.
Finally, ship it for real. Production AI Systems covers deployment, monitoring, and scale — the work that turns the loop you built into something other people can depend on.
You don't need all of them. Pick the one that matches the limitation that annoys you most right now. That specific irritation is the best curriculum you have.
The fastest way to cement this path is to keep working on the same triage assistant instead of starting something new. Here is how I would grow it, smallest step first.
Add a second knowledge source. Right now your assistant answers from one small knowledge base. Point it at a second one and make it decide which to consult. You will feel immediately why routing is its own skill.
Read its escalation calls by hand. Log every time the assistant escalates and every time it answers, then actually read them. You are not chasing a number — you are checking whether its confidence matches reality. This is the most useful and least glamorous work in the field.
Let a human correct it. Add a way for a support agent to mark an answer "wrong" and store that correction. You have just built the seed of every feedback loop I use today.
Give it a face. Wrap the assistant in the smallest possible web form so a non-engineer can try it. Watching someone who didn't build it actually use it will teach you more than any test suite.
Resist the urge to rebuild from scratch. Every one of these extends the system you already understand. Starting a brand-new "dream app" usually means re-learning the basics instead of advancing past them.
I am only listing things I actually use. A short, true list beats a long, padded one.
For the model:
For MCP:
For Python:
asyncio documentation — because real MCP servers are asynchronous, and this is where that finally clicks.Read source, not just docs. When I'm stuck, I read the reference MCP servers above before I reach for another tutorial. Working code answers questions that prose cannot.
I build in the open, and I would rather point you at real places than a list of dead invite links.
Here is the question I want you to sit with before you move on: the triage assistant you built decides when to escalate to a human. Where should that line sit — and who pays the price when you draw it wrong? Set the threshold too cautiously and you bury people in needless handoffs; set it too confidently and a real problem gets a canned reply. I do not have a universal number for you, and anyone who claims one is selling something. Deciding that line, for a specific system and the specific people it serves, is the actual job. Welcome to it.
Almost there. You started not knowing what an AI system was; you finish having built one — the same support-triage loop that launched my own work. Try the extension challenge below, take the final check, and then go pick the next path that scratches the itch you feel right now.
Nice work. Here's what's next.
Back to this pathOr book the diagnostic call