Strategy, Tactics, and Implementation
TL;DR
Reasoning design has three separable levels. Strategy is the reasoning shape — the epistemic method, the abstract pattern of how thought proceeds. Tactics are its graph realization — the specific steps and how the reasoning loops back to refine itself. Implementation is the prompt set that drives each step. The levels are separately specifiable and independently testable, coupled only through explicit contracts, and each has its own optimization target. Beneath all three runs a recurring pattern: across the strategies we have cataloged, each tends to move through problem semantics, representation transforms, and solver affordances — and IRG’s gates enforce the transitions. The practical payoff is a debugging ladder: find the altitude of a failure before choosing the fix.
The agent that kept crying wolf
You are building an agentic system to run your inbox. The job is a small pipeline: fetch each new message, decide whether it is a phishing attempt, and — when the sender is legitimate — draft a reply. You wire it together as a chain of agent calls, point it at your mail, and let it run.
The fetching works. The drafting works. The middle step is where it falls apart. The detector keeps flagging a newsletter you actually subscribed to — and last Tuesday it waved a genuinely nasty spoof straight through, so the draft step cheerfully wrote a warm reply to an attacker.
So you do the natural thing: you fix the prompt. You tell the detector to weigh the sender domain more heavily — that catches the spoof, but now three legitimate senders get flagged. You add a line about urgency language; that helps, until a real invoice reminder trips it. Each edit rescues one case and breaks another. Five rewrites in, the detector is no more trustworthy than when you started.
Here is what the prompt cannot reach. You asked the detector for one snap judgment — phishing, yes or no — a single model call that skims the email and blurts a verdict. But telling a real attack from a real newsletter is not a snap judgment; it is a small investigation. Who actually sent this, once the headers are resolved? Where do the links truly go? What is the message pushing the reader to do, and how urgently? Any one signal can mislead — the answer is in weighing them together. No change of wording turns a blurt into an investigation. That is a change in the shape of the reasoning, and the prompt is the wrong altitude to make it.
This is the point where the agent needs something it does not have on its own: a reasoning structure. Instead of one call that guesses, the detection step becomes a small graph — an IRG — that runs the investigation explicitly. One node resolves the true sender, one traces the links, one reads the urgency cues; a gate weighs the signals and decides, and when a case is genuinely borderline the graph loops once to gather more before it commits. The outer agent hardly changes — it still fetches, it still drafts — but the step that used to guess now reasons, and every verdict arrives with the evidence that produced it. When it flags your newsletter, you can see exactly why, and fix the real cause.
That structure has three parts, and naming them is what this document is for. The strategy is the shape you just imposed: gather independent signals, then weigh. The tactics are the specific nodes that carry the shape out, and how they loop to refine. The implementation is the prompt inside each node. The failure you fought for two weeks lived in the strategy — but the only knob you could see was the implementation, so you turned it, and turned it, at the wrong altitude.
An agent is good at doing — fetching, calling, drafting in sequence. It is not, on its own, good at reasoning through a judgment, and tuning its prompt harder will not make it so. When a step has to reason, you give it a structure instead: a strategy, carried out by tactics, executed by an implementation. That structure is what an IRG is — and the rest of this document is its anatomy.
Definitions
| Ref | Term | Definition |
|---|---|---|
| D1 | Strategy | The reasoning shape: the abstract pattern of how thought proceeds. |
| D2 | Tactics | The specific graph topology that instantiates a strategy. |
| D3 | Implementation | The prompt set that drives execution at each node. |
| D4 | Gate | A checkpoint node that inspects an intermediate product and decides whether the graph proceeds, iterates, or exits. |
Assumptions
| Ref | Assumption |
|---|---|
| A1 | The three levels (D1–D3) are separately specifiable and independently testable, coupled through explicit interface contracts. In practice the levels constrain one another — a new strategy may demand an output the current topology does not expose — so this is a design goal that keeps them loosely coupled, not a claim that any level can change with zero effect on the others. |
| A2 | Across the strategies cataloged so far, we observe a recurring three-layer pattern — problem semantics, representation transforms, solver affordances. An empirical observation offered as a design heuristic, not a claim that every possible strategy must traverse it. |
| A3 | The optimization targets we assign each level reflect our engineering practice, not necessity. |
Why the levels must be separated
A practitioner sitting down to design a reasoning graph faces an immediate question: what shape should the reasoning take? Topology patterns — linear, diamond, tree, lattice, recursive, ensemble — describe structural possibilities. But they describe geometry, not intent. A diamond topology is a convergent shape; it does not tell you why you are converging, or what kind of reasoning produces that convergence. The same diamond can serve dialectical reasoning (thesis and antithesis resolving into synthesis), differential diagnosis (candidates narrowing to a diagnosis), or Bayesian updating (evidence streams converging on a posterior). Same geometry, three entirely different kinds of thought.
Collapsing these concerns into one design decision produces graphs that are hard to reason about and impossible to optimize systematically: a prompt tweak silently changes what convergence means; a topology change silently discards a strategy’s gate discipline. Separating the levels (A1) is what lets reasoning design be practiced as engineering.
The three levels
One disambiguation first, since these words are overloaded elsewhere. Here strategy is the epistemic method — the kind of reasoning the task calls for — and tactics is its executable graph realization. Topology is a tactic, not a strategy; a prompt is an implementation, not a tactic. A reader used to “strategy vs. tactics” from other domains may be tempted to call the graph shape the strategy and the prompts the tactics — in this framework, both of those sit one level lower than the name suggests.
| Level | What it is | Optimization target | Example |
|---|---|---|---|
| Strategy | The reasoning shape — the abstract pattern of how thought proceeds. Determines which gates fire, what convergence means, and how quality is measured. | Fit to the task’s epistemics: is this diagnosis, derivation, generalization, argumentation? | Toulmin argumentation |
| Tactics | The specific graph topology that instantiates the strategy: node classes, edges, decomposition depth, iteration structure. | Cost, latency, parallelism, per-node difficulty within model capability. | A hub-and-spoke graph |
| Implementation | The prompt set that drives execution at each node. | Per-node precision, domain vocabulary, output contract compliance. | Precision-tuned prompts per node class |
We treat the levels as separately specifiable, coupled only through explicit contracts (A1). A regulatory compliance task might take Toulmin argumentation as its strategy (D1), a hub-and-spoke graph as its tactic (D2), and precision-tuned prompts as its implementation (D3). Change the prompt set to move the same graph from one domain’s vocabulary to another. Change the topology to trade latency for depth while preserving the strategy’s gates. Change the strategy only when the kind of thought the task needs has changed. The levels are not perfectly independent — a strategy can demand an output the topology does not yet expose, and a topology change can force new prompts — but as long as the contract between two levels holds, a change on one side does not ripple through to the other. That bounded coupling is what makes the design tractable.
On our account, this separability is what makes reasoning structure a designable variable at all. The R/K/G framework — the previous document — makes that variable its subject: it calls this structure G, and argues that once G is separable from model capability (R) and knowledge (K), it becomes an independent axis of optimization with its own return curve. This document zooms in on G and asks how it is designed.
A worked swap
To make the separation concrete, hold one strategy fixed and vary the levels beneath it. Take Toulmin argumentation as the strategy — assert a claim, ground it in evidence, state the warrant that links them, admit the strongest rebuttal, and rule. That epistemic shape is what stays constant below; what changes is how it is realized and how it is worded.
| Level | Realization A | Realization B | What it means |
|---|---|---|---|
| Strategy | Toulmin — claim, grounds, warrant, rebuttal, ruling | Toulmin — unchanged | Fixed. The epistemic method, its gates, and what “ruled” means do not move. |
| Tactics | Linear chain: claim → grounds → warrant → rebuttal → ruling | Parallel branches: grounds and rebuttal built concurrently, an arbiter reconciles | Varies. Same strategy, different topology — trading latency for a more balanced treatment of the rebuttal. |
| Implementation | Domain-A vocabulary and evidence contracts | Domain-B vocabulary and evidence contracts | Varies. Same nodes, different prompts — the graph re-pointed at another domain. |
What stays invariant is the part that carries the reasoning’s integrity: which gates fire, what counts as a rebuttal that must be answered, and what a ruling has to satisfy. What varies is cost, latency, and vocabulary. A team can move from Realization A to B to shave latency, or re-point the whole graph at a new domain by changing only the implementation — without relitigating what good reasoning looks like for the task. We keep this at the level of ideas on purpose: the node contracts and prompts that make a given realization reliable are where the real engineering lives, and they are domain-specific.
The three-layer meta-strategy
One more pattern recurs beneath the strategies in the library. Across the strategies cataloged so far, we observe (A2) that they tend to move through three layers of cognitive work, whatever discipline they come from:
| Layer | The work | Failure when skipped |
|---|---|---|
| Problem semantics | Establish what the task actually is, and what “solved” means — the success criteria the rest of the graph will be held to. | The system answers a different question than the one asked, fluently. |
| Representation transforms | Restructure the problem into a tractable form: decompose, reframe, formalize, select the evidence that matters. | The solver receives the problem in a shape it cannot reliably process; quality becomes luck. |
| Solver affordances | Match the execution steps to what the nodes can actually do — per-node difficulty within capability, outputs within contract. | Individual nodes are overloaded; errors appear mid-graph and compound silently. |
A well-designed graph touches all three layers explicitly. A poorly designed one jumps from problem semantics straight to solving — the cognitive equivalent of answering a question before understanding it. IRG enforces the layer transitions with gates: before the graph moves from reframing the problem to solving it, a gate asks whether the problem is now in a form the solver can actually work with. It is the same checkpoint mechanism the strategies use for their domain rules — the way a validity gate checks the premises before any conclusion is drawn — applied here to the handoff between layers.
The meta-strategy is also the practical design procedure. When a graph underperforms, diagnose in layer order: first ask whether the graph established the right success criteria; then whether the representation the solver received was tractable; only then tune prompts. In our practice, most quality problems attributed to the model have turned out to be representation problems wearing the model’s clothes.
Find the altitude of the failure
Put the three design levels and the three cognitive layers together and you get the one habit this document is really arguing for: find the altitude of a failure before choosing the intervention. The industry’s reflex is to meet every bad output with a better prompt or a bigger model — the two knobs always in reach. But a failure has an altitude, and a fix applied at the wrong altitude either does nothing or moves the problem somewhere else.
| Rung | The question to ask | What a failure here looks like |
|---|---|---|
| 1 · Problem | Did we define the right problem, with a success condition the graph is actually held to? | Answering the wrong question, fluently. No prompt fixes it. |
| 2 · Representation | Did we transform the problem into a form the solver can process? | A tractable-looking task handed over in an intractable shape; quality becomes luck. |
| 3 · Node capability | Did we assign each node work it can reliably perform, with outputs within contract? | An overloaded node whose errors surface three steps later and compound silently. |
| 4 · Implementation | Only now: are the prompts precise enough? | Right node, right shape, imprecise wording. This is the rung most teams start on. |
Read top-down, this is a diagnosis; read bottom-up, it explains why prompt-tuning feels like whack-a-mole. In the opening scene, the defect lived on rungs 1–2 — a snap-judgment shape for what was really an investigation — while every fix was applied on rung 4. That mismatch between where a failure originates and where the fix is applied is its own kind of bug, and naming it is half of avoiding it: find the altitude of the failure before choosing the intervention.
- Strategy
- The shape of the reasoning — the abstract pattern thought follows. In the scene, the agent needed a gather-the-signals-then-weigh shape, not a single snap judgment.
- Tactics
- The specific steps that carry the strategy out, including how the reasoning loops back to refine itself — iteration, revision, a second pass.
- Implementation
- The prompt at each step. The knob most visible to you, and often not where a failure actually lives.
- The three-layer meta-strategy
- A pattern recurring across the strategies cataloged so far: problem semantics (what “solved” means), representation transforms (reshaping the problem into a tractable form), and solver affordances (matching steps to what the nodes can do). Diagnose failures in that order.
- Failure altitude
- Every reasoning failure originates at a level — problem, representation, node capability, or prompt. Find the altitude before choosing the fix; a prompt applied to a representation failure only moves the problem around.
- Agents vs. judgments
- Agents perform actions; reasoning graphs govern judgments. The adoption pattern: keep the automation, find the consequential decision steps, and replace those with governed subgraphs.
- Gate
- A checkpoint node that inspects an intermediate result and decides whether the graph proceeds, loops, or exits — the mechanism that enforces the transitions above.
Agents act; graphs govern judgments
The scene at the top hints at an adoption pattern worth stating plainly. An agent is good at doing — fetching, routing, transforming, writing, submitting. Those are actions, and ordinary automation handles them well. What an agent is not, on its own, good at is reasoning through a consequential judgment: the step where a wrong answer is expensive and has to be defensible afterward.
So the move is not to replace an agent stack. It is to find the judgment steps inside it and govern those:
| Step | What you do |
|---|---|
| Keep the automation | Fetching, routing, formatting, sending — leave the ordinary actions running as agents. |
| Find the judgments | Locate the steps where the system decides something consequential and would have to explain itself later. |
| Govern those steps | Replace each with a structured reasoning subgraph — gates, evidence contracts, a review step — an IRG in place of a single guess. |
The agent keeps orchestrating; the judgment step stops guessing and starts reasoning, with a trace to show for it. It is an incremental path — govern the decisions that matter, one step at a time — not a rip-and-replace of everything that already works.
Where to go next
Reasoning Circuit Complexity takes the structures described here and measures them — depth, width, verification density, and the cost of each. The Reasoning Strategies series catalogs the strategy library one family at a time, each specified as an executable, gated graph shape. And the R/K/G framework, if you arrived here first, is the case for why any of this earns its keep.