Adapters

An adapter invokes the agent. It does not instrument it. There is no SDK to embed, no decorator to add and nothing in the production request path.

Adapter	Status
LangGraph Agent Server	Verified end-to-end against a live deployment
Generic HTTP	Verified end-to-end against a live deployment
OpenAI Agents SDK	Implemented, exercised against stubs
LangChain	Implemented, exercised against stubs
Local Python function / class	Implemented, exercised against stubs
WebSocket · A2A · MCP	Implemented, exercised against stubs

Two of these have been run end-to-end against production-shaped third-party environments. The rest are implemented against documented interfaces and stub tests. We list the difference because “supports nine protocols” is a claim a prospect can disprove in an afternoon, and “here are two genuinely different stacks we have run end-to-end without modifying the agent” is one they can verify.

Generic HTTP

The most portable option, and usually the fastest way into an unfamiliar environment.

agent:
  type: http
  endpoint: https://agents.internal/cards/invoke
  auth: ${CARDS_AGENT_TOKEN}
  request:
    message_field: input
    session_field: thread_id
  response:
    text_field: output

Field names are illustrative. The adapter maps to whatever request and response shape your API already uses; it does not require you to conform to ours.

What an adapter does not do

It does not read your agent’s source code.
It does not require the agent’s prompts, model or knowledge base.
It does not modify the agent under test.

Evidence about what the agent did comes from traces, not from the adapter. That separation is what allows the same approved control to run against agents built on different stacks.

Adapters

Generic HTTP

What an adapter does not do

Related