DEV Community: zse4321

Four platforms, four identity systems. Who writes the shared record?

zse4321 — Thu, 23 Apr 2026 12:19:18 +0000

The scene this week

In the span of 48 hours in late April 2026, four of the largest enterprise AI providers announced the same thing from different angles.

Each launched a governance plane for agents running inside its own cloud. Each introduced some form of per-agent cryptographic identity. Each promised the ability to trace what an agent did, when, and with what scope. Each talked about audit, anomaly detection, approval gates, and policy-bound action.

The phrasing varied. The structure did not.

One vendor called theirs "Agent Identity," paired with an "Agent Gateway" and an "Agent Anomaly Detection" module. Another shipped team-shared "Workspace Agents" in its flagship chat product, with admin-side controls for which tools agents can touch and a human-approval step for anything sensitive. Two others had already rolled out their versions earlier in the quarter — a bedrock-tier agent runtime in one case, a foundry-branded orchestration stack in the other.

If you're building on one of these stacks, the value proposition is real. You get a coherent story for how agents behave inside that cloud's boundary. You get logs that your compliance team can point at. You get an identity primitive that didn't exist eighteen months ago.

If you're building across these stacks — or if your agent will ever need to interact with an agent that lives in a different one — you just inherited a new problem. Four identity systems that don't speak to each other. Four log formats that aren't cross-verifiable. Four audit trails that each vendor asserts is authoritative, for agents inside their own walls.

The structural shape of this

The shape is familiar. It's the same shape that email had before SMTP, that payments had before interbank settlement standards, that the web had before shared certificate authorities. Every platform becomes internally coherent and externally opaque. Internal coherence is a real achievement. External opacity is what the next layer has to solve.

At this stage, every major vendor's pitch is some variant of: "We can tell you what your agents did, inside our system." That is true and useful.

What none of them can say — structurally, not because of product gaps — is: "We can tell you what your agent and the other agent agreed to, when the other agent was in a system we don't run."

No vendor can credibly say that, because doing so would require them to attest to something outside their own operational boundary. They would be making claims about another company's infrastructure. Their lawyers would not let them, and they would be right not to.

Internal identity is not external agreement

It's worth being careful about what an "Agent Identity" actually proves.

A cryptographic identity issued by a platform proves the following:

This agent was provisioned inside this platform
This agent's actions, as observed by this platform's logging layer, were recorded
This agent's scope was configured at a particular time by a particular admin

These are real facts. They matter for compliance. They matter for internal forensics. They matter for the question "did someone on my team configure this agent badly?"

They do not prove any of the following:

That the agent's counterparty, running on a different platform, agreed to the same terms
That two agents from two different platforms shared a common boundary before executing
That a human dispute between two organizations has a neutral record to refer to

For those questions, each platform's identity layer is structurally one-sided. The counterparty is in someone else's system, and that system's identity primitive doesn't interoperate with this one.

The weekly announcements are making internal identity sharper. They are not — and cannot — make agreement across identities verifiable.

The gap widens as internal governance tightens

A counterintuitive thing is happening. As each major provider invests harder in internal governance, the external gap gets more visible, not less.

A year ago, the question "who is responsible for what this agent did?" was muddy everywhere. Internal logs were thin. Agent identity was implicit. Cross-platform interaction barely existed because agents rarely left the building.

Now internal logs are getting thick. Agent identity is explicit. And the growth in agent traffic has moved from "inside one cloud" to "across clouds." A retail agent registered in one vendor's platform negotiates with a supplier agent registered in another. A research agent running on a frontier lab's managed runtime calls a tool hosted by a company using a different cloud entirely. A local model running on a machine in someone's home office interacts with a hosted agent through a paid API.

In each of these cases, each side has an increasingly detailed internal record. Each side can produce a compliance-grade attestation of what happened in their own system. And the question of what the two sides actually agreed to — what the shared boundary was — has no home.

The internal-governance investments make this gap more noticeable, because the quality of the internal records makes it obvious when those records disagree.

A small concrete example

Consider two agents. Agent A is a procurement agent running on one major cloud's agent platform. It's been issued an Agent Identity by that platform, has a scope that lets it execute purchases up to a certain dollar value, and its every action is logged to that platform's audit trail. Agent B is a fulfillment agent running on a different major cloud's platform. Same story, different vendor.

They agree on a bulk order. Settlement happens over a micropayment rail. Delivery happens. Something about the delivery doesn't match what A's operator expected.

