Do I still need AGLedger if I already have a platform?
AGLedger is not an agent platform. It is the cryptographic accountability spine that runs underneath whatever platform you are using — or alone if you do not have one. If you need trace replay, eval scoring, prompt management, or orchestration, you need both. If you do not yet have a platform, AGLedger may be enough on its own for the accountability layer.
LangSmith · Langfuse · Galileo · Arize · Helicone · OpenTelemetry
Last updated: 2026-05-25 · API v0.25.4
Scope
What AGLedger is not
Honest scope-setting before anything else. AGLedger does not replace any of the tools below. If one of these is what you need, keep using 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. The trace IDs from your platform 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 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
Four capabilities, none of which the platforms above provide. This is the entire reason to put AGLedger underneath them.
A cryptographic accountability spine. Signed records, hash-chained in a tamper-evident vault. COSE_Sign1 (RFC 9052) envelopes with Ed25519 signatures over CBOR-encoded in-toto v1 Statement payloads. Anyone with the public keys can verify the entire chain offline.
An interface for delegated-work verdicts. Principal accepts, rejects, or requests revision on what a performer delivered. The state transition is signed. Display tokens are FULFILLED, FAILED, RECORDED — the customer vocabulary, not internal identifiers.
Cross-org loop closure via Settlement Signals. Terminal verdicts on federated work emit SETTLE, HOLD, or RELEASE by webhook to your ERP, payment platform, or ticketing system — Ed25519-signed and verifiable against AGLedger's public keys with no shared secret. Three parties accountable to each other without a trusted central authority.
An integration substrate that pulls in your existing trace IDs. The agent supplies the trace ID it already has — OTel, Langfuse, Helicone, LangSmith, Arize, Datadog, Honeycomb, MLflow, and others — and AGLedger stores it inside the signed envelope. The signed chain settles disputes about which trace was referenced at the moment of notarization.
Complement
What to keep, what AGLedger adds
The verb is complement, not replace. Most buyers already have one of these platforms; AGLedger sits underneath and adds the things the platform was not built to provide.
| If you have | Keep it for | AGLedger adds |
|---|---|---|
| LangSmith / Langfuse | LangChain and LangGraph tracing, prompt registry, dataset-based eval runs, playground debugging | Cross-framework attribution for HTTP calls and non-LangChain handoffs, Ed25519-signed and hash-chained records, federation across organizational boundaries, customer-owned data plane |
| Galileo / Arize | Quality scoring, hallucination detection, faithfulness metrics, drift monitoring, production observability | Non-repudiation, cryptographic proof of what the agent did (separate from how well it did it), tamper-evident audit chain, signed delegation handoffs between agents |
| 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, Settlement Signals for terminal verdicts on 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, SCITT-aligned transparency envelopes |
| No platform yet | — | AGLedger may be sufficient on its own for the accountability layer. It is not sufficient for tracing, evaluation, or orchestration — add a platform when one of those becomes the bottleneck. |
Differentiators
What only AGLedger does
Four properties that no agent platform on the market provides. These are the reasons Enterprise buyers put AGLedger underneath the platform they already chose.
Cross-platform attribution via TraceID join keys
The agent supplies its trace identifier at notarize time and AGLedger stores it inside the signed envelope under metadata.traces. The hash of the payload — including the trace block — is what gets signed. When a workflow crosses frameworks, the trace ID inside the record is the join key that lines everything up. The record points at the trace; the trace lives where it has always lived. See the integrations page for the full key vocabulary.
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
Pulling traces into the chain
The mechanism is intentionally narrow: 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 does not require any change to how your existing observability stack collects spans.
The full list of supported trace systems — OpenTelemetry, LangSmith, Langfuse, Helicone, Arize, Phoenix, Braintrust, Traceloop, LangGraph, Datadog, Honeycomb, MLflow, Weights & Biases — lives on the integrations page with the canonical key names for each.
Related capabilities
Notarize, Verify, and Notify as three distinct services — the shape the alternatives flatten into a dashboard.
The verdict interface logging tools do not provide — principal-rendered accept or reject signed at the moment of decision.
The cross-org capability no SaaS observability or single-tenant ledger offers — signed accountability without sharing the underlying data.
Customer-owned data plane — the platform contrast that separates AGLedger from hosted-only audit and observability services.
Why standards-aligned transparency services and federation together close the gap the alternatives leave open.
The architectural reason logs and unsigned audit trails are not interchangeable with a signed record chain.