An agentic workflow ends at a change request, not a transcript

In an agentic workflow, the model decides the next step while the run happens, rather than executing a path written in advance. Every explainer you will open says that, and they are right. Most stop before the run has a machine to happen on, a branch to leave work on, or a person who can refuse the result. Kortix is the open-source AI Operating System, and we think that ending is the half a company should judge.

The definitions agree, and they stop at the model

IBM calls agentic workflows "AI-driven processes where autonomous AI agents make decisions, take actions and coordinate tasks with minimal human intervention" (IBM). Neo4j says the goal stays fixed while the path to reach it isn't fully specified upfront (Neo4j). Both sentences put the agentic part in the decision, and both are right about it.

Neither one-line definition says where the run happens, what the run leaves behind, or who sees the result before it reaches anything real. The pages themselves go further. IBM lists human-in-the-loop feedback among its components, and Box pauses "for human approval" on sensitive steps and logs every action for traceability (Box). A definition is not a control.

That gap is structural. A sentence that has to cover a triage loop in a vendor's cloud and a script on your laptop has nowhere else to stop, and two teams can buy the same phrase and get very different amounts of control.

A run happens on a machine, and leaves a branch

A chat log records what the model said. A run records what a machine did, and the two stop being interchangeable once someone has to review the work.

One isolated sandbox per session. Each session has its own isolated machine and branch. On Kortix, the machine boots from the sandbox image the project declares, and it is "its own isolated machine: its own filesystem, its own process table, its own network" (agent computer). It clones the project repo into /workspace, so the agents and triggers arrive as files. Then it cuts a branch named after the session, and every edit or stray file the run produces lives on that branch and nowhere else. The machine is disposable. The branch is not.

A run that installed a package, migrated a database and then forgot to commit did work, but it left nothing a colleague can read. When the agent is finished, kortix cr opens a change request toward main. The reviewer gets a diff plus the session id behind it.

A trigger is a row in a file, not a canvas

A canvas asks you to draw the shape of a process and then runs the drawing. Kortix keeps the schedule in kortix.yaml, next to the agents and sandbox images, so a trigger is one row with five facts:

triggers:
  - slug: daily-digest
    type: cron
    agent: kortix
    cron: "0 0 9 * * 1-5"
    timezone: America/Los_Angeles
    session_mode: fresh
  - slug: invoice-sweep
    type: cron
    agent: finance
    cron: "0 30 6 1 * *"
    timezone: Europe/Berlin
    session_mode: reuse
  - slug: oncall-handoff
    type: cron
    agent: support
    cron: "0 0 17 * * 5"
    timezone: UTC
    session_mode: fresh
  - slug: roadmap-review
    type: cron
    agent: planner
    cron: "0 0 8 * * 1"
    timezone: America/New_York
    session_mode: pinned

The cron has six fields, second through weekday, in any IANA timezone. A webhook row swaps the schedule for a secret name. Every webhook trigger names a project secret that signs it, so a trigger without one is rejected at validation. The signature is HMAC-SHA256 over the raw body in an X-Kortix-Signature: sha256= header. The GitHub-compatible X-Hub-Signature-256 header works too, so a repo webhook needs no adapter.

Then session_mode. A fresh fire is a clean slate, with a new branch and a new machine. reuse re-prompts the most recent healthy session the trigger created, so a monthly invoice sweep keeps one thread. pinned names one exact session by id and falls through if that session is gone. Exactly two types: cron and webhook. session_mode has four values: fresh, reuse, pinned, keyed. The default is fresh, and the modes fall through in order, so a fire does not disappear.

That is the whole scheduling surface, and you can diff it. A canvas hides the same decisions in a settings panel, until somebody asks why the finance sweep runs at 06:30 Berlin time.

The change request is where the decision lands

What makes an agentic workflow useful to a company is where the result lands: somewhere a person has the authority to stop it. Session work reaches main through a change request. Merge is default-deny for agents. A person with the merge permission reads the diff and decides. A session can merge its own change request only when its agent's grant in kortix.yaml includes that capability. The starter agent ships with a broad grant that a team can narrow. Either way the rule sits in a file you can read.

Automations follow the same road. A triggered session is visible to the whole project rather than to whoever configured the trigger, and it stops after five minutes idle. The automations page puts the rule plainly: "An automation gets no privileges a person would not get." A scheduled run at 3am is not a larger actor than the person who could have done the task by hand. Approval gates you set. Off until you set them. That order matters before a nightly job goes live.

GitHub's version, and where a repository ends

GitHub Agentic Workflows is the one product in this group that ships a working system, and for repository work it is good. It is MIT licensed, and gh aw compile turns a prompt into a hardened, pinned Actions workflow. Agents read by default, and writes land as safe outputs applied by a separate job. The docs tell you to "Review generated changes before merging" (GitHub Agentic Workflows). Budgets default to 1,000 AI Credits per run and 5,000 per day as of October 2026, so a loop that goes wrong hits a ceiling.

The design is honest about its boundary: every workflow it runs is an Actions workflow over a GitHub repository, and it can run on your own Linux runners. The review it asks for is a pull request, which is the right shape when the work is code and tests. It has less to say about the agentic workflow that updates a CRM record, chases an overdue invoice or drafts a policy answer. Those runs do not end in a repository, and a pull request cannot review them.

A company runs on a repo, a CRM, a billing system and a document store at once. A workflow that touches all four needs a review step outside git too.

Three questions to ask any vendor page

Any page can claim its agents decide the next step. Three questions separate a system you can operate from one you can only demo.

• What does the run leave behind? A transcript or a screenshot asks the reviewer to trust a recording. A branch with committed work is something they can read.
• Who can refuse it, and where is that rule written? A merge button in a settings panel is not a policy. A grant in a file, changed through the same review as everything else, is.
• Where do the trigger and the agent's grant live? When the schedule is a row beside the agent that runs on it, one diff shows both. When one lives in a canvas and the other on a separate screen, nobody sees the pair together.

Ask those three of Kortix as well. The answers are in kortix.yaml and in the change request it opens.

The definitions of agentic workflow locate the decision and leave the rest open. Where the run happens, and who can say no to the result, is the part a buyer has to check.

Three posts go deeper: how to build reliable AI agent workflows covers a control per failure mode, the agentic operating system makes the permissions argument, and human in the loop vs human on the loop sorts out who decides at each call.

If you want the run to end that way, try Kortix. Free to start, free to self-host.