One Connector, Every AI Client: Why Per-Client Integration Stops Working

Over the last few weeks we have looked at four assistants in turn — Langdock, Gemini, Claude and Microsoft Copilot — and made a version of the same argument each time: the model is rarely the constraint. Reach and method are.

This post is the argument those four were building toward. It is about what happens the moment you stop running one assistant against one system, which is roughly the moment any real enterprise programme reaches production.

Nobody standardises on one client. They just say they do.

Every organisation we talk to begins with a single-client story. Then reality arrives:

• Engineering wants a coding agent, and it is not the same product the business uses.
• A European entity needs a workspace with data residency the group standard does not offer.
• A licence bundle makes one assistant effectively free for 40,000 seats, so it stays.
• A function pilots something specialised, it works, and it becomes load-bearing.
• A model release changes the calculus for one specific workload.

Within eighteen months, "we standardised" means three or four clients in production and a policy document that describes one. That is not a governance failure. It is the normal shape of a fast-moving category.

The multiplication problem

If capability is integrated per client, the work is not N. It is N clients times M systems, and it repeats every time either number changes.

Each new client means reconnecting every system, re-running every approval, rebuilding the entitlement mapping, and adding an audit surface. Each new system means doing it once per client. The integration effort is the visible cost; the governance duplication is the expensive one.

The version of this most organisations actually live with is worse still, because the integration is not centrally built at all. It is hand-wired per user, pasted from a wiki page, and each copy drifts independently. Nobody can answer the restriction question at all, because the answer differs per laptop.

One connector, served over MCP

The alternative is to stop treating capability as something you install into a client and start treating it as something a client connects to.

Palma serves tools and skills over the Model Context Protocol. Any MCP-capable client connects to the same gateway. There is no SDK to adopt, no rearchitecting and no per-client integration work, because the protocol is the integration.

Connectors are assigned per person by IdP group, from Entra ID or Okta. No per-user setup, no credentials on laptops. The person's entitlements are a property of their identity, which means those entitlements are identical regardless of which client they happen to open.

Three consequences follow, and they are the whole argument.

1. Capability is fresh, not pasted

Every session resolves live. When an agent connects, the MCP initialize handshake returns the tools and skills that person is entitled to at that moment. The gateway's skill-set cache runs a 30-second TTL with push invalidation on commit, so a change made by a platform owner is live within seconds — no redeploy, no re-onboarding, nothing for a user to re-paste.

Contrast that with a hand-wired config, which is correct on the day it is written and slowly wrong afterwards. The failure is silent, which is why it survives so long.

2. Skills make the agents materially better

A tool is a verb. A skill is the playbook that tells the agent when and how to use the verbs it already has — which system is authoritative, what runs first, what a correct output looks like, when to stop.

Skills reach an agent through four MCP surfaces: skill:// resources with an index.json discovery manifest; five meta-tools (search_skills, load_skill, save_skill, suggest_skill_improvement, skill_feedback); MCP prompts named skill__<name>; and a Skills section injected into the initialize handshake instructions, capped at twelve with a "+N more" tail.

The discipline around them is what makes this safe at scale. Versions are immutable, content-hashed snapshots. Only scanner-passed versions are ever served. Secrets are stripped from skill content before a version is stored. Visibility is tiered — private, shared, public — with personal skills serving only their owner and off by default per tenant. A tool reference in a skill documents a dependency and never grants access. And a skill that requires a tool cannot be attached directly to a space: it must travel in a pack, so the playbook never lands without the access it assumes.

3. The person carries their capability between clients

Because the connector is served rather than installed, the same connectors, skills and policies follow the person into whichever assistant they open. Someone can work in one client in the morning and another in the afternoon and get the same tools, the same playbooks and the same limits.

Switching or adding a client stops being a programme. Nothing is re-approved, re-installed or re-audited, because none of it was client-specific in the first place.

What this changes for a platform lead

Three things, concretely.

Client choice becomes reversible. Today's best assistant for a workload is unlikely to be next year's. If your capability layer is client-agnostic, that is a procurement question rather than a re-platforming project.

Policy has one place to live. Restrict a data source once and it is restricted everywhere, in seconds, for everyone in the affected groups. Install policy modes — open, whitelist or restricted — apply per environment, so different risk profiles coexist without separate stacks.

Process becomes an asset rather than folklore. Once your best operator's method is a versioned skill served to every agent, it stops being something that leaves with the operator. It also becomes something you can improve deliberately, with a feedback path from the people running it.

The underlying bet

All of this rests on MCP being a stable, open standard rather than a vendor format, which is why Palma is a Silver member of the Agentic AI Foundation and a member of the Linux Foundation.

The reasoning is not sentimental. A capability layer is infrastructure, and the value of infrastructure is proportional to how long you can leave it alone. Anything built against a single vendor's agent framework inherits that vendor's roadmap, including the parts you did not choose. Anything built against an open protocol survives the client churn that this category guarantees.

If you run one client against one system, none of this matters much. The moment you run two of either, it is the whole problem.