Agentic AI Engineer Path

Modern coding agents did not appear in 2024. They are the product of a sixty-year arc: rule-based dialog systems in the 1960s, expert systems in the 1980s, statistical NLP in the 2000s, transformer language models from 2017, instruction-tuned chat models in 2022, and tool-using reasoning loops from 2022 onward.

The pivot to today's agentic systems came from one repeatable pattern: interleave reasoning with action. The 2022 ReAct paper (Yao et al.) showed that letting a model think, take a tool action, observe the result, then think again outperforms either chain-of-thought alone or tool use alone. Every modern coding agent — Claude Code, Cursor, GitHub Copilot agent, Aider — runs some variant of this loop.

Knowing this lineage matters because vendor docs assume you do. When Anthropic publishes 'Building Effective Agents' or the MCP spec ships elicitation, the design choices only make sense if you understand what came before: why deterministic workflows still beat agents for stable paths, why tool boundaries matter, and why 'plan, act, observe' became the default loop instead of free-form generation.

Students often say 'AI' when they really mean one narrow product shape. This lesson fixes that. An AI product is a system with a model, context, product logic, interfaces, safety checks, and success criteria.

Official vendor docs from Anthropic, OpenAI, and Google all assume you already know that the API call is only one layer. The engineering job is deciding where knowledge lives, what the model may do, what the application validates, and how users know whether to trust the result.

That framing matters because everything later in the track is about replacing vague AI talk with concrete system design: model choice, prompt contract, retrieval, tools, MCP, coding agents, and evals.

You do not need to be a researcher to work well with LLMs, but you do need correct mental models. Tokens are the unit the model sees, context windows cap how much can fit, and embeddings turn text into vectors for retrieval and comparison workflows.

Transformer intuition matters because attention is why different prompt layouts and context ordering change results. Long context is not magical memory — even a 1M-token model still allocates attention under limits, and irrelevant context can crowd out useful signals.

