Bring-Your-Own-Agent Runtimes: A Design Note

Every organization building an internal AI platform eventually hits the same fork: mandate a single agent framework for every team, or accept that different teams have already picked different ones — LangGraph here, a custom loop there, someone's vendor SDK on the third team — and design the platform to govern all of them without owning any of them.

The mandate is tempting because it looks simpler on a slide. It rarely survives contact with a second team, because the frameworks aren't actually interchangeable — they make different tradeoffs on state management, tool calling, and human-in-the-loop patterns that matter differently depending on what the agent does. Forcing a team building a low-latency customer-facing assistant onto the same framework as a team building a long-running batch research agent produces friction in both directions, and "just rewrite it" is rarely the answer anyone wants to hear eighteen months into a project.

What "bring your own agent" actually requires

The honest version of this isn't "anything goes." It's a small, deliberately narrow contract between the platform and every agent runtime that wants to run on it — narrow enough that switching frameworks doesn't mean renegotiating the contract, but real enough that the platform can still govern what it needs to.

A standard identity and invocation boundary. Every agent, regardless of internal framework, authenticates the same way and is invoked through the same interface — this is what lets the control plane apply policy uniformly without needing to understand each framework's internals. This is usually the easiest piece to get teams to agree to, because it doesn't touch how they build the agent itself, only how it's called.

A standard structured-output contract for anything action-taking. The platform doesn't need to know how an agent decided to take an action; it needs the action itself expressed in a common schema — what's being done, to what, under what confidence — so that policy evaluation and audit logging work the same way regardless of what produced the action. Teams resist this less than expected once they realize it's a thin translation layer at the boundary, not a rewrite of their internal logic.

A standard tool-registration path, even if tool-calling internals differ. This is where MCP earns its keep in a bring-your-own-agent design specifically: if every framework's tool calls ultimately route through MCP-compatible tool servers, the platform can govern tool access centrally without caring whether the calling agent is LangGraph, a custom loop, or something built next quarter that doesn't exist yet.

What you deliberately don't standardize

State management, prompt structure, planning strategy, and internal reasoning format all stay inside the framework boundary, by design. Trying to standardize these is where "bring your own agent" quietly turns back into a mandate wearing a different name — and it's usually motivated by a real but misplaced concern ("we can't debug five different internal architectures") that's better solved by requiring good tracing at the invocation boundary than by requiring identical internals.

The tradeoff, stated honestly

This approach costs you uniformity of tooling — your platform team can't build one deeply-integrated debugging UI that assumes a specific framework's internals, because there isn't one framework. What you get in exchange is that teams building genuinely different kinds of agents don't fight their tools to do it, and the platform doesn't become the reason a team quietly builds a shadow system outside it because the sanctioned path didn't fit their use case. For most organizations past the first two or three agent teams, that trade is worth making — the alternative isn't actually "everyone uses one framework happily," it's "everyone uses one framework, and some of them route around the platform to do it properly."