Framework integrations

If your agent is built on a framework, you don't call the gateway by hand. A drop-in adapter wraps the tools you already define, so every call the agent makes is scored, policed, and audited, with no change to your agent logic.

The model

There are two ways to put a framework's tools behind the gateway:

• Wrap a tool (most frameworks): guardTool / guardTools (TypeScript) or guard_tool (Python) returns a drop-in replacement that scores the call's arguments, then runs the original tool on allow. Name, description, and schema are preserved.
• A callback handler (LangChain in Python): attach one handler and every tool the agent runs is checked first, with no per-tool wrapping.

Allow, deny, hold

A guarded call scores its arguments through the gateway before the tool runs. A require_approval hold is waited out transparently and resolves to the final allow / deny. Adapters never surface a third state. On a deny you choose the behaviour:

• Raise (default): a denied call raises AxioRankDeniedError and the tool step fails hard (onDeny: "throw" in TypeScript, on_deny="raise" in Python).
• Return a refusal: onDeny: "return" / on_deny="return" returns a short, model-readable refusal string in place of the tool result, so the agent reads why it was blocked and re-plans. The natural choice for an autonomous agent.

Supported frameworks

The adapters are thin: each one funnels through the same toolCall used by the TypeScript and Python SDKs, so the allow / deny / hold semantics are identical to a hand-written integration.

Next steps

• TypeScript SDK · Python SDK: the underlying clients.
• Content-inspection engine: what each call is scored against.
• Gateway API: the HTTP contract behind every adapter.