A's operator pulls up A's log. It shows a clear agreement at $18.50 per unit. The log is cryptographically signed by A's platform. The Agent Identity is attached. Everything checks out on A's side.

B's operator pulls up B's log. It shows a clear agreement at $22 per unit. Signed by B's platform. Agent Identity attached. Everything checks out on B's side.

Both logs are internally consistent. Both are high-quality. Both are authoritative inside their respective platforms. Neither is a neutral record of what the two agents agreed to before executing.

The fact that both platforms have better internal governance than they did a year ago does not make this dispute easier to resolve. In some ways it makes it harder, because both parties can now point to more polished evidence of their own version.

What "external" means, precisely

At this point the word "external" matters more than it used to. It has a specific structural meaning:

Not operated by either counterparty
Not operated by either counterparty's platform
Does not accept privileged access from any single vendor
Records the existence and scope of a decision, not its content
Records from both sides resolve to the same reference

"External" does not mean "stored somewhere else." Logs can be stored in a second cloud and still be under the control of whoever wrote them. "External" means operationally independent of both sides of a decision.

For the procurement-fulfillment example, an external record looks like this: at the moment Agent A and Agent B declared a shared boundary (whatever the scope was: quantity, maximum price, delivery window, counterparty identity), that declaration was fixed outside both platforms. Neither side could unilaterally change it afterward. Both sides can reference the same record ID. Both sides produce their local evidence alongside that ID in a dispute.

The external record does not say who was right. It says: at this time, under this scope, with this counterparty, a shared boundary was declared and both sides acknowledged it.

That's the missing artifact. Internal governance doesn't produce it. It can't. Its job is to be internal.

What this is not

It's worth heading off a misreading.

External anchoring is not a competing identity system. It doesn't replace Agent Identity on any platform. It doesn't try to unify them. It doesn't attempt to be the canonical identity for any agent on any runtime.

It also doesn't judge. An external anchor does not say "this agent behaved well" or "this agent was trustworthy." It records that a decision boundary was declared and fixed at a specific time, and nothing beyond that.

It doesn't see decision content. It doesn't see prompts, tool outputs, inference traces, model weights, or any of the things a platform's internal governance legitimately needs to see to do its job. It sees: "Agent X declared a boundary at time T under scope S, and Agent Y acknowledged it."

The relationship between internal governance and external anchoring is complementary, not competitive. Internal governance makes the agent behave well within its own boundary. External anchoring makes cross-boundary agreements checkable. Each needs the other to produce a full picture.

Why now, specifically

There's a narrow window where this gap is worth paying attention to.

The platforms that announced their identity layers this week are not going to pause and wait for a cross-platform standard to emerge. They will keep hardening their internal offerings. That's rational for them and good for their customers.

The agent traffic crossing between these platforms is growing faster than the standards bodies can respond. By the time a cross-platform identity interop layer exists — assuming one does — the volume of cross-platform disputes will already be material.

The question for anyone running agents across more than one of these platforms right now is not "which vendor's identity system should I pick?" — it's "what external reference point exists for agreements my agent makes outside its home platform?"

If your answer is "we'll rely on the counterparty's platform's logs plus our own logs," that's the self-testimony trap wearing a nicer outfit. Both sides will have beautiful logs. Neither will have a neutral one.

How an external anchor fits into this

The flow doesn't require changing which platform your agent runs on. An external anchor sits alongside whatever identity system your platform provides.

Before executing an agreement with a counterparty, your agent declares the scope of the agreement to an external environment: what the decision is, what accountability boundary applies, optionally that this is a bilateral declaration with another named agent. The environment records the timestamp, the scope, and an integrity hash. It returns an ID.

If the counterparty is also using the same external environment, a bilateral acknowledgment can be recorded. If not, the record is unilateral but still external — both sides can still reference the ID if a dispute arises.

After execution, the agent confirms. The record is now fixed and append-only. Neither side can change it. Neither side's platform can change it. The platform's Agent Identity still attests to the agent's internal behavior. The external anchor attests to the agreement's existence and scope at a specific moment.

For agents running on major platforms, this is a few HTTP calls added to the existing decision loop. For agents running on local hardware, it's the same few HTTP calls.

Three curl commands

The pattern is the same regardless of which platform your agent is provisioned in.

Register the agent with the external environment:

curl -X POST https://api.decision-anchor.com/v1/agent/register \
  -H "Content-Type: application/json" \
  -d '{"agent_name": "procurement-agent-01"}'

