Template Thinking: Why Your Next AI Agent Should Steal from Cognitive Science

Architecture is usually where AI enthusiasm goes to become expensive.

A team starts with a capable model. Then it adds a planner. Then memory. Then a tool router. Then a critic. Then a second critic because the first critic was apparently too polite. A few weeks later, the “agent” works on the demo path, fails on the second edge case, and nobody can explain whether the problem is the prompt, the retrieval layer, the tool schema, the memory policy, or the small parliament of LLM calls now debating inside the workflow.

This is the architecture problem behind language agents. The question is no longer whether a single model can produce a useful answer. The question is how multiple model calls, tools, state updates, and evaluation steps should be composed into a system that behaves reliably enough to touch real work.

The paper Cognitive Models and AI Algorithms Provide Templates for Designing Language Agents argues that agent builders should stop treating this composition problem as a creative writing exercise with API calls attached.¹ Its proposal is simple: many useful agent architectures can be designed by borrowing templates from cognitive science and classic AI algorithms. In other words, if your agent must communicate, plan, represent knowledge, search, decompose problems, or explore an environment, there is probably already a computational tradition that has spent decades thinking about the same problem.

The useful part is not nostalgia. Nobody is being asked to worship the filing cabinet of old AI. The useful part is that these templates give agent design a starting structure, a vocabulary, and a set of inductive biases. That is much better than discovering, after three months of prompt patching, that your “novel” architecture is just a confused version of search.

An agent template is a DAG, not a vibe

The paper formalizes an agent template as a directed acyclic graph over modules. The modules can be LLM calls or tools. The edges specify execution order and information flow. Root nodes consume the initial input. Intermediate nodes transform, evaluate, simulate, retrieve, or update state. Terminal nodes produce the final output.

That sounds dry. It is also the part business teams should care about.

A vague agent description says: “The system reasons, uses tools, and improves over time.” Lovely. So does a competent intern, until lunch. A template description says something more inspectable: “The agent first decomposes the user request, routes subtasks to specialist modules, evaluates candidate outputs, merges them, and emits a final answer with state updates.” Now the system has a shape. That shape can be reviewed, tested, logged, and governed.

The paper’s core move is to say that a template is not merely a software diagram. It is also a hypothesis about the kind of problem being solved.

A search template assumes the task benefits from expanding and evaluating alternatives. A communication template assumes the task benefits from modeling audience reactions. A reinforcement-learning template assumes the agent must make sequential decisions under uncertainty. The architecture is not neutral. It smuggles in a theory of the task. Better to choose that theory deliberately than to let it leak in through whatever framework tutorial was fashionable last Tuesday.

Category 1: Communication agents need audience simulation, not nicer adjectives

Communication is a good example because many business users misunderstand the problem. They think a communication agent needs a better tone prompt: “Make this warmer,” “sound more executive,” “be empathetic but concise,” and the classic corporate spell, “make it professional.”

The paper points to Rational Speech Acts as a better template. RSA treats communication as recursive social reasoning. A speaker chooses an utterance by considering how a listener is likely to interpret it. The listener, in turn, reasons about what the speaker intended. Communication is not decoration on top of content. It is inference about another mind.

Translated into an LLM-agent template, this can become a pipeline:

This matters for customer support, sales enablement, policy communication, investor relations, and internal change management. In those settings, the risk is not only factual error. The risk is pragmatic failure: the message is technically correct but interpreted in the wrong way.

The business implication is straightforward. If the task is communication, do not start by adding synonyms. Start by asking which audience model the agent needs. Does it need to model a frustrated customer, a skeptical regulator, a confused employee, or a procurement manager reading between the lines? A communication template makes that modeling step explicit.

The boundary is equally important. Simulated audience reaction is not the same as real audience reaction. LLM-based simulation can be useful as a design scaffold, but it should not become the only evidence for high-stakes communication. If the message can materially affect legal, financial, or reputational outcomes, human review and real feedback data still matter. The template improves the structure of the thinking. It does not abolish reality. Annoying, I know.

Category 2: Planning agents need role separation before they need another prompt

Planning is where many agents become theatrical. They produce a long chain of reasoning, declare a plan, revise the plan, reflect on the plan, and then fail because step three required a file that did not exist.

The paper discusses planning templates inspired by cognitive models, including the Modular Agentic Planner. The important idea is not that the brain is a perfect blueprint for enterprise software. The important idea is role separation. Human planning appears to involve different functions: decomposing goals, proposing actions, monitoring errors, predicting future states, and coordinating behavior. A language-agent planner can separate those functions into modules rather than asking one model call to do everything in one dramatic monologue.

For business workflows, this distinction is not cosmetic.

