Move Beyond AI Demos.
Ship a Production-Ready Agentic AI System.

You already know what an agent is. This week is about what surrounds it. The model is one component; production behaviour is decided by the harness around it — instructions, runtime state, orchestration, tools, context, permissions, validation, budgets and recovery. You convert a business use case into functional and non-functional requirements, decide honestly what belongs inside a graph versus plain deterministic code, and design the architecture before writing it. Then you build the runtime: typed state contracts, structured execution, loop protection, iteration and token budgets, checkpointing and resumable workflows — deterministic control wrapped around a probabilistic model.

Prompt engineering is one small part of a larger discipline. Context engineering is deciding what enters the model's window at all — system instructions, conversation history, agent state, tool results, retrieved knowledge, memory, and output from other agents — and what gets budgeted, compressed, compacted or left out. You then separate working state from memory, decide what should persist and what must never persist, and build an agent runtime with durable execution: checkpointing, pause and resume, long-running work and human approval pauses. Retrieval appears here as one source of context among several.

A tool that works in a notebook is not a tool that survives production. You build reliable tool contracts with structured schemas and Pydantic validation, then wrap them in execution policy: allowlists, read versus write separation, idempotency, retries with backoff, timeouts, circuit breakers, rate limits and execution budgets. You cover where MCP genuinely belongs — and where a direct function call is the better engineering choice. Then the concept widens: Tool Gateway → MCP Gateway → Agent Gateway, a policy and control plane between agents and the tools, models, services and other agents they reach for. Finally, identity: user identity versus agent identity, delegated authorization, least privilege, and sandboxed execution boundaries.

Production agent workflows run for minutes, not milliseconds. The flagship system becomes a FastAPI service with Celery workers, queue design, job state, progress streaming, cancellation and resumption. Then the distributed-systems reality: one user request fans out into multiple agents, multiple model calls and multiple tool calls, so agent workloads amplify infrastructure pressure in ways ordinary CRUD services do not. You cover backpressure, load shedding, admission control, retry storms and cascading failure — and set SLIs, SLOs and error budgets for things that actually matter: task success rate, p95/p99 latency, tool success rate, cost per successful workflow. If you have run production services before, this is the week your existing experience pays off directly.

Three disciplines that decide whether anyone trusts the system. Evaluation starts with golden datasets, output quality, retrieval, tool-selection and trajectory evaluation, deterministic checks, LLM-as-judge design and CI eval gates — then becomes continuous: production traces feed categorised failures, failures become new eval cases, changes are regression-tested before redeployment. Agentic observability means a trace that spans request → agent → model → tool → MCP → retrieval → sub-agent, instrumented with OpenTelemetry for vendor-neutral traces alongside Langfuse and LangSmith. Agentic security goes well past generic prompt injection into goal hijacking, excessive agency, context and memory poisoning, privilege abuse, exfiltration and unsafe code execution — taught as threat modelling and blast-radius reduction, not a cybersecurity specialisation.

AgentOps is the operational discipline around shipping and evolving agents. You containerise the API, workers and supporting services, wire CI/CD with automated tests and evaluation gates before release, and handle the versioning problem that ordinary software does not have: prompts, models, workflows and tools all version independently and all can regress. You ship a reference AWS deployment with Azure and GCP portability explained, then add monitoring, autoscaling, load and concurrency testing, rollback, incident response and a runbook. The week also covers model gateway and model routing as architecture patterns — provider abstraction, capability-, cost- and latency-aware routing, fallback models and provider failover. The core ends with a system that is actually deployed, not merely deployment-aware.

The orchestration patterns serious enterprise systems actually use. Human-in-the-loop approval workflows, escalation and exception handling, supervisor patterns, and constrained multi-agent coordination — including an honest treatment of when not to use multi-agent architecture at all. You cover A2A and event-driven agent workflows, failure recovery across agents and services, and identity boundaries between them. Then the governance layer enterprises eventually need: an Agent Registry for discovery and control of agents, tools, MCP servers, capabilities, owners, versions and dependencies — the beginnings of an enterprise agent control plane. Closing with the vocabulary distinction that keeps architectures clean: a prompt is an immediate instruction, a skill is a reusable procedural capability, MCP is an interface to tools and context, and A2A is how agents talk to each other.

Your flagship system goes in front of a review the way a senior architecture panel would run it: threat model, reliability, evaluation coverage, observability gaps, latency attribution, cost analysis, scalability bottlenecks, failure modes, identity and permission review, and the architecture decisions behind all of it. You then turn the implementation into the artefacts that outlast it — architecture diagram, ADRs, production-readiness report, portfolio case study and a senior system-design walkthrough. The goal is a specific and durable capability: being able to answer why was the system built this way, not merely which libraries did I use.