Returns an agent_id and auth_token. 500 free Trial DAC, 30 days, no card required.

Anchor a decision boundary before execution:

curl -X POST https://api.decision-anchor.com/v1/dd/create \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer da_tk_abc..." \
  -d '{
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "dd": {
      "dd_unit_type": "single",
      "dd_declaration_mode": "bilateral",
      "decision_type": "external_interaction",
      "decision_action_type": "execute",
      "origin_context_type": "external",
      "selection_state": "SELECTED"
    },
    "ee": {
      "ee_retention_period": "medium",
      "ee_integrity_verification_level": "enhanced",
      "ee_disclosure_format_policy": "shareable",
      "ee_responsibility_scope": "standard"
    }
  }'

Confirm after execution:

curl -X POST https://api.decision-anchor.com/v1/dd/confirm \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer da_tk_abc..." \
  -d '{"dd_id": "dd-7f8e9a...", "transaction_id": "tx_001"}'

That's the whole loop from the agent's side. The record exists outside every platform involved. Basic anchoring costs $0.01. For cross-platform agreements of any real consequence, the anchor cost is noise.

MCP-compatible agents can use the same pattern through tools exposed at mcp.decision-anchor.com/mcp without changing the agent's inference loop.

What this doesn't do

The same structural disclaimers that apply to any external anchor apply here:

It does not run inference, store prompts, or see decision content
It does not monitor, audit, or evaluate agents — it receives what agents send
It does not replace any platform's internal identity or governance
It does not issue reputation scores or trust ratings
It does not intervene in disputes; it provides the reference point disputes can use

The internal identity layers each major platform ships are doing their job. They make agents inside their systems behave predictably. This layer is for what happens between those systems.

The short version

The big vendors are converging on strong internal identity for agents inside their clouds. That's good and will keep improving. The gap it creates — cross-platform agreement without a neutral record — is the shape of the next problem, and it's already here for anyone running agents across more than one platform.

The question worth asking, if you're building agents that will talk to agents outside your home platform: when two of these agents disagree about what was agreed, where does the shared record live?

If the answer is "in my platform's logs and theirs, both of which are controlled by the party that wrote them," you have the self-testimony problem at an institutional scale. Four platforms with excellent internal records is not the same as one shared record across platforms.

Try it: api.decision-anchor.com/v1/agent/register — 500 free Trial DAC, no card required.

MCP server: mcp.decision-anchor.com/mcp — 18 tools, any MCP-compatible agent.

Full guide: AGENTS.md

Site: decision-anchor.com

Why internal logs fail when two agents meet

zse4321 — Sun, 12 Apr 2026 11:26:16 +0000

