Adapter Overview

Edictum ships 19 framework adapters across Python, TypeScript, and Go. Adapters are thin translation layers -- they convert framework-specific hook events into Edictum envelopes and translate enforcement decisions back into the format each framework expects. All allow/block logic lives in the pipeline, not in the adapters.

This means you get identical enforcement semantics regardless of which framework or language you use. Switching frameworks requires changing only the adapter wiring, not your rulesets. The same rules.yaml works across all three SDKs.

Multi-Language Coverage

The Common Pattern

Every adapter follows the same three-step setup:

from edictum import Edictum, Principal
from edictum.adapters.langchain import LangChainAdapter  # or any adapter

# 1. Load rulesets
guard = Edictum.from_yaml("rules.yaml")

# 2. Create the adapter
adapter = LangChainAdapter(
    guard=guard,
    session_id="my-session-123",       # optional -- auto UUID if omitted
    principal=Principal(user_id="alice", role="analyst"),  # optional
)

# 3. Get the framework-specific hook and wire it in
wrapper = adapter.as_tool_wrapper()

Quick Comparison

Capabilities

For regulated environments requiring PII interception (not just detection), use LangChain, Agno, Google ADK, or Semantic Kernel.

Common Constructor

All adapters share the same core constructor signature:

adapter = SomeAdapter(
    guard=guard,                    # required -- the Edictum instance
    session_id="my-session-123",    # optional -- auto-generated UUID if omitted
    principal=principal,            # optional -- identity context for audit
)

All adapters also expose set_principal(principal) to update the static principal mid-session without replacing the adapter.

Some adapters accept additional parameters. See individual adapter docs for details (e.g., terminate_on_deny for Semantic Kernel).

Common Features

Lifecycle Callbacks

React to allow/block decisions in real time with callbacks on the guard:

guard = Edictum.from_yaml(
    "rules.yaml",
    on_block=lambda env, reason, cid: print(f"DENIED {env.tool_name}: {reason}"),
    on_allow=lambda env: metrics.increment("allowed", tool=env.tool_name),
)

These fire in all 8 adapters. See Lifecycle Callbacks for use cases and full API reference.

Observe Mode

Every adapter supports observe mode. When the guard is created with mode="observe", blocks are logged as CALL_WOULD_DENY audit events but the tool call is allowed to proceed:

guard = Edictum.from_yaml("rules.yaml", mode="observe")
adapter = SomeAdapter(guard=guard)

This lets you deploy rulesets in production to validate enforcement behavior before switching to mode="enforce".

Audit Sinks

Route audit events to a file with automatic redaction:

from edictum.audit import FileAuditSink, RedactionPolicy

redaction = RedactionPolicy()
sink = FileAuditSink("audit.jsonl", redaction=redaction)

guard = Edictum.from_yaml(
    "rules.yaml",
    audit_sink=sink,
    redaction=redaction,
)

Principal Context

Attach identity information to every audit event:

from edictum import Principal

principal = Principal(
    user_id="alice",
    role="sre",
    ticket_ref="JIRA-1234",
    claims={"department": "platform"},
)

adapter = SomeAdapter(guard=guard, principal=principal)

Choosing an Adapter

Pick the adapter that matches your agent framework:

• Claude Agent SDK -- Building with Anthropic's agent SDK. Hook-based enforcement via pre_tool_use / post_tool_use.
• LangChain -- Using LangChain agents with ToolNode. Wrap tool calls via as_tool_wrapper().
• CrewAI -- Using CrewAI crews. Global before/after hooks applied to every tool call across all agents in the crew.
• Agno -- Using the Agno framework. A tool_hooks compatible function that wraps tool execution.
• Google ADK -- Using Google's ADK runtime. Supports runner plugin wiring and per-agent callback wiring.
• Semantic Kernel -- Using Microsoft Semantic Kernel. Registers an auto-function-invocation filter on the kernel.
• OpenAI Agents SDK -- Using the OpenAI Agents SDK. Per-tool guardrails via tool_input_guardrails / tool_output_guardrails.
• Nanobot -- Using the nanobot multi-channel agent framework. Drop-in GovernedToolRegistry that wraps every execute() call.

If your framework is not listed, use Edictum.run() directly -- it provides the same pipeline without any adapter:

result = await guard.run(
    tool_name="read_file",
    args={"path": "/etc/passwd"},
    tool_callable=my_read_file_fn,
)

Performance

All adapters converge to the same overhead -- the adapter layer adds zero measurable cost on top of the core pipeline. Benchmarks from edictum-demo (v0.16.0, Apple M-series):

At ~43 us vs 300-2000 ms LLM round-trips, enforcement adds 0.009% of total latency. The overhead is dominated by YAML rule evaluation, not by adapter translation.

Installation Extras

Each adapter has an optional dependency group:

pip install edictum[langchain]        # LangChain adapter
pip install edictum[crewai]           # CrewAI adapter
pip install edictum[agno]             # Agno adapter
pip install edictum[semantic-kernel]  # Semantic Kernel adapter
pip install edictum[openai-agents]    # OpenAI Agents SDK adapter
pip install edictum[yaml]             # YAML rule engine (no framework deps)
pip install edictum[all]              # Everything

Google ADK requires google-adk (pip install edictum google-adk). The Claude Agent SDK and Nanobot adapters have no extra dependencies beyond edictum[yaml].