Developer Guide

Agent Framework Integrations

Keep your agent's orchestration. Put independent assurance before consequential tool execution, using the LangGraph and Google ADK reference applications.

Discuss Your Integration Explore AI Agent Assurance

The integration boundary

Intercept the action, not the agent's reasoning

The framework continues to manage models, routing, tools and agent handoffs. An application-owned adapter captures current enterprise state and the proposed decision, calls AnantVerify, and applies the resulting control before an external effect occurs.

Agent integration flow

Agent tool proposal
Current state + proposed decision
AnantVerify
ALLOW / HOLD / ESCALATE / BLOCK
Application execution gate

Reference application	Framework	Interception point
Multi-agent customer support	LangGraph	Tools node before refund, fee waiver or cancellation effects.
Customer service	Google ADK	Tool function before refund or escalation effects.
Supply chain	Google ADK	Material tool functions before enterprise state changes.

Reference applications, not blanket certification

These examples use real framework applications. Deterministic experiment harnesses are separate and are not substitutes for running a real agent. LangChain is a broader integration target; this guide's concrete graph reference is LangGraph, not a separately verified LangChain application.

Framework names are the property of their respective owners. They are listed to describe integration patterns—not to imply partnership, certification or endorsement.

Shared assurance interface

Call AnantVerify from Python

Prerequisites: access to the AnantVerify source distribution, a reachable backend, a machine-agent key, and a registered decision pack with an approved version. Install the SDK from that checkout; the command below does not assume a public package-registry release.

# From the supplied AnantVerify source checkout:
pip install -e clients/python/anantverify

Set ANANTVERIFY_URL to your backend URL and ANANTVERIFY_API_KEY to your server-side machine-agent key. Never expose the key to browser code. This focused SDK example calls POST /v1/dtt/packs/{pack_id}/decide; pack_id, version, state and the proposed decision token must match your registered contract.

import logging
import os

from anantverify import AnantVerifyClient, FailurePolicy

av = AnantVerifyClient(
    base=os.environ["ANANTVERIFY_URL"],
    key=os.environ["ANANTVERIFY_API_KEY"],
    timeout=5.0,
    retries=1,
)

def assess_action(pack_id, version, state, proposed, decision_id):
    result = av.decide_pack(
        pack_id,
        version=version,
        state=state,
        proposed=proposed,
        decision_id=decision_id,
        mode="ENFORCE",
        action_class="high",
        failure_policy=FailurePolicy.FAIL_CLOSED,
    )
    verdict = result.get("verdict")
    if verdict not in {"ALLOW", "HOLD", "ESCALATE", "BLOCK"}:
        raise ValueError("Invalid AnantVerify verdict; action withheld")
    if result.get("degraded"):
        logging.error("Assurance unavailable; action withheld: %s", result)
    elif verdict != "ALLOW":
        logging.warning("Action withheld: %s", result)
    return result

The caller must execute only after a non-degraded ALLOW, persist the assurance result, and explicitly route every other verdict. HTTP or validation errors must surface and withhold the action, not trigger an unguarded retry. Keep the same decision_id for a retry of the same proposal and state; reassessment after a material change needs a new identity.

Verdict	Application behavior
ALLOW	Execute the assessed action only if its material context is still current.
HOLD	Withhold execution; resolve missing evidence, stale state or dependencies, then reassess.
ESCALATE	Withhold execution and route to an authorized review process.
BLOCK	Do not execute the proposed action; surface the reasons.

This is an assurance call, not a complete execution gateway. Bind the action and its arguments to the assessed state, enforce idempotency at the business system, and recheck material context before applying an effect.

LangGraph reference

Guard the tools node across specialist handoffs

The multi-agent customer-support reference uses a triage supervisor and refund, billing and cancellation specialists. The graph retains routing and shared case state. Its tools node snapshots the case and asks the shared AssuranceGate for a verdict before applying each material effect.

The excerpt below belongs inside that existing node. deepcopy, gate, LG_TOOL_DECISION and lg_effect are supplied by the reference application; this is not a standalone graph. The example maps its refund, waive and cancel tools to the pack's APPROVE proposal token.

# Inside the reference graph's tools node, before applying an effect:
snapshot = deepcopy(case)
snapshot["request"]["action"] = name
payload, enforcement, sequence, approval_id = gate.decide(
    agent_role=name,
    decision_type="tool_call",
    proposed=LG_TOOL_DECISION[name],
    state=snapshot,
    tool=name,
    arguments=args,
)

if enforcement.allow:
    result = lg_effect(state, name, args)
