# Open source agent runtime architecture: four jobs

> An agent runtime is the layer that runs agent work: it gives a task a machine, decides what the agent may touch, records what happened, and feeds the result into the next run. Most products ship the first job and stop. Kortix is the open-source AI Operating System.

URL: https://agentruntimesguide.com/agent-runtime-architecture

## One session, end to end

`sessions`

```
It cuts a branch from `base_ref`.
Kortix boots a sandbox from the session's sandbox template, or from the platform default image when the project has none.
The sandbox clones the repo to `/workspace` and starts the harness.
The agent commits and pushes to its session branch.
A person reviews it and merges it.
A merge does not stop the session.
```

Source: https://kortix.com/markdown/docs/work/sessions.md

The sequence in the sessions documentation, in order, from branch to merged change request.

## Execute: the job every runtime ships

An agent runtime is the infrastructure layer that runs the agent. It gives the agent a machine, a copy of the code, and a harness that turns model output into tool calls. [Credal](https://credal.ai/blog/agent-harness-vs-agent-runtime) draws the line that vendor pages blur: an agent harness is "the application-layer scaffolding that turns a model into an agent", while an agent runtime is "an infrastructure-layer execution environment where the agent actually runs". Execute is the visible half of the work.

What execute needs is isolation that leaves a trail. One isolated sandbox per session. Each session has its own isolated machine and branch. Isolation on that pattern settles three problems at once. A runaway agent cannot touch a colleague's session. The branch name says which work belongs to which run. The git history becomes the account of what changed.

The sequence is short because each step does one thing. It cuts a branch, boots the machine, clones the repo, lets the agent commit, and hands the diff to a person.

A machine alone does not make a runtime. A hosted function that runs your agent loop for thirty seconds gives you execute and nothing else, which is enough for a demo and not enough for the payroll run.

## Constrain: what the agent may touch

Execute without constrain is a shell holding your credentials. Constrain answers three questions buyers tend to fold into one: what the agent may run, what it may reach, and who decides what happens to the work it produces.

Approval gates you set. Off until you set them. That default deserves a second look on any security page, because a gate that is on by default and a gate you switch on look identical in a feature list. The two behave differently in week one.

The merge path is the second half. Session work reaches `main` through a change request. Merge is default-deny for agents. The agent pushes to its own branch all day; a person decides what joins the trunk. An agent with a wide reach and an automatic merge is an unattended deploy pipeline with a language model at the keyboard.

## Observe: the record that makes a review possible

A reviewer needs more than a chat transcript. They need the prompt, the tool calls, the diff and the identity behind each call, in one place they can read afterwards. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan. Recording and reading are separate capabilities, and a runtime that records without an export path leaves your security team copying screenshots.

Observation answers the question you ask six weeks later. When an agent changed a customer record, or opened a pull request against the wrong service, the record is the difference between an hour of forensics and a week of guessing. Teams that treat logs as a debugging convenience find out during their first incident that logs are the evidence.

## Improve: turning one run into a better next run

Improve is the job almost nobody builds, and the one that compounds. It has two halves. The first is feedback: the result of a run, including the review comments on its change request, has to reach the next run. The second is the ability to change how the agent behaves.

Keeping the agent's instructions in the same repository as the code makes this easy. A behaviour change is then a commit: reviewable as a diff, revertible, and visible in the project history. The runtime supplies the machine and the record. The repository supplies the memory of what the team learned.

For a worked example, the [agent-runtime-starter](https://github.com/Kortix-seo/agent-runtime-starter) repository holds an agent file with per-tool permission rules, a `kortix.yaml` that grants connectors and secrets, and a README that walks a session branch through the change request that lands it.

## One mechanism per job to ask about

| Job | Mechanism to ask for | Question for a vendor |
| --- | --- | --- |
| Execute | A machine and a branch per session | What does one session get of its own? |
| Constrain | A change request a person merges | Who can merge, and is the agent on that list? |
| Observe | An audit record of every action | Can we read and export the record? |
| Improve | Agent config kept in the same repo | Can we review a behaviour change as a diff? |

Four questions, one per job, and each has a factual answer a vendor can give in a sentence. "Yes, on the enterprise plan" is still an answer. A demo that shows the agent writing code, and never shows the merge, the record or the config, is a demo of execute only.

## What the missing two jobs cost a team

[Work-Bench](https://www.work-bench.com/post/the-rise-of-the-agent-runtime), which studies this layer across its portfolio and the wider market, calls the agent runtime "the infrastructure layer being built to safely execute, constrain, observe, and improve agent work at scale". Two numbers from that paper explain why the last two jobs decide whether a pilot survives a first quarter. 57% of companies have agents in production (G2, 2025). 65% name agentic system complexity as the top barrier (KPMG, Q4 2025).

The bill arrives in three places. Reviews slow down, because a person has to re-run the agent to see what it did. The same failure returns, because nobody can tell whether the last fix helped. And the incidents that reach a security team come from the three jobs nobody built: an agent that reached a system it should not have, work merged that nobody read, a mistake the team had already corrected once.

Kortix runs this sequence today, with the machine, the branch and the change request in one place. [Read the docs](https://kortix.com/docs) for the flags. For the surrounding decisions, start with [what an agent runtime is](/what-is-an-agent-runtime), [how a runtime differs from a harness](/agent-runtime-vs-agent-harness) and [what a runtime costs](/agent-runtime-cost).

## Two questions from the first vendor call

Both come up before a pilot starts, and each has a short answer.

### What happens when a session’s machine stops mid-task?

A harness that keeps the running turn only in memory loses a cut-off answer, so Kortix sends the original message again. A harness that persists the turn gets one continuation message. An unanswered turn gets its message again, and a finished turn gets nothing. A lost sandbox boots from the branch, so pushed work returns.

### How long does a session keep its machine awake?

A running turn holds the machine for four hours, renewed while the turn runs. An idle session stops about 15 minutes after its last turn and wakes on the next message. A session waiting on a person holds it for two hours.

## Run all four jobs on a runtime you can read.

Start a session and watch what it records, merges and keeps.

[Try Kortix](https://kortix.com) · [How a runtime differs from a harness](https://agentruntimesguide.com/agent-runtime-vs-agent-harness)

Open source · Self-host is free · One isolated sandbox per session