From AI Model to AI Agent Engineering

Rod was in Edinburgh for a conference, and the day the conference ended, he had six hours to organize a post-conference meetup for 160 people. He needed a pub near the venue with vegan options, capacity confirmed before a 5 PM cutoff, a flyer, a Luma event page, and food orders coordinated with the venue. That's the running example for this entire course — a real logistics problem with real constraints, not a synthetic demo. Every week it gets harder, and the agent built to solve it gets smarter.

Ask most people what turns a chatbot into an "AI agent" and you'll get some version of: it remembers more, it has a longer back-and-forth, it feels more capable. That's the wrong axis entirely. A chatbot and an agent can run on the identical model. The difference isn't in the model at all.

This course is taught by Rod Rivera — Developer Relations at Rasa, AI Professor of the Practice at ITAM, founder of the 30,000+ developer AI Product Engineer community, and someone who has spent 15+ years building AI/ML systems, including prior AI initiatives at Alibaba Cloud, Huawei, and Samsung. That background matters here for a specific reason: the two-capstone split this course is built around, headless automation versus a bounded conversational agent, comes directly out of watching both approaches fail and succeed in production, not out of a textbook.

What actually changes when your AI can act

Here's the working definition this course builds on: Agent = LLM Brain + Planning + Tools + Memory + Interaction. The LLM supplies reasoning — it looks at a goal and proposes what to do next. Everything else in that equation is code you write. The planning loop, the tool execution, the memory store, the interaction layer: none of that is the model. It's the architecture wrapped around it.

This matters because of what the model itself cannot do. It cannot open a browser tab. It cannot send a WhatsApp message. It cannot call a pub and ask about capacity. What it can do is generate text — and if that text happens to be shaped like a function call, your code can read it and act on your behalf. The LLM does not do things. It suggests what to do. Your code is the one that actually turns the key.

That single distinction is the misconception this lesson exists to correct. "Agent" isn't a bigger or chattier model — it's a property of the surrounding system. An engineer who can prompt a model well but has never built the loop, the tool dispatcher, or the memory layer around it is only halfway to being an agent engineer.

Two answers to the same design question, not two skill tiers

By the end of this five-week course you will have built two working agents in Python, and it's worth being precise about why there are two and not one. PyNanoClaw is a headless automator: it's triggered over WhatsApp or Telegram, it searches the web, manages files, schedules tasks, and runs an always-on loop overnight — a Python rewrite of the NanoClaw architecture. Voice Rasa Agent is a conversational co-worker: speech comes in through STT, gets interpreted by Rasa's CALM pipeline, goes to an LLM, and comes back out through TTS — built to handle ambiguity and ask clarifying questions rather than act on a guess.

Put the same Edinburgh problem in front of both and they solve it differently:

Why this distinction gets a whole course instead of a footnote: it maps onto a hiring pattern the source material for this lesson claims but that this lesson has not independently verified. The deck this course draws on attributes a February 2026 line to Kate Jensen, Head of Americas at Anthropic: "2025 was meant to be the year agents transformed the enterprise — the hype turned out to be mostly premature. It wasn't a failure of effort. It was a failure of approach." That same source cites a 4.2x growth in agent-related job postings since 2023, a £120k+ average London salary for AI agent engineers, and 72% of enterprise teams planning agent deployment in 2025: figures this lesson is passing along as reported, not as independently confirmed. Treat the quote and the numbers as claims to check before you repeat them yourself. What isn't in question is the pattern underneath them: teams are hiring for agent engineering skill, and "approach," meaning architecture, is exactly the thing separating projects that ship from projects that don't.

Why bigger context windows don't settle this

One thing agent engineers have to reckon with early: even once you've built the loop correctly, the model inside it has real limits that no amount of clever prompting removes. Compare four models' advertised context windows — GPT-4o at 128K tokens, GPT-4.5/o3 at 200K, Kimi K2 at 256K, Gemini 2.0 Flash at 1M — and the naive read is that bigger is strictly better. It isn't, and this course's first code-along shows why in five minutes.

python lost_in_the_middle_demo.py

The demo hides a needle — the literal string "The secret code is PINEAPPLE42." — inside roughly 810 repetitions of unrelated filler text, and asks a small model, google/gemma-2-2b-it, served via the Nebius Token Factory endpoint (api.tokenfactory.nebius.com), to retrieve it from the start, the middle, and the end of that context. Temperature is set to 0 so the result is deterministic rather than a matter of luck. The rule of thumb this course uses as a starting marker: somewhere around an 8K-token "danger zone," models begin losing track of information buried in the center of a long prompt — even though the window as a whole is far larger than that.

What the result actually means

Run the demo and — with this small model on this synthetic, repetitive filler — you'll likely see the needle recovered from all three positions. That result is not a contradiction of the lost-in-the-middle phenomenon; it's the boundary condition around it. Repetitive, uniform filler is trivially easy for an attention mechanism to filter out — the needle stands out like a lighthouse against a flat backdrop. The classic U-curve failure — high recall at the start and end, a trough in the middle — shows up under harder, more realistic conditions: many documents that are all semantically similar to each other, where the signal genuinely doesn't stand out from the noise around it.

What that means in practice: context length alone is not the variable that predicts failure. Distinguishability is. A unique fact in a sea of repetition gets found. A relevant fact buried among two dozen similar-looking ones does not — regardless of whether your window is 8K tokens or 1M.

This lesson only needs you to see that the phenomenon exists — the mechanism behind why it happens (the softmax math, the research literature, the engineering fixes) is next Saturday's material in full.