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.
What it serves
An account you connected is one kind of thing behind the boundary. The rest is your own material, and it is the half that has no vendor in it at all.
- 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.
- Tasks are what you have to do, each with a status, so a thing can be closed rather than remembered forever.
- Assets are your own files, kept under their own names.
- Skills are your reusable procedures, exposed as MCP prompts. They are yours, not the agent's.
- Entities are the people and companies you deal with, so an address is looked up rather than recalled.
- Vault is secret material, passwords and API keys, handed out one item at a time. Nothing lists what else is in there.
Everything but connections is the owner layer, and it serves without a credential of any kind. A new profile arrives with all of it already granted, because there was never anything for a connect step to authorise. A brand new endpoint with nothing connected is already useful.
Over a hundred providers are connectable, and most of them are one command with nothing to register: the vendor signs you in as you run connect, so there is no console to visit. Every provider is the list. Google and Slack authorise against an OAuth client Lanes operates, so there is no Cloud console and no client secret of theirs on your machine. Mail, calendars, and contacts over IMAP and CalDAV take an app password, and a few providers take a token you paste, which is what makes them work over SSH.
Each Google product is its own connection, and one OAuth client covers all seven. 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.
What is not on the list you can add yourself: any MCP server, any REST API with an OpenAPI spec, any IMAP mailbox, any CalDAV or CardDAV server. Most take a short YAML file and no code, and they sit behind the same permissions and the same audit log as everything else.
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.
A profile does not hold an account. It grants one. You connect Gmail once, then grant it to whichever profiles should see it, and an account a profile was never granted is not listed at all, so an agent never learns it is there to ask about. Its own material stays its own: what you write into memory, tasks, assets, skills, entities, or the vault under work is absent under personal. What the profiles in a workspace do share is the credential store, the audit log, and the endpoint token.
A profile also declares who may use it, which is the other half of the question. An empty members list means nobody rather than everybody.
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 a Lanes sign-in, and the endpoint sits on the same machine as the agent calling it. Claude Code and Codex are registered for you. Claude Desktop and Cowork reach it too, set up by hand, because neither can be handed a URL.
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 --workspace cloud 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. Naming the workspace is not optional there: publishing is one of the few things that refuses a default rather than guessing.
One codebase covers both. A workspace 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 five commands.
$ bun install -g @lanes-sh/link # puts `lanes` on your PATH
$ lanes auth login
$ lanes link profile add personal --workspace local
$ lanes link start
ok serving http://127.0.0.1:7337/mcp
profiles: personalThe third one puts you on the profile as its owner, which is what makes it reachable at all: a profile declares who may consume it, and an empty members list means nobody rather than everybody.
Then, in another shell, register the endpoint with the agents you have installed:
$ 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
installed skill at ~/.codex/skills/lanes-link/SKILL.mdThat is a working endpoint, with an agent that knows what it is for. Your memory, tasks, assets, skills, entities and vault work already. lanes link connect gmail --profile personal walks you through the first account: connecting authorises it into the workspace, and naming the profile is what grants it there.
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 Creating a provider 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.