Operating Agents
Operating Agents: Preface
The framing note for the Operating Agents course, introducing the chapter structure, blueprints, companions, and builder-first doctrine.
This course is a builder-first guide to how modern agent systems are designed, evaluated, and constrained in practice. It is not trying to explain every direction in agent research, and it is not trying to turn the field into a sequence of slogans. Its purpose is narrower and more useful. It aims to teach what a serious builder needs in order to inspect a real workflow, identify what layer is failing, and choose the right level of intervention.
The package was distilled from the broader survey Advances and Challenges in Foundation Agents. That survey is wide by design. It covers memory, reasoning, action, optimization, collaboration, safety, and much more. This course keeps the practical center of that landscape and then separates it into layers with different jobs. The essays are the public front door. The companions widen the map without bloating the main chapter. The blueprints are the load-bearing decision layer for builders who need defaults and escalation rules rather than another long explanation. The survey and paper notes remain the source and audit layer for readers who want to inspect where the compression came from.
Who This Course Is For
This course is for serious builders, technical operators, and researchers who want deployable understanding rather than hype. It is written for readers who expect to review or ship agent workflows in real systems, where the questions are about state, interfaces, authority, evaluation, failure handling, and cost. The target reader does not need to be a specialist in every part of the literature, but they do need to care about how the system behaves once language leaves the prompt and starts interacting with software, memory, people, and policy.
It is also useful for readers who already know the surface vocabulary of the field but want a cleaner map of how the pieces fit together. Many people have seen the names of the methods and the demo categories. Far fewer have a stable model of which layer each method belongs to, what failure it is meant to address, and when it should not be the first tool reached for.
This course is not a beginner overview of AI. It is not a framework tutorial. It is not a collection of demos dressed up as architecture. The package assumes the reader wants operational judgment: the ability to say what kind of system this is, what part of it deserves attention, and what standard should be used to decide whether a change actually improved it.
What You Should Be Able To Do After Reading
By the end of the course, a reader should be able to inspect an agent workflow and locate the layer where the main problem lives. That means distinguishing a memory problem from a reasoning problem, a reasoning problem from an action-interface problem, a collaboration problem from a safety-boundary problem, and a workflow-quality problem from an evaluation problem. The outcome is not abstract familiarity with agent terminology. The outcome is the ability to read a system and judge what it needs next.
In practical terms, the reader should be able to:
review a live or proposed agent workflow and identify which architectural layer is carrying the failure
choose the right chapter and matching blueprint for the problem at hand
use the companion to widen the map when the main chapter is too narrow for the case
know which papers deserve escalation once the local design question is clear
That is the standard the package is trying to meet. If a reader finishes the course and still cannot review a workflow that they may need to inspect next week, the course is not doing its job.
How The Course Is Organized
The public course has six sections, presented in this order.
Action explains what changes when language gains the ability to produce bounded state change through tools, code, data systems, browsers, and other software interfaces.
Memory explains how an agent should carry information across time without turning the past into an ungoverned source of present authority.
Reasoning explains how tasks should be structured, grounded, checked, and escalated when a single fluent pass is not enough.
Multi-Agent explains when one workflow should become several roles and what kind of handoff makes that split real rather than theatrical.
Safety explains where control can be lost once the system can read untrusted input, remember durable state, call tools, and exchange artifacts.
Optimization explains how to improve the workflow once it works at all, and why the workflow rather than the prompt becomes the true object of optimization.
Optimization is intentionally treated as a bonus module. It assumes the earlier layers already exist in recognizable form. A workflow cannot be optimized responsibly before its memory, reasoning, action, coordination, and safety surfaces are clear enough to evaluate.
How To Use The Course Surfaces
The package separates teaching, decision guidance, and source depth so each layer can stay readable and do one job well.
The core essays are the public teaching layer and the front door into the package. Their job is to define the operating problem, establish the central thesis of the topic, and give the reader a usable method in chapter form. They are not supposed to carry every taxonomy, every edge case, or every decision table. If they tried, they would stop teaching and start sprawling.
The companions are second-pass breadth chapters. They exist because the main essays should stay tight. Their job is to widen the field without diluting the practical center. That is where the broader taxonomies, adjacent lines of work, interpretation of the literature, and category distinctions belong. A companion should make the field larger in a controlled way. It should not force the core chapter to become a survey in disguise.
The current companion layer is:
The blueprints are the builder-facing decision layer, and in day-to-day architecture work they are often the most heavily used surface in the package. Their job is not to teach from zero. Their job is to compress the topic into defaults, escalation triggers, alternatives, failure review, and evaluation criteria. Once a reader knows which layer of the workflow is under strain, the matching blueprint should be the shortest path from understanding to a defensible design decision.
The matching blueprint set is:
Action: Chapter 8 Blueprint: Action Systems and Tool Use
Memory: Chapter 3 Blueprint: Memory
Reasoning: Chapter 2 Blueprint: Reasoning and Planning
Multi-Agent: Chapter 14 Blueprint: Multi-Agent Design
Safety: Chapters 17, 18, and 19 Blueprint: Safety
Optimization: Chapters 9 and 11 Blueprint: Optimization and Self-Improvement
The original survey is the source landscape from which this course was distilled. It keeps the wider field visible, including material that does not belong in the core teaching path. That breadth matters because a distillation is only trustworthy if the reader can still trace it back to the larger map.
The paper notes remain the source-audit layer. They are where a reader goes once the local design question is specific and the next step is no longer orientation but close study. Their role is depth, provenance, and interpretive discipline. They justify the compression above them without forcing every reader to carry the full source load all the time.
Two Orders Matter
Two different orders organize this package, and they serve different purposes.
The public essay order is for teaching. It opens with action because action makes the boundary between assistant and agent visible at once. From there the course moves into memory, reasoning, multi-agent design, safety, and optimization. This sequence is meant to help the reader form a stable picture of the operating system they are studying.
The blueprint order is for architectural dependency. In core/practical-chapter-blueprints/, the sequence runs memory, reasoning, action, optimization, multi-agent, and safety. That order reflects the engineering dependency chain. A long-running system first needs persistence rules. Then it needs task structure. Then it needs action surfaces. Then it becomes worth improving. Only after that do coordination choices and full deployment boundaries come into view.
The public sequence is for teaching. The blueprint order is for architectural dependency. The course keeps both visible because hiding one of them would make the package harder to use. A reader should be able to learn the field in the public order while still understanding why the underlying builder stack is arranged differently.
How To Read This Package Well
The cleanest study loop is simple.
Read the essay first to understand the operating problem and the practical center of the chapter.
Read the companion next if you need the wider field map, the omitted taxonomies, or a better guide to the surrounding literature.
Read the matching blueprint when the question becomes architectural or operational and you need defaults, escalation rules, or evaluation criteria.
Return to the survey or the paper notes only after the design question is specific enough that deeper reading will answer something concrete.
Readers do not need to move linearly through the whole package every time. If the immediate task is a workflow review, it is often better to start with the chapter that matches the bottleneck, then use the companion and blueprint as depth layers. The course is structured so that this kind of targeted reading is possible without losing the larger map.
The standard behind all of this is plain and demanding. The package favors bounded workflows over theatrical autonomy, explicit evaluation over decorative traces, typed memory over undifferentiated retention, strict action surfaces over vague intent, conservative multi-agent escalation over agent proliferation, and safety as architecture rather than as a soft suffix. If the course does its job, the reader should leave with something more durable than a list of methods. They should leave with a way to inspect agent systems soberly, name what matters in them, and improve them without confusing motion for progress.
First Chapter
Chapters List
Thanks for reading Rooted Layers! Subscribe for free to receive new posts and support my work.