From inheritance to instantiation
In L-0594 you learned that new agents can inherit components from existing agents — borrowing triggers, response patterns, or monitoring criteria rather than inventing everything from scratch. Inheritance is powerful, but it still requires you to look at a specific existing agent and decide which parts to reuse. Each new agent begins as a negotiation between the old and the new.
Templates take inheritance one step further. Instead of borrowing from a specific agent, you extract the common structure that multiple agents share and codify it as a reusable blueprint. The template is not any particular agent. It is the skeleton that many agents have in common — the scaffolding you fill in with specifics each time you create a new one.
This distinction matters because it changes the economics of agent creation. Without templates, every new agent is a custom design project. With templates, most new agents are instantiation projects: you select the appropriate template, fill in the slots, and deploy. The creative work shifts from structural design to contextual specification — not "how should this agent be organized?" but "what specific trigger, response, and criteria does this agent need?"
The idea is not new. It is one of the oldest and most consequential ideas in human engineering, and its history reveals why it works so reliably.
Christopher Alexander and the pattern language
In 1977, the architect Christopher Alexander published A Pattern Language, a book that would reshape how entire industries think about reusable design. Alexander and his co-authors catalogued 253 patterns — recurring solutions to recurring design problems in towns, buildings, and construction. Each pattern had a name, a description of the problem it addressed, and a solution that could be adapted to specific circumstances.
Pattern 159, for example, is "Light on Two Sides of Every Room." The problem: rooms lit from only one side produce glare and visual discomfort. The solution: ensure every habitable room receives natural light from at least two directions. The pattern does not specify the room's size, purpose, or location. It specifies a structural principle that applies across thousands of different rooms. An architect designing a kitchen in Osaka and an architect designing a library in Oslo both use the same pattern, but the resulting spaces are completely different.
Alexander's radical insight was that patterns are not constraints. They are enablers. A person designing a house without patterns must solve every problem from first principles — where to place windows, how to orient rooms, what makes a threshold feel welcoming. A person designing with patterns starts from a library of proven solutions and composes them into a configuration that fits their specific context. The patterns do not dictate the outcome. They eliminate the need to reinvent the structural decisions that have already been solved, freeing the designer to focus on the decisions that are genuinely unique.
The software industry recognized the power of this idea almost immediately. In 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — the "Gang of Four" — published Design Patterns: Elements of Reusable Object-Oriented Software, explicitly modeled on Alexander's pattern language. Their 23 patterns, including the Template Method pattern, became the foundation of modern software architecture. The Template Method pattern is particularly instructive: it defines the skeleton of an algorithm in an abstract class, allowing subclasses to fill in specific steps without changing the overall structure. The skeleton stays fixed. The details vary. This is exactly what an agent template does for your cognitive architecture.
The checklist as cognitive template
Not all templates look like architectural blueprints or software abstractions. Some of the most powerful templates in human practice are deceptively simple: they are checklists.
In 2009, the surgeon and writer Atul Gawande published The Checklist Manifesto, documenting how structured checklists transform performance in complex, high-stakes environments. Gawande's central argument is that modern professional work has become too complex for any individual to execute reliably from memory alone. Surgeons perform procedures involving hundreds of steps. Pilots manage aircraft with thousands of interacting systems. Construction managers coordinate dozens of trades across months of work. The failure mode is not ignorance — the professionals know what to do. The failure mode is omission — under pressure, in real time, with distractions and interruptions, even experts skip steps.
The World Health Organization's Surgical Safety Checklist, which Gawande helped develop and test across eight hospitals in eight countries, reduced surgical complications by 36 percent and deaths by 47 percent. The checklist did not teach surgeons anything new. It provided a template — a fixed sequence of verification points that every surgical team executed before, during, and after every procedure. The template ensured that known best practices were followed consistently, not sporadically.
The mechanism is worth understanding precisely: a checklist is a template for attention. It specifies where to look, in what order, and what to verify, without specifying the content of each verification. The surgical checklist does not tell the anesthesiologist what the patient's allergy status is. It tells the anesthesiologist to confirm the patient's allergy status. The slot is fixed; the content is specific to each case.
Your cognitive agents work the same way. A "morning review" template might specify: (1) check calendar for the day, (2) identify the single most important task, (3) set a boundary for when deep work begins, (4) confirm that the environment supports focus. This template works regardless of what is on your calendar, what your most important task is, or what your environment looks like today. The structure is reusable. The content changes every time.
Boilerplate and scaffolding in software
The software development industry has spent decades refining the economics of template-based creation, and the patterns they have discovered apply directly to cognitive agent design.
A boilerplate is a pre-written code structure that handles common setup tasks — configuration, authentication, database connections, error handling — so that developers can begin working on the unique logic of their application immediately. Boilerplates encode decisions that have been made thousands of times before: how to structure a web server, how to handle user sessions, how to log errors. A developer starting a new project from a boilerplate does not skip these decisions. They inherit them from accumulated collective experience.
The economics are stark. Studies of developer productivity consistently show that boilerplate and template usage reduces project initialization time by 60 to 80 percent. But the benefit is not purely about speed. Templates also reduce variance. A team of ten developers, each starting from scratch, will produce ten different project structures with ten different approaches to configuration, error handling, and testing. A team of ten developers starting from the same template will produce ten projects that share a common structure, making them easier to understand, maintain, and hand off to other team members.
This variance-reduction effect is the second major benefit of agent templates. When you create agents from templates rather than from scratch, your cognitive architecture develops consistency. Your agents share common structures, common monitoring hooks, common naming conventions. This makes the entire system more legible — to you, now, and to your future self who needs to understand, maintain, and evolve these agents months or years later.
Standard operating procedures as organizational templates
Outside software, the most widespread form of reusable template is the Standard Operating Procedure. SOPs have been a cornerstone of organizational management since at least the industrial revolution, and they serve exactly the function that agent templates serve for individuals: they encode proven processes into reusable structures that can be executed consistently by different people at different times.
An SOP does not describe a single execution. It describes the structure that every execution follows. A hospital's SOP for patient intake specifies the sequence of steps — verify identity, record vitals, confirm allergies, check medication list, assign room — without specifying the patient. The template handles the process. The practitioner handles the content.
The organizational knowledge literature emphasizes a critical property of SOPs: they preserve institutional knowledge across personnel changes. When an experienced employee retires, their tacit knowledge of how to handle common situations leaves with them — unless that knowledge has been externalized into templates. The SOP captures not just what to do but the accumulated wisdom about the order in which to do it, the common failure points, and the exceptions that require special handling.
Your cognitive agent templates serve the same preservation function. When you extract a common pattern into a template, you are not just saving time on future agent creation. You are externalizing your accumulated understanding of what makes a certain class of agents work well. The template captures your design wisdom — which trigger structures are reliable, which response patterns produce consistent results, which monitoring criteria catch problems early. Without the template, that wisdom lives only in your memory, where it degrades, gets forgotten, and must be rediscovered each time you build a similar agent.
Transfer learning: templates in machine intelligence
The machine learning community has discovered a powerful version of the template concept: the pre-trained model. In transfer learning, a neural network trained on a large, general dataset — millions of images, billions of words — is reused as the starting point for a new, specific task. The pre-trained model has already learned general features: edges and textures in images, grammatical structure and semantic relationships in text. A practitioner building a specific application — say, a system that classifies medical images — does not train a model from scratch on medical data alone. They start from the pre-trained model and fine-tune it on their specific dataset.
The results are dramatic. Transfer learning typically reduces the amount of task-specific training data needed by an order of magnitude and produces better-performing models than training from scratch, because the general features learned from millions of examples provide a foundation that small specialized datasets cannot build independently. The pre-trained model is, functionally, a template — a reusable structure that captures general knowledge and can be specialized for specific purposes.
The parallel to cognitive agent templates is direct. Your templates encode general knowledge about how agents of a certain type work well. When you instantiate a template for a specific new agent, you are performing transfer learning: applying general structural knowledge to a specific cognitive task. The template gives your new agent a head start, the same way a pre-trained model gives a new ML application a head start. You do not need to rediscover from scratch that reactive agents need clear triggers, that routine agents need completion signals, or that monitoring agents need defined review cadences. The template already knows this. You just need to specify the particulars.
Piaget and the schema as cognitive template
The concept of a reusable mental structure is not borrowed from engineering. It originates in the study of the mind itself.
Jean Piaget, the Swiss developmental psychologist, introduced the concept of the schema in the 1920s as a fundamental unit of cognitive organization. A schema is a mental template — a structured pattern of thought that helps a person make sense of new experiences by relating them to existing knowledge. When a child encounters a new four-legged animal, they do not analyze it from first principles. They assimilate it into their existing "animal" schema, checking whether it fits the template. If it fits, understanding is instant. If it does not fit — if the new animal has features the schema does not account for — the child must accommodate, modifying the template to handle the new case.
Piaget's insight is that cognition itself operates through templates. You do not process each new experience as if it were the first experience you have ever had. You match incoming information against stored patterns, and those patterns — schemas — are reusable structures that accelerate understanding the same way design patterns accelerate software development and SOPs accelerate organizational processes.
Your cognitive agent templates are deliberate, externalized versions of what Piaget described as happening automatically and internally. The difference is that by making the template explicit — writing it down, giving it a name, defining its slots — you gain the ability to inspect it, improve it, and share it. An implicit schema can only be modified through the slow process of accumulated experience. An explicit template can be revised the moment you recognize a flaw.
Building your template library
The practical work of agent templates involves three stages: extraction, codification, and instantiation.
Extraction means recognizing that multiple existing agents share a common structure. This requires reviewing your agent portfolio — the full set of agents you have built, as examined in L-0592 — and looking for structural similarities rather than content similarities. Two agents that address completely different domains (one manages your reading habit, the other manages your email processing) might share the same template: time-based trigger, sequential checklist, completion marker, weekly review. The content is different. The structure is identical. That shared structure is a candidate for extraction.
Codification means writing the template down explicitly. A useful agent template specifies several elements: the type of trigger (time-based, event-based, environmental, emotional), the response structure (single action, sequential checklist, decision tree, if-then-else), the completion criteria (how you know the agent has finished its work), the monitoring hooks (what you measure to assess whether the agent is performing well), and the known failure modes (common ways this type of agent breaks down). Each element is a slot. The template defines the slots and their relationships. It does not fill them in — that is the work of instantiation.
Instantiation means creating a new agent by filling in the template's slots with specific content. You select the template that matches the type of agent you need, then provide the specifics: this trigger, this response sequence, these completion criteria, these monitoring metrics. The structural decisions are already made. You are making only the contextual decisions — the ones that are genuinely unique to this agent.
A well-designed template library typically contains four to seven templates, not dozens. If you have too many templates, you have not abstracted enough — each template is too specific, too close to a single agent rather than a class of agents. If you have too few, you are forcing dissimilar agents into the same structure, which produces the rigidity failure mode. The right number of templates covers the recurring patterns in your cognitive architecture without trying to cover every possible agent.
Templates are not permanence
There is a common misunderstanding about templates that must be addressed directly: the belief that creating a template means the template is finished. It is not. Templates evolve.
Alexander understood this. His patterns were not fixed rules. They were living descriptions of recurring solutions, and he expected practitioners to modify them based on their own experience and context. The Gang of Four's software patterns have been reinterpreted, extended, and sometimes superseded as programming paradigms have evolved. Gawande's surgical checklist was revised multiple times based on field data showing which steps added value and which created unnecessary friction.
Your agent templates should follow the same trajectory. When you instantiate a template and discover that the new agent needs a structural element the template does not include, update the template. When you notice that a template slot is consistently ignored or filled with placeholder content, remove it — it is scaffolding that does not support anything. When you discover a new class of agents that does not fit any existing template, create a new one. The template library is a living tool, not a finished artifact.
The goal is not to have perfect templates. The goal is to have templates that make agent creation fast enough and consistent enough that you actually build the agents you need, instead of leaving them as vague intentions because the design effort feels too high. A good template reduces the activation energy for agent creation — and when activation energy drops, creation rate rises.
From templates to legacy
You now understand how to extract common structures from your agents, codify them as reusable templates, and instantiate new agents from those templates. This capability accelerates your agent creation and brings consistency to your cognitive architecture. But acceleration has a consequence: you will build more agents, faster. And some of those agents will outlive the context that justified them.
Templates make creation easy. They say nothing about retirement. The next lesson, L-0596, turns to the agents that templates help proliferate but that no one remembers to decommission — the legacy agents that persist in your system long after their purpose has expired, still consuming cognitive resources, still firing on triggers that no longer matter, still occupying space in an architecture that has moved on without them.
Sources:
- Alexander, C., Ishikawa, S., & Silverstein, M. (1977). A Pattern Language: Towns, Buildings, Construction. Oxford University Press.
- Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
- Gawande, A. (2009). The Checklist Manifesto: How to Get Things Right. Metropolitan Books.
- Piaget, J. (1952). The Origins of Intelligence in Children. International Universities Press.
- Pan, S. J., & Yang, Q. (2010). "A Survey on Transfer Learning." IEEE Transactions on Knowledge and Data Engineering, 22(10), 1345-1359.
- Iterators HQ. "Boilerplate Code: Productivity and Consistency in Software Development." iteratorshq.com.
- Slack. "What Are Standard Operating Procedure Templates?" slack.com/blog.