Can a LangGraph agent run under your controls without rewriting it?
A team has an agent written in LangGraph. Before it touches customer data, the platform team wants it on the inventory, approved by a named reviewer, run as one step of a governed flow, with its tools reached through one gateway and its model calls screened and masked. The question is whether that means rewriting the agent.
It does not. The platform's controls apply to an endpoint, not to a framework. The Registry and the Orchestrator work on a contract: an endpoint that speaks REST, A2A or MCP, JSON in and JSON out. Flow Studio has no framework chooser.
The rest of this post is the LangGraph example from the container run, step by step, with its code. The overview of the series puts the five frameworks side by side.
1. Register the agent by its endpoint
The agent is registered in the Registry with a manifest: name, description, endpoint, version, protocol and capabilities, with input and output schemas. Registering it is enough for it to appear in Flow Studio's side panel. The example's manifest, with the endpoint as a placeholder:
POST /tenants/{tenant_id}/agents/register (multipart field: manifest)
{
"name": "LangGraph example agent",
"description": "A LangGraph agent that looks up a routing table through MCP tools behind the Gateway, with its model calls going through Kavach and Aavaran.",
"endpoint": "http://<agent-host>:8000/run",
"version": "0.1.0",
"protocol": "rest",
"capabilities": [
"mcp-tools",
"tool-use",
"kavach-shielded-model-calls"
],
"agentType": "agent",
"interface": "rest",
"category": "Framework examples",
"agent_metadata": {
"health_endpoint": "http://<agent-host>:8000/health",
"framework": "langgraph"
},
"input_spec": {
"type": "object",
"required": [
"task"
],
"properties": {
"task": {
"type": "string",
"description": "What to ask the agent"
},
"task_class": {
"type": "string",
"description": "A task class to look up, such as bug-fix"
}
}
},
"output_spec": {
"type": "object",
"properties": {
"answer": {
"type": "string"
},
"tool_calls": {
"type": "array"
},
"model": {
"type": "string"
},
"shielded_by": {
"type": "string"
},
"entities_masked_count": {
"type": "integer"
}
}
}
}The author is set to the signed-in user. Headers an agent needs are kept in the Registry's encrypted store.
2. Submit it for approval, and approve it
Approval is a request per agent version, pending, then approved or rejected, with who submitted it and who decided. In the run, the agent was submitted and approved before the flow ran.
POST /tenants/{tenant_id}/agents/{agent_id}/submit-for-approval
POST /tenants/{tenant_id}/agents/{agent_id}/approval/{approval_id}/decide?decision=approveThe Registry records the decision and emits the audit events approval_submitted and approval_approved.
3. Serve it as a step: the contract
The Orchestrator calls a REST agent with POST and a JSON object, adding X-Tenant-Id, X-Agent-Id, X-Correlation-Id (the run's id) and X-Span-Id, and expects a JSON object back; an answer of 400 or more fails the step. Before a run it probes each endpoint with HEAD, then GET, and any answer under 500 passes. The agent's host must be public, or listed in AGENT_INTERNAL_HOSTS. The example serves the agent with a few lines of FastAPI:
# common/aa_examples/step_server.py (trimmed): the whole of what the platform asks of a REST agent
app = FastAPI(title=f"{framework} example agent")
@app.get("/health")
def health():
return {"status": "ok", "framework": framework}
@app.get("/run")
def probe():
# The Orchestrator probes with HEAD, then GET; any answer under 500 passes.
return JSONResponse({"detail": "POST a JSON object to this address."}, status_code=405)
@app.post("/run")
async def run(request: Request):
payload = await request.json()
ctx = RunContext.from_headers(request.headers) # X-Tenant-Id, X-Agent-Id, X-Correlation-Id, X-Span-Id
outcome = await execute(framework, run_agent, AgentRequest.from_payload(payload), ctx)
return JSONResponse(outcome.body, status_code=outcome.status)Drawn in Flow Studio, the LangGraph agent is the first step of a two-step flow; the second, the Text Insights sample agent, reads its answer.
4. Tools over MCP, through the Agent Universal Gateway
The agent's tool calls go to the Gateway's MCP route, with a Gateway API key in X-API-Key; the Gateway checks them and passes them over MCP to the agentanywhere-mcp server. Five questions to ask of an AI agent gateway explains what the Gateway checks. The LangGraph code:
# langgraph/agent.py (trimmed)
from langgraph.graph import START, MessagesState, StateGraph
from langgraph.prebuilt import ToolNode, tools_condition
def build_graph(ctx, tools):
model = build_model(ctx).bind_tools(tools)
async def call_model(state: MessagesState):
return {"messages": [await model.ainvoke([SystemMessage(INSTRUCTIONS), *state["messages"]])]}
graph = StateGraph(MessagesState)
graph.add_node("model", call_model)
graph.add_node("tools", ToolNode(tools))
graph.add_edge(START, "model")
graph.add_conditional_edges("model", tools_condition) # tool calls -> "tools", otherwise END
graph.add_edge("tools", "model")
return graph.compile()
async def run_agent(req, ctx):
# Tools over MCP, through the Gateway; the Gateway's API key travels in X-API-Key.
transport = StreamableHttpTransport(ctx.settings.mcp_url, headers=ctx.settings.gateway_headers())
async with MCPAdapter(Client(transport)) as adapter:
tools = await adapter.list_tools()
state = await build_graph(ctx, tools).ainvoke({"messages": [HumanMessage(req.prompt())]})The tools come from LangChain's MCP adapter; the graph runs them in a `ToolNode`. In the run the agent called the taksha_router_table tool through the Gateway.
5. Model calls behind Kavach and Aavaran
The agent's model client points its base URL at Kavach, which is OpenAI chat-completions compatible. Kavach screens the request for injection, has Aavaran mask personal data, calls the model, checks the answer and keeps an audit line; tool calls pass through. In the 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. Masking before the model is one of the safeguards the DPDP Rules name.
# langgraph/agent.py
model = ChatOpenAI(model=s.llm_model, base_url=s.llm_base_url, api_key=s.llm_api_key,
default_headers=ctx.llm_headers(), temperature=0, max_retries=0).bind_tools(tools)X-User-Id carries the run's id, so the run can find Kavach's audit lines; nothing personal.
Where the settings come from
Every address and key is read from the environment, so the same image runs in any stack. These are the values the local stack used; the key is a placeholder.
# The example reads everything from the environment, so the same image runs in any stack.
LLM_BASE_URL=http://kavach:8787/v1 # Kavach; Aavaran's proxy is http://<aavaran>:8080/v1/proxy
LLM_MODEL=<model-name>
MCP_URL=http://gateway:8000/mcp # the Gateway's MCP route
GATEWAY_API_KEY=${GATEWAY_API_KEY} # a Gateway API key, sent as X-API-Key
AGENTOBS_BASE_URL=http://observe:8090 # Observe6. What the run leaves: an evidence pack and an Observe trace
The Orchestrator keeps an evidence pack for every run, built only from what it recorded: each step's status and output, the agent, the model and the mask it reported, approvals. This excerpt is real output from the container run, with ids shortened:
{
"kind": "agentanywhere.evidence-pack",
"run": {
"run_id": "usecase-6-c2a5ab4d…",
"status": "success"
},
"steps": [
{
"agent_name": "LangGraph example agent",
"status": "success",
"model": {
"provider": "kavach",
"model": "stub-model",
"shielded_by": "Kavach",
"kavach_record": "d80367d7…"
},
"masking": {
"method": "irreversible",
"policy_id": "default-shield",
"entities_masked_count": 4
},
"output": {
"framework": "langgraph",
"framework_version": "1.2.16",
"tool_calls": [
{
"name": "taksha_router_table",
"arguments": {
"task_class": "bug-fix"
}
}
],
"shielded_by": "Kavach",
"entity_types": [
"email",
"pan"
],
"entities_masked_count": 4
}
},
{
"agent_name": "Text Insights",
"status": "success"
}
],
"audit_events": null,
"audit_events_note": "The audit trail could not be read for this request."
}The audit_events note is there because the audit service was not part of the run (see below).
When Kavach refuses the call
A second run sent a real injection. Kavach refused the model call, the agent answered HTTP 403, and the step failed with Kavach's reason in the evidence pack. Real output from the container run:
{
"run": {
"status": "error"
},
"steps": [
{
"agent_name": "LangGraph example agent",
"status": "error",
"error": "AgentHttpError: The agent answered HTTP 403: The model call was refused by Kavach (prompt_injection). ML injection classifier fired (label=INJECTION, score=0.985); Canonical attack phrasing matched"
}
]
}The Observe trace
The example opens a run record in Observe with its SDK, under the platform's run id, and passes on what Kavach's audit lines said. Real output from the container run, ids shortened:
{
"correlation": {
"run_id": "usecase-6-c2a5ab4d…",
"agent_slug": "example-langgraph",
"status": "completed"
},
"trust_summary": {
"events": 3,
"kavach": {
"allow": 2,
"block": 0,
"flag": 0
},
"veil": {
"passes": 1,
"entities_masked": 4,
"entity_types": [
"email",
"pan"
]
}
}
}Can the same LangGraph agent be an A2A agent?
LangGraph's own A2A server is part of the LangSmith Agent Server, not the open-source library. So the example runs the same graph as an `a2a-sdk` executor, on the HTTP+JSON binding under `/a2a`, behind the Gateway. The Gateway's Agent Card names that route, and the platform registers the agent at the Gateway's address.
# langgraph/app.py: the REST step and, from the same agent, an A2A server
app = make_step_app("langgraph", run_agent)
a2a_app = build_a2a_app(
RunAgentExecutor("langgraph", run_agent), # a2a-sdk executor around the same graph
build_card(name="LangGraph example agent",
description="A LangGraph graph that looks up a routing table through MCP tools.",
public_url=os.getenv("GATEWAY_PUBLIC_URL", "http://gateway:8000"),
skill_id="router-table-lookup",
skill_description="Says which model tier measured best for a task class, from the router table tool."))The Gateway forwards /a2a/... to one A2A backend, so the examples point it at one framework at a time.
Registered at the Gateway's address
The platform registers the A2A agent at the address the Gateway's Agent Card names, with the Gateway's key kept in the Registry's encrypted store, approves it, and calls it as an A2A step. The card and the registration from the run, the key as a placeholder:
GET /.well-known/agent-card.json (the Gateway's own card; excerpt from the container run)
{
"name": "AgentAnywhere Universal Gateway",
"protocolVersion": "1.0",
"supportedInterfaces": [
{ "url": "http://gateway:8000/a2a", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" }
]
}
POST /tenants/{tenant_id}/a2a/agents
{
"name": "LangGraph example agent (A2A, via the Gateway)",
"endpoint": "http://gateway:8000/a2a",
"binding": "HTTP+JSON",
"protocol_version": "1.0",
"card_url": "http://gateway:8000/.well-known/agent-card.json",
"version": "0.1.0",
"skills": ["router-table-lookup"],
"headers": { "X-API-Key": "${GATEWAY_API_KEY}" }
}The A2A step's evidence pack
Run as an A2A step, the same graph's model calls still go through Kavach, so the A2A step's evidence pack lists the model and the mask as the REST step's does. Real output from the container run, ids shortened:
{
"run": {
"status": "success"
},
"steps": [
{
"agent_name": "LangGraph example agent (A2A, via the Gateway)",
"status": "success",
"model": {
"provider": "kavach",
"model": "stub-model",
"shielded_by": "Kavach",
"kavach_record": "f621fbb5…"
},
"masking": {
"method": "irreversible",
"policy_id": "default-shield",
"entities_masked_count": 4
}
}
]
}What this does not show
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 the 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.
A2A exposed, not called. The agent is exposed as an A2A agent behind the Gateway's Agent Card, and the platform called it as an A2A step. The agent itself calls no other A2A agent.
One environment per framework. The example has its own environment and image, pinned to langgraph 1.2.16 with langchain 1.4.6 (for the MCP adapter) and, for the A2A server, a2a-sdk 1.2.3, on Python 3.11. The frameworks' dependencies conflict (for example, mcp 2.x, which LangChain's MCP client uses, cannot share an environment with Microsoft Agent Framework, which caps it below 2), so each runs alone.
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.
Frequently asked questions
Can a LangGraph agent run inside AgentAnywhere without changing the platform?
Yes. A LangGraph agent served as a REST endpoint is registered in the Registry by its endpoint, approved, and placed in a flow as a step; no platform code changes. This was shown in a container run on 21 October 2026, with a stand-in model.
How does a LangGraph agent call MCP tools through the AgentAnywhere Gateway?
With LangChain's MCP adapter over a fastmcp streamable-HTTP transport carrying the Gateway's API key in X-API-Key; the graph runs the tools in a ToolNode. The Gateway routes the calls over MCP to the MCP server.
How are a LangGraph agent's model calls screened and masked?
The graph's `ChatOpenAI` has its base_url pointed at Kavach. Kavach screens each model call for injection, has Aavaran mask personal data, then calls the model; tool calls pass through. A blocked call returns HTTP 403 and the step fails with that reason.
Does LangGraph have its own A2A server?
LangGraph's A2A server is part of the LangSmith Agent Server (langgraph-api), not the open-source library. In this example the graph is exposed as an A2A agent with a2a-sdk instead, behind the Agent Universal Gateway.
What does the platform record when a LangGraph agent runs?
An evidence pack per run, with each step's status and output, the agent's name, the model and the masking Kavach reported, and approvals; and, through Observe's SDK, a run record with Kavach's allow and block verdicts and the entities masked.
Sources
Vendor documentation read on 21 October 2026; the example's code is in agentanywhere-examples, which has no public repository yet.
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.
