How it works

A pipeline that turns agent telemetry into FCA-ready audit evidence.

Clarent runs as five stages: a firm-side SDK instruments each agent, our ingestion service captures the trace, a stitcher reconstructs the full decision chain, the policy engine evaluates it against UK regulatory rules, and the dashboard or audit pack surfaces the result. Below is how each stage works, the guarantees it provides, and what your engineers will integrate.

The five stages

01 Instrument SDK in your agent code. 02 Ingest Spans validated and stored. 03 Stitch Spans reconstructed into chains. 04 Evaluate 15 rules, signed verdict. 05 Audit Dashboard and PDF on demand.
01

Instrument

Firms add the Clarent SDK to their agent code with a handful of decorators. Every decision, tool call, and sub-agent delegation becomes a structured span before any data leaves the firm's environment.

Under the hood

A pip install clarent-sdk, then @clarent.trace_agent on each root agent function and clarent.trace_action() context managers on internal steps. Spans are built in OpenTelemetry's OTLP format and transported over HTTPS, so Clarent slots into any existing observability pipeline.

A PII scrubber runs in-process, inside your application, before any span leaves the firm. UK regex patterns cover National Insurance numbers, account numbers, sort codes, postcodes, and IBANs, plus configurable custom patterns for firm-specific identifiers.

# Configure once, at process start
import clarent

clarent.configure(
    api_key="clr_live_xxxx",
    firm_id="firm_acme_bank",
    environment="production",
)

# Decorate the root agent function
@clarent.trace_agent(
    agent_id="complaint-handler-v2",
    smf_owner="SMF24",
    policy_scope=["OUTCOME_SUPPORT", "OUTCOME_UNDERSTANDING"],
    model_ref="complaint-handler-v2.1-validated",
)
def handle_complaint(complaint_text: str, customer_id: str) -> dict:
    ...

No PII leaves your environment. Clarent infrastructure never sees raw customer data.

02

Ingest

Spans arrive at Clarent's ingestion service over HTTPS, are authenticated and validated, then written to columnar storage and queued for stitching.

Under the hood

The service is a Python FastAPI application running on Cloud Run in GCP's europe-west2 region (London). API keys are authenticated against SHA-256 hashes stored in PostgreSQL. Plaintext keys are never persisted.

