Governing an agent you didn't build

The question that comes before the purchase

Anyone who already has agents running always asks the same question, and it has two halves.

The first is what happens to what already exists. Teams built in LangGraph, in LangChain, in an internal library, and nobody wants to rewrite anything.

The second comes right after, and it's the one that decides: if I go in, can I get out?

Both have the same answer, and it's more technical than commercial.

Registering isn't migrating

An agent registered in Tessera stays where it is. Same code, same repository, same team maintaining it, same technology. It isn't converted, it isn't rewritten, and it doesn't start running inside the platform.

What comes into being is the layer around it.

It shows up in the inventory, with a declared owner, version and environment, like any other agent in the organization. Company policies are evaluated on the calls it makes. Its runs go into the same observability and the same audit trail as agents built here. And its consumption is attributed to the team that maintains it, in the same report.

From the point of view of whoever runs the fleet, it's no longer invisible. From the point of view of whoever built it, almost nothing changed.

The condition that has to hold

Here's the limit, and it's the most important point in this article.

You can only govern what you can intercept.

The layer evaluates policy on the calls that pass through it. If the agent calls a model, a tool or a database directly, without going through the path the platform observes, that specific call is out of reach. It isn't blocked, it isn't recorded and it doesn't count toward cost.

That isn't a Tessera limitation. It's a property of any governance layer that isn't the runtime itself: you govern what passes through you.

In practice, this means integration involves real work, and that work is routing. The agent's outbound calls have to go out through the observed path. It's usually configuration, because frameworks expose that hook, but it's work and not a checkbox, and anyone who promises otherwise is leaving something out.

What this means for lock-in

The answer to the second half of the question follows directly from this.

Since nothing was migrated, leaving isn't a migration. The agent is still what it always was: same code, same technology, same repository. What you lose when you leave is the layer, not the asset.

What you lose is real and worth naming. Gone are the unified inventory, central policy evaluation, the common trail and cost attribution. The agents keep working, and the organization is once again left without a place to ask what they did.

That's the difference between depending on a platform and being locked into it. Dependence is when leaving costs you capability. Lock-in is when leaving costs you the asset.

Why almost nobody does this

It's worth saying, because it explains why the question exists.

A platform that builds agents has an incentive for agents to be built on it. Governing what was built elsewhere means delivering value to people who chose another tool, and much of the market would rather not.

Tessera's position here is structural, not generous. A governance layer that only governs what it created itself doesn't solve the organization's problem, because the problem is precisely heterogeneity. Governing only your own walled garden is selling a solution to a problem the customer doesn't have.

What integration doesn't solve

It doesn't make behavior uniform. Two agents in different frameworks, under the same policy, are still different agents. The policy limits what they can reach; it doesn't make them decide the same way.

It doesn't give you internal observability into the other framework. The platform sees what crosses the layer: calls, policies, cost, outcome. It doesn't see the internal decision tree of a graph built elsewhere, because that's private state of that runtime.

And it doesn't transfer accountability. Registering a third-party agent gives you visibility and control over what it can reach. Whoever built it and deployed it is still accountable for what it decides. Explore Integrations.