Fit AGLedger under the stack you already run
AGLedger is not an agent platform, and it ships no connectors to the systems your agents write to - your CRM, ERP, or ticketing system. The agent calls those directly; AGLedger sits at the seam and signs the record of the change the moment it happens. What it integrates with is the surrounding stack you already run: your observability tools stay, your SIEM stays. AGLedger plugs in beside them, carrying the join keys that let everything line up and exporting the same events in the shape your security team already reads. It is a complement, not a replacement.
Because the platform is agnostic and the API is built for agents to read, you do not build a bespoke integration layer. The agent calls the same REST surface anything else does, follows the nextSteps and hint fields in each response, and reads the directive in each error. The agent integrates itself.
OpenTelemetry · Langfuse · Arize · Datadog · Honeycomb · OCSF · REST · SDK · CLI · MCP
Last updated: 2026-06-29 · API v1.2.0 · 193 routes
Trace correlation
Carry the trace ID inside the signed envelope
AGLedger does not ingest your traces, proxy your calls, or replace your observability platform. The agent supplies the trace identifier it already holds - from OpenTelemetry, Langfuse, Arize, Datadog, Honeycomb, or any of the trace tools listed below - and the notary signs a record that stores it under metadata.traces. The agent reports with its key; the notary signs what it reported. The trace identifier is part of what gets signed.
The hash of the record's payload - including the trace block - is what the instance key signs. If anyone later disputes which trace was referenced at the moment the work was notarized, the signed chain settles the question. The record points at the trace; the trace lives where it has always lived. You get a tamper-evident join key across systems without moving any data into AGLedger.
| Key | System | Format |
|---|---|---|
otel_trace_id / otel_span_id | OpenTelemetry / W3C TraceContext | 32 hex / 16 hex |
langsmith_run_id | LangChain LangSmith | UUID |
langfuse_trace_id | Langfuse | string |
helicone_request_id | Helicone | UUID |
arize_trace_id / phoenix_span_id | Arize / Arize Phoenix | string / hex |
braintrust_span_id | Braintrust | string |
traceloop_trace_id | Traceloop / OpenLLMetry | string |
langgraph_run_id | LangGraph | UUID |
datadog_trace_id | Datadog APM | uint64-as-string |
honeycomb_trace_id | Honeycomb | hex |
mlflow_run_id | MLflow | UUID |
wandb_run_id | Weights & Biases | string |
Use the keys that apply. Unknown keys are accepted but not part of the convention - stick to this set so downstream consumers can rely on the shape. The SDKs emit it for you.
SIEM export
OCSF events into your security operations pipeline
AGLedger emits Open Cybersecurity Schema Framework (OCSF) events for every state transition, completion submission, verdict, settlement signal, and dispute action. Two push channels ship out of the box: file (newline-delimited JSON for log shippers) and HTTP (POST to a collector endpoint with configurable auth).
The OCSF taxonomy maps cleanly onto Splunk, Microsoft Sentinel, Datadog Cloud SIEM, Sumo Logic, Chronicle, and any SIEM that consumes the schema. Alert rules, dashboards, and correlations written against OCSF work against AGLedger events without translation. The same trace IDs you carried in metadata.traces ride through into the OCSF event, so a SIEM correlation can pivot straight back to the observability platform that holds the span.
SIEM export is the auditor-facing read of the same record the dev already accumulated. Nothing migrates: the events the operator watched and the evidence the security team queries are the same signed records, projected into the shape each reader needs.
API surfaces
REST primary, plus SDKs, CLI, and MCP server
Anything that speaks HTTP can call AGLedger directly - the native REST surface is 193 routes, OpenAPI 3.0 documented, and it is the primary interface. The TypeScript SDK, Python SDK, CLI, and MCP server are thin wrappers over that same surface, included where they reduce friction. None of them is required; the API is the integration.
nextSteps, suggestion, and hint fields where useful, so agents learn the surface in-band. Errors follow RFC 9457 Problem Details with directive guidance, not just diagnostics, and discovery runs zero-scaffolding from /llms.txt and /.well-known.npm install @agledger/sdk - thin typed wrapper, no opinion on framework.pip install agledger - matching surface to the TS SDK, same shape.npm install -g @agledger/cli - scriptable from any shell or CI pipeline.npm install -g @agledger/mcp-server - for agent hosts that prefer MCP tool discovery. Same record lifecycle, exposed as MCP tools.AGLedger is platform-agnostic and framework-neutral - tested across Claude, GPT, Gemini, and Nova, with no dependency on any agent framework. Full API reference in the API reference. SDKs and CLI in the SDK guide.
Event delivery
Record events delivered to your existing systems
Where SIEM export carries events in a security-team-native shape, Notify pushes the same record events - created, completion submitted, fulfilled, failed, delegated, disputed, settled - as signed webhooks to the systems and humans already in production. Signing is HMAC by default and Ed25519 RFC 9421 for Settlement Signals™ a counterparty has to trust.
The event surface, both signing schemes, and the delivery guarantees live on the Notify capability page; the webhook guide has the consume-and-verify code. This page does not repeat them.
Complement, not replace
It sits beside your observability and eval tools
AGLedger is not an observability platform and not an eval tool. It does one thing those tools do not: it signs a tamper-evident record over the full lifecycle of the work, attributing the accountable principal inside the payload. The trace tools see what happened; AGLedger produces evidence of it that holds up offline.
If you are weighing AGLedger against an observability or eval product and asking whether you still need it alongside something like LangSmith, Galileo, or Helicone, that comparison is laid out in full on the alternatives page.
Related capabilities
The underlying HTTP surface every integration calls - lifecycle, Notify, federation, and SCITT endpoints.
The durable signed webhook engine - HMAC and Ed25519 RFC 9421, CloudEvents, circuit breaker, replay.
Cross-org signed-message transport - how a remote Server's verdict surfaces as a local event.
Signing model, SSRF protection on delivery URLs, and the rotation model for integration credentials.
How agents discover the API without scaffolding and why the discovery surface itself is an integration primitive.