Where open-source Kortix runs your agentic workflow, and who reads the diff

The short answer

An agentic workflow starts with a goal and an agent that can act, and the steps between them get decided during the run. The agent reads what came back, chooses the next action, and keeps going until the goal is met or a stop condition fires.

Most definitions stop at that loop, and the loop is the easy half. A workflow that touches nothing is still a conversation. Before it describes work, the sentence needs two more parts: a computer to act on, and a gate that decides whether the result lands.

Both parts show up in a live session. git branch --show-current returns a session id, because the machine cut a branch named after the run. kortix cr returns change request opened toward main, because the result goes to a person as a diff.

What the standard definitions leave out

IBM's definition is the one most readers meet first. IBM calls agentic workflows "AI-driven processes where autonomous AI agents make decisions, take actions and coordinate tasks with minimal human intervention". It then lists the parts: models, tools, feedback mechanisms, prompt engineering, multi-agent collaboration and integrations. The account of reasoning is careful and it holds up. What it never states is what an action lands on. There is no machine in the definition, and no branch either. Human-in-the-loop arrives as one more feedback component inside the loop, rather than a person who accepts the output.

Neo4j stops at the same boundary from the other direction. "In agentic workflows, the goal is still defined, but the path to reach it isn’t fully specified upfront." Its four steps are planning, tool use, reflection and orchestration. The rest of the piece is a catalogue of design patterns with implementation notes. Tools get a full section, but a tool is a call into some system, not a place to work. Approval appears twice: as the step after one agent validates another's proposal, and as a reason to prefer a deterministic workflow when an action is high-risk.

Both descriptions are accurate about the decision process, and silent about everything under it. A reader who has to run one is left holding the two questions that decide the design: where does this happen, and who says yes before it reaches anything real.

What a run needs underneath the loop

A loop becomes a workflow when three things are settled before the first message: a place to work, a set of tools it may call, and a record of what it did. The first one is the part explanations skip.

Here the place is a Linux machine booted from the sandbox image the project declares. It is its own isolated machine, with its own filesystem, its own process table and its own network. Two runs never share a working directory or inherit each other's half-finished install. The machine clones the project repo into /workspace. The agents, skills, memory, connectors and triggers are already on disk when the first prompt arrives, because all of them are files in that repo.

sandbox:
  default: python
  templates:
    - slug: python
      image: python:3.12-slim
      cpu: 2
      memory: 4
      disk: 20

That block is the provisioning step, in full. An agent that names sandbox: python gets a Python 3.12 machine with two cores, four gigabytes of memory and twenty of disk. Same machine every time, before it reads a word of the prompt. Nothing is installed on anyone's laptop, and no setup step sits between the trigger and the first tool call.

What the run leaves behind

A session works on a branch of its own. Every edit, commit and stray file the session produces lives on that branch and nowhere else. OpenCode runs inside the machine as the harness, with the project's models, tools and secrets injected at runtime.

Nothing on the machine is precious. A bad install, a wrong migration, a deleted directory, and the machine goes away and takes all of it along. Only what the agent commits survives. That rule makes an unpredictable run reviewable. The output arrives as a diff against a known base, with the changed lines there for a person to read.

How the result lands

The work a session commits reaches main through a change request. Merge is default-deny for agents, so a run cannot put its own work into the default branch on its own authority. A session that only answers, or stops on a question, ends in the session and lands nothing. Someone reads the diff, runs it if the diff is code, and merges or asks for another pass.

This is the half that turns a demo into a workflow. A run that writes to a branch and hands over a change request behaves like a colleague with a review step, and the review is what makes the rest affordable.

Agentic or deterministic

The difference is who chooses the branch. A deterministic workflow encodes the path in advance: step one, step two, a rule for each fork. An agentic workflow encodes the goal and lets the agent pick the path while it runs. That is why it can recover from a failure nobody planned for.

Real systems mix the two. A cron schedule is deterministic. A webhook signature check is deterministic. The judgment about what to do with the payload is not. The comparison works through where each approach pays for itself, and where a fixed sequence is still the cheaper answer.

What a definition leaves to the team running it

A definition describes a loop, and a loop is not yet something anyone can review. Neither of those definitions says when a run stops spending, which files it changed, or who accepts the result. Those are decisions a team makes about its own process, and they arrive as configuration and as a diff.

A concrete case shows the gap. A digest that reads yesterday's commits is a goal, an agent and a schedule, and the definition is satisfied. It says nothing about the branch the summary lands on, nothing about the person who reads it, and nothing about what happens to a session that runs long. Each of those is a choice with a cost, and the cost stays outside the sentence.

Here the choices are settled in files. A trigger sits in kortix.yaml, a session boots its own machine, and the work it commits reaches main through a change request. The tools comparison reads the platforms people ask about most against the machine and the review, with each rival's own page linked.

Starting one you can inspect

The smallest real workflow is a trigger, an agent, and a place for the result to land. A trigger has exactly two types: cron and webhook. It lives in kortix.yaml beside the agents and the sandbox images, one file a reviewer can diff.

From there the run takes over on its own computer. What it commits goes back to the repo as a change request, and a run that only answers lands nothing. Build one writes that row, ships it and fires it once by hand. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.