For a while, "Connections" in Farstax meant we were probably going to run a connector platform.
The idea was understandable. If an agent is going to do useful work beyond a repository, it needs access to things like GitHub, calendars, email, Slack, Notion and whatever else the company uses. A connector runtime gives you a catalogue, authentication, actions and a common API.
We evaluated OpenConnector as a per-workspace runtime and did a fairly serious spike.
The awkward result was that it worked.
It bound locally. Its credential storage was encrypted. Scoped runtime tokens and action allowlists behaved sensibly. It exposed an MCP interface. We exercised a real GitHub connection. Backup and restore worked when we respected SQLite's WAL behaviour.
The decision was still DEFER.
Not because the software was poor. Because adopting it would have made Farstax responsible for a much larger problem than the one we were trying to solve.
The connector runtime came with a company attached
A connector is not just an API wrapper.
Once Farstax owns the runtime, we also own its lifecycle on every workspace, its updates, its storage, its backup contract, its memory budget, its OAuth callback model, its client-secret boundary, its provider quirks and the support expectation created by whatever appears in the catalogue.
The OpenConnector spike made that concrete.
A continuously running instance had a meaningful memory footprint on the small workspace shape we care about. Google authentication raised real questions about callback routing and exactly where OAuth material should live. Different Google services were separate connector identities. Backup had to include the database state and encryption material correctly.
None of these findings made OpenConnector unusable. They showed us what adopting it meant.
We were not selecting a library.
We were volunteering to own a connector platform.
Meanwhile, MCP had moved the boundary
At the same time, the Model Context Protocol ecosystem was giving the coding agents a different route.
The providers Agent Bridge already runs can act as MCP clients. There is an official MCP Registry for discovery. MCP servers own their tools and, increasingly, their own authentication shape.
That suggested a smaller product.
Farstax did not need a catalogue of integrations with a Farstax action schema behind each one. It could be a discovery and management surface over the ecosystem that already existed.
The model became:
The Registry supplies discovery metadata. The user decides what to trust. Agent Bridge manages the provider-native MCP configuration. The coding agent talks to the selected MCP server.
Farstax observes enough state to make that usable.
That is a much less ambitious architecture.
I mean that as a compliment.
We stopped trying to certify the world
The first version of the Connections idea also carried an implicit support problem.
If Farstax presents a catalogue, does every entry mean "Farstax supports this"? Do we qualify every MCP server against every coding CLI? Do we copy tool schemas into our own database? Do we maintain an allowlist? What happens when a server changes independently?
The official Registry gave us a better boundary.
Registry presence means discoverable, not approved.
Live negotiation is the useful connection test. Configure the MCP. Authenticate if required. Ask it what tools it actually exposes. Reflect the observed state.
We can still qualify the generic MCP capability of the coding agents we support. If a particular server has a non-standard extension or a proven interoperability problem, we can investigate that evidence.
What we do not need is an N-by-M certification programme merely so the Connections page feels controlled.
OAuth was the exception that proved the boundary
Authentication did not disappear.
Some managed MCP connections need durable OAuth material that we do not want exposed to the workspace agent. We eventually built a narrow host-owned OAuth capability for that case.
It would have been easy to interpret that requirement as proof that the larger connector platform was necessary after all.
We went the other way.
The OAuth capability owns OAuth. It does not become a universal connector runtime, a generic secrets vault or a Farstax action catalogue. The MCP server still owns its protocol and tools.
This has become a recurring design test for us: when one hard requirement appears, solve that requirement at its boundary before promoting it into a new platform.
The spike was still worth doing
There is a temptation to describe avoided architecture as obviously unnecessary in hindsight.
That would be unfair to the work.
Without the OpenConnector spike, "use MCP instead" would have been mostly taste. We learned that the candidate runtime had credible security and execution mechanics. We also learned exactly which operational and OAuth responsibilities would become ours if we adopted it.
That evidence made the smaller choice more convincing.
The spike did not fail.
It clarified what we would be buying.
What I am watching next
MCP may not remove the need for richer managed Connections forever.
Customers may want a simpler trust model, unified account setup across several MCP servers, stronger enterprise controls or a service that does not exist as a usable MCP server. Any of those could move the boundary again.
For now, I am glad we did not turn "agents need access to other software" into "Farstax must own every integration between them".
We nearly built our own connector platform.
The useful result of the experiment was realising that the ecosystem had already given us permission not to.