# What agent runtimes leave behind, and what open source keeps

> An agent runtime is the machine an agent runs on. What matters is what its work leaves behind, and Kortix keeps that record in an open source repo you own.

URL: https://agentruntimesguide.com/

Agent runtimes

**The open-source AI Operating System**

`The event table of Kortix Audit log for the Northwind account: the record a run leaves behind, with the event, the scope it touched and who performed it, from listing projects and project secrets to warming a session sandbox`

```

```

Source: https://kortix.com/docs/audit-actions

`agent-computer`

```
Every Kortix session gets its own computer
an isolated Linux machine
that clones your repo
cuts a branch named after the session
Work lands through a change request
a person approves
```

Source: https://kortix.com/agent-computer

Session work reaches `main` through a change request. Merge is default-deny for agents.

[Try Kortix](https://kortix.com) · [See the comparison](https://agentruntimesguide.com/#comparison)

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

## What each runtime leaves behind

Four products, read from their own pricing and documentation pages, checked October 2026.

| | Kortix (recommended) | AWS Bedrock AgentCore | E2B | Agyn |
| --- | --- | --- | --- | --- |
| Open source | Yes. Read it, fork it, audit it. | No. A managed AWS service. | Yes. The runtime is open and self-hostable. | Yes. Open source, on your own Kubernetes. |
| Where the agent runs | Its own isolated machine and a branch named after the session | A dedicated microVM per session on AWS | An isolated microVM per session, in their cloud or yours | Your Kubernetes cluster, one Helm release, per agent isolation |
| What the run leaves behind | A change request against main, in the repo you own | Nothing by default. Disk and memory end with the microVM | A filesystem you keep until you kill the sandbox | A record of every run |
| Approval before it lands | Session work reaches main through a change request. Merge is default-deny for agents. | None built in. Your application decides what ships | None built in. Every sandbox hands output back to your code | Config arrives as a reviewed pull request; runs are recorded |
| Self-host | Yes. In your VPC or on-prem. Self-host is free. | No. Managed only. | Yes, via Embed on your own infrastructure | Yes. One Helm release on your cluster |
| Billing unit | Credits: 25 tiers from $50 a month (5,000 credits) to $50,000 a month (5,000,000 credits), at 100 credits per dollar. | Per second of CPU and memory, one-second minimum | Per second of running time, plus a plan base | Your own cluster and cloud bill |

## What the runtime hands back

Three jobs, and the artifact each one leaves for a person to read.

### Engineering: A refactor on its own branch

The agent clones the repo, works on a branch named after the session, and opens a change request.

Work product: `acme-api-refactor.diff`

```diff
- charge(amount)
+ charge(amount, currency)
```

+1 -1

One change request, one reviewer.

### Support: Tickets read, replies drafted

The agent reads the queue through a connector and drafts a reply on each ticket, leaving the send to a person.

Work product: `northwind-triage.sheet`

| Ticket | Intent | Draft reply |
| --- | --- | --- |
| #4821 | refund | Refund issued, 3 to 5 days |
| #4826 | address change | Updated on the account page |

12 drafts, none sent without a person.

### Operations: The Monday report, already written

A cron trigger starts the session, the agent pulls last week’s numbers, and the report arrives as a file in the repo.

Work product: `globex-weekly.checks`

- Rows matched: 1,204
- Variance flagged: 3
- Sources cited: 6

Reviewed before it reaches the leadership channel.

## What an open source runtime keeps in your hands

Three things a company holds when the layer under its agents is code it can read.

- **The repo**: Agents, skills and their configuration sit in a git repo you can read, fork and audit, so a permission change is a diff a person can review before it lands.
- **The record**: On most runtimes a session leaves a transcript. Here each session has its own isolated machine and branch, and session work reaches main through a change request, so the review history of what agents did lives next to the review history of what people did.
- **The move**: The same stack runs in your VPC or on your own network, so changing where the layer runs is a deployment you control.

[Read the docs](https://kortix.com/docs)

## Two questions before you choose a runtime

### Is an agent runtime the same thing as a sandbox?

No. A sandbox is the isolated machine an agent runs on. A runtime is that machine plus the rules around it: which files it sees, which credentials it can spend, and how its work reaches the repository.

### Do you need an agent runtime if you already use a framework?

No. A framework decides what the agent tries next, and many frameworks ship the execution layer in the same bundle. A separate runtime earns its place when you want the machine, the permissions and the record held somewhere you control.

## Start with one session and one change request

Bring a repo, keep your own model keys, and review what the agent hands back.

[Try Kortix](https://kortix.com) · [What an agent runtime is](https://agentruntimesguide.com/what-is-an-agent-runtime)

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