Running work
How work moves from prompt to merged change, and the three ways it starts.
Kortix does work inside a session: a branch and a sandbox for one unit of work. A session ends when its change request (CR) merges back to the default branch. This page walks through the loop, then shows the three ways a session can start.
Sessions
A branch and a sandbox for one unit of work.
Change requests
The reviewed merge back to the default branch.
Runtime
Env vars, tokens, and the sandbox image a session runs in.
What happens when a session starts
- Kortix creates the session row and cuts a branch from the default branch. The branch name is the session id.
- Kortix resolves a sandbox image: the default image, or your own
.kortix/Dockerfileif the manifest declares one. - The sandbox boots. Its daemon,
kortix-agent, clones the repo to/workspace. It starts OpenCode REST. Session status becomesrunning. - The agent works. It uses secrets through the environment variables Kortix sets, then commits and pushes to the session branch.
- The agent opens a change request. You review it and merge it — the only way work reaches the default branch.
Three ways work runs
A session starts one of three ways.
| Mode | How it works |
|---|---|
| On-demand | You ask in chat and get the result now. |
| Human-assisted | The agent works and checks in with you for the calls that matter. |
| Automated | A trigger — a schedule or webhook — starts the session end to end. |
Related
Projects
A git repo with a manifest.
Agents
A markdown persona with scoped tools.
Models
Which model a session uses, and who pays.
Triggers
Schedules and webhooks that start sessions.
Connectors
Scoped reach into external apps.
Slack & channels
Chat surfaces that start sessions.
Computers
Machines distinct from session sandboxes.
Accounts
Principals, roles, and assignments — who can do what.