Own your intelligence, own your tools

An agent has three parts you can control: the model, the harness that runs the model in a loop, and the context the model sees. Own all three and you can swap models when a better one ships, tune the loop for your domain, and keep what your agent has learned out of any one vendor’s hands.

There’s one more layer an enterprise needs to own to protect against lock-in: the tool layer. It’s typically where your APIs, your data stores, your credentials and your permissions live. And in most agent stacks today it is the least owned layer of the four.

The lock-in argument applies to tools too

The case for a neutral harness is a lock-in argument. If your agent’s memory is stored the way one model vendor likes to read it, you can’t leave that vendor without losing what the agent learned. So keep memory in a layer you control, and keep that layer independent of the model.

Run the same argument on tools and it holds. If your Salesforce integration is a LangChain tool, your Jira integration is a Claude Code plugin, and your internal pricing API is wrapped in a custom Python function somebody wrote for one agent, then your tools are bound to three different frameworks. Switching frameworks means rewriting integrations. Adding a fourth agent means wiring every tool up a fourth time. The credentials for those tools end up copied into each framework’s config, and the permission model becomes whatever each framework happens to support.

Where the tool layer is going

MCP already gives the industry a neutral format for tools, which is most of why this problem is now solvable. A tool defined once as an MCP server can be called from Claude Code, Cursor, or an agent you wrote yourself. The protocol settles the “how do I call it” question the same way native tool-calling APIs settled the JSON-parsing hacks of 2023.

But a protocol settles the format, and the format was never the hard part. The hard part is everything around it, for example:

• Who is allowed to run which server?
• Where do API keys live and who can read them?
• Which tools can a given agent see, and when should that change mid-task?
• What gets logged when an agent calls a tool against production, and who reviews it?

People who have built agent memory say the same thing about it. The database is easy; the hard part is the intelligence around the database that decides what goes in. The runtime, the registry, the secrets, the authorization and the audit trail are the work, and they’re the part that nobody owns if they’re scattered across frameworks.

What owning the tool layer means

Owning your tools means four things hold no matter which model or framework is on the other end of the call.

1. One definition, every agent. A tool is defined and deployed once, and every agent in the company calls that same deployment. Nobody copies the integration into a second framework.
2. Credentials never leave the tool layer. The agent gets a tool, never a secret. API keys, OAuth tokens and database passwords are injected at the tool runtime, so a prompt injection or a misbehaving agent can’t read them and a framework swap doesn’t mean rotating them.
3. Permissions are set once and enforced everywhere. Which agents can see which tools, and what each tool can reach, is a policy at the tool layer, not a setting inside each framework’s config. Change the policy and every agent picks it up.
4. Every call is logged in one place. When an agent hits a production API, the record of what called what, with which arguments, lands in one audit trail rather than in five frameworks’ logs.

None of these is a framework feature, and none should be. A framework’s job is to run the model in a loop well; it’s a bad place to keep the things that have to outlast every rewrite.

How we approach it at Stacklok

Stacklok treats the tool layer as its own piece of infrastructure, below the agent framework and above the APIs, so that the four properties above hold across whatever agents a company runs. Our view is that the tool layer should be treated the way platform teams already treat service meshes or secrets managers: shared, governed, and indifferent to which application is calling through it.

In practice that means a few things. MCP servers run in a managed runtime with their secrets injected at launch, rather than as processes an individual developer spins up with keys in a config file. The servers an organization trusts are listed in a registry, so engineers pull from a vetted set instead of whatever is on GitHub this week. Access policy decides which agents and which people can reach which tools, and that policy applies the same whether the caller is Claude Code, a LangChain agent, or an internal bot. And tool calls are logged centrally, so the audit question has one answer.

ToolHive is the open source way to start down that path. It runs MCP servers in isolated containers, handles secrets so they never sit in plain text in an agent’s config, and ships with a registry of servers that have been reviewed. A single engineer can install it and have a governed MCP server running in a few minutes, and the same servers then serve every agent framework they point at it. Stacklok’s platform builds on that foundation for teams that need organization-wide policy, central logging, and deployment across clusters.

We’re not neutral here, obviously, but the argument stands on its own. If owning your intelligence means being able to change any one layer without losing the others, the tool layer has to be owned too, and it has to be owned somewhere the framework can’t reach.

Where to start

Pick one tool that more than one of your agents already uses, and move it into a shared MCP server with its credentials injected at runtime. Point every agent at that server. You’ll find out quickly which of your frameworks make that easy and which have been quietly holding your integrations hostage.

ToolHive is on GitHub at github.com/stacklok/toolhive if you want to try it with that first tool. If you’d rather talk through how this looks across a whole organization, we’d like to hear what you’re running.