Keep the determinism out of the model

Most of the flakiness I see in agentic engineering workflows comes from one mistake: asking the model to re-reason its way to an answer that a small deterministic script already knows. Which project key this team uses. What labels a bug gets. How to format a date range for the sprint. The opaque ID behind a teammate's name. None of that needs inference. It needs a lookup and a default.

An agentic task is really two kinds of work bolted together. There is judgement — reading a stack trace, proposing a fix, weighing a tradeoff — which is what you actually want the model for. And there is execution — fetching the issue, applying the standard labels, posting to the right channel — which has a known correct answer every time. Judgement wants a model. Execution wants a lookup. Let the model do both and the execution half becomes a slow drip of drift.

So I built a CLI called omega to take the execution half back. It wraps the operations I reach for every day — issues, merge requests, chat, worklogs, dates — behind one consistent interface, and encodes my team's conventions so results are repeatable rather than re-argued each session. The design rule is the Unix philosophy pointed at LLM tool use: each command does one thing, takes explicit values, and produces reliable output. The model decides what to do; omega decides how. Skills infer. Omega acts.

The shape of the drift

Here is the kind of call a model reconstructs from memory, a little differently every time:

acli jira workitem create \
  --summary "Fix token refresh" \
  --project ???     # which key does this team use again?
  --labels ???      # what do bugs get tagged with?
  --assignee @me    # ...which resolves to the wrong account

Four openings for drift in one command, and a fifth hiding underneath: the CLI exits 1 even when it succeeds, so a naive wrapper reads that as failure and retries. Each mistake is small on its own and corrosive together, because once you stop trusting the output you check everything by hand, which defeats the point of the agent.

The same intent, handed to omega:

omega jira workitem create --summary "Fix token refresh"

Project, labels, type, and assignee are defaults, encoded once. The exit code is 0 on success, every time. The model spent no tokens deciding any of it, and got the part it is actually good at — what the ticket should say — exactly right.

Own the identifiers, not just the defaults

The sharpest version of this is not defaults at all. It is identifiers. A teammate's chat ID is an opaque string that means nothing to a human, changes if they leave and rejoin the workspace, and gets copied into every script that ever messages them. Ask the model to recall it and you invite both a token cost and a wrong answer. So omega owns it:

omega slack dm alex "the migration is deployed"

alex is an alias. The real ID lives in a single constants module, and every command reads it from there. When it changes, I update one line and the whole surface is correct again. This is why the tool earns its place even when the underlying API works fine: the problem was never a broken call, it was the same opaque value duplicated everywhere.

Encode the failure modes too

omega also absorbs the sharp edges of the tools underneath — the CLI that exits 1 on success, the flag that is --unlabel on one command and --remove-label nowhere, the date that has to be a plain string or the API rejects the whole document. Each is a known, fixed answer the model should never rediscover mid-session — small, boring pieces of code in the execution layer, so the workflow never depends on the model getting a shell gotcha right.

The escape hatch, and the boundary

Determinism this rigid needs a way to grow, or it becomes a cage. When omega does not cover something, the raw CLI is still there as a fallback, and one command — omega add — turns a one-off into a permanent one: it builds the new command against the existing ones as a pattern, and won't commit until I've run a real invocation and confirmed the output. The tool grows more capable as I use it, but never less predictable — nothing lands unverified.

Routing everything through one command has a quieter benefit. The agent's execution surface is now exactly what omega exposes, and nothing else. It can create a ticket, because there is a command for that. It cannot delete a repository, because there is no command for that. Widening what the agent can do is an explicit, auditable act, not whatever the model can talk a general-purpose shell into. The determinism buys reliability; the single door buys control.

Why it matters beyond my terminal

The same shape shows up everywhere agents meet real systems: a control layer that owns the identifiers, encodes the conventions, and absorbs the failure modes, so the model is free to do the part that needs intelligence. Get that boundary right and agentic work stops feeling like a slot machine and starts feeling like tooling.

Determinism is not the enemy of agentic workflows. It is the thing that makes them trustworthy.