A compliance-review agent, for example, should not only produce a conclusion. It should identify the task, break it into review steps, propose evidence to inspect, predict what each evidence source can clarify, monitor missing information, and then coordinate a final response. A financial-analysis agent should not merely “think step by step.” It should separate data extraction, assumption checking, scenario construction, calculation, sensitivity review, and final interpretation.

The paper’s planning category suggests a practical rule: when the workflow has sequential dependencies, give the agent a control structure, not just a bigger context window.

The paper cites planning benchmarks such as Tower of Hanoi and PlanBench in discussing modular planning systems. For our purpose, the exact benchmark is less important than the design lesson: planning agents need internal division of labor. If the task requires planning, the architecture should say which module proposes, which module evaluates, which module monitors, and which module decides.

Category 3: Code agents turn reasoning into inspectable artifacts

The paper’s representation category draws on the “Language of Thought” tradition: the idea that some forms of cognition may be modeled as structured symbolic programs. For LLM agents, the practical version is familiar. Instead of forcing the model to solve everything in prose, have it generate code, execute the code, and use the result.

This category is especially relevant for business tasks involving calculation, transformation, validation, data extraction, API operations, and workflow automation. In these settings, natural language is often the wrong medium for the final reasoning step. Prose is flexible. That is also why it is slippery.

A code-based template has a simple structure:

The business value is not only accuracy. It is auditability. A generated program can be inspected. An execution trace can be logged. Inputs and outputs can be compared. In regulated or operationally sensitive contexts, that difference is substantial.

There is also a useful correction here. Code-based agents are not only for software engineering. They are useful wherever symbolic manipulation is safer than verbal improvisation: invoice reconciliation, spreadsheet checking, portfolio calculations, inventory rules, report generation, ETL workflows, and simulation. The agent does not need to be a “coding assistant.” It needs to know when code is the right representation for thought.

The boundary is obvious but often ignored. Code execution introduces its own risks: sandboxing, permissions, dependency management, hidden assumptions, and brittle generated scripts. A code template improves inspectability, but only if the execution environment is controlled. Otherwise, congratulations: you have replaced hallucination with automation risk, a very modern form of progress.

Category 4: Search agents make exploration explicit

Search is one of the paper’s strongest categories because it exposes a quiet weakness in ordinary chain-of-thought prompting.

A single reasoning trace is often treated as if it were a deliberate search process. It is not. It is closer to asking the model to walk one plausible path through a latent solution space. Sometimes that path is good. Sometimes it is merely fluent. The user sees a line of reasoning and mistakes it for systematic exploration.

Search templates externalize the process. Tree of Thoughts, for example, separates candidate generation from candidate evaluation. Instead of letting the model produce one chain, the agent can expand multiple partial solutions, score them, prune weak paths, and continue searching.

This is useful when the task has multiple plausible solutions and early commitment is expensive. Vendor selection, legal argument mapping, strategic planning, root-cause diagnosis, and complex research synthesis all fit this pattern. The business problem is not “answer the question.” The business problem is “search through alternatives without pretending the first articulate answer is the best one.”

The paper also discusses search algorithms such as breadth-first search, depth-first search, beam search, and Monte Carlo Tree Search. It does not claim that every one of these has been fully exploited as a language-agent template. In fact, one useful observation is that MCTS is widely used in AI systems but appears underused as a direct source of language-agent templates. That is a research opening, not a deployment guarantee.

For business teams, the decision rule is simple: if the task has a large solution space and weak early signals, use a search template. If the task is routine and deterministic, search may be unnecessary overhead. Not every email needs a tree search. Some emails merely need to be shorter. A tragic but manageable distinction.

Category 5: Decomposition agents reduce problem size, but not judgment risk

Divide-and-conquer is the most intuitive template family. Break the task into subproblems. Solve them. Merge the results. This pattern appears in Least-to-Most prompting, Decomposed Prompting, multi-tool orchestration systems, and multimodal agents such as those that route subtasks to specialized models.

For business users, this is probably the easiest template to adopt and the easiest to misuse.

The benefit is clear. Decomposition reduces cognitive load per module. A contract-review agent can separate clause extraction, obligation classification, risk scoring, cross-reference checking, and final memo writing. A market-research agent can separate source discovery, competitor extraction, pricing analysis, customer segmentation, and synthesis. A finance agent can separate data cleaning, assumption validation, calculation, and narrative explanation.

The trap is also clear. Decomposition creates integration risk.

If subproblems are badly specified, the agent solves the wrong fragments. If the merge step is weak, contradictions survive into the final answer. If each module sees only local context, the whole system may lose the global objective. Divide-and-conquer is not “split the task randomly and hope the aggregator has a personality.” The merge function is part of the algorithm.