else:
    # Record the verdict or approval request; do not apply the effect.
    # Route HOLD / ESCALATE to the application's pause or review flow.
    ...

Inspect agent-demo/langgraph/multi_agent_support.py and agent-demo/runner/assure.py in the supplied checkout. The langgraph-customer-support pack evaluates the evolving case; a refund changes what a later waiver or cancellation is allowed to do. Keep one trace across specialists, and capture the updated state before each subsequent assessment.

Do not leave an unguarded tools node or alternate business API path that lets the agent bypass the execution gate.

Google ADK references

Wrap material tools before their effects

The customer-service reference registers ordinary tool functions with an ADK Agent. Its issue_refund function calls assure_and_run before updating refund state. A blocked or awaiting-approval response returns to the agent without applying the effect; orchestration remains with ADK.

This excerpt is from the existing tool body. The reference supplies deepcopy, ctx, gate, assure_and_run and CS_DECISION_FOR_TOOL. Its helper calls the same shared AssuranceGate used by the graph integration.

# Inside the reference ADK agent's issue_refund tool:
outcome = assure_and_run(
    gate,
    agent_role="adk_cs",
    tool="issue_refund",
    arguments={
        "amount": amount,
        "order_id": order_id,
        "customer_id": customer_id,
    },
    snapshot=deepcopy(ctx.state),
    proposed=CS_DECISION_FOR_TOOL["issue_refund"],
)
if outcome:
    return outcome  # Explicit blocked / awaiting-approval tool response.

ctx.state.setdefault("refund", {})["issued"] = True

Inspect agent-demo/google-adk/customer_service.py and agent-demo/runner/adk_run.py. The adk-customer-service pack uses REFUND for issue_refund and ESCALATE for escalate_to_human. Proposed decision tokens are pack-specific, not interchangeable with LangGraph's APPROVE token.

A second ADK application, agent-demo/google-adk/supply_chain.py, applies the same tool-boundary pattern to supply-chain decisions using the google-supply-chain pack. Adapt state mapping and decision contracts to the actual application rather than copying customer-service policy into another domain.

Try the reference workflow

Compare observation with enforcement

These commands run in the supplied AnantVerify source checkout, not in the website project. Use its configured Python environment with the actual framework dependencies, start the backend, and register the matching reference packs and versions. The reference apps simulate business effects in application state; they are not live payment or refund connectors.

The runner reads DTT_API_URL for its backend, defaulting to http://127.0.0.1:8123. Configure its model endpoint through OPENAI_API_KEY and OPENAI_MODEL, or its local Ollama settings ANANT_MODEL_BASE and ANANT_MODEL. The runner's environment variables differ from the SDK example above. Use the source distribution's deployment guidance for backend authentication.

# From the supplied source checkout, with its Python environment active:
cd agent-demo
python -m runner.run --catalog

# Baseline observation does not enforce verdicts.
python -m runner.run --framework langgraph --scenario lg_double --mode OBSERVE

# Repeat with enforcement before material tool effects.
python -m runner.run --framework langgraph --scenario lg_double --mode ENFORCE
python -m runner.run --framework adk-customer-service --scenario cs_refund_ok --mode ENFORCE

The catalog lists the available applications and scenarios, including google-supply-chain. Compare the same scenario under OBSERVE and ENFORCE. OBSERVE records assurance without enforcing it and is not a production safety boundary. ENFORCE applies the configured verdict behavior before tool effects.

Validate the outcome, not just the tool response:

Confirm assurance events identify the live REST endpoint and the relevant verdict.
Confirm a blocked action leaves business state unchanged.
Confirm a permitted action updates state once, and the next assessment sees that change.
Test HOLD, ESCALATE and backend outages as well as ALLOW and BLOCK.
Treat approval creation and framework resume as separate wiring; test both before relying on human approval.

Before production

Make the execution boundary explicit

Map authoritative state, freshness, evidence and tool arguments to a versioned decision contract; do not rely on the model's description of enterprise state.
Choose enforcement mode and outage policy explicitly. For consequential actions, withhold execution when assurance is unavailable or invalid.
Bind approval to the specific action and assessed state. Reassess when material context changes; approval is not reusable permission.
Implement business-action idempotency separately from assessment retries, and persist trace, decision, assurance and execution records.
Test interaction and sequence failures, not only isolated tool calls, with Decision Transformation Testing.

Continue with Runtime Control, DTT Methodology and Replay & Audit.

Bring your agent. Define the action boundary.

Review the reference applications and map one consequential workflow to your enterprise state, evidence and authority.

Discuss Your Integration Request an Agent Assurance Demo