Background. Consumer LLM products place model selection, reasoning controls, tools, file upload, coding features, and persistent instructions behind one chat interface. A new user can stay in the text box without learning what the rest of the interface changes.

Problem. The interface does not tell you which capability a task needs or what each choice costs. A poor model choice, missing context, or unnecessary tool call can reduce quality or add latency without producing an explicit error.

Key idea. Walk through the product surface in the order a user encounters it, using concrete tasks to show when model selection, reasoning, tools, files, coding, and persistent instructions change the result.

Why it matters. Start here if the agent ecosystem is new to you. The demonstrations also expose the workload behind the interface: one user task can create several model calls, tool calls, and growing prompts. Those are the quantities the rest of the course measures.

Background. A terminal coding agent can inspect a repository, edit files, run commands, and continue until it decides the task is complete. Its context contains the conversation, file contents, and command output accumulated during that work.

Problem. Two resources need explicit management. Without a check the agent can run, “looks done” is its only stopping signal. Without context discipline, exploration and command output consume the window before the task is complete.

Key idea. Give every task an executable verifier, then separate exploration, planning, implementation, and commit. Provide specific context, course-correct early, clear unrelated work from the session, and use subagents or parallel sessions only when their outputs can be reviewed and combined.

Why it matters. Treat the guide as both a user manual and a workload description. Verification changes when a run can stop; context management changes prompt length; subagents and parallel sessions change the number and dependency structure of model calls. Assignment 1 records each of those effects.

Background. Practice around coding agents is distributed across product documentation, blog posts, and individual prompts. The same techniques recur under different names, which makes experience difficult to transfer between tools.

Problem. Advice without a shared vocabulary is hard to compare or apply to a failure. A user needs to know whether a task calls for a smaller prompt, a test loop, a checkpoint, a subagent, or a different interface.

Key idea. Organize an evolving field guide around reusable practices, including Git as the recovery mechanism, subagents for bounded work, red-green testing, agent-driven manual testing, code walkthroughs, and annotated examples of real prompts.

Why it matters. Use this as a reference after the two readings above rather than as a linear feature tour. It connects each user habit to a control mechanism the harness can expose, which is the bridge from using an agent in this lecture to designing one in Lecture 4.

Background. Persistent instruction files place an entire operating manual in the prompt, even when the current task needs only one procedure. Installing more procedures can therefore consume context before the user asks for anything.

Problem. An agent needs enough information to discover a relevant capability without paying to load every capability in full on every call. The loading policy must also package scripts and reference material that are useful only after a procedure is selected.

Key idea. Use three levels of progressive disclosure: load each skill’s name and description at startup, read its SKILL.md body when selected, and open bundled files only when a later step needs them.

Why it matters. This is a concrete context-admission policy. The description imposes a standing token cost, while the body and resources are paid only on use. Read it against Lecture 2's context-rent discussion and ask which level each instruction actually deserves.

Background. Many MCP hosts place every enabled tool definition in the model’s prompt and return every intermediate tool result through the conversation. Tool catalogs and data then compete with the user’s task for the same context.

Problem. Direct tool calling repeats schemas on every model call and serializes large results through the model even when ordinary code could filter or combine them. The overhead grows with both the number of tools and the length of the workflow.

Key idea. Present tools as code APIs that the agent can discover on demand, then execute loops, joins, filtering, and error handling outside the model. Only selected definitions and compact results enter the context.

Findings. In the article’s worked example, on-demand discovery reduces tool-definition input from 150,000 tokens to 2,000 tokens, a 98.7% reduction. The example demonstrates a mechanism rather than a benchmark over a representative task distribution.

Why it matters. It makes context admission actionable. Tool selection becomes retrieval, intermediate data can remain outside the prompt, and several dependent tool operations can run without inserting another model call between them.

Background. Skills and MCP servers are installed into the same context window, and both reach the model as text it reads before deciding anything. A user configuring an agent therefore has three places to put one piece of guidance: the system prompt, a skill, or the tool itself.

Problem. The three are not interchangeable, and the difference is not a matter of wording. The system prompt outranks the user's own messages by construction, so a rule written there is obeyed rather than weighed. A tool description is resident on every turn whether or not the turn needs it. A requirement stated as prose in either place is one the model can reason its way past.

Key idea. Separate capability from know-how, then match each to the placement that makes the model treat it correctly. MCP supplies capability as a tool list merged into the prompt, close enough to an ordinary HTTP API that an OpenAPI specification does the same job. A skill supplies know-how as ordinary thread messages below the system prompt, which is what allows the model to weigh it against the task. A non-negotiable goes into neither and becomes a required tool argument, since an argument the model has to supply is not one it can argue with.