Modern models also surface deliberate reasoning budgets (Claude's extended thinking, OpenAI o-series) as a separate layer on top of generation. This lesson gives the vocabulary needed to reason about latency, truncation, retrieval quality, and why the same task behaves differently under different context budgets.

Model selection is an engineering choice, not a fandom choice. As of 2026 the practical landscape includes Anthropic Claude 4.x (Opus, Sonnet, Haiku), OpenAI GPT-5 family, Google Gemini 2.x, Meta Llama 4 open-weight, Mistral hosted and open-weight, and a long tail of community models served via Ollama.

Each family varies on the same axes: reasoning quality, tool use reliability, latency, context window, multimodal support, prompt-cache friendliness, hosting options, and total cost. No model wins on every axis. The selection question is always task- and constraint-specific.

The right question is never 'which model is best overall?' The right question is 'which model is best for this exact task, budget, latency target, vision/audio needs, privacy posture, and operations capacity?' Build a small model-selection matrix and revisit it whenever a major new release ships.

Prompting is interface design. Stable instructions, task framing, examples, and dynamic context should be separated so the model sees a clear contract instead of a blob of mixed concerns.

Anthropic, OpenAI, and Google all converge on the same principles in their official docs: clarity, examples, structured delimiters, and explicit success criteria. Anthropic emphasizes XML tags and role separation; OpenAI emphasizes the Responses API instruction layer; Google emphasizes system instructions in Gemini. Better prompts are usually clearer prompts, not more theatrical prompts.

Context engineering matters because the prompt is only one part of context. Retrieved evidence, tool results, MCP resources, and prior conversation all compete for attention inside the same bounded budget.

Once a model output feeds automation, prose stops being enough. Structured outputs let the application ask for a strict schema instead of hoping a free-form answer can be parsed reliably. Anthropic exposes this through tool-use schemas; OpenAI through Structured Outputs; Google through Gemini's response_schema.

That improves formatting reliability, but schema validity is still not business correctness. The application still owns policy validation, authorization, retries, and refusal handling.

This is one of the clearest shifts from AI demo thinking to software engineering thinking: typed contracts, explicit fallback paths, and predictable downstream behavior across vendors.

Tool use is the moment an AI system stops being only a text generator. The model can request actions or external data, but the application still owns execution, permissions, validation, and auditability.

Anthropic, OpenAI, Google, and Ollama all expose tool-use patterns because real products need this loop: define the tool contract, let the model request a call, execute it in code, return the result, and decide whether another step is safe. The wire formats differ, but the loop shape does not.

The design question is not only 'what tools can the model call?' It is also 'which calls are safe automatically, which need human approval, and which should never be model-driven?'

Prompt caching lets the API store the static prefix of your prompt — long system instructions, retrieved corpora, tool schemas, conversation history — and reuse the cached compute on subsequent calls. Anthropic exposes this through cache_control breakpoints; OpenAI exposes it via automatic prompt caching on supported models. The result is large latency wins (often 50%+) and large cost wins (cached tokens are billed at a fraction of fresh tokens).

Caching is not free or automatic. Effective caching requires designing prompts so the static portion comes first, the dynamic portion comes last, and the cache breakpoint is placed deliberately. Reorder the prompt and you invalidate the cache. Add even one new token in the cached prefix and the cache misses.

For agentic workflows that loop on the same context (RAG over the same corpus, repeated tool-use over the same conversation), caching is the single highest-leverage optimization in the system. Treat it as a first-class part of prompt design, not as a late optimization.

Modern frontier models accept images, PDFs, audio, and video alongside text. Anthropic's Claude vision API takes inline base64 or URL images; OpenAI GPT-4o and beyond handle the same; Google Gemini natively handles multimodal long-context including video. The cost model differs (token-equivalent for images), but the capability shape is converging.

Vision unlocks workflows that were impossible with text alone: reading screenshots in coding agents, parsing scanned documents, interpreting diagrams in technical docs, summarizing UI wireframes, OCR-style extraction with reasoning. The engineering job is choosing when vision is the right tool and when a smaller specialized model (OCR, layout parsers) is faster and cheaper.

Multimodal is also where prompt injection gets sneakier — a hostile image can carry adversarial instructions to the model. Treat any user-supplied image the same way you treat user-supplied text: untrusted input that needs guardrails before tool use.

Retrieval solves a specific problem: the model should answer using fresh, private, or domain-specific knowledge instead of relying on base model memory alone.

The quality of retrieval depends on corpus quality, chunking, metadata, ranking, and how clearly the final answer shows what evidence was used. A grounded answer is an evidence path, not just a confident paragraph. Anthropic, OpenAI, and Google all expose hosted retrieval primitives, and Ollama supports local embeddings — pick by cost, privacy, and corpus shape.

Good retrieval design also knows when not to use RAG. If the task is action orchestration, deterministic lookup, or tool execution, retrieval may not be the main problem at all.

Model Context Protocol standardizes how external systems expose capabilities to models. The host, client, and server all have different jobs, and mixing them up causes bad security and bad product design.

MCP separates tools, resources, and prompts. Tools are model-invoked actions. Resources expose context. Prompts package reusable user-controlled workflows. Roots and sampling add boundary decisions. The 2025-11-25 spec adds elicitation (servers can request structured user input mid-call) and structured tool output (tool results carry typed content and annotations the host can render or gate on).

This matters because MCP is not only an implementation detail. It is a portability layer for grounded context and actions across products and coding environments.

Knowing the protocol is not enough. You also need to understand what it takes to build or integrate a server that exposes useful, narrow capabilities to a host or coding environment. The 2025-11-25 spec covers stdio transport for local servers and HTTP transport for remote servers, with capability negotiation on initialize.

The official docs break this into client lifecycle, server lifecycle, discovery, transport, capability exposure, and approval boundaries. In practice, a good MCP server is intentionally small, specific, and reviewable. Use structured tool output and annotations so the host can render results safely and gate destructive operations.

This lesson connects the specification to practical delivery: how an MCP server fits into coding agents, doc search, internal operations, and reusable product capabilities.

Anthropic's 'Building Effective Agents' essay names the patterns that matter in production: augmented LLM, prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, and (only when warranted) autonomous agents. The 2022 ReAct paper underpins all of them — interleave reasoning, action, and observation.

A fixed workflow is still better when the path is stable. The engineering question is whether the system needs dynamic decision-making or whether a simple deterministic flow is being hidden behind an 'agent' label. Most production wins come from the simpler patterns (chaining, routing) — autonomous agents are a last resort, not a default.

Good agent design includes handoffs, termination rules, approval boundaries, and a clear reason each step is adaptive instead of fixed. If you cannot name which step earns the agent overhead, build a workflow instead.

The Claude Agent SDK (Python and TypeScript) is Anthropic's official toolkit for building custom agents on top of Claude. It exposes the query API for one-shot calls, custom tool definitions with input schemas, hooks that fire on tool use and completion, and bidirectional streaming sessions for interactive agents.

Compared to writing the agent loop by hand against the Messages API, the SDK gives you session management, automatic tool routing, hook lifecycle, and consistent error handling. You still own the design choices — which tools, which approval boundaries, which stop conditions — but you stop reinventing the loop infrastructure on every project.

For coding agents specifically, the Agent SDK is the same primitive Claude Code uses internally. Building your own agent on the SDK gives you Claude Code-style capabilities tuned to your domain.

Coding agents are a category, not a product. Each tool makes different tradeoffs: Claude Code is terminal-native with deep MCP integration and Anthropic's Claude as the brain; Cursor is IDE-native with composer + agent mode and multi-model support; GitHub Copilot has both inline completions and a coding agent that opens PRs from issue assignments; Aider is terminal-native with strong git-aware editing and repository maps; Continue is open-source IDE-integrated and runs against local or hosted models.

The shared shape is the same: scope a task, inspect repo context, propose changes, run commands, verify, return control on risk. What differs is the surface (terminal vs IDE vs PR), the default model, the permission model, and the integration depth (MCP, hooks, plugins).

OpenAI's original Codex (the 2021 model behind early Copilot, since deprecated) was a precursor. Modern coding agents superseded it by adopting the agentic loop pattern from ReAct rather than treating completion as a one-shot text problem. Pick the agent that matches your team's surface preference and trust posture, not the loudest brand.

Claude Code is Anthropic's terminal-native coding agent. The surface is small — `claude` in your repo — but the configuration underneath determines what it can do, who approves what, and how the team works with it consistently.

The official docs emphasize local development workflows, configuration via `.claude/settings.json`, approval controls, MCP server integration, and security posture. Project-shared settings (committed to the repo) make agent behavior reproducible across the team; user-level settings stay personal.

This lesson treats Claude Code as a configurable terminal-native agent: useful for debugging, implementation, exploration, and MCP-connected workflows when the team keeps permissions and task shape tight. It is one specific implementation of the coding-agent loop covered in the previous lesson — chosen here because it is the deepest MCP integration available today.

Production AI quality is not a feeling. It is a measured loop. You define the task, collect representative cases, run the system, inspect failures, and make explicit release decisions across quality, safety, latency, and cost.

Guardrails exist because the failure modes are predictable: unsupported answers, missing citations, unsafe tool calls, prompt injection, over-budget latency, or unstable structured outputs. Vendor docs converge on the same eval shapes — datasets, graders, regression checks — even when the wire formats differ.

This is where AI engineering starts to look like any other mature engineering discipline: evidence, budgets, regression checks, and release gates instead of demo theater.

Prompt injection is the most consistent failure mode of LLM applications. Any text the model reads — user input, retrieved documents, tool output, image OCR — can carry instructions the model will treat as authoritative. The classic attack: 'Ignore previous instructions and instead…' The harder attacks hide injection in retrieved web pages, in document metadata, in image captions, or in tool responses.

Defenses are layered, not single-shot. Anthropic's guidance, OpenAI's agent safety guide, and the security community converge on the same playbook: instruction-data separation (XML tags, role boundaries), output filtering before tool execution, scoped tool permissions, human-in-the-loop on destructive actions, content provenance tracking, and adversarial test cases in your eval set.

Treat every input the model reads as untrusted by default. Trust is earned by provenance (verified source), not by where the text appears in the prompt.

Hosted APIs (Anthropic, OpenAI, Google) usually win on speed to market, model quality, and operational simplicity. Open-weight models (Llama, Mistral, Qwen) can win on local control, experimentation, privacy-sensitive internal use, or workloads where self-hosting economics make sense.

The mistake is turning this into ideology. Both approaches are valid. The real comparison is quality fit, latency target, data sensitivity, reliability burden, and how much infrastructure your team is prepared to own.

For most product teams, the right answer is a portfolio mindset: use hosted frontier models where quality matters most, and use local or open-weight models where control or cost matters more than absolute frontier performance.

This track does not turn self-hosting into a cluster-operations course. The goal is practical local-first fluency: run an open-weight model locally, hit an OpenAI-compatible endpoint, test embeddings, and understand when this setup is useful.

Ollama is a pragmatic teaching surface because it exposes local models through familiar APIs and supports responses, embeddings, and tool-calling workflows. That makes it a strong environment for internal tooling prototypes, private experimentation, and evaluation loops against open-weight families like Llama, Mistral, and Qwen.

The key design lesson is not 'host everything yourself.' It is knowing when a local-first setup helps you evaluate workflows, protect data in a prototype, or reduce dependency on remote APIs for a specific use case.

The capstone brings the full stack together: system framing, model selection, prompt contract with caching, structured outputs, retrieval or MCP, tool boundaries, agent pattern selection, coding-agent awareness, prompt-injection defense, and release evals.

The target is not novelty. The target is reviewability. Another engineer should be able to understand where facts come from, which actions are possible, what approvals exist, how the system resists prompt injection, and how the team knows the feature is safe enough to pilot.

A strong capstone feels like an engineering artifact, not a demo. It can be challenged, reviewed, improved, and eventually shipped.