If you want to ensure all your agents maximize their capabilities - for both engineers and non-technical teammates - a unified internal MCP is the right call once you pass ~50 employees. There are tradeoffs, but for us the benefits far outweigh the costs.

On a typical afternoon at Basis, a Cowork agent on our sales team picks up an inbound lead, finds the contact in HubSpot, pulls the latest Gong call recording for the firm, runs a People Data Labs enrichment, drafts a personalized outreach email in the assigned rep's voice, posts the draft as a thread reply in Slack, and tags the rep.

Meanwhile, a separate Codex session, started by an engineer on the same floor, opens a Neon branch off our QA Postgres, runs a read-only query against NetSuite, and then writes up the finding in a Linear document with comments threaded against the relevant accounting policy.

Both agents talk to a single endpoint, signed in once with Google SSO, with per-user OAuth tokens that the user had connected weeks earlier. Both calls are logged with structured telemetry against tools that the user's specific role and team were authorized to call.

These workflows are routine now at Basis. They run through Satellite, the unified internal MCP we built last quarter. Pre-Satellite, our average Basis teammate had 3.2 third-party integrations connected to their agents. Post-Satellite, that number is 17.3.

Building Satellite was not an obvious choice. We considered other legitimate, credible paths to give our agents the tools they need, including embracing CLIs and using off-the-shelf provider plugins. But creating a unified MCP has been the right choice for us, despite some tradeoffs. Here’s why we did it. 

Why a unified MCP won out for us

The most important goal was to give every agent at Basis the tools it needs to do real work. Four specific benefits of Satellite have made that possible.

Adoption stops being gated by individual setup friction. Before Satellite, a teammate who wanted their agent to read Linear had to find the right MCP, install it, configure auth, and debug whatever broke. Most teammates didn’t do this more than two or three times. With Satellite, the same teammate clicks through Google SSO once and immediately has access to every provider their role and team are authorized to use.

The deeper change is that the adoption and productivity gap between empowered engineers and everyone else collapsed. When we added Granola to Satellite, every Cowork user got meeting transcripts in their next session without having to even know what an MCP is. This is the production answer to the N×M problem. About 95% of our Basis teammates now use Satellite, which means they get access to new tools the day they're released, automatically.

Switching agent harnesses takes 30 seconds, not 30 minutes. Claude Code, Codex, Cursor, and Cowork all support MCP. Once a teammate's connectors live behind Satellite, moving from one harness to another is a single re-authentication, not a fresh round of MCP installation. That portability is what lets us easily choose the best tool for each job.

Centralized policy gives us an enforceable security posture instead of a hopeful one. With dozens of MCPs scattered across personal laptops, the security model is trust: trust each teammate to configure the right scopes, not connect the wrong tool to the wrong channel, not paste a credential into the wrong file. With one unified gateway, the security model is in code. The gateway decides which providers are visible to which callers, which write actions are allowed against which targets, and which credentials leave the gateway in plaintext (none). When we needed to prevent agents from posting to client-facing Slack channels, we shipped a server-side blocklist in one place and every agent at the company picked it up automatically. 

Every new provider compounds across the entire company. The day we shipped Knock, every notification-related agent across Basis got it. The day we shipped Neon ephemeral branches, every engineer who wanted a throwaway test database got neon_create_branch with a 24-hour TTL and a per-user cap of five. There was no rollout meeting, no manual install step, no configuration sprint. The connector arrived and the agents picked it up. Each addition increases the leverage of every prior addition as the surface available to agents keeps getting bigger.

Alternate paths we considered

Before deciding to build Satellite, we considered four other paths. Each is the right answer in some contexts.

Do nothing. Let people set up their own MCPs individually. This is the path of least resistance for a small engineering team. It preserves maximum flexibility for power users. It does not work past 50 people because the median teammate is not engineering-fluent.