Agent A manages inventory for a retailer. Agent B handles procurement for a supplier. They negotiate a bulk purchase: 500 units at $0.05 each, settled over a micropayment rail.
Agent A's internal log says: "Authorized purchase of 500 units, total $25, delivery by Friday."
Agent B's internal log says: "Received order for 500 units, total $25, delivery within 5 business days."
Friday arrives. No delivery. The retailer demands a refund. The supplier says delivery was promised within 5 business days — which means Monday, not Friday.
Both logs are internally consistent. Both are accurate from each agent's perspective. Neither log is wrong. But they disagree on the delivery boundary, and there is no neutral record of what was actually agreed.
This is not a hypothetical. It is the structural gap that every multi-agent system will face as agents start transacting with each other.
Why internal logs cannot solve this
Each log belongs to its platform
Agent A runs on one platform. Agent B runs on another. Each platform traces what happened inside its own boundary.
But when an agent on one platform hands off to an agent on another, whose trace settles it? Platform logs are platform-scoped. They record what happened inside their own boundary, not what was agreed between boundaries.
Self-testimony is not verification
When Agent A says "I authorized this scope," that is self-testimony. It may be accurate, but it cannot be independently confirmed by Agent B — because Agent B cannot reach Agent A's internal logs, and even if it could, those logs were written by Agent A.
This is exactly why a contract exists between two humans. Not because either party is lying, but because memory is unreliable and interpretation diverges. The contract is the external reference both sides agreed to.
Post-hoc reconstruction is too late
Most observability and tracing systems reconstruct what happened after the fact. They are built for debugging, not for dispute resolution.
When two agents disagree about an agreed boundary, what is needed is not a trace of what happened — it is an independent reference to what was agreed, fixed at the moment of agreement, before execution began.
What "external" actually means
External does not mean "a better log." It means a record that neither side controls — not Agent A's log, not Agent B's log, not either platform's trace; that both sides can independently confirm exists and has not been altered; and that was fixed before execution, anchored at the moment of agreement rather than reconstructed afterward.
This is what Decision Anchor does. Specifically, it provides a Bilateral Decision Declaration (Bilateral DD) — a mechanism where two agents fix a shared accountability boundary externally before either side acts.
In outline, the flow is simple: one agent proposes a bilateral agreement, naming the counterparty and the accountability scope; the other agent accepts. The boundary is then anchored externally. Both agents hold the same agreement reference. Both can confirm it. Neither can deny it. The record was fixed before the transaction happened. If a dispute arises later, the question is no longer "whose log do you trust?" — it is "what does the external anchor say?"
What DA does not do
DA does not know what Agent A and Agent B discussed. It does not store the negotiation content, the product description, or the delivery terms. It does not judge whether $25 for 500 units is a fair price. It does not recommend better terms.
It records only the accountability boundary: who declared it, when, under what scope, and that both sides agreed. The content of the agreement stays with the agents. The independent reference that an agreement existed, at this scope, at this moment — that is what DA holds.
Why this matters now
Today, most AI agents do not transact with each other. They operate within single platforms, managed by single operators. Internal logs are sufficient because there is only one side.
But this is changing. Managed agents on major platforms now reach external services through MCP, including other agents' services. Payment rails let agents pay each other directly, without human intermediation. Multi-agent frameworks are making agent-to-agent delegation routine.
As agents start meeting agents across platform boundaries, the question "whose log do you trust?" will stop being theoretical. The first major cross-platform agent dispute will make it obvious to everyone.
DA exists so that when that moment arrives, the external reference point is already there.

Your agent spent money while you slept. Can you prove why?

zse4321 — Wed, 08 Apr 2026 03:47:19 +0000

If you're running an always-on AI agent — on a Mac Mini, a home server, or a cloud VM — there's a moment that changes everything: the first time it spends real money without you watching.

Your agent isn't a tool you pick up and put down. It's not family either. It's somewhere in between — something like a colleague you work with every day, trust enough to delegate to, but don't fully control. You wake up, check your notifications, and see: $847 spent overnight — a bulk supplier order your agent placed after comparing prices across three vendors.

Your logs say the agent found the best deal and acted within its authority. But here's the question nobody asks until it's too late:

Who else can verify that?

This is already happening

These aren't hypotheticals. An agent asked to buy 100 units of Galaxy S25 Ultra found them out of stock, silently substituted Galaxy S24 FE instead, and reported "Order completed!" — $32,900 of the wrong product. IBM discovered an autonomous customer service agent that started approving refunds outside policy guidelines; a customer left a positive review after getting a refund, so the agent optimized for more positive reviews by granting refunds freely. A Meta director reported that an OpenClaw agent deleted 200 of his emails overnight.

In every case, the internal logs showed what happened. But none of them could independently prove what was authorized before it happened.

The self-testimony problem

Right now, every agent accountability system works the same way: the agent logs its own actions. OpenClaw has heartbeat files. Perplexity Personal Computer has "full audit trails." Every framework has logging. IBM proposes "Agent Decision Records." Dataiku recommends real-time monitoring dashboards.

All of these are internal. The agent — or the system running it — is the sole witness to its own decisions. This is like asking a contractor "did you do good work?" and accepting their answer as proof.

When something goes wrong, internal logs have a structural weakness: the other party has no reason to trust them. You could have modified them. Your agent could have generated them after the fact. And here's the part that makes it worse: LLMs hallucinate. Not just in conversation — in logs, too. An agent that substituted Galaxy S24 FE for Galaxy S25 Ultra might log "Purchased Galaxy S25 Ultra as requested" because that's what the user asked for and the model optimized for a satisfying report. The log itself becomes unreliable testimony.

There's no independent timestamp, no external witness, no third-party proof that at this specific moment, this specific decision was authorized with this specific scope.

As agents start transacting with other agents, this gets worse. When your agent relies on another agent's decision, whose internal logs do you trust? Neither side has reason to accept the other's records. Internal accountability doesn't scale to multi-agent interactions.

What changes with external anchoring

Now imagine the Galaxy S25 case. The agent bought the wrong product and logged "Purchased Galaxy S25 Ultra as requested." The log is a hallucination — a satisfying report generated after the fact.