Findings. A skill description costs roughly 100 tokens of resident context, and its body of a few thousand tokens loads only once that description matches the task, which is the three-level admission policy Agent Skills describes, reached independently from one team's practice. The post also reports what misplacement costs: a system-prompt rule instructing the agent to split long telemetry queries made it refuse legitimate week-long requests, and the identical rule reloaded as a skill restored the intended behavior. The author attributes much of the hallucination he sees from frontier models to prompts that leave no compliant answer available, such as demanding three to five tags for an empty document.

Why it matters. It turns Lecture 2's distinction between resident and retrieved context into a rule you can apply per instruction rather than per file. Ask of each line of configuration whether it has to be resident, whether it should be weighed or obeyed, and whether it is a constraint the model should be unable to decline. The three answers select the system prompt, a skill, or the tool signature, and the same three questions apply to a persistent instruction file and to a connected MCP server.

Background. Instruction files and skills influence an agent only when the model notices and follows their text. Some requirements, such as blocking writes to a protected directory, cannot depend on that cooperation.

Problem. Repeating “never do this” in the prompt spends tokens without enforcing the boundary. The host needs a deterministic interception point before an action and observable signals after actions and session events.

Key idea. Register handlers on lifecycle events such as SessionStart, PreToolUse, PostToolUse, and Stop. A PreToolUse command hook can inspect a proposed call and block it before the permission check or tool execution.

Why it matters. Hooks draw the line between guidance and enforcement. Read the event table rather than every schema: identify which requirements belong in context, which belong in an automatic repair, and which must be rejected before they run.

Background. A developer who works across several coding agents keeps the configuration that shapes them, including an instruction file, skills, extensions, scripts, and a work directory, outside any one product. That surrounding structure, rather than the model behind the terminal, is what this post calls the harness.

Problem. A single prompt that plans, implements, and critiques the same task confuses its own objectives, and sending every step to a frontier model pays the highest available price for work a cheaper model finishes. Configuration written against one vendor’s tool has to be rewritten when the developer switches tools.

Key idea. Keep the instruction file, the skills, and the scripts they call in one repository that every terminal agent loads, then isolate the roles a task passes through: exploration produces a plan, the plan becomes an explicit DAG of tasks, a worker implements one node at a time, a critic simplifies and questions the result, and a promoter communicates the finished work. Route each role to a model chosen for it, reserving the frontier model for planning, the first task, and promotion, and running maintenance work on a cheaper one.

Findings. The author reports that the split cut their frontier-model usage in their most intense contexts by 75%, leaving two twenty-dollar monthly subscriptions sufficient for both client and personal work. The number is one developer’s self-report across their own projects rather than a controlled measurement, and the post concedes that confirming which harness changes helped will require an empirical approach it has not yet applied.

Why it matters. It is the practitioner’s side of the question Guardrails Beat Guidance studies below, and the two disagree usefully about what counts as evidence for a configuration choice. Read it for the framing the rest of the course assumes: models become interchangeable parts, and what the user designs is the harness, meaning the roles, the model routing, the scripts, and the files that persist between sessions.

Background. Coding agents load repository rules, skills, and persistent configuration as context. Teams write these files from experience, but a plausible rule is not evidence that the rule caused a better result.

Problem. Rule content, polarity, position, and the mere presence of additional context are confounded unless each is varied against a no-rule control. Observational examples therefore cannot identify which instruction helped.

Key idea. Extract 25,532 rules from 679 public rule files, then run more than 5,000 Claude Code trials while varying curated, random, shuffled, mismatched, and individually ablated rules.

Findings. Curated and random rule sets both improve pass rate by 13.8 percentage points over the no-rule baseline on the paper’s 58-task subset. In the individual ablations, beneficial rules are negative constraints and harmful rules are positive directives.

Why it matters. The random-rule control shows why a rule should not receive credit without an ablation. Treat the polarity result as a strong hypothesis rather than a universal law, because the experiment uses one harness, one model, and one benchmark subset.

Background. An agent can reach repository operations through MCP tools or by writing ordinary command-line commands. Comparisons often attribute a cost difference to the interface even when the surrounding harness also changes.

Problem. System prompts, tool descriptions, retry behavior, and whether the agent follows the assigned route can all differ between runs. An unpaired comparison therefore measures several variables at once.

Key idea. Hold one six-operation software task fixed, run it across seven agent scaffoldings and five models, pair MCP and CLI runs where the scaffold supports both, and verify the repository state instead of trusting the agent’s completion claim.

Findings. Thirteen paired MCP-to-CLI cost ratios range from 0.43× to 29×. The scaffold dominates the result, and agents frequently ignore the interface they were assigned.

Why it matters. It sets a methodological requirement for interface comparisons: verify the route actually used and hold the harness fixed. The evidence comes from one small task, so the instability of the ratio, not any one ratio, is the result to retain.