Summary

A beginner's crash course presented as a conversation: Remy Gaskell explains the vocabulary of agent systems — the agent loop, harnesses, context files, memory, MCP and skills — then builds a working executive assistant live while Greg Isenberg asks the beginner's questions. The teaching is unusually clear and the demonstrations are real rather than described, including one that partly fails on screen and is left in. Set against that, the opening productivity claim is extraordinary and entirely unsupported, and the security section is the weakest part of the video. Posted 17 March 2026, this is the oldest entry in this batch by some margin — roughly six months before the others — so the product names and model versions are dated while the concepts are not.

• The clearest definition in the batch, and the reason to keep this entry: a chat model is question to answer, an agent is goal to result. Isenberg's restatement is that chat is ping-pong while an agent is given a goal.
• The agent loop is broken into observe, think, act, repeating until the task is complete — and the point that makes it useful is how completion is decided: by the parameters set in the original prompt. His example is that an instruction to compile ten sources and produce a report gives the loop its own stopping condition.
• An agent is described as four components: the model as the brain, the loop, the connected tools, and the context. The platform that runs the loop is the harness, and his argument is that the popular products are all just harnesses. His analogy is learning to drive rather than learning a particular car — some have better features, but the controls transfer.
• A live side-by-side of the same prompt in three different tools shows the loop reaching the same result by the same route — research the unknown subject, write a plan, write the code, then open and screenshot the output to verify it before declaring the task done. The self-verification step at the end is the notable behaviour.
• The demonstration is left in with its errors visible: the generated site contained a wrong email address and an out-of-date location. Presented in passing rather than as a caveat, but it is a concrete illustration that the confident-looking output was partly wrong.
• The distinction he draws between chat memory and agent memory is the most practically useful correction in the video. Chat products save memories automatically to a store the user cannot see or control; agents require memory to be set up explicitly. He argues the explicit version is a benefit rather than a limitation, because automatic memory pulls context from unrelated conversations into work where it does not belong.
• He demonstrates the failure rather than asserting it: telling the agent a preference, watching it acknowledge, then opening a new session in the same folder where it has no recollection. His framing of why this frustrates people is good — you correct the agent, it agrees, and the next day it makes the same mistake, and it looks broken when it is simply not writing anything down.
• The fix shown is a memory file plus an instruction in the context file telling the agent to read it, update it when corrected, and replace outdated entries in place rather than appending. He notes some harnesses now do this automatically, but argues it is worth understanding because they are doing the same thing underneath.
• Two pieces of upkeep advice for these files: keep a context file to roughly 200 lines, and instruct the agent to save only substantial corrections rather than every trivial one. Asked directly whether memory files grow until the rules conflict, he answers honestly that he has not hit that point himself but can imagine it happening over years — an admitted gap rather than a confident answer.
• The context file goes by a different filename in each harness but is the same concept, and he equates it to the custom-instructions field in chat products. For larger bodies of context he points the main file at a separate folder, noting that files sitting in the project are not loaded unless something tells the agent to read them.
• He argues prompt engineering has given way to context engineering: with enough business context loaded, the prompt can be 'stupidly simple' and still produce a usable result. The demonstration supports this narrowly — the same four-word request produced a generic reply before the context file and a specific one after.
• Skills are explained as standard operating procedures for AI — 'once you explain something once, you never have to explain it ever again' — packaged as a markdown file describing the process. He contrasts this with memory, arguing that one-off formatting preferences for a particular deliverable belong in a skill rather than clogging the memory file.
• Two ways to create a skill are shown: feed in an existing document such as a course transcript and ask the harness's own skill-creator to build one, or perform the process manually once and then ask it to package up what was just done. The second is the more general technique.
• His most concrete worked example: an advertising-analysis process he says took three to four hours manually was performed once with the agent over about two hours, then packaged as a skill. He reports a later run scraping roughly 220 competitor ads with landing-page screenshots and a written breakdown. Self-reported, single instance, no verification of output quality.
• MCP is explained through a translator analogy he credits to a previous guest: before it, connecting a model to each tool required custom work per tool; MCP standardises the connection so each side speaks its own language. He attributes its creation to Anthropic, and Isenberg confirms.
• Skills can be chained — a morning-brief skill invoking a research skill when the calendar shows a meeting — and run on a schedule, which he notes the harnesses have begun supporting. Isenberg offers a real personal use: scraping car marketplaces every three hours for a specific configuration and being notified, replacing an hour a day of manual checking.
• A useful organisational distinction: skills, context files and tool connections can each be global or scoped to one project. His reasoning for scoping is not tidiness but context cost — a narrow skill loaded everywhere 'plugs up the context' where it is not needed.
• His beginner recommendation is to start with the easier, more constrained harnesses, build and settle the processes there, and only then migrate to a more autonomous one, which he describes as the hardest to learn and set up.