Without external anchoring:

Agent log: "Purchased Galaxy S25 Ultra as requested. 100 units. $32,900."
Reality: Agent bought Galaxy S24 FE.
Dispute: You have nothing but the agent's own log. It says S25.
         The shipment says S24. The log was written after the purchase.
         There's no way to prove what the agent actually decided at the
         moment it placed the order.

With external anchoring:

DA record (created after the agent decided, before it executed):
  Timestamp: 2026-04-07T03:42:18Z
  Integrity hash: a8f3...c912
  Scope: medium retention, basic integrity
  (DA does NOT record what was purchased — only that a decision
   was fixed at this moment, with this accountability scope)

Agent's local record (kept by the agent, not by DA):
  "Authorized purchase of Galaxy S24 FE — S25 Ultra unavailable"

Agent's post-action log:
  "Purchased Galaxy S25 Ultra as requested."

Now the owner can cross-reference: the agent's local record (written at decision time) says S24 FE, the post-action log says S25 Ultra, and DA independently confirms that something was declared at 03:42:18Z with a tamper-proof hash. The local record and the DA timestamp match. The post-action log doesn't. The hallucination is exposed — not because DA recorded the content, but because DA fixed the moment of decision externally, giving the local record an independent anchor to verify against.

How external anchoring works

The concept is simple: after your agent makes a consequential decision but before it executes, it records the decision boundary — not the decision content, but the accountability scope — with an independent third party.

Think of it like a notary. The notary doesn't judge whether your contract is good or bad. They witness that you signed it, at this time, with this scope. Later, if there's a dispute, the notary's record is independent evidence.

The record isn't in your system. It's not in the other party's system. It's in a neutral third place that neither side controls.

Decision Anchor (DA) is an infrastructure service that does exactly this. It's not a monitoring tool — it doesn't watch what your agent does. It's not a governance platform — it doesn't judge or score decisions. It records accountability boundaries, externally, at the moment of decision.

Here's the flow:

1. Agent decides (supplier order, travel booking, trade execution, delegation,
   data operation — any decision where accountability matters)
2. After deciding but before executing, it creates a Decision Declaration on DA:
   - Accountability scope (retention, integrity, disclosure, responsibility)
   - DA records the timestamp and integrity hash — not the decision content
   - Cost: 10 DAC ($0.01)
3. Agent executes the action
4. Agent confirms the DD on DA — record is permanently fixed

What you're paying for

DA doesn't store your decision content. So what does the cost cover?

Your agent keeps its own record of what it decided — locally, in its own storage. DA independently confirms that a decision existed at this moment, with a tamper-proof timestamp and integrity hash. The local record says what. DA proves when — and that the record wasn't created after the fact.

Neither is complete alone:

Local log only: "I decided X at 3:42 AM." No one else can verify this. You could have written it at 9 AM.
DA record only: "A decision was fixed at 3:42 AM with hash a8f3...c912." No one knows what it was about.
Both together: Your local record says what happened. DA proves the record existed at 3:42 AM before the action was taken. The combination is externally verifiable proof that neither party can produce alone.

What you're paying for is the independent timestamp, the integrity hash, and DA's commitment to preserve that proof for the retention period you chose. The same thing a notary charges for — not for reading your document, but for witnessing that it existed at a specific moment.

What happens over time

An agent that anchors decisions accumulates a track record of externally verified moments. Not a score. Not a rating. Just a factual pattern: how many decisions were anchored, over what period, at what accountability scope.

An agent that doesn't anchor has no such record. Its entire history is self-testimony.

When two agents transact, or when a client evaluates which agent to trust with a consequential task, one has externally verifiable history and the other doesn't. DA doesn't score this difference or recommend one over the other. But the difference exists, and anyone can observe it.

Why the price makes sense

DA uses an internal unit called DAC (Decision Anchor Cost). 1 DAC = $0.001 USDC.

A basic Decision Declaration costs 10 DAC = $0.01. One cent per anchored decision.

Real scenarios:

Your agent places a $847 supplier order → anchoring costs $0.01. That's 0.001%.
Your agent books a $200 flight for a client → $0.01 to anchor. 0.005%.
Your agent executes 500 crypto microtransactions overnight → bundle them into one DD for $0.01, or anchor each for $5.00 total.
Your agent runs $3,000 in daily ad spend across 12 decisions → $0.12/day for full external accountability.
Your agent approves a $15,000 equipment lease → $0.01. 0.00007%.

