Google's recent free agentic-engineering course is the fastest way for a non-specialist founder to go from "I use AI" to "I ship an agent that runs on its own" — and it costs nothing. It walks through six ideas: context engineering, building your first agent, agent memory, agentic loops, building an MCP server, and prompt engineering. If you build alone, don't treat it as a tutorial to complete; treat it as a build spec, because each module maps to exactly one decision or one artifact you should ship this week.

Short answer: Watch it once for the mental model, then build one small agent — one tool, short-term memory, a hard iteration cap — because the course's real payload is a handful of design decisions, not code you copy.

Context engineering: the model's whole world is the window#

The core lesson is that an agent's behavior is downstream of its context, not just its prompt. Context engineering is the practice of deciding, on every turn, which instructions, tools, memories, and history get assembled into the model's context window. The common analogy is a chef's mise en place: you lay out ingredients before you cook. The agent can only act on what's on the counter.

What to build next: a one-page context budget for your agent. Write down what's always in the window (system role, available tools), what's fetched on demand (memory, docs, records), and what gets dropped when things get long. Do this before you write any code — it's the cheapest hour you'll spend.

Building your first agent: it's a loop, not a magic box#

The single most demystifying idea in the whole course: an agent is just a model in a loop with tools. Strip away the frameworks and the shape is this:

while not done:
    response = model(context)
    if response.wants_tool:
        result = run_tool(response.tool_call)
        context = context + result
    else:
        done = True

That's the entire trick. The model reasons, optionally calls a tool, reads the result, and repeats until it decides it's finished. Everything else is production hardening.

What to build next: the smallest agent that does one real chore in your business — triage inbound email, turn a signup form into a CRM row, draft a first-pass reply. One tool, one loop, nothing clever. Ship it to yourself.

Agent memory: short-term, persistent, long-term#

The course splits memory into three tiers, and the value is in keeping them separate. Short-term is the live conversation or working context. Persistent is state that survives a single session — a user's preferences, an order ID, where a task left off. Long-term is knowledge distilled and reused across many sessions: facts learned, what worked before. These are three different decisions, not one feature.

Memory is not one thing you bolt on. It's three decisions about what your agent should keep, what it should carry between sessions, and what it should be allowed to forget.

What to build next: pick your tiers deliberately. Most solo products need short-term plus a simple persistent key-value store, and nothing more, for a long time. Reach for long-term memory (summaries, embeddings) only when the agent genuinely needs to learn across sessions — and don't confuse it with retrieval. Our field guides on the types of agent memory and memory vs RAG are the two references to keep open here; the short version is that a database row often beats a vector store.

Agentic loops and long-running agents: the danger is "unbounded"#

The core lesson is that an agent left to run for minutes or hours is a financial and reliability risk unless you bound it. Long-running agents need iteration caps, cost budgets, checkpoints they can resume from, and human approval for anything irreversible. The reason is arithmetic: reliability multiplies across steps, so more autonomous turns means more ways to drift.

What to build next: before you let anything run unattended, set a hard cap — a maximum number of steps and a maximum spend per run — plus one checkpoint so a stalled agent can resume instead of restarting. This is also the backdrop for Google's broader push to make memory a first-class part of the agent runtime, which we covered in Google makes memory a process.

Building an MCP server: stop hand-wiring integrations#

The core lesson is that MCP — the Model Context Protocol — is the open standard that lets any agent talk to your tool without a bespoke integration every time. The course frames it as MCP versus API, and the distinction is clean: an API is an interface your code calls; an MCP server exposes a tool in a form an agent can discover and call on its own, arguments and all. It's often described as the "USB-C port" for AI tools.

What to build next: wrap your single most valuable internal action — query your database, create an invoice, update a record — as one MCP tool. You do it once, and every agent or client you adopt later can use it without new glue code. For a team of one, that leverage is the whole point.

Prompt engineering: still the cheapest lever#

Even in an agentic world, the system prompt is where you encode the agent's role, its constraints, its output format, and — critically — when to stop. Specific beats clever every time.

What to build next: write your agent's stop condition explicitly. The most common failure mode for solo builders isn't a bad answer; it's an agent that doesn't know it's done and loops until it times out or drains its budget.

Start here this week#

You won't have built the whole curriculum — and you shouldn't try to. You'll have a running agent and, more importantly, the six decisions that let you build the next one in an afternoon.