Applied LLM Systems & Agents

You ask an agent to book the cheapest flight to Berlin. It books the 6 a.m. departure with two layovers — technically the cheapest, exactly as specified. The model did not fail; your specification did. That gap between what you said and what you meant is the defining engineering problem of systems that act: a chat model that misunderstands you wastes a reply, while an agent that misunderstands you spends money, writes to databases, and sends the email. This track is about building the machinery — and the guardrails — for LLMs with hands.

An agent, you will find, is a loop, not a bigger prompt: plan, call a tool, observe the result, repeat, under a step budget. The model proposes actions; tools execute them; and between the two sits the boundary — MCP — which type-checks every call before any side effect happens. Most agent bugs live at that boundary, not in the model, which is why the opening module has you run agents live against a mock clinic backend and watch exactly where they go wrong. From there the track turns to adaptation: the three levers for making a general model good at your task — prompt, fine-tune, distill — in order of escalating commitment and cost.

The closing modules face the consequences of autonomy in production. Applied LLMOps sets latency budgets, batching and routing for systems where one user request fans out into many model calls. And the healthcare capstone raises the stakes to their realistic maximum: an assistant touching GDPR Article 9 health data, where a right-to-erasure request must propagate through every derived copy — retrieval index, fine-tuned weights, logs. Autonomy is not a demo feature; it is a liability surface, and engineering it well is the point. Underlying all of it is the economics: every token is billed, reasoning tokens cost the most, and the levers of more tools, more skills and the right model per task are what keep an agent both capable and affordable.