Autonomous engineering lanes
Tickets in, reviewed pull requests out.
Lanes runs coding agents in isolated sandboxes, checks their work with gates the platform executes itself, has an independent reviewer read the diff, and opens a GitHub pull request. You step in when an agent asks, or take over the same sandbox.
- Ticketintake rule
- Sandboxisolated, read-only token
- Quality gatesrun by the platform
- Reviewindependent
- Pull requesta human merges
Works with
- Works with
- GitHub
- Linear
- Claude Code
- Codex
- OpenCode
- Daytona
- OpenRouter
- Jiracoming
- Notioncoming
How it works
One lane, five stops, a human wherever it matters.
- 01
Pick up a ticket
A Linear ticket matching your intake rule, or a work item you create, is assigned to an idle lane.
- 02
Work in a sandbox
The agent gets an isolated remote sandbox with the repository and a read-only token. It never touches your machine.
- 03
Pass the gates
The platform runs your build, lint and test commands. The result is measured, not self-reported.
- 04
Independent review
A separate reviewer reads the task, the diff, the check results and prior findings. It never sees the implementer's history.
- 05
Open the pull request
The platform pushes a branch and opens a PR. A human merges. The lane never writes to the default branch.
The escalation loop. When an agent is unsure, it escalates to the Engineer Inbox and waits. Your answer goes back to the same agent session.
For engineers
Hand off the chore. Keep the steering wheel.
Agents work while you do something else, and they come to you when it counts.
Engineer Inbox
Agents ask instead of guessing. Answer a question, approve a step or unblock a lane; the answer returns to the same session.
Take over the same sandbox
Pause a running item, prompt the agent for extra turns, or work in the sandbox yourself. Resume and the gates and review run again.
Follows your conventions
Agent profiles, skills and MCP tools carry your team's conventions into every run, layered per platform, project and lane.
Reviewable by design
Every item ends as a normal pull request with the gate results and review findings attached. You decide what merges.
For teams
Run several lanes, keep the numbers.
Connect your tracker, decide what agents may pick up, and see what each item cost and how long humans spent on it.
Parallel lanes
Run several lanes at once, each with its own sandbox and escalation policy. Work waits in a queue when no lane is idle.
Linear intake rules
A rule turns matching tickets into work. Auto assigns a lane, idle leaves it for a human, refine has an agent sharpen the spec first. Progress is written back to the ticket.
Triage
Route incoming work to the right project among destinations an admin has approved, or leave the decision to a person.
Pipelines
Compose reusable agents with approval and condition nodes in a visual editor. Every project starts with a sensible default.
Multi-repo work items
One item can span several repositories. Each changed repository gets its own checkpoint, gates and pull request.
Metrics and budgets
See attempts, review loops, human time, tokens and cost, and merges per item. Credits, plan limits and spend caps keep usage bounded.
Guardrails
Autonomy with a short leash.
These limits are enforced by the platform, not requested in a prompt. Read the full trust model.
Never writes to the default branch
Only the platform pushes, through a validated bundle path, and only to a work branch.
Read-only sandbox tokens
Sandboxes get read-only repository tokens (short-lived with the GitHub App) and no workflows permission. Write credentials stay out.
Gates run on the platform
Required checks are executed by the platform. A failing required check blocks the item from review.
A reviewer that can't be swayed
The reviewer sees the task, the diff, the checks and earlier findings, never the implementer's reasoning.
Agent output is untrusted
Everything read from a sandbox is bounded and validated, and never interpolated into a shell.
Secrets by reference
Profiles and workflows carry references. Values are resolved only where they are used.
FAQ
Questions engineers ask first.
Does it push to main?
No. Lanes never writes to the default branch. It pushes a work branch through the platform and opens a pull request. Merging stays a human decision.
Which models and agent harnesses does it use?
Harnesses today are Claude Code, Codex and OpenCode, chosen per agent profile. Models are available through OpenRouter, and sandboxes run on Daytona.
Can I bring my own model key?
Yes. A workspace can use its own provider key instead of the platform's. The key is injected into the agent's environment under strict naming and metering rules.
What does a human still do?
You answer escalations, approve steps where you add approval nodes, and review and merge the pull request. You can pause any run and take over the sandbox.
How is usage billed?
Usage is metered in credits, with plan limits and spend caps per account. Talk to us for details; we are onboarding teams from the waitlist.
Get access
Put a lane on your backlog.
Lanes is invite-based while we onboard teams. Leave your email and we'll write when your access is approved.