Skip to main content

​
How framework wrapping works

In addition to its native create_agent(...) runtime, hexgate ships adapters that wrap agents built with OpenAI Agents SDK, LangChain / LangGraph, Google ADK, or Pydantic AI to add two things without touching the agent’s logic:
  1. Tool-call policy enforcement. Each tool the agent can invoke is gated by a PolicyEnforcer that returns a typed Decision (allow / deny / needs-approval) per call. Non-allow outcomes render as a [policy_denied] / [approval_required] marker the model sees as tool output (or, for pydantic_ai, a ModelRetry) rather than aborting the run, so the agent can recover.
  2. User-aware observability. Every run is traced through Langfuse with the active HexgateContext’s identity (user id, session id, role) propagated onto the spans.
The four integrations differ in shape because the underlying SDKs do: Role resolution happens at call time from the active HexgateContext contextvar — one wrapped agent serves many users concurrently because the scope is per-call. All adapters resolve the API key the same way: from the explicit api_key= argument, falling back to the HEXGATE_API_KEY environment variable.

​
Compatible framework versions

hexgate’s adapters are exercised against a framework-version matrix. Policy enforcement is verified across these ranges: Upper bounds are the latest versions tested, not hard ceilings — newer releases may work but aren’t verified yet. Minimums for pinned dependencies (openai-agents, langchain, langgraph, google-adk, pydantic-ai-slim) are enforced by hexgate’s requirements. langgraph>=1.1.10 is floored alongside langchain>=1.2.15: it’s the langgraph of that verified set, and older langgraph is the transitive import break that fails langchain 1.1.0/1.2.5.