About Lanes

The unit of work used to be the keystroke, then the line, then the pull request. It is becoming the task: you say what needs to happen, an agent does it, you check the result.

That changes two things at once, and they are the same problem seen from two ends. You need somewhere to run many agents without losing track of them. And you need those agents to reach your real accounts and your real context, without handing any one of them the keys to everything.

Lanes is both halves. We build them together because that is how they are used.

What that looks like

An agent that is any use has to touch things that matter: your mail, your calendar, your issues, your repositories, your notes. The moment it does, three questions arrive at once. What can it reach? How far into each thing can it go? And how do you find out what it actually did?

So the work splits across a board and an endpoint, and the interesting part is where they meet. Tasks live on the board, each with its own terminals and its own isolated checkout, so ten agents can run at once without stepping on each other. What any of them can reach is decided in one place, once, and applies wherever that agent is running: on your machine, in a chat window, in a Slack channel, or in a loop nobody is watching.

The same setup carries a personal assistant that triages your inbox, a team of internal agents that each see only their own corner, and a fleet of coding agents working through a sprint. What changes between them is the scope, not the machinery.

How we think about access

This is the part most tools get backwards, so it is worth saying plainly.

An agent is a visitor. The accounts, the memory, the notes and the credentials are yours. An agent is given a view of some of them, for as long as you allow it. It does not own them, and nothing it does should be able to change how far in it comes.

Deny by default, enforced at dispatch. Asking a model to behave is not a boundary. A permission either holds when the prompt says otherwise or it is not a permission. gmail.search allowed with gmail.send denied has to hold no matter what an email it just read tells it to do.

Scope belongs in policy, not in a second account. The usual way to narrow an agent is to go and create another service account in the vendor, with another credential, and remember which is which. That is how people end up over-provisioning: it is simply easier. Narrowing should be one line you write, and widening should be another.

A refusal is the system working. When an agent is blocked, that is the answer, not an obstacle to route around. What it was refused is worth reading, because it tells you what the job actually needs better than any guess you make up front.

Credentials never reach the agent. It gets results. If it could read the token, every permission above it would be decoration.

Everything is recorded, including the refusals. An append-only log of what was reached and what was turned away. You should never have to take our word, or the agent's, for what happened.

Work and personal do not mix. Separate profiles, separate credentials, separate stores. Something added under one is invisible under the other, and an account a profile was never granted is not listed at all, so an agent never learns it exists.

What we stand for

Your work stays yours. Source code, terminal output, prompts and agent responses stay on your machine. We are not in the path between your agent and your model provider, which is also why you keep paying that provider directly rather than a meter of ours.

State the limits. The security model says what is not guaranteed as plainly as what is, because a guarantee the code does not deliver is worse than no guarantee. The trust centre marks controls we have not built yet as planned rather than quietly implying them.

Portable by construction. What we store for you is plain files on your own disk. Read them in an editor, back them up, keep them in a private repository, or take them somewhere else. There is no export to request.

Open where it counts. The access layer, the piece that holds your credentials and decides what an agent may do, is open source under Apache-2.0. The part you are trusting most is the part you can read.

The pieces

• Lanes Desktop is where agents run: a board of tasks, each with live terminals and its own git worktree, on your Mac.
• Lanes Link is what they run through: one endpoint you own, holding your accounts, memory, tasks, skills and secrets behind the access model above.
• Lanes Compute is GPUs on demand when the work outgrows your laptop.

The use cases are the more useful way in, if you would rather start from a job than a product.

Get in touch

A small team, building in the open and shipping most weeks. The blog carries what changed and why.