Tooling

Tooling is the set of interfaces through which people in your organization do AI work: IDEs and their assistants, agent CLIs, notebooks, chat surfaces, and low-code builders. The Build question is not which of these is best. It is what sits underneath all of them, and whether that layer is yours.

The churn is the design constraint

Name the AI coding tool your engineers used eighteen months ago. Now name the one they use today. For most organizations those are different answers, and there is no reason to expect the next eighteen months to be calmer.

This is normally treated as a procurement annoyance. It is actually an architecture requirement. If identity, key distribution, data access, and runtime are configured inside a specific tool, then adopting the next tool means redoing all four, and the organization quietly develops a preference for whatever it already has. That preference is not a considered decision. It is switching cost pretending to be strategy.

The alternative is an enablement layer that the tools plug into rather than the other way round. Identity comes from your identity provider. Keys come from your key service. Data access goes through your gateway. Execution happens in your runtime. The tool becomes a client, and a client is replaceable.

What belongs in the layer, not the tool

Five things, and it is worth being strict about them.

Identity. The tool authenticates the person against your IdP. It does not hold its own user list, and it does not have a separate concept of a team.

Model credentials. The tool receives a scoped, short-lived credential, or it talks to a gateway that holds the real key. It never sees a long-lived provider key, and it is never the thing that decides which model is allowed.

Data access. The tool reaches data through an interface that already knows who the user is and what they are allowed to see. Handing an assistant a database URL and trusting the prompt is not access control.

Execution. Anything that runs code, installs packages, or touches infrastructure runs somewhere you chose, with the permissions you granted. See Run.

Telemetry. Usage, cost, and traces flow to your observability stack, not only to the vendor’s dashboard, which you will lose access to the day you stop paying. See Observe.

If those five are yours, a tool migration is a configuration change and a training session. If any of them lives inside the tool, it is a project.

Desktop tools, remote capability

A common false choice: either people work locally and lose access to shared compute, data, and long-running agents, or everything moves to a browser and you fight the developers who are faster in their own editor.

The resolution is that a desktop tool can drive remote capability. The editor stays local; the agent runs on a machine you control, with the data mounted and the credentials injected there. Nothing sensitive lands on the laptop, and the workflow is still the one people already know. Getting this right is mostly about the execution and credential boundaries above, not about the editor.

Standardize the interface, not the vendor

The useful standardization target is the shape of the integration: how a tool discovers what data and actions it may use, how it authenticates, and how it reports what it did. Where an open protocol exists for that shape, prefer it, because it is what makes the next tool a drop-in.

Standardizing the vendor instead produces the outcome the framework is arguing against: a single supplier holding your identity, your keys, your data path, and your runtime, with a switching cost that grows every quarter.

Tooling is a supply chain

An agent CLI or an editor extension is executable code with network access and, usually, your credentials. It deserves the same provenance questions as any other dependency: who publishes it, who can merge to it, is the version pinned, and what happens on auto-update.

There is a newer wrinkle. Prompts are now part of the shipped artifact, and a prompt is an instruction to something that can act. Review processes built to read a code diff will skim a text file.