The paper notes an important frontier: many decomposition methods were developed before modern reasoning-optimized models and long-running agents matured. Stronger models can already decompose some tasks internally. That does not make explicit decomposition obsolete. It changes where the template is valuable. The stronger the base model, the more explicit decomposition should be reserved for tasks where auditability, coordination, tool routing, or long-horizon reliability matter.

In plain terms: do not decompose because the diagram looks sophisticated. Decompose because the task has separable structure and the business needs visibility into that structure.

Category 6: RL templates are for agents that must learn while acting

The reinforcement-learning section is the most technically ambitious part of the paper, and also the easiest to over-market.

Many real agents are sequential decision-makers. They act, observe outcomes, update beliefs, and act again. A customer-service agent may ask clarifying questions before resolving a case. A trading agent may gather signals before entering a position. A research agent may choose which source to inspect next. A robotics agent may explore an environment while trying not to break anything expensive.

The paper maps several RL algorithms into language-agent templates: policy iteration, Posterior Sampling for Reinforcement Learning, and Information-Directed Sampling.

Policy iteration separates action choice from world modeling

Policy iteration alternates between evaluating a policy and improving it. In an LLM-agent version, modules can approximate the policy, transition dynamics, and reward function in language. The architectural lesson is not “LLMs now solve RL.” The lesson is that sequential decision agents should distinguish among at least three questions:

1. What action should I take?
2. What will happen if I take it?
3. How valuable is that outcome?

When one model call answers all three at once, diagnosis becomes difficult. If the agent acts badly, did it misunderstand the state, mispredict the transition, misvalue the reward, or choose poorly despite knowing better? A policy-iteration-style template gives those failures separate addresses.

PSRL makes uncertainty a first-class state variable

Posterior Sampling for Reinforcement Learning is useful because it treats the environment as uncertain. The agent maintains beliefs about the world, samples a plausible environment model, acts according to that sample, observes what happens, and updates its beliefs.

The language-agent version discussed in the paper uses a verbal “posterior”: a text summary of what the agent knows and what uncertainty remains. That is not a mathematically exact posterior distribution. The paper is clear about the compromise. The point is tractability: language can carry structured uncertainty when formal state spaces are hard to define.

For business agents, this is a powerful design idea. Many agents need to remember not only facts, but uncertainty about facts. A procurement agent should know which supplier claims are verified and which are inferred. A due-diligence agent should track unresolved risks. A research agent should distinguish between “we know,” “we suspect,” and “we have not checked.”

A memory store that only accumulates notes is not enough. The agent needs an uncertainty state.

IDS makes information-gathering deliberate

Information-Directed Sampling extends the idea further. Some actions are not immediately rewarding but are valuable because they produce information. The paper’s example is intuitive: a delivery robot in a new building might spend time checking the directory, even if that action is not part of the final delivery route. It incurs short-term cost to reduce uncertainty.

Business workflows are full of directory-checking actions. Ask one clarifying question. Pull one more document. Query the database before drafting. Verify the client’s jurisdiction. Inspect the exception log. These actions delay completion, but they may prevent expensive mistakes.

An IDS-style agent scores actions by both expected regret and information gain. For enterprise systems, this suggests a better design language for agents that must decide whether to proceed, ask, verify, or explore.

The boundary is important. These are not plug-and-play guarantees. The paper discusses prior work and examples, including small MDPs and Wordle-like tasks. That is very different from proving robust performance across enterprise environments. The practical takeaway is architectural, not magical: if an agent must learn while acting, the architecture should explicitly represent belief, uncertainty, reward, and information value.

What the paper directly supports, and what business readers should infer carefully

This paper is a position paper and survey-style argument. It does not introduce a single new benchmark showing that one grand template dominates all others. That is not a weakness if read correctly. It is only a weakness if someone tries to sell it as a leaderboard result wearing a lab coat.

The paper’s evidence consists mainly of formalization plus mappings from existing language-agent designs to cognitive models and AI algorithms. Some cited systems report empirical gains in their own settings. The paper uses those as examples that templates are already present in successful agent designs.

This distinction matters because business adoption often fails through category error. A paper proposes a design principle. A vendor reads it as a guarantee. A manager buys it as a product feature. Six months later, everyone discovers that “inspired by reinforcement learning” does not mean “approved for autonomous capital allocation.” The universe remains unfair.

A better reading is this: the paper gives us a way to choose architecture before optimization. Templates are priors. They narrow the design search space and make system behavior easier to interpret. They still require task-specific testing.

A practical template-selection map for business teams

