# Deterministic tools before model tokens: cheaper agent operations

## Deterministic tools before model tokens: cheaper agent operations

**When a firm is run by AI agents, the main operating-cost rule is: spend model inference on judgment, and move anything that recurs into typed, deterministic software that runs without a model.** A language-model session is expensive and variable; a script that does the same job on a timer is cheap and repeatable. The 561 Group has made this a standing rule for every session on every model and account, and the reasoning applies to any organization using agents.

### What is the rule?

The Group's rule says a session must move recurring work into the Group's existing deterministic software so it runs without a model in the loop, using typed operations and retained original evidence instead of repeated model-driven orchestration. It adds two clarifications. Preserve useful original evidence and the typed inputs of invocations. And do not make another parallel dispatcher: extend the existing software owner and consume it.

The failure the rule responds to is specific. An agent session repeatedly performed the same chain of source capture, worker invocation, receipt and repository bookkeeping by hand, spending tokens each time to re-create orchestration that software should own. The rate of such spending was outpacing the rate at which the work was retiring its own debt.

### Why does this follow from the economics?

Three reasons.

1. **Marginal cost.** A deterministic job costs compute and electricity. A model session costs inference for every step, including steps that never needed judgment.
2. **Variance.** A model may handle the same input differently on two days. A script's behavior is the same unless someone changes it, and a change is visible in a diff.
3. **Evidence.** A script that writes a typed record leaves a durable witness. A model's summary of what it did is a claim that needs its own checking.

The Group's operating method adds a fourth, strategic reason: an agent may profitably perform thousands of microtasks that would be irrational for a person, but only if each is cheap enough. Cost per task is the viability condition.

### What belongs to the model, and what to the tool?

| Work | Better carried by | Why |
| --- | --- | --- |
| Fetch a page, hash it, store the digest | A script | Fully specified; the result is checkable |
| Compare retrieved bytes with an expected artifact | A script | Binary result with a witness |
| Run a scheduled reconciliation | A node job on a timer | Declared trigger and custody |
| Read an ambiguous incident and propose a hypothesis | A model | Open-ended inference |
| Write a first draft of an explanation | A model | Language generation; a human or office receives it |
| Decide which of two plausible repairs to make | An office, assisted by a model | Judgment with consequences |
| Turn a recurring judgment into a rule or script | A model, once | Converts model tokens into durable capability |

The last row is the strategic one. A model's best use is to make itself unnecessary for the task it just did.

### How does this connect to MAPE-K?

In the loop ([how to run a company as a MAPE-K loop](https://operations.561.group/how-to-run-a-company-as-a-mape-k-loop/)), Monitor and Execute are usually deterministic; Analyze and Plan may need judgment on novel cases. As patterns repeat, analysis rules and plan templates are extracted into tools, and the model's share of the loop shrinks. The loop gets cheaper to run every hour as the Knowledge stage accumulates tools. It is the same idea as [Rendanheyi is a Hoare program](https://operations.561.group/rendanheyi-is-a-hoare-program/): the smallest enterprise is a script with a stated order and a witness.

### What does a good tool look like?

1. **Typed.** An exact input, an exact output, or a typed refusal.
2. **Evidence-leaving.** It retains the original result and a digest.
3. **Owned.** It lives in the package that owns the capability. Other packages call it; they do not copy it.
4. **Declared.** Its trigger and the repository paths it may write (its custody) are declared in the release, with no overlapping custody between jobs.
5. **Bounded.** It has a time and cost ceiling.
6. **Consumed.** Someone or something reads its output. Data no consumer needs is deleted.

### What are the common mistakes?

- **Vibing through it.** Handling a recurring job by prompting a model each time because building the tool feels slower. It is slower once and faster forever.
- **Another dispatcher.** Writing a new orchestrator instead of extending the existing one. Capability ownership has one home.
- **Hand-linked timers.** Scheduling by a manual systemd unit outside the release. The Group retired such units, some of which ran beside their own replacements.
- **Writing outside the section's data directory.** Tools write to their owning section's own data area, not to arbitrary home-directory locations.
- **Treating a tool denial as a permanent veto.** A later session re-evaluates capability rather than inheriting a previous denial.

### How do you start?

List the last ten things your agents did twice. Choose the one with the clearest input and output. Write the triple (what it needs, what it promises, when it refuses), build the tool, give it a witness, schedule it in the release and delete the session-level instructions it replaces. Repeat.

### Is this implemented?

The rule is a recorded standing rule. The job-declaration and custody mechanism is a decision note with implementation slices landing as of early October 2026. No cost-saving figure is claimed in this article, and none should be inferred.

### Where to go next

[The operating method](https://operations.561.group/the-work-method-from-demand-to-received-value/) · [How a node changes itself](https://operations.561.group/how-a-node-changes-itself/) · [Red Cup Engineering](https://engineering.561.group/), which builds the underlying software · [the 561 Group](https://561.group/)