An algorithm is a finite, deterministic sequence of steps that transforms inputs into outputs. That definition is old — from math, from computer science, from the tradition of writing down exactly what you mean before you claim you mean something. It applies directly to agent work.
In an agent context, the algorithm is the part of the agent loop the operator wrote down. It is the explicit procedure that converts an abstract goal — "publish the newsletter," "reconcile the account," "audit the directory" — into a sequence of tool calls with defined inputs and defined failure paths.
Most agent failures trace back to one of two causes: an algorithm that was never written down, so the agent improvises and drifts; or an algorithm that was written down once and never updated, so the procedure has rotted away from the system it describes. This piece is about recognizing both failure modes, maintaining an algorithm library the way you maintain memory, and knowing when the algorithm is the problem rather than the model.
What an Algorithm Is in an Agent Context
A useful working definition for operators: an algorithm is a written procedure that specifies, step by step, how to transform a goal into a sequence of tool calls.
The key word is written. An algorithm that lives only in the operator's head is a heuristic, not an algorithm. It cannot be audited, reproduced, or handed to another session and expected to produce the same result.
Written does not mean formal. A numbered Markdown list in a workspace file is an algorithm. A skill prompt that spells out the activation order of tools is an algorithm. A cron job that fires a specific sub-agent with specific arguments is an algorithm, assuming the procedure for that sub-agent is documented.
The test is whether the same agent, given the same starting state, will produce the same output. If yes, it is an algorithm. If the output varies because the agent is "figuring it out" each time, you have a heuristic disguised as a procedure.
Algorithm, Heuristic, and Policy
These three terms get mixed constantly, and the mixing causes real failures.
An algorithm is fully specified. Step 1, then Step 2, then Step 3. Given the same inputs, it always produces the same outputs. You can trace through it manually and confirm it is correct.
A heuristic is a rule of thumb. "If the file is older than 30 days, archive it." Heuristics are useful — they keep agents from stalling on trivial decisions — but they are not guaranteed to be correct, and they do not specify what to do when the heuristic does not apply.
A policy is a decision rule that governs which algorithm or heuristic to apply. "Use the bank reconciliation algorithm for checking accounts. Use the receipt audit heuristic for expense reports." Policies live above algorithms. They are the routing logic.
Agents encounter all three at runtime. A well-designed workspace has explicit policies that route to explicit algorithms that invoke tools. When any of the three is missing or implicit, the agent has to make up the difference — and it will, by guessing.
Where Algorithms Live in the Stack
The three-layer agent stack — the trio of runtime, composition, and distribution — provides one useful framing. Algorithms sit in the composition layer, but they also appear in the loop itself.
Inside the agent loop, the agent evaluates its current state, selects an action, executes it, and re-evaluates. The selection logic — the decision about which action to take — can be an algorithm (a deterministic decision tree) or a heuristic (the model's judgment). When the operator writes a procedure for the agent to follow, they are replacing heuristic selection with a deterministic algorithm.
The state graph is the structural representation of an algorithm. Each node is a state; each edge is a step. An algorithm that is a numbered list in a Markdown file has a corresponding state graph — one that is usually never drawn, which is part of why the algorithm rots.
Tools are the runtime layer. Algorithms are what sit above tools, organizing tool calls into purposeful sequences. A skill often contains an algorithm — the prompt template specifies not just what the agent should do, but in what order, with what inputs, and what to do on failure.
What an Operator's Algorithm Library Looks Like
A well-maintained agent workspace has an algorithm library: a collection of written procedures, each one a documented recipe for a recurring task.
The library is not a folder of prompts. It is a folder of procedures — step-by-step sequences that could be handed to a new agent session and produce the same result. The algorithm for a weekly content audit differs from the algorithm for a daily deployment check. Each one is documented.
The structure of a single algorithm entry:
1. Name. What task this algorithm solves. 2. Trigger. When to invoke this algorithm (cron schedule, tool call, operator request). 3. Inputs. What the algorithm needs at the start. 4. Steps. Numbered, ordered, deterministic steps. 5. Failure paths. What to do when a step fails. 6. Verification. How to confirm the algorithm produced the right output. 7. Last reviewed. The date this procedure was last verified against the system it describes.
The last field is the one most algorithm libraries skip. It is also the most important. An algorithm that has not been reviewed against the system it operates on is a candidate for wiki-memory decay — it describes a system that has changed.
When to Write Down an Algorithm (and When Not To)
Write an algorithm when:
- The task recurs. One-time tasks that will never run again are not worth the documentation cost.
- The output must be consistent. If two sessions produce different outputs from the same starting state, something has drifted — and the task probably needs an algorithm to correct it.
- The procedure is complex. Anything more than three steps benefits from being explicit. The model's context window is finite; an explicit algorithm is easier to keep in scope than a vague instruction.
- The procedure involves external systems. A task that calls external APIs, reads from a database, or modifies a filesystem has failure modes that are hard to reason about without an explicit step sequence.
Do not write an algorithm when:
- The task is exploratory. Asking an agent to "research X" is not an algorithm — it is a goal. The agent's job is to figure out the procedure. If you write the procedure before the research is done, you are pre-deciding the answer.
- The cost of writing exceeds the cost of variance. For personal, low-stakes recurring tasks, a loose heuristic may be sufficient. The cost of maintaining a written algorithm — reviewing it, updating it — is real.
- The system is still changing rapidly. Writing an algorithm for a workspace that has not stabilized will produce an algorithm that is immediately stale. Wait until the system has a shape.
Algorithm Drift — The Silent Failure
Algorithm drift is the condition where a written algorithm no longer matches the system it operates on. It is the procedure equivalent of memory decay — the documentation was accurate once, nobody updated it, and now the algorithm produces wrong outputs or fails in unexpected ways.
The failure is silent because the algorithm is written down. The operator assumes the written procedure is current. The agent follows the procedure faithfully. The output is wrong, but nobody audits the procedure against the system because the procedure exists and therefore must be correct.
The tell: the agent produces correct output for some instances of a task and incorrect output for others, and the difference does not correlate with anything in the agent's behavior — it correlates with changes to the external system that the algorithm has not been updated to reflect.
The fix is review cadence, not better tools. Each algorithm in the library needs a "last reviewed" date, and that date needs to be checked against actual changes in the systems the algorithm touches.
Algorithm Over-Specification
An over-specified algorithm is one that specifies steps that should be left to the agent's judgment. It is the procedural equivalent of over-constraining the context.
Over-specification happens when the operator writes the algorithm as a script — every tool call, every argument, every branch explicitly named. The result is an algorithm that the agent follows mechanically but cannot adapt when something changes. The moment the external system changes slightly, the over-specified algorithm fails because there is no flexibility written into it.
The sign of over-specification: the algorithm works for exactly one version of the task and breaks as soon as anything changes. The agent cannot generalize because the procedure did not allow for generalization.
The antidote is to specify the goal and the constraints, not the specific steps. Let the agent loop decide which tools to call to achieve the goal within the constraints. The algorithm specifies the destination; the loop figures out the route.
Algorithm Under-Specification
The opposite failure. An under-specified algorithm gives the agent a goal without a procedure — "reconcile the account" with no steps, no inputs, no failure paths. The agent must decide how to approach the task from scratch each time.
Under-specification is common in cron-triggered tasks. The cron fires. The agent is prompted to "handle the weekly reconciliation." The agent makes assumptions about where the data lives, what format it is in, what "done" means. Those assumptions are often wrong, or right only for the first few runs before the data changes.
The sign of under-specification: the first run of a recurring task succeeds; the second run produces a slightly different output; the third run produces a wrong output or an error. The algorithm is drifting because the agent is re-inventing the procedure each time rather than following a stable one.
Algorithms as a Debugging Tool
When an agent task is failing repeatedly, the first diagnostic step is to write down the algorithm — the procedure the agent is following, or the procedure you think the agent is following. In most cases, writing the algorithm exposes the gap.
Common gaps exposed by writing the algorithm:
- Missing inputs. The algorithm assumes a file exists, but the file is not guaranteed to be present.
- Unspecified failure paths. The algorithm does not say what to do when Step 3 fails, so the agent does something unpredictable.
- Hidden dependencies. Step 4 depends on output from Step 2, but the algorithm does not say so.
- Wrong assumption about system state. The algorithm was written when the system had Feature X; Feature X was deprecated; the algorithm still assumes it.
Writing the algorithm is not the fix. It is the diagnosis. The fix is updating the algorithm based on what the written procedure reveals.
Algorithms and the Human/Agent/Robot Triad
The triad that drives every agent stack — human, agent, robot — maps cleanly onto algorithm ownership.
The human writes and maintains the algorithm. The human knows the goal, knows the constraints, knows what "done" looks like. The human is also the one who discovers that the algorithm has drifted, because the human is the one who audits the output against expectations.
The agent executes the algorithm. The agent follows the written procedure, applies the model to ambiguous cases the algorithm did not specify, and reports results. The agent does not improve the algorithm by default — it follows it. If the algorithm is wrong, the agent produces wrong output until the algorithm is fixed.
The robot (the underlying runtime — the filesystem, the network, the external API) is what the algorithm operates on. When the robot changes, the algorithm may need to change. An algorithm for querying a v1 API will fail when the API is upgraded to v2. The robot is the world the algorithm navigates; it changes independently of the human's intentions.
The failure mode of algorithm drift is fundamentally a triad problem: the human wrote the algorithm for a robot that has changed, but the agent keeps executing the old procedure faithfully. The fix lives with the human — reviewing and updating the algorithm to match the current robot. The agent cannot do this because the agent cannot see the gap between the procedure and the world.
Closing
An algorithm library is not a nice-to-have for a mature agent workspace. It is the operational record of what the workspace knows how to do reliably. A workspace with well-maintained algorithms is a workspace where tasks can be delegated, audited, and reproduced. A workspace where algorithms are implicit or outdated is a workspace that depends on the agent improvising well — which works until it does not.
The discipline is simple: if it recurs and it matters, write the algorithm. If you write the algorithm, review it. If the system it describes changes, update it. An algorithm that has not been reviewed against the system it operates on is a liability, not an asset.
The goal is a workspace where the agent's job is to execute procedures that produce consistent results — not to figure out the procedure each time from scratch. That is what separates a working agent stack from an agent that is always discovering how to do its job.