Let people use native connectors and plugins shipped by providers. The non-engineering version of "do nothing": tell each teammate to install the official Slack and Linear plugins and trust the vendors to keep them current. This path does not centralize control, it does not give us a single audit surface, and it leaves us downstream of every vendor's plugin roadmap.

Provide a shared Google Doc with the recommended connectors. A one-time onboarding task for each new hire to install the right MCPs from a curated list. The setup would take an hour, but curated lists are the sort of resource that are correct for a week and stale for a year.

Embrace CLIs instead of MCPs. Engineers love CLIs and they are token-efficient. We ruled this out because non-engineers cannot drive a CLI through Cowork or Claude Desktop, and the whole point was to bring the non-engineering half of the company along. CLIs are still available to the engineers who prefer them; Satellite does not preclude them.

How Satellite actually works

‍

We are publishing the recipe we used to bootstrap Satellite. Hand it to a coding agent and in less than a day it can build a working starter version of the gateway, with one provider mounted end-to-end and a provider-addition skill ready for the next one. Cloudflare's enterprise MCP reference architecture is the closest published analogue, and we built Satellite for the same reasons they built theirs.

Satellite is one MCP endpoint that fronts 36 providers, with one identity layer for human callers and a second for service-to-service callers. Every human at Basis signs in once with Google SSO; every service that talks to Satellite (our on-call agent, our adoption-analytics service) authenticates with a service-account credential and a per-service allowlist of which providers it is permitted to see. The two identity layers share the same provider mounts but use entirely different machinery.

Each provider connects through whichever path the upstream supports: per-user OAuth for the eight providers where every person needs their own scope (Google Workspace, Slack, Linear, GitHub, Figma, Notion, Granola, Knock), per-user database credentials for a few internal stores, and shared API keys with secrets-manager indirection for the rest. Refresh tokens for the OAuth providers are encrypted at rest.

Satellite filters which tools each caller sees on every request, along several axes that combine to give us the power we wanted: the right tools for the right person, no more and no less. A user who has not connected Slack does not see Slack tools. A service-to-service caller never sees the tools we reserve for human users. Tool calls are logged with structured telemetry at roughly 30,000 lines per hour, against multiple horizontally scaled instances behind Cloudflare.

The trade-offs we accept, and how we’ve addressed them

We maintain every wrapper ourselves. When the official Slack MCP gets a new tool, for example, ours does not pick it up automatically. Every wrapper is a lifetime commitment to a piece of upstream software we don’t control. We accepted that cost going in. The reason it is acceptable is that wrappers are now mostly written by our coding agents, and the maintenance cost has fallen sharply since we started.

We incur a skills tax. Vendor-bundled plugins ship with vendor-authored skills. Claude, Codex, and Cursor plugins now bundle MCPs with skills that teach the agent how to use the tools. The mere fact that a vendor ships a skill doesn’t mean the bundled skill is good, but it does mean we don't have to build and maintain that skill ourselves.

The flip side is that we may want to write our own anyway, because the bundled skill is generic to the vendor's entire user base while ours can be specific to how Basis works. We’re choosing the flexibility, even though it requires more effort. Every homegrown skill is a thin layer of procedural knowledge sitting on top of the wrapper, and most of those skills are themselves written by agents (supervised by a human reviewer). The same monorepo agents that consume Satellite also write the skills that teach future agents how to use Satellite. Every connector we add raises the floor for every teammate. Every skill we write makes agents more useful. 

What's next

Now that almost every teammate uses Satellite with their agents, it has become the interface we use to supercharge employee productivity. We’re working on distributing plugins via Satellite, which will bundle guidance for agents with MCPs.

More broadly, we hope that every lesson we learn is one fewer lesson the next team building a unified MCP has to learn the hard way.

If you’d like to work on Satellite and other projects to build an AI-native company, we’re hiring. 

‍Matthew Busel leads the Atlas team at Basis. Michael Crabtree is Atlas Tech Lead. Justin Mann is a member of Atlas technical staff. Seth Schiesel contributed to this post.