Why a metaharness?
What changes when an organization moves beyond one coding-agent provider and begins using several agents, models, and inference systems.
Governance is fairly direct inside one provider’s ecosystem. Developers use the same coding agent, sign in through the same account system, and receive tools and access through one administrative path.
That arrangement provides more than access to a model. It also provides identity, subscription management, client distribution, and a common place to apply controls. Much of the governance is inherited from the provider ecosystem.
The arrangement changes when an organization wants to try another agent, use models from several providers, run open-weight models, or host inference itself. The new tools may be useful, but they sit outside the original administrative boundary. Governance no longer comes with the ecosystem.
As tool choice expands, governance stops being inherited and becomes infrastructure the organization must provide.
The problem is not the number of agents
The problem is that every agent has a different control surface. Configuration lives in different files. Skills, plugins, hooks, and MCP servers use different formats. Version changes can move paths or change what a client supports. Authentication and model routing also vary.
Platform teams can address some of this with scripts or device management. Those tools work well for files on managed employee devices, but they are a poor identity layer and may not reach contractors or other machines. They also leave the organization maintaining separate logic for every agent and version.
An inference gateway solves a different part of the problem. It centralizes model access and records requests, but it does not configure local agents, distribute extensions, or know what is happening in the developer’s working directory.
Where the gaps appear
Policy fragments across clients
Each agent has its own configuration files, extension formats, hooks, and release boundaries. A policy written for one client does not automatically apply to another.
Device control has limited reach
MDM can push files to enrolled employee devices. It is less useful for contractors, unmanaged devices, and policy that needs to follow a user across machines.
Gateway keys sit in plaintext on developer machines
Without an identity-aware exchange, virtual keys are copied into local agent configuration. Those long-lived credentials then sit unencrypted on every machine that uses them, long after the session that needed them.
A gateway alone cannot attribute usage to work
A gateway sees the user, model, and client, but not the local repository, working directory, commit, or Jira, Linear, or GitHub work item behind a session. Capturing that requires a layer closer to the developer.
The gateway credential problem
A gateway usually gives each user a virtual key. Someone must create that key, deliver it to the developer, and place it where each agent expects it. The key often ends up as plaintext in a local configuration file. It may remain there long after the session that needed it.
Placing the gateway behind a private network reduces who can reach it, but it introduces another requirement: developers must stay connected to a VPN or private tunnel whenever they use inference. This is a network boundary, not a user-level credential exchange.
A metaharness can use the organization’s identity provider instead. The developer signs in through a browser and receives a short-lived token for the current session. A proxy validates that token and substitutes the real gateway credential on the server. The upstream key never needs to be copied into the agent’s configuration.
The work attribution problem
Inference gateways already know who made a request, which model handled it, and often which agent sent it. What they cannot discover on their own is what the developer was working on: the current directory, repository, branch, commit, or the Jira, Linear, or GitHub issue behind the session.
A layer running on the developer’s machine can collect approved local context and ask the developer to choose a work item for the session. It can then carry that metadata into gateway request records. The result is a link between model consumption and a specific body of work, rather than another total grouped only by user or model.
This link gives finance teams request-level evidence tied to specific work items. That makes inference spend easier to allocate and supports the organization’s CapEx and OpEx analysis.
What a metaharness should do
- Keep the native agent intact. The shared layer should not replace each agent’s interface or remove its unique features.
- Translate one policy. Organizations should define intent once, while adapters handle the configuration expected by each supported agent and version.
- Attach policy to identity. Governance should follow a person across supported machines instead of depending only on device enrollment.
- Keep long-lived credentials off clients. Short-lived session tokens should stand between developer machines and server-held gateway keys.
- Keep gateway routing optional. Configuration governance should still work when agents connect directly to their providers.
- Deliver extensions from one control plane. Plugins, skills, hooks, MCP servers, and helper binaries should reach every client from a single catalog, instead of being installed and updated machine by machine.
Blue’s approach
Blue is an open-source, self-hosted implementation of this metaharness pattern. It wraps supported native CLIs, authenticates the developer, fetches organization policy, checks version compatibility, prepares managed configuration for the launch, and then passes control to the selected agent.
The aim is a common administrative layer for organizations that no longer use one coding-agent ecosystem.