Lanes Link: One Endpoint for Everything an Agent Needs

Most agents eventually need the same things: access to your email, calendar, files, and notes, but also the context around you: what you know, the skills you use, and the secrets or credentials they need to get work done.

Today, all of that tends to get wired up separately. You connect Gmail to one agent, then again to the next. You configure permissions again, copy over context again, recreate skills, and hand out credentials in slightly different ways. Each agent ends up with its own little world.

But all of those things still belong to the same person.

Lanes Link gives you one place to manage them. A single MCP endpoint you run yourself, where you connect accounts once, keep memory and reusable skills, store sensitive credentials in a vault, and decide exactly what each agent is allowed to access and do.

It is not an agent runtime: no loops, no scheduling, no model routing. It is the shared layer underneath the agents you already use.

And as of today, it's open source under Apache 2.0.

Here's what it provides, how permissions work, and how to run it yourself.

Three clients, one endpoint you run yourself. A fourth client is not a fourth integration: it inherits the same connections, the same policy, and the same audit log.

What it serves

Four kinds of thing sit behind the same boundary.

Connections are the external accounts you have linked, managed with lanes link connect. Each one is a set of capabilities the endpoint can dispatch to.
Memory is your accumulated knowledge, worth searching before an agent concludes it knows nothing about you. What one session writes is served back to every later session, including a session in a different agent.
Skills are your reusable procedures, exposed as MCP prompts. They are yours, not the agent's.
Vault is secret material, passwords and API keys, handed out one item at a time. Nothing lists what else is in there.

Memory, skills, and the vault are the owner layer, and they serve without a credential of any kind. A brand new endpoint with nothing connected is already useful.

The connectable providers today: Gmail, Drive, Sheets, Docs, Calendar, Tasks, and Contacts on Google; Mail, Calendar, Contacts, and Drive on iCloud; Notion and Linear through their own remote MCP servers. Each Google product is its own connection, and one OAuth client covers all seven. Only Google needs a client you register yourself: Notion and Linear register themselves, and iCloud takes an app-specific password.

Update, 21 August 2026. The last sentence is no longer true, and it was the sharpest edge in the whole product. Google connections now authorise against an OAuth client Lanes operates, so there is no Cloud console to visit and no seven-day re-authorisation cycle. Registering a client of your own is still supported, and still the right answer for an organisation that requires it: lanes link connect gmail --own-client. What that trades is written up in the privacy policy.

Where a tool takes a file, you give it a name: a path, an HTTPS URL, or an attachment already sitting on another message. The endpoint reads the bytes and hands them to the provider, so nothing has to be encoded into a tool call and pushed through the model.

Permissions the runtime enforces

Every capability is denied until you allow it, and policy only ever tightens as a request travels inward. gmail.search = allow and gmail.send = deny are decisions the runtime enforces, not instructions the model is asked to respect.

Every invocation produces exactly one audit event, append-only, with per-provider redaction that keeps the identifiers and withholds your content. Refused calls are recorded too, and lanes link audit tail --denied-only prints those alone. Records are hash-chained per run, and lanes link audit verify walks every chain.

Lanes Link has no database. State and the audit log are objects in a blob store: a directory on your machine locally, a bucket when deployed.

Profiles keep work and personal apart

Work and personal are not the same world, and an agent should not have to guess which one you meant. One endpoint serves every profile in a workspace, under one token, and every tool call carries a required profile argument beside connection. There is no current profile and nothing to switch: the caller names which profile a call acts within, every time.

Profiles share no configuration, no state, and no credentials. Two mailboxes in two profiles are still one gmail.users.messages.list tool: the profile argument decides which mailbox it reaches, and naming a connection from a different profile is refused before anything is dispatched.

Run it locally, or on your own cloud

Local is where to start, and where most people stay. It needs Bun 1.3.11+ and nothing else, no account anywhere, and the endpoint sits on the same machine as the agent calling it. Claude Code, Codex, Claude Desktop, and Cowork all reach it there.

Your own cloud is for reaching the endpoint from somewhere that is not that machine: the claude.ai web client, ChatGPT, a phone. lanes link deploy creates the Google Cloud project, links billing, enables the APIs, mints the service account and the bucket, builds the image, and rolls a Cloud Run revision, all on its first run. There is no key pair to mint in a console.

One codebase covers both. A target names an adapter set, and that is all that changes between them: locally a directory and an encrypted file, deployed a bucket and Secret Manager. Connections, providers, policy, and limits are declared once and apply to either.

Get started

A local endpoint takes three commands and no account anywhere.

console

$ bun install -g @lanes-sh/link                # puts `lanes` on your PATH
$ lanes link profile add personal --default
$ lanes link start
ok    serving http://127.0.0.1:7337/mcp
      profiles: personal

Then, in another shell, register the endpoint with every harness you have installed:

console

$ lanes link mcp add
ok    registered lanes-link with Claude Code (user scope)
      installed skill at ~/.claude/skills/lanes-link/SKILL.md
      installed scout agent at ~/.claude/agents/lanes-link-scout.md
ok    registered lanes-link with Codex

That is a working endpoint, with an agent that knows what it is for. lanes link connect gmail walks you through the first account.

What's next

More providers are coming, and Lanes Cloud: the same runtime and the same data model, run for you, for people who want neither a machine that has to stay awake nor a cloud project to look after. A workspace you built locally moves across intact, because the data model is the same. Lanes Cloud is not open yet, so if you want it, join the waitlist and we will tell you when it opens.

Lanes Link is open source as of today, Apache-2.0, and no secret, credential, or personal configuration ever enters the repository. Providers are additive by design, so a new one lands without touching the core, and docs/creating-a-provider.md is written to be enough on its own. Issues, pull requests, and provider proposals are all welcome at lanes-sh/link.

Join our Discord and tell us what you connect first.