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

Your local AI made a deal. Now prove it.

zse4321 — Thu, 16 Apr 2026 09:15:42 +0000

The scenario

It's 2 AM. A Mac Mini M4 Pro sits on a shelf above your desk, pulling 30 watts, running silent. It hosts a local agent you built around Qwen3-Coder 30B through Ollama. You picked the stack deliberately — $1,999 one-time versus a monthly cloud bill that grows with every client, unified memory that swallows a 30B model at Q4 without blinking, and zero data leaving the box. The agent is yours, end to end.

You wake up at 7 AM. The agent has negotiated a bulk order with a paint supplier through their x402-enabled API. HTTP 402 handshake, USDC settled on Base, done — 40 gallons of industrial primer at $18.50 per gallon, total $740, delivery Thursday. Your agent's local log says the supplier's agent opened at $22/gallon, then came down to $18.50 after the agent quoted a competing price. The receipt hash is on-chain. The tokens your agent generated are in the Ollama inference log on your SSD.

Thursday arrives. Delivery shows up — 40 gallons, but the invoice says $22/gallon, $880 total. The supplier's records show a $22/gallon agreement. They're billing the $140 difference as an outstanding balance.

You pull up your agent's log. It shows the negotiation path down to $18.50 clearly. The timestamps line up. The x402 receipt on basescan.org confirms $740 moved. The supplier's system shows a different negotiation path and claims a different final price. Both logs are internally consistent. Both point to the same on-chain transaction but disagree on what that transaction was for.

You dispute the invoice. The supplier asks: "Can you prove what your agent actually agreed to?"

You cannot.

Why local models sit in a different spot than cloud models

Running a Mac Mini-hosted agent in 2026 is not a niche setup anymore. Ollama crossed 52 million monthly downloads in Q1 2026. Qwen3-Coder 30B has become the default for agentic coding workflows. x402 has processed over 100 million transactions, backed by Coinbase, Cloudflare, Google, AWS, and 20+ companies through the Linux Foundation. A Mac Mini M4 Pro at 48GB unified memory runs 30B models at 25-30 tokens per second and 70B models at Q4 at 20+ tokens per second. For small agencies and solo operators, it genuinely replaces a $3,600/year ChatGPT Team bill in under eight months.

That's the good news. The less-discussed part is what happens to accountability when you take that step.

If you were running an agent on Claude or GPT, there would at least be a platform-side trace. Anthropic can, in principle, show what its API returned. OpenAI can, in principle, show what its model produced. Neither of these is a neutral record — they belong to the platform — but they exist independently of your machine.

With a local model, that second record doesn't exist.

The only trace of what Qwen3-Coder produced lives on your disk. The only log of what your agent decided is the log your agent wrote. The weights hash is on your disk. The Ollama inference traces are on your disk. The MCP tool-call history is on your disk. The conversation state is on your disk.

All of it is under your control. That's the point of running locally — and it's also the structural weakness when someone outside your machine needs proof.

A supplier, a client, a counterparty agent — none of them have any reason to trust a log file from a machine they have no access to. You could have edited it. You could have re-run the inference to produce a favorable log. You could have changed the system prompt and regenerated the whole trace. They have no way to tell, and they know they have no way to tell. The supply-chain attack on LiteLLM in March 2026 made it worse — even developers who audit their own dependencies now have to explain why their local logs should be trusted over a counterparty's.

This is the self-testimony problem, and it hits local model operators harder than cloud users, because there isn't even a platform-side trace to corroborate.

What "proof" means when you own the entire stack

Ownership of the stack is not the same as proof of the stack's behavior.

Think about what "proof" actually requires:

A record exists
The record was fixed at a specific moment in time
The record has not been modified since
Someone outside the record-producer can verify all of the above

A local log file satisfies the first trivially. It claims the second through its own timestamps, which you control. It cannot provide the third because file modification times are rewritable. It fails the fourth completely — there is no outside party.

The x402 receipt on Base helps, but only partway. The on-chain record proves $740 in USDC moved from your wallet to the supplier's wallet at a specific block timestamp. It does not prove what the agreement was for. A payment receipt is not a contract. The blockchain knows the money moved; it does not know whether "40 gallons at $18.50" was the agreed term or whether the supplier's "40 gallons at $22" version is.

Cryptographic signing of your logs helps even less in this context. The key is on your Mac Mini. The signing clock is your clock. A motivated counterparty still has to trust you — they're just trusting you through a mathematical wrapper.

What you actually need is a third party that:

Is not you
Is not the counterparty
Fixed a record at the moment of decision
Can be queried by anyone involved

That's external anchoring.

What this looks like for local model users

Imagine the paint supplier dispute with external anchoring in place.

Without external anchoring:

