Solutions · Engineering

The work that never reaches the top of the queue.

Every session boots its own cloud computer, clones the repo, and cuts its own branch. The agent reproduces the failure, writes the patch, runs the suite, and opens a change request. You review a diff, not a transcript.

One machine per session · one branch per session · merge is default-deny

Runs on
A real Linux machine with a shell
Works on
Its own branch, cut per session
Lands as
A change request against main
Merge
Default-deny for agents
The handoff

The backlog you have stopped pretending you will get to.

Not the architecture. The long tail underneath it — the reproductions, the bumps, the flakes, the mechanical migration across two hundred files. Work that is well-specified, individually small, and collectively the reason nothing else ships.

  1. 01

    The bug nobody has reproduced

    It takes the report, builds the case on its own machine, and comes back with either a failing test or the reason it could not reproduce. A session that cannot reproduce says so. It does not invent a fix for a bug it never saw.

  2. 02

    The flaky test everyone reruns

    It runs the suite in a loop, isolates which test actually fails and how often, and finds the shared state or the timing assumption underneath. The change request carries the failure rate it measured before and after.

  3. 03

    Dependency bumps, with the build proved

    Upgrade, build, run the suite, read the changelog for the breaking notes, patch the call sites that moved. If the suite goes red it opens the change request anyway, with the failures in the description rather than a green claim.

  4. 04

    The mechanical migration across two hundred files

    One rename, one API move, one lint rule turned on — the kind of change that is trivial per file and unbearable at scale. It works file by file on its own branch and lands one reviewable diff.

  5. 05

    Last night’s exceptions, grouped

    It reads the errors the day threw, clusters them by root cause rather than by message, ranks them by how many people hit them, and takes the top one all the way to a patch.

  6. 06

    Docs that have drifted from the code

    It diffs the documented behaviour against the actual behaviour and corrects the document to match the code, or flags the code as the thing that is wrong. Both are the same commit type here — everything is a file.

The output

A diff on a branch, with the suite already run.

The output of an engineering session is the thing engineering already reviews. There is no new artifact to learn, no summary to trust — the change is the change, and the tests either passed on the machine that wrote it or they did not.

kortix/session-9f4c2b7e · retry backoff jitterChange request
packages/queue/src/retry.ts
-const delay = base * 2 ** attempt;
+// Full jitter. Without it every worker wakes on the same tick and the
+// retry storm is indistinguishable from the outage that caused it.
+const delay = Math.random() * base * 2 ** attempt;
packages/queue/src/retry.test.ts
+test("spreads retries across the window", () => {
+ const spread = sample(1_000).stddev / EXPECTED_MEAN;
+ expect(spread).toBeGreaterThan(0.4);
+});
2 files · +7 −1 · 214 tests pass
Illustration. The branch name is the session id, because that is what a session branch is.

You review the change, not a report about it

The agent commits on the session branch and opens a change request against main. What arrives in review is a diff with a description — the same object a colleague would have opened.

It ran before you read it

The sandbox is a real Linux machine, so the agent installs, builds and runs the suite itself. A change request that arrives red says so in the description rather than claiming green.

One branch, one machine, no collisions

Sessions do not share a working tree. Twenty of them can run against the same repo at once, each on its own branch and its own computer, without stepping on each other.

Where it reaches

The repo, the tracker, the thread.

An engineering session already has the strongest reach on the platform, because most of the work is inside the repo it cloned. Connectors cover the rest — and every credential is resolved on our side of the wall, never inside the machine.

The repo itself
Cloned into the sandbox at session start, on a fresh branch. The agent has a shell, a filesystem and the full history — it can bisect, run the suite, and read the commit that introduced the line it is about to change.
GitHub
Read issues, comments and the state of a branch, and write back where you have allowed it. Kortix opens the change request itself; the connector is for everything around it.
Linear
Pull the ticket that started the session, read the acceptance criteria, and post back the change request link when the work lands. The ticket stays the source of truth for scope.
Slack
The live channel. Mention the bot in a thread and that thread becomes a session; the answer, and any file it produced, comes back into the same thread. Teams is shipped but off until your deployment turns it on.
Your own services
Point Kortix at an OpenAPI or Postman spec, a GraphQL endpoint, a remote MCP server, or a bare HTTP base URL. It reads the source, works out the authentication, and turns every operation into a tool the agent can call.

Easy connect covers 3,000+ apps through their OAuth screens. Anything not in that catalogue is reachable through MCP, OpenAPI, GraphQL or raw HTTP — which is usually the honest answer for an internal service, because it never had a public catalogue entry to begin with.

How it runs

Ask now, watch the ones that matter, sleep through the rest.

The same session machinery, started three different ways. Nothing about the isolation or the review changes with the trigger.

  1. 01On demand

    From the thread you are already in

    Describe the bug in a Slack thread, or start a session from the web app or the CLI. You get a reaction on your own message rather than a bot post, and the reply lands in the same thread.

  2. 02Human-assisted

    It stops where you told it to stop

    Set an action to Ask and the run pauses at the call and waits, showing you the action and its arguments. Approve and the same call completes and the session carries on from exactly where it stopped.

  3. 03Automated

    A cron, or a signed webhook off your own alerts

    Triage the overnight exceptions at 06:00. Or wire your alerting to a signed webhook so a paging event starts a session with the incident payload already in the prompt.

Control

Nothing merges itself.

The interesting question about an autonomous engineer is not what it can write. It is what it can land. Here is the answer, stated exactly.

Merge is default-deny
An agent cannot merge to main. The permission exists — an admin can grant project.cr.merge — but the grant lives in kortix.yaml, so widening it is itself a change someone reviews. Nothing about that is a hidden default.
Approval gates are off until you set them
The shipped default is permissive: actions run unless you say otherwise. Set Ask on the ones that should pause and Block on the ones that should never happen, per action or with one pattern rule. We would rather tell you the default than let you assume the safer one.
Each session is walled off from the others
One disposable Linux machine per session, on its own branch. The only thing genuinely shared is the world outside — which is why the connectors, not the machine, are where reach is decided.
Connector credentials never enter the machine
The sandbox carries one project-scoped Kortix token and no third-party keys. The gateway decrypts the real credential server-side and attaches it to the outbound call. A runtime secret you deliberately grant is different — that one is a real environment value the agent can read, and it is meant to be.
Every tool call is written down
The gateway that resolves the credential is the same thing that writes the record: the action, the agent, the person or trigger behind the session, the outcome, and who released a held call.

The same platform, the other teams

One project, one set of connectors, one memory that compounds. Each team writes the skills for its own work; nobody stands up a second system.

All solutions →
Engineering

Give it the ticket nobody picked up.

Open source and self-hostable. Any model, your keys. Kortix Cloud, your own VPC, or your own on-prem network.

Kortix for engineering teams