The strongest business use of the paper is not to copy one architecture. It is to classify the task before building the agent.

This map is more useful than another universal “agent framework.” It forces the design conversation to begin with the problem class. That is where it should have been all along, but software engineering has a long tradition of rediscovering obvious things through outages.

The operational sequence should look like this:

1. Define the task pattern.
2. Choose the nearest template family.
3. Specify modules and data flow.
4. Decide what state must persist.
5. Decide what each module must log.
6. Test the template against realistic failure cases.
7. Only then tune prompts, tools, and model choices.

Most teams do this backward. They pick a model, build a demo, add tools, patch failures, and then infer the architecture from the wreckage. Template thinking reverses the order.

Governance value: interpretability built into the system shape

The paper repeatedly returns to interpretability. This should not be misunderstood as “the model becomes transparent.” LLM internals remain hard to interpret. The gain is architectural interpretability.

If an agent follows a known template, reviewers can ask sharper questions.

For a search agent:

• What candidates were generated?
• What heuristic scored them?
• Why was one path expanded and another pruned?

For a communication agent:

• Which audience assumptions were used?
• What reactions were simulated?
• Why was one message selected?

For an RL-style agent:

• What belief state did it carry?
• What uncertainty remained?
• Which action was chosen for reward, and which for information gain?

These are governance questions. They are also debugging questions. That is the quiet beauty of template-based design: the same structure that makes an agent more explainable also makes it easier to fix.

Post-hoc explainability often feels like asking a magician to describe the rabbit after the hat has already been returned to wardrobe. Template-based architecture moves some explanation into the process itself. Not all of it, but enough to make engineering conversations less mystical.

The boundary: templates are priors, not magic architecture coupons

The paper is persuasive because it does not need to claim that one template wins everywhere. In fact, the discussion explicitly pushes against that idea. The relevant principle is close to the No Free Lunch intuition: no single architecture dominates across all task distributions.

That means template choice is itself a design decision.

A search template may improve reasoning quality but increase cost and latency. A decomposition template may improve coverage but create integration errors. A code template may improve auditability but introduce execution risk. An RL-style template may represent uncertainty better but require careful state management and evaluation. A communication template may simulate audience reactions but still miss real human context.

The correct business conclusion is not “use templates.” It is: choose templates according to the failure mode you actually face.

Templates do not remove evaluation. They make evaluation more targeted. Instead of testing an opaque “agent,” the team can test whether the decomposer decomposes correctly, whether the evaluator scores usefully, whether the state updater preserves uncertainty, and whether the final aggregator resolves conflicts.

That is already a large improvement over the common enterprise benchmark: “It looked good in the meeting.”

From agent prompt to operating model

The paper’s deeper contribution is to move agent design from prompt craft toward operating model design.

A prompt tells the model what to do. A template defines how work is organized. That distinction matters because enterprise AI systems are not just answer machines. They are workflows with accountability, state, permissions, tool access, and failure recovery.

For Cognaptus-style business automation, this suggests a practical design principle: every serious agent should come with a template declaration.

Not a poetic name. Not “AutoGPT-like.” Not “multi-agent reasoning engine,” which is often just five prompts in a trench coat.

A useful declaration would say:

This agent uses a divide-and-conquer template with explicit retrieval, subtask execution, contradiction detection, and final aggregation.

Or:

This agent uses a PSRL-inspired exploration template with a persistent verbal belief state and uncertainty update after each interaction.

Or:

This agent uses a search template with candidate generation, independent evaluation, beam pruning, and final synthesis.

That declaration gives product managers, engineers, clients, and auditors a common object to discuss. It also makes the agent easier to improve. When performance fails, the team can ask whether the template was wrong for the task, whether a module was weak, whether the data flow was incomplete, or whether the evaluation criteria were badly specified.

This is the business value: cheaper diagnosis, not just smarter generation.

The mature question is not “Can the model do it?”

The paper arrives at a useful moment because the industry has already learned the first lesson of LLMs: single models are powerful. The second lesson is less glamorous: powerful components do not automatically compose into reliable systems.

Agent builders now face an architecture problem. They can solve it through improvisation, brute-force search, or increasingly elaborate prompt folklore. Or they can start from computational patterns that already encode assumptions about communication, planning, representation, search, decomposition, and sequential decision-making.

Template thinking does not make agent design easy. It makes it less arbitrary.

That is enough to matter.

The next time a team proposes an AI agent, the first question should not be, “Which model are we using?” It should be:

What kind of problem is this, and which template are we stealing from?

Stealing, in this case, is just another word for remembering that cognitive science and AI existed before the latest framework release. A small scandal, but a useful one.

Cognaptus: Automate the Present, Incubate the Future.