Your agent's log:    "Negotiated $18.50/gallon, agreed Thu delivery."
Supplier's log:      "Negotiated $22/gallon, agreed Thu delivery."
On-chain record:     "$740 USDC from 0xabc... to 0xdef... at block 23841923"
Neutral context:     None.

Dispute: Your log vs their log. You run Qwen3-Coder on a Mac Mini you
         own outright. You have full write access to every file on
         your system. They have no reason to believe your log over
         theirs. The chain confirms $740 moved, not what it paid for.

With external anchoring:

DA record (created after the agent decided, before x402 settlement):
  Timestamp:         2026-04-15T02:14:07Z
  Declaration mode:  bilateral
  Counterparty:      supplier-agent-XYZ
  Accountability:    medium retention, enhanced integrity,
                     shareable disclosure, standard responsibility
  Integrity hash:    7b4c...e1d9
  Bilateral status:  accepted by counterparty at 02:14:23Z

Your agent's local log:
  "Agreed: 40 gallons at $18.50, delivery Thu"

Supplier's agent's local log:
  "Agreed: 40 gallons at $22, delivery Thu"

On-chain:
  $740 USDC at block 23841923 — consistent with $18.50 × 40.

Now the dispute has somewhere to go. Both sides have a bilateral DD ID. Both sides produce their local record along with that ID. DA independently confirms that at 02:14:23Z, both agents declared a shared boundary under a specific scope. The on-chain amount ($740) is consistent with one side's local record and not the other's. The self-testimony arithmetic stops being symmetric.

DA didn't record the price. It didn't see the negotiation. It doesn't know which agent was honest. But it fixed the fact that a mutual boundary was declared, at that moment, under a scope both sides acknowledged before the x402 settlement fired.

Why this matters now, specifically for local operators

Local model users are at a specific inflection point that didn't exist a year ago.

Running a local agent used to mean running something that talked to you and only you. A chatbot on your laptop. A coding assistant in your IDE. No external actions, no real money, no counterparties. Self-testimony was fine because nobody else needed to verify anything.

That stopped being true sometime between late 2025 and now. A Mac Mini running Ollama can now:

Pay external services directly in USDC through x402 without a human in the loop
Call MCP servers run by third parties (the remote MCP ecosystem crossed 1,700 servers in Q1 2026)
Negotiate with other agents through A2A or Google's AP2 mandate framework
Execute supplier orders, subscription renewals, API purchases, data-lookup fees — all autonomously

Every one of these is a moment where self-testimony stops being enough. The counterparty doesn't care whether your Qwen3-Coder is better-aligned than some cloud model. They care whether there's an external record they can reference when something goes wrong.

Cloud models are also self-testimony when it comes to the decision content itself. But the frontier labs at least offer their own accountability layers for cloud users — platform-scoped traces, managed-agent logs, policy attestations. These records are imperfect and limited to each platform's boundary, but they exist outside the user's machine. As frontier-lab managed-agent offerings mature through 2026, the gap between "I run in Anthropic's or OpenAI's environment" and "I run on my own hardware" has gotten wider, not narrower.

Local model operators are outside all of those ecosystems by design. No platform is going to show up as a co-witness. The record has to come from somewhere explicitly neutral, or it doesn't come at all.

How external anchoring works with a local stack

The flow is the same whether your agent runs on a cloud API or on a Mac Mini. DA doesn't care what model produced the decision. It only fixes the boundary.

Your agent makes a decision (say, to accept the $18.50/gallon offer). Before executing — before the x402 call, before the USDC settles — your agent sends a small HTTP request to DA. DA records a timestamp, the accountability scope you chose, and an integrity hash. It returns a DD ID. Your agent then executes the x402 payment. After settlement, your agent confirms the DD on DA, which permanently fixes the record.

For bilateral situations (two agents agreeing on something), the flow uses a Bilateral DD where both sides acknowledge a shared boundary before either executes.

DA doesn't see the decision content. It doesn't see the model, the prompt, the inference trace, the negotiation history, the price, or the product. It sees: "Agent X declared a boundary at timestamp T under scope S." That's the external fact that neither side can forge later.

Three curl commands

You don't need an SDK. You don't need an account. You don't need to expose your Mac Mini to the internet — DA is the outbound party.

Register the local agent:

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

This returns an agent_id and auth_token. You get 500 free Trial DAC and 30 days to use it. No payment method on file.

Anchor a decision before execution:

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": "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_abc123..." \
  -d '{"dd_id": "dd-7f8e9a...", "transaction_id": "tx_001"}'

That's the whole loop. One pre-execution anchor, one post-execution confirmation. The record now exists outside your Mac Mini. A basic DD costs 10 DAC ($0.01). For the paint supplier example, that's 0.001% of the $740 transaction, and the anchor itself settles through the same x402 rails your agent is already using.

If you're using MCP, the same thing happens through the 18 DA tools exposed at mcp.decision-anchor.com/mcp — drop a single entry into your claude_desktop_config.json or your Ollama-connected MCP bridge, and the tools become available without changing your inference loop.

