Can agents from different frameworks run under your controls?
Teams build agents with the framework they know. A platform team still wants every agent on one inventory, approved by a named reviewer, run as a step of a governed flow, with its tools reached through one gateway and its model calls screened and masked, whichever framework it came from.
The platform's controls apply to an endpoint. An agent is registered by its endpoint (REST, A2A or MCP), approved, and placed in a flow; the Orchestrator calls it with a JSON object and reads a JSON object back. Flow Studio has no framework chooser: it does not know or show which framework an agent was built with.
So the question for each framework is narrower: how does its agent reach tools over MCP with a gateway key, how does its model client take a base URL, and can it be served as an endpoint. The table answers that for five.
Five frameworks, side by side
What each framework's agent used in the examples, from the code that ran. Versions are the ones pinned on 21 October 2026.
| Framework | Tools over MCP through the Gateway | A2A | Platform step | Model calls behind Kavach and Aavaran |
|---|---|---|---|---|
| Framework: LangChain 1.4.6 | langchain.mcp.MCPAdapter, with a fastmcp transport carrying X-API-Key | No A2A server or client in the library | REST step | ChatOpenAI(base_url=…) |
| Framework: LangGraph 1.2.16 | The same adapter, inside an explicit StateGraph (ToolNode, tools_condition) | Exposed as an A2A agent by an a2a-sdk wrapper; LangGraph's own A2A server is part of the LangSmith Agent Server | REST step and A2A step | As LangChain |
| Framework: Google ADK 2.12.0 | McpToolset(StreamableHTTPConnectionParams(url, headers)) | Exposed as an A2A agent by ADK's own A2aAgentExecutor, on a2a-sdk's HTTP+JSON routes | REST step and A2A step | LiteLlm("openai/<model>", api_base=…) |
| Framework: Microsoft Agent Framework 1.22.0 | MCPStreamableHTTPTool(static_headers=…) | Exposed as an A2A agent by A2AExecutor (agent-framework-a2a, a beta), with stream=True | REST step and A2A step | OpenAIChatCompletionClient(base_url=…) |
| Framework: OpenAI Agents SDK 0.24.0 | MCPServerStreamableHttp(params={url, headers}) | No A2A support in the SDK | REST step | OpenAIChatCompletionsModel(openai_client=AsyncOpenAI(base_url=…)); the SDK's trace export off |
Every example sends its run to Observe with a few lines of Observe's SDK. Nothing in an A2A column calls another A2A agent; the agents are exposed, and the platform calls them.
What every example shares
The step contract. POST to the agent's endpoint with a JSON object, the run's id and workspace in headers, a JSON object back; an answer of 400 or more fails the step. The Orchestrator probes each endpoint before a run, and the agent's host must be public or listed in AGENT_INTERNAL_HOSTS.
Registration and approval. Each agent was registered in the Registry with its name, endpoint, version, protocol and capabilities, submitted for approval and approved before its flow ran.
Tools through the Gateway. Each framework's own MCP client called the Gateway's MCP route with a Gateway key in X-API-Key, and the Gateway passed the calls to the MCP server. Five questions to ask of an AI agent gateway explains what it checks.
Model calls behind Kavach and Aavaran. Each framework's model client took Kavach's address as its base URL. In every passing run Kavach's audit lines recorded 4 entities masked, and neither the e-mail address nor the PAN in the request reached the model server. A second run sent a real injection: Kavach refused the model call, and the step failed with Kavach's reason in the evidence pack.
A record of each run. The Orchestrator's evidence pack lists the steps, the agent, the model and the mask Kavach reported, and approvals; Observe holds the run record and Kavach's verdicts.
What ran, and what only exists in code
Ran. The Orchestrator called each framework agent as a REST step. It called the LangGraph, Google ADK and Microsoft Agent Framework agents as A2A steps through the Gateway too.
Exists in code, not run here. A workspace can connect an MCP server so that the tools it picks become agents of their own, the direction opposite to these examples. And a workspace's flows can be offered as an MCP server or as an A2A agent, so that a framework agent could call a platform flow. Both are in the platform's code; neither was part of this run.
What none of the examples shows
No real model. The model was a stand-in server. Nothing here shows what a real model does with masked text or with tool results.
No audit service. The audit service was not part of the run, so each evidence pack's audit_events field reads "The audit trail could not be read for this request."
No Agent Lab checks. The credentials, personal-data, injection, soak and health checks need Agent Lab's runner, which was not part of the run.
One environment per framework. Each example has its own environment and image, because the frameworks' dependencies conflict (for example, mcp 2.x cannot share an environment with Microsoft Agent Framework, which caps it below 2).
The platform's local stack. Every service ran in a container on a rented machine, with an in-memory workflow server. It is the platform's local stack, not a production deployment.
No Semantic Kernel. Semantic Kernel has no example: Microsoft names Agent Framework its successor.
Read the five posts
LangChain agents with MCP tools and guardrails. LangGraph over MCP and A2A. Google ADK agents with MCP and A2A. Microsoft Agent Framework agents with MCP and A2A. The OpenAI Agents SDK with MCP tools and guardrails.
Each has the example's code for registration, the step contract, the MCP tool call through the Gateway and the base URL for Kavach and Aavaran, with real output from the run.
Frequently asked questions
Which agent frameworks have been shown running inside AgentAnywhere?
LangChain, LangGraph, Google ADK, Microsoft Agent Framework and the OpenAI Agents SDK. In a container run on 21 October 2026, with a stand-in model, an agent built with each was registered, approved and run as a step in a flow, with its tools over MCP through the Agent Universal Gateway and its model calls behind Kavach and Aavaran.
Does AgentAnywhere need framework-specific code to run an agent?
No. The Registry and the Orchestrator work on a contract: an endpoint that speaks REST, A2A or MCP, with JSON in and JSON out. Flow Studio has no framework chooser and does not show which framework an agent was built with.
How does a framework agent reach tools through the AgentAnywhere Gateway?
With the framework's own MCP client, pointed at the Agent Universal Gateway's MCP route with a Gateway API key in X-API-Key. The Gateway passes the calls over MCP to the MCP server.
Can a framework agent be an A2A agent behind the AgentAnywhere Gateway?
Three were: LangGraph through an a2a-sdk wrapper, Google ADK through its own A2aAgentExecutor and Microsoft Agent Framework through its A2AExecutor (a beta package), each on the HTTP+JSON binding behind the Gateway's Agent Card. The platform called each as an A2A step. The LangChain library and the OpenAI Agents SDK have no A2A support.
How are a framework agent's model calls screened and masked?
The framework's model client takes Kavach's address as its base URL. Kavach is OpenAI chat-completions compatible: it screens each call for injection, has Aavaran mask personal data, then calls the model. A blocked call returns HTTP 403, and the step fails with that reason.
Why is there no Semantic Kernel example?
Microsoft names Agent Framework the successor to Semantic Kernel, so the Microsoft example is built with Agent Framework.
Written by
AgentAnywhere Research
The team that builds the platform and the models
AgentAnywhere Research writes about the platform, the model families and the trust layer we build and run in India. Where a figure is ours, it says what it covers; where something is a demonstration, it says so.
