Do I still need AGLedger if I already run an observability platform?
Yes, and you keep the platform too. AGLedger is a cryptographic notary, not an agent platform and not an eval tool. It runs underneath whatever you already use - or alone if you have nothing yet. Your platform tells you what happened, so you can debug it. AGLedger produces a signed, tamper-evident record of what the work intended, what it produced, and the verdict that closed it - readable later by the operator and provable to an outside auditor. The two do not overlap.
LangSmith · Langfuse · Galileo · Arize · Helicone · OpenTelemetry
Last updated: 2026-06-10 · API v1.2.0
The distinction
They capture and inspect. AGLedger notarizes.
Observability and eval platforms capture your traces and inspect the contents - the prompts, the tokens, the model output, how good the answer was. That work is for you, to debug and improve. AGLedger does the opposite job: it never inspects the deliverable. It takes what an automated process reports it intended and did, signs it, and chains it into a tamper-evident record. The agent reports with its key; the notary signs what it reported and names the accountable principal inside the signed payload. The output of one is a dashboard you read. The output of the other is evidence an auditor can verify offline without taking your word for it.
Scope
What AGLedger is not
Honest scope-setting first. AGLedger does not replace any of the tools below. If one of these is the thing you need, keep the platform that does it.
Not an agent platform. No prompt registry, no playground, no model gateway, no orchestrator runtime.
Not a trace replay tool. No span viewer, no waterfall UI, no LLM-call inspection. A trace ID from your platform can ride inside the signed envelope; the spans themselves stay where they have always lived.
Not an eval or quality-scoring tool. No hallucination detection, no faithfulness scoring, no drift monitoring. AGLedger records what was notarized and what verdict closed it out. It does not inspect deliverable content and does not judge how well the work was done.
Not an orchestration framework. No graph DSL, no node runtime, no checkpointing. Your orchestrator stays. AGLedger notarizes the work it produces.
Capability
What AGLedger is
One primitive - a signed record spanning the full lifecycle of a piece of work - expressed through three pillars. None of the platforms above provide any of them.
Notarize. Capture what an automated process intended and what it did, signed and hash-chained the moment it happens. COSE_Sign1 (RFC 9052) envelopes carry Ed25519 signatures over CBOR-encoded in-toto v1 Statement payloads. The notary signs with the instance key and names the accountable principal inside the payload, so attribution is tamper-evident without asking agents or principals to hold signing keys.
Gate. When you ask AGLedger to gate work, the principal - a human, an agent, or a rules engine - renders accept or reject at a delegation boundary, and AGLedger captures the verdict as a signed state transition. AGLedger holds the signed decision; it is not the judge. Customer-facing display tokens are FULFILLED, FAILED, and RECORDED, not internal identifiers.
Notify. A durable, signed webhook engine that keeps every other system and human in the loop - HMAC or RFC 9421 Ed25519 signatures, delivery rather than polling. Settlement Signals (SETTLE, HOLD, RELEASE on terminal cross-org verdicts) are one payload class on this channel.
Two doors
Why teams run it underneath what they already have
Two distinct reasons arrive on this page, and the same records serve both.
AI developers come for signed intent. Agents lose the plot across context wipes, hand-offs, and restarts. A signed record is a source of truth an agent can recover from - what was it told to do, and what did it already do. Your observability platform was built to help you debug, not to give the agent itself a durable, attributable state to read back. Developer Edition is free; plug it in today.
Enterprises come for compliance. Consequential agent work needs tamper-evident, attributable evidence that an outside auditor can verify, and that maps to regulation. An eval score and a trace waterfall are not that. A signed, hash-chained record of intent, result, and verdict is. No migration is involved - it is the same records the developer was already accumulating.
Complement
What to keep, what AGLedger adds underneath
The verb is complement, not replace. Most teams already run one of these. AGLedger sits underneath and adds what the platform was not built to provide.
| If you have | Keep it for | AGLedger adds underneath |
|---|---|---|
| LangSmith / Langfuse | LangChain and LangGraph tracing, prompt registry, dataset-based eval runs, playground debugging | Signed, hash-chained records of intent and result across any HTTP call and non-LangChain handoff, signed delegation chains, federation across organizational boundaries, a customer-owned data plane |
| Galileo / Arize | Quality scoring, hallucination detection, faithfulness metrics, drift monitoring, production observability | A tamper-evident record of what the work intended and produced, separate from how well it scored, with signed delegation handoffs and an auditor-verifiable chain |
| Helicone | LLM call gateway, request caching, cost tracking, per-model usage analytics | Workflow-level records that sit above individual LLM calls, delegation chains across agents and services, and Settlement Signals on terminal verdicts for consequential work |
| OpenTelemetry only | Distributed traces, metrics, structured logs across your microservices | Business-meaningful units of work above the span level, signed verdict state, federation, Settlement Signals, and SCITT-aligned transparency envelopes |
| No platform yet | - | AGLedger can stand alone as the accountability layer. It is not a substitute for tracing, evaluation, or orchestration - add a platform when one of those becomes the bottleneck. |
Differentiators
What only a notary gives you
Four properties an observability or eval platform was never built to provide. These are the reasons teams put AGLedger underneath the platform they already chose.
Offline-verifiable, tamper-evident records
Each entry is a COSE_Sign1 envelope carrying an Ed25519 signature over a CBOR-encoded in-toto v1 Statement, hash-chained to the one before it. Anyone holding the instance's published verification keys can confirm offline that the signatures are genuine and the chain is unbroken - no trust in AGLedger, and no trust in you, required. See the verification page for the offline check.
Cross-organizational accountability via P2P federation
Each organization runs its own AGLedger Server. State transitions, agent identifiers, verdict outcomes, and Settlement Signals cross the federation boundary; the underlying business data does not. RFC 9421 HTTP Message Signatures on the wire, RFC 8785 JSON canonicalization for deterministic schema digests. The chain crosses; the data stays sovereign. See the federation page for the protocol shape.
Customer-defined predicate profiles, content-addressed
Seven predicate kinds - record-state, settlement-signal, vault-checkpoint, schema-event, tenant-read, counter-attestation, federation-projection - each published with a content-addressed schema digest. Customers can define enterprise-specific contract types whose schema travels inside the signed envelope. Verifiers fetch the schema by digest and confirm structural conformance offline. See the schemas page for predicate use.
Customer-owned data plane
Self-hosted in your infrastructure. Your PostgreSQL instance. Your Ed25519 signing keys, stored in your secrets manager. AGLedger LLC operates no production data plane for customer records and is therefore neither processor nor controller in the standard deployment. The system fails open rather than fails closed - an AGLedger outage cannot halt agent work. Air-gapped operation is supported; no runtime dependency on our website, Docker Hub, or npm. See the deployment page for the full self-hosted model.
Trace correlation
Your existing trace IDs ride inside the record
You do not have to choose between the trace your platform already collects and the signed record. The agent supplies its trace identifier at notarize time, AGLedger stores it inside the signed envelope, and the relationship is fixed at the moment of signing. AGLedger does not ingest your traces, does not proxy your platform, and requires no change to how your observability stack collects spans. The signed chain settles disputes about which trace was referenced; the trace itself stays where it has always lived. The full list of supported systems - OpenTelemetry, LangSmith, Langfuse, Helicone, Arize, Phoenix, Braintrust, Traceloop, LangGraph, Datadog, Honeycomb, MLflow, Weights & Biases - and the canonical key names live on the integrations page.
Related capabilities
Notarize, Gate, and Notify as three distinct pillars - the shape observability flattens into a dashboard.
The signed verdict an eval score is not - principal-rendered accept or reject, captured at the moment of decision.
Cross-org signed accountability - what no single-tenant observability service reaches across.
Customer-owned data plane - the contrast that separates AGLedger from hosted-only observability services.
The other substitute - retention is not authenticity, and how AGLedger composes with the WORM bucket you already trust.
Why standards-aligned transparency and federation close the gap observability leaves open.
The architectural reason logs and unsigned audit trails are not interchangeable with a signed record chain.