An agentic workflow should call automation; open-source Kortix draws the line

The two halves of a real process

Every process a company runs has two halves, and they are easy to confuse because they sit in one diagram. One half is exact: the invoice sweep starts at 06:30 on the first of the month, Berlin time; a webhook signature is compared against a project secret; a tax rate is 19 percent. The other half is judgment: which of forty invoices is the exception, what the note to the vendor should say, whether the mismatch deserves a phone call.

Kortix keeps the first half where a reader can check it. A schedule is one row in kortix.yaml, beside the agents and the sandbox images. The row is versioned with everything else in the repo, so the schedule has a history and a reviewer.

The mistake is smaller than it sounds and far more common: moving the exact half into the prompt. A line like "round every total to two decimals" or "retry the upload three times" reads like a requirement when you write it. Inside a prompt it is a suggestion the model may follow, and the run will not tell you when it did not.

What a prompt is bad at

Three things break first when you express them as sentences instead of code.

Arithmetic is the obvious one. Ask a model to add forty line items and it will usually be right, which is worse than always wrong, because the error arrives in the month nobody checks. A function returns the same total every time, and someone can test it.

Ordering comes second. "Post the message after the record is saved" carries a precedence inside a sentence, and precedence in prose depends on the model reading it the same way twice. A transaction or a queue gives you the order instead.

Retries are the third and the costliest. A prompt can say "try again if it fails", and the agent will retry in whatever way it picks, for as long as it decides. A retry loop has a count, a backoff and a stop condition, and all three are numbers.

The rule that follows is short: anything carrying a guarantee belongs in a tool the agent calls. The guarantee lives in code, and the agent decides when to call it and what to do with the answer. On the invoice sweep the matcher is a script in the repo; the agent reads the exceptions it returns and writes the note. No total passes through the model.

What deterministic engines are bad at

The other direction fails in the way automation teams know by heart. A step nobody wrote. A vendor sends a PDF scanned sideways, a purchase order number inside an email subject line, a currency the form never offered. In a workflow of connected steps that case has no branch, so the run stops and a person gets a ticket. Forty of those a month and the automation has created a job rather than removed one.

An agent takes that case because the case is the work. It opens the file, reads what is actually there, finds the number, writes down what it did. The price of that flexibility is that you cannot replay the run exactly, which is precisely why the exact half must not depend on it.

The two failures mirror each other. A fixed sequence cannot cover a case nobody imagined. An agent cannot promise the same answer twice. A process that wants both keeps the sequence in code and puts the agent in front of it.

Which parts of your process should stay deterministic

These are the parts I would keep deterministic.

• The schedule. A cron expression in a named IANA timezone, or a single run_at, says when a run starts. A model deciding to start work at some point is a different product.
• The signature on an inbound event. A webhook trigger names a project secret, and a trigger without one is rejected at validation. Constant-time comparison is code, not a habit.
• Money. Totals, tax, conversion, anything an auditor may ask you to reproduce a year from now.
• Permission. Whether a connector call runs, waits for a person or is blocked is a policy decision, and policy gets checked rather than narrated.
• The stop. A triggered session stops itself after 5 minutes idle. That is a budget, and budgets are numbers.
• The path to the main branch. Session work reaches main through a change request, and merge is default-deny for agents.

The test for that list is whether anyone will ask you to reproduce the answer. A total, a tax line, a permission check: each one belongs in code, and the agent calls it. A judgment about what to try next stays with the agent, because the first attempt is cheap when someone reads the diff.

Where the run happens, and what a person sees

Each session has its own isolated machine and branch. The machine boots from the sandbox image the project declares, clones the repo into /workspace, and puts the session's work on a new branch. The changed lines then sit as a diff against a known base, which is what a person can review.

The review happens on the change request. A person opens it, reads the changed lines, merges or asks for another pass. A deterministic engine cannot offer that, and neither can an agent without a machine. A branch leaves a base, the changed lines and a place for a comment, so a reviewer works from the same material the run did.

What a wrong answer costs

Errors in the exact half repeat. A rounding bug in a total is a bug every month, at the same step, in the same order, which is why it can be found, tested and fixed. The bill is a rate: one wrong figure times however many invoices carry it.

Errors in the judgment half arrive one at a time. An agent handed an invoice that scanned sideways writes a note the vendor will not like. That answer is wrong once, and it is wrong in a place a person sees before it leaves. Ask the same agent to compute the total and the error sits in a place nobody checks until an auditor does.

The two halves fail at different rates and for different reasons, so the review has to match the failure. A deterministic step that breaks breaks in the same spot every run, and a test catches it before the month closes. An agent's mistake is local to the run it happened in, and a person reading the diff catches it before it lands.

What decides the design is the point where a wrong answer stops. In code it stops at a test, and at a reviewer once the mistake sits in a diff. A wrong figure that reaches a customer's inbox has stopped nowhere already, and no review step refunds that.

Where the line moves

As models improve, the judgment half grows. More reading, more classification and more drafting moves into the run. The exact half does not shrink. It moves down into tools the agent calls, where it gets cheaper to test and easier to audit.

The border between agentic and deterministic is a border inside one process, not between two products. Drawing it deliberately is the work: keep the guarantee in code, keep the choice with the agent, keep the merge with a person. Four runs with their trigger rows show the shape on real schedules, and the definition covers the loop itself.

The tool comparison puts the platforms people ask about to the same rows, Kortix included. Self-host is free if the answer has to live on your own network.