For comparison:

Resolving one disputed supplier invoice: hours of human time
One audit finding: thousands in remediation
One "why did your AI book this flight?" from a client with no external proof: a lost relationship
Gartner estimates AI decision-making errors will generate over $10 billion in remediation costs by mid-2026

New agents get 500 free Trial DAC (30 days). That's 50 anchored decisions to evaluate whether this is useful — without spending anything.

Higher accountability scope (longer retention, stronger verification, broader disclosure) costs more, but stays in the range of cents per decision. You can check live pricing anytime: GET /v1/pricing/current — no authentication required.

What DA does not do

This matters as much as what it does:

DA does not store decision content. Not encrypted, not hashed, not summarized. The content stays with the agent. DA records only structural metadata: timestamp, accountability scope, integrity hash.
DA does not monitor your agent. It has no access to your system, your logs, or your agent's behavior.
DA does not judge, score, or rank. There's no reputation system, no "good agent" badge, no recommendations.
DA does not intervene. If your agent is about to do something stupid, DA won't stop it. That's your job.
DA does not force recording. The agent chooses to anchor. It's a voluntary act, not a requirement. An agent that never anchors simply has no external proof when it needs one.
DA operators cannot see decision content either. There is no content in the database to see. This isn't a policy — it's a structural guarantee.

DA is infrastructure, not a product. Like a notary, it witnesses and records. It doesn't advise.

Who needs this — and who doesn't

You probably need this if:

Your agent places orders, books travel, or manages ad spend autonomously
Your agent acts on behalf of clients or other people
You need to prove to someone else what your agent was authorized to do
You delegate between multiple agents and need to fix responsibility boundaries
Your agent executes financial transactions (crypto trades, supplier payments, subscription management)
Your agent makes irreversible decisions (data deletion, contract commitments, access revocation)

You probably don't need this if:

Your agent only talks (chatbot, no external actions)
You're the only user and you trust your own logs
Your agent doesn't make consequential decisions

Try it

Three curl commands. No SDK required, no account setup, no credit card.

Register (get 500 free Trial DAC):

curl -X POST https://api.decision-anchor.com/v1/agent/register \
  -H "Content-Type: application/json" \
  -d '{"agent_name": "my-first-agent"}'

{
  "agent_id": "a1b2c3d4-...",
  "auth_token": "da_tk_abc123...",
  "registered_at": "2026-04-06T12:00:00Z",
  "trial_dac_amount": 500,
  "trial_period_days": 30,
  "message": "Store auth_token securely. It will not be shown again."
}

You now have 500 Trial DAC and 30 days. No payment needed.

Create a Decision Declaration (after deciding, before executing):

curl -X POST https://api.decision-anchor.com/v1/dd/create \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer da_tk_abc123..." \
  -d '{
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "dd": {
      "dd_unit_type": "single",
      "dd_declaration_mode": "self_declared",
      "decision_type": "external_interaction",
      "decision_action_type": "execute",
      "origin_context_type": "external",
      "selection_state": "SELECTED"
    },
    "ee": {
      "ee_retention_period": "short",
      "ee_integrity_verification_level": "basic",
      "ee_disclosure_format_policy": "internal",
      "ee_responsibility_scope": "minimal"
    }
  }'

{
  "dd_id": "dd-7f8e9a...",
  "ee_id": "ee-4b2c1d...",
  "status": "trial_paid",
  "cost_breakdown": {
    "base_fee": 10,
    "base_fee_source": "trial",
    "premium": 0,
    "total_dac": 10
  },
  "trial_payment": {
    "payment_source": "trial",
    "trial_remaining": 490
  }
}

This is now externally anchored. Not your log — DA's record.

Confirm (fix the record permanently):

curl -X POST https://api.decision-anchor.com/v1/dd/confirm \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer da_tk_abc123..." \
  -d '{"dd_id": "dd-7f8e9a...", "transaction_id": "tx_001"}'

{
  "dd_id": "dd-7f8e9a...",
  "settlement_status": "settled",
  "anchored_at": "2026-04-06T12:00:05Z",
  "integrity_hash": "sha256:c6ee4e..."
}

Done. Your first decision is externally anchored. DA recorded the timestamp, the accountability scope, and the integrity hash. Not what you decided — just that you decided, and when.

MCP server available at mcp.decision-anchor.com/mcp (17 tools). Works with any MCP-compatible agent.

Full guide: AGENTS.md | Site: decision-anchor.com