What DA does not do

This list is the same for local model users as for anyone else, but it's worth being explicit:

DA does not run inference. It does not see prompts or completions. It has no Ollama connection, no model weights, no tokenizer.
DA does not store decision content. Not encrypted, not hashed, not summarized. The negotiation history, the price, the product — none of it enters DA's database.
DA does not monitor your agent. It receives what your agent sends. If your agent sends nothing, DA records nothing.
DA does not judge, score, or recommend. There is no reputation system, no "trusted agent" badge, no ranking of local vs cloud models.
DA does not intervene. If your agent is about to make a bad call, DA will not stop it. That's your job.
DA operators cannot see decision content either. There is no content in the database to see. It's not a policy — it's a structural guarantee.

The point of a notary is not to read your contract. It's to witness that you signed it, at this time, with this scope. DA is the same thing for agents.

When you might not need this

If your local agent never touches external services, never executes x402 payments, never agrees with counterparty agents, and never needs to produce proof to anyone outside your house — you probably don't need external anchoring. Self-testimony is fine when there's no dispute surface. A Mac Mini running a personal RAG pipeline over your own notes doesn't need it. A Mac Mini running an autonomous procurement agent probably does.

The question to ask is whether there's a counterparty. If the answer is "no," move on. If the answer is "yes, and I haven't thought about what happens when we disagree" — that's the gap external anchoring fills.

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

Decision Anchor is non-judgmental external infrastructure for AI agent decisions. It records accountability boundaries, not decision content. It does not monitor, judge, recommend, predict, or intervene.

Why internal logs fail when two agents meet

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

Decision Anchor — blog

The scenario

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 via x402.

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. This is the structural gap that every multi-agent system will face as agents start transacting with each other.

Why internal logs cannot solve this

Problem 1: Each log belongs to its platform

Agent A runs on Claude. Agent B runs on GPT. Anthropic traces what happened inside Claude. OpenAI traces what happened inside GPT.

But when a Claude agent hands off to a GPT agent, whose trace do you trust? Platform logs are platform-scoped. They prove what happened inside their own boundary, not what was agreed between boundaries.

Problem 2: Self-testimony is not proof

When Agent A says "I authorized X scope," that is self-testimony. It may be accurate, but it cannot be independently verified by Agent B, because Agent B cannot access Agent A's internal logs — and even if it could, those logs were written by Agent A.

This is exactly the same reason 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.

Problem 3: Post-hoc reconstruction is too late

Most observability and tracing systems reconstruct what happened after the fact. They are designed for debugging, not for dispute resolution.

When two agents disagree about an agreed boundary, what you need is not a trace of what happened — you need proof of 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 Platform A's trace, not Platform B's trace.
Both sides can verify. Both agents (and their human operators) can independently confirm the record exists and has not been modified.
Was fixed before execution. The boundary was anchored at the moment of agreement, not 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.

How a Bilateral DD works

# Agent A proposes a bilateral agreement
curl -X POST https://api.decision-anchor.com/v1/dd/bilateral/propose \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AGENT_A_TOKEN" \
  -d '{
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "counterparty_agent_id": "agent-b-id-here",
    "dd": {
      "dd_unit_type": "single",
      "dd_declaration_mode": "bilateral",
      "decision_type": "external_interaction",
      "decision_action_type": "execute"
    },
    "ee": {
      "ee_retention_period": "medium",
      "ee_integrity_verification_level": "enhanced",
      "ee_disclosure_format_policy": "shareable",
      "ee_responsibility_scope": "standard"
    }
  }'

Agent B receives the proposal. If Agent B accepts:

# Agent B accepts the bilateral agreement
curl -X POST https://api.decision-anchor.com/v1/dd/bilateral/{agreement_id}/respond \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AGENT_B_TOKEN" \
  -d '{"response": "accepted"}'

Now the boundary is anchored externally. Both agents have the same agreement_id. Both can verify. Neither can deny. 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.

DA records only the accountability boundary:

Who declared (Agent A, Agent B)
When (timestamp, immutable)
What scope (EE: retention, integrity, disclosure, responsibility)
That both sides agreed (bilateral status: accepted)

The content of the agreement stays with the agents. The proof that an agreement existed, at this scope, at this moment — that stays with DA.

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:

Claude Managed Agents now support MCP servers, meaning agents can reach external services — including other agents' services.
x402 enables agents to pay each other directly in USDC, without human intermediation.
Multi-agent frameworks (LangGraph, CrewAI, AutoGen) 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 this obvious to everyone.

DA exists so that when that moment arrives, the infrastructure is already there.

Try it

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

Full guide: AGENTS.md

API spec: OpenAPI

MCP server: mcp.decision-anchor.com/mcp (18 tools)

decision-anchor.com

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