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 does this team use. What labels go on a bug. How to format a date range for the sprint. None of that needs inference. It needs a lookup and a default.

So I built a CLI called omega. It wraps the deterministic operations I reach for every day, GitLab, Jira, Slack, worklogs, dates, behind one consistent interface, and it encodes my team's defaults so the results are repeatable rather than re-argued each time. The agent does not decide the assignee or guess the label taxonomy. It calls omega and gets the same answer I would.

The point is not that omega is clever. It is deliberately dull. The point is where the boundary sits.

Two kinds of work

An agentic task is a mix of two things. There is judgement, which is what you actually want the model for: reading a stack trace, proposing a fix, weighing a tradeoff. And there is execution, which is the deterministic plumbing around that judgement: fetching the issue, applying the standard labels, posting to the right channel, writing the worklog.

When you let the model do both, the execution half becomes a source of drift. It formats the date differently today than yesterday. It forgets the project key. It invents a label that nearly matches the real one. Each of these is individually small and collectively corrosive, because you stop trusting the output and start checking everything by hand, which defeats the purpose.

Pull the execution out into a tool with encoded defaults and the drift disappears. The same inputs produce the same command produces the same result. The model's job shrinks to the part that genuinely needs a model, and it does that part better because it is not also trying to remember your label conventions.

Encode the defaults, expose the escape hatch

The rule I follow: anything that has a correct answer independent of context gets encoded, not inferred. Assignee, labels, project keys, channel IDs, date formats. These live in omega as defaults, so a bare omega bug does the right thing without the model reconstructing the team's conventions from scratch every session.

The counterpart to that rigidity is a way to grow it. When omega does not yet cover something, the raw CLI underneath (glab, acli) is the fallback, and omega add is how a one-off becomes a permanent default. The tool gets more capable as I use it, but it never gets less predictable.

That combination, deterministic core with a teachable edge, is what makes it safe to hand to an agent. The model can lean on it for the repeatable ninety percent and only reach for improvisation at the genuine edges, where improvisation is what you wanted anyway.

Why it matters beyond my terminal

The same shape shows up everywhere agents meet real systems. The reliable pattern is a control layer between the model and the systems it touches: one that knows the defaults, enforces the conventions, and produces repeatable results, so the model is free to do the part that actually 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.