Every span passes Pydantic validation. Invalid spans return 400. Unknown or unmatched keys return 401. Valid spans are written to ClickHouse raw_spans (10-year TTL by default, sized for the EU AI Act's audit horizon) and published to Pub/Sub topic clarent-spans-raw in the same transaction boundary. The service sustains 1,000 spans per second under load with no drops.

All data sits in GCP europe-west2. UK data residency is enforced in Terraform, not a promise.

03

Stitch

A worker reconstructs every multi-step agent run into a complete, ordered decision chain. Sub-agent delegations, tool calls, and human escalations all become nodes in a single graph.

Under the hood

The stitcher subscribes to clarent-spans-raw and buffers spans by trace_id. After 30 seconds of quiescence, meaning no new spans arriving for that trace, the buffer flushes and the chain is assembled into a directed acyclic graph. Depth, children, and execution sequence are computed from the OpenTelemetry parent-span relationships.

Orphan spans, whose parent never arrived, are logged and excluded from the chain rather than papered over, so the audit record never contains fabricated relationships. Completed chains are written to ClickHouse chains and published to Pub/Sub clarent-chains-ready.

For hybrid agents where the root span originates on a no-code platform, the buffer timeout extends per-connector: Microsoft Copilot Studio (15 minutes), M365 Copilot (90 minutes), Salesforce Agentforce (20 minutes). Defaults are configurable via environment variables.

Every decision chain is reconstructed end-to-end, including across no-code platforms.

04

Evaluate

The policy engine loads each chain, picks the policy version active at the time the agent ran, evaluates fifteen regulatory rules, and writes an immutable, cryptographically signed verdict record.

Under the hood

The engine subscribes to clarent-chains-ready. For each chain it resolves the policy version active at chain.start_time. Never retroactively. A chain that ran in March is always evaluated against the policy in force in March, even if it lands in May.

Fifteen rules run across five frameworks: FCA Consumer Duty (six rules across all four outcome areas), FG21/1 vulnerability (two rules), SMCR accountability (three rules), PRA SS1/23 model risk (three rules), and the DUA Act 2025 (one rule). Each rule returns one of four statuses: COMPLIANT, APPROACHING_BOUNDARY, BREACH, or NOT_APPLICABLE. The overall verdict takes the worst status across all applicable rules.

The verdict is canonicalised (JSON, sorted keys, no whitespace), signed with HMAC-SHA256 using a key in GCP Secret Manager, and written to ClickHouse verdict_records. That table is append-only at the database grant level: the application user has no UPDATE or DELETE permission. Any tampering, including by Clarent staff, breaks the signature.

Verdicts are immutable, cryptographically signed, and pinned to the policy version in force at the time.

05

Audit

Compliance officers see every verdict in the dashboard. When a regulator asks for evidence, a signed PDF audit pack is generated on demand.

Under the hood

The dashboard is a React and FastAPI application secured with JWT cookies (httpOnly, SameSite=Lax). Every database query is firm-scoped: a request from Firm A for any of Firm B's data returns 404, not 403, so cross-firm existence is never leaked through error semantics.

The audit pack generator produces three pack types (single-run, workflow, and firm-wide) using ReportLab. Each pack contains seven sections including the chain reconstruction, the verdict record with HMAC signature, named SMF accountability for each decision node, policy version evidence, and the chain-of-custody. Packs are stored encrypted in Google Cloud Storage in the same europe-west2 region.

When the FCA asks for evidence, you generate a signed PDF in seconds. Not weeks.

Architectural guarantees

Five things that cannot be turned off.

These guarantees are structural, not configurable. They hold whether you are a customer, a partner, or a Clarent engineer.

i.

UK data residency

All customer data sits in GCP europe-west2 (London). Region pinning is enforced at the Terraform module level, so no service can be created outside it.

ii.

Verdict immutability

verdict_records is append-only at the database grant level. The application user has no UPDATE or DELETE permission. HMAC-SHA256 signing detects tampering even by privileged actors.

iii.

Policy versioning

Chains are always evaluated against the policy version active at chain.start_time. New rules never apply retroactively to historical activity.

iv.

In-process PII scrubbing

The SDK strips UK PII patterns inside the firm's process before any span is exported. Clarent infrastructure never sees raw customer data.

v.

Firm isolation

Every read is scoped by firm_id through a single client. Cross-firm access returns 404, not 403, so existence cannot be inferred from error codes.

Integration footprint

What it works with.

Open OTLP transport. No proprietary protocols. Your existing observability stack stays unaffected.

Pro-code Python agents

The Python SDK works with LangChain, LlamaIndex, AutoGen, CrewAI, and bespoke agent frameworks. Add decorators to your existing agent functions and ship.

TypeScript and JavaScript agents

A TypeScript SDK at functional parity with the Python SDK ships in M8. The OTLP transport and PII patterns are identical, so verdicts from a TS-instrumented agent are interchangeable with verdicts from a Python one.

No-code platforms

Hybrid connectors stitch no-code parent runs together with the pro-code agents they invoke: Microsoft Copilot Studio, M365 Copilot, and Salesforce Agentforce. The stitcher extends its buffer window per platform so the no-code root span and the pro-code child spans land in the same chain.

Existing observability

Clarent uses standard OpenTelemetry over HTTPS. If you already have an OTel collector, you can point a sampling pipeline at Clarent's ingestion endpoint without replacing anything downstream.

Want to see this on your own agents?

Request a working demo against a representative agent.

A Clarent solutions engineer will walk through the pipeline live, instrument one of your test agents, and produce a sample audit pack within the session.

Talk to engineering
No self-serve. A Clarent solutions engineer will contact you within one business day. UK data residency (GCP europe-west2) guaranteed from day one.