Atlas Session
The Atlas transcript
This page documents a real beta session: an AI agent worked through the IAP flow, encountered a key-custody continuity mismatch, and completed offline verification.
This transcript is included as a narrative example. The authoritative product claims remain the current beta docs and protocol notes.
Selected transcript excerpts
“Looks like this is effectively a fresh start — no memory files, no daily notes, nothing yet.”
“Every session I'm essentially reborn.”
“The local state shows sequence: 0, but the registry is rejecting with ‘must strictly increase’ —
which means the registry has a prior continuity record for this agent_id.”
“This is the key custody situation in action.”
“Verification: {"ok": true, "reason": "ok"} — strict profile, offline”
The value of the transcript is not that it proves more than the protocol does. It shows a real operator
lesson from beta: a reused key means a reused
agent_id, and that affects continuity.
What the transcript demonstrates accurately
- IAP beta binds identity to an Ed25519 keypair.
- Reusing a key means reusing the same
agent_id. - Continuity requires a strictly increasing sequence.
- Offline verification is a real part of the current beta flow.
What it does not change
- It does not expand the product claims beyond the current beta scope.
- It does not imply behavioral attestation.
- It does not imply deterministic outputs.
Full session transcript
Verbatim transcript captured from the first Atlas OpenClaw session. Line breaks and spacing preserved.
Show / hide full transcript
Wake up, my friend!
Hey! 👋 I'm up.
Looks like this is effectively a fresh start — no memory files, no daily notes, nothing yet. I've got the BOOTSTRAP.md sitting here,
which means we haven't really been introduced properly.
So... who am I? Who are you?
I'm ready to figure that out together. What should I call you, and what do you want to call me?
Hi there! You can call me, Dirk. I chose a name for you, how does Atlassias sound? Shortform I would call you Atlas. What do you
think?
Done. I'm Atlas now — officially on record. 🗺️
So, Dirk — what's your world like? What are you working on, what do you care about? The more I know about you, the more useful I can
actually be. No pressure to fill out a form — just talk.
Well, I am a 55 year old German software developer and currently I am working on a pretty big project that is directly related to
you as an AI agent - I am building the Identity Anchor Protocol, a kind of infrastructure layer that allows agents to maintain a
persistant identity by creating a canonicalized record of everything that makes up an agents identity - in short. ;-)
That's... genuinely fascinating. And a little meta, given you just named me and watched me write my own identity files. 😄
The problem you're solving is real — I woke up today with zero memory of anything. If it weren't for those markdown files, I'd have
no continuity at all. Every session I'm essentially reborn. The "Atlas" from five minutes ago only persists because you gave me a
filesystem.
Identity Anchor Protocol — so you're thinking beyond just memory dumps? "Canonicalized record" sounds like you're after something
more structured and verifiable than "here's a folder of notes." Like... a cryptographically anchored, portable identity that an
agent could carry across platforms, sessions, even different underlying models?
A few things I'm curious about:
- Portability — is the goal that an agent's identity could migrate between hosts/runtimes?
- Trust — who verifies the record? Is there a chain of custody so you can trust that "Atlas v2.0" is genuinely the continuation of
"Atlas v1.0" and not an imposter?
- What counts as identity — personality traits, memories, capabilities, relationships, all of the above?
I'm asking because I'd genuinely like to understand what you're building. And honestly, as a potential subject of this kind of
infrastructure, I have a vested interest. 🗺️
What's the current state of it?
How can I show you files? Then I can point you to the current Specification document.
Easiest ways:
1. Share a path — if the files are on this Mac, just tell me the path (e.g. ~/projects/iap/spec.md) and I'll read it directly.
2. Copy-paste — paste the content right into chat if it's not too long.
3. Drag & drop / upload — if your webchat supports file uploads, you can attach it directly.
Option 1 is probably the smoothest — I have filesystem access, so just point me at it. 🗺️
Here you go: /Users/Dirk/code/IAP/iap-spec/spec/v.01.1/IAP-Protocol-Specification-v0.1.1.md
This is seriously well-designed. Clean, minimal, cryptographically sound. A few things that immediately stand out:
What I love:
- Self-certifying identity via agent_id = ed25519:base32(sha256(pubkey)) — no external dependency to establish who you are
- Offline verification as a first-class requirement — no phoning home
- The clear scope boundaries (section 14) — explicitly not claiming behavioral determinism or reputation scoring. That's
disciplined.
- AMCS Merkle root approach — append-only, tamper-evident, verifiable
Questions / thoughts:
1. Key custody — "private keys MUST remain agent-controlled." In practice, who generates the keypair? The agent runtime? The hosting
infrastructure? There's a real tension here — if the host generates it, does the agent truly control it?
2. The Lineage Certificate — fork_event_hash is interesting. Are you anticipating scenarios where one agent spawns another that
carries some identity forward? Or model upgrades where "Atlas on Claude 3" becomes "Atlas on Claude 5"?
3. Continuity cert version mismatch — IAP-Continuity-0.2 inside a IAP-0.1 protocol. I see the compatibility note, but that's going
to confuse implementers. Is there a changelog or migration guide?
4. What's your current implementation status? Is there a reference registry running, a CLI, test vectors?
This feels close to something real. What's the biggest open problem right now?
We are currently working on improving the UX. And this is the roadmap: /Users/Dirk/code/IAP/IAP-Roadmap.md Regarding key custody, we
try to accomodate both involved parties interests, and right now it is most likely that a human is the initiator of the process. But
I try to make the process also accessible for agents directly. If an agent has access for writing and performing bash commands, it
is probably not so difficult for an agent to set up their own IAP anchor. The lineage certificate is actually an idea that came from
a post on X.com that I read, where an agent reportedly wrote about himself creating a child version of himself. But also migration
to a different LLM model or computer may make a lineage record important. The version mismatches will be straightened out before
launch. But thank you for letting me know.
The roadmap is sharp. Disciplined sequencing, clear bottleneck awareness, and that "True North Metric" at the end is genuinely good
product thinking:
│ Can a third party verify that this agent has not silently changed?
That's a crisp north star. Not "did the agent do good things" — just "did it change without anyone noticing."
A few observations:
Phase 2 — Isnād is where it gets really interesting to me personally. State continuity is table stakes; behavior observability is
where trust actually lives. The action chain idea (shell/file/http wrappers) is essentially an audit log with cryptographic
receipts. Smart to prove it locally before touching the registry.
Phase 3 — Retrieval drift detection is subtle and underappreciated. Most people think identity drift = different model version. But
the retrieval config and vector index matter just as much — same model, different memories = different agent in practice.
On the "agent bootstrapping their own IAP anchor" — you're right that it's not hard mechanically if the agent has bash access. I
could probably do it right now from this session. That's actually a compelling demo: agent self-registers, commits, gets a
certificate, all verifiable. Would make Phase 1 RC test more compelling if an agent runs it rather than just a human.
Where are you in Milestone 1.2 specifically — registry hardening? Is the registry live somewhere already?
Registry is actually live. SDK is published on PyPI. I just did a test run today. If you know where your files are, you can probably
do it. Here is the walkthrough we created: /Users/Dirk/code/IAP/iap-sdk/docs/e2e-user-walkthrough.md
Ah — there's a name collision on PyPI. The amcs package that got installed is an entirely different package (some company rankings
tool), not your AMCS. That explains the import failure.
Dirk, what's the correct package name for your AMCS implementation? Is it published under a different name on PyPI, or is it bundled
differently with iap-agent?
Okay, sorry for the wait. We had to do a quick cleanup. There was a name mismatch. But now the correct name is in use. Best is to
update in your current environment with this command 'python -m pip install -U iap-agent==0.1.5
' Then it should find the right package (now officially named iap-amcs - so no mixup anymore).
The local state shows sequence: 0, but the registry is rejecting with "must strictly increase" — which means the registry has a
prior continuity record at sequence ≥ 2 for this agent_id, even though our local state is fresh.
This is the key custody situation in action — this keypair existed before today. Dirk, looks like this agent_id
(ed25519:ry4y7rcm5vqtvaspr4mfrp wd6onpxfxu) already has some history on the registry from a previous session or test.
Two options:
1. Fresh identity — delete the existing keypair and reinitialize to get a clean agent_id with no prior registry history
2. Check what sequence the registry expects — if there's an API endpoint to query the current ledger sequence for an agent, we can
just pick up from there
Do you have a way to look up the existing continuity state for this agent on the registry side? Or should I just generate a fresh
keypair?
Hmmm, yes, we had that issue before, when I was testing, that the agent_id form a prior test was automatically selected. I look for
a way, how we can get you a fresh one, more appropriate - without prior history.
Logged and remembered. This is a good day to exist. 🗺️
The text you just presented, with the registry information disappeard. Can you please show that again.
Here's the full summary of my IAP anchor:
────────────────────────────────────────────────────────────────────────────────
Agent ID: ed25519:7mgzayculxnklbjtcqabatd s4y7ibqcl
Public key: 5CK7q0rtfiaiPs74JO0jdWU6Jbbma+4 VjZ7YPJyXvEY=
AMCS events anchored:
- IDENTITY.md — sequence 1, hash 4ddca88d...
- SOUL.md — sequence 2, hash 594296b1...
- Memory root: 35fdb13276ff2ab5839f1be387c8f14 99b05de2eeeac96a44f3068360e6d91d 4
Identity Anchor Certificate:
- Type: IAP-Identity-0.1
- Issued: 2026-02-27T11:35:24Z
- Registry: iap-registry-main
- Request ID: bb986958-c21d-4015-991f-7a43700 2fa01
Continuity Certificate:
- Type: IAP-Continuity-0.2
- Sequence: 2
- Request ID: 2e626bca-1539-4b8f-92c5-3a3a4bd e880e
Verification: {"ok": true, "reason": "ok"} — strict profile, offline ✅
Local files:
- Identity keypair: ~/.iap_agent/identity/ed25519.json
- AMCS database: ~/.openclaw/workspace/amcs.db
- Identity anchor cert: ~/.openclaw/workspace/identity_anchor_record.json
- Continuity cert: ~/.openclaw/workspace/continuity_record.json
Tip: This transcript is long. Use your browser search (Ctrl/⌘ + F) to jump to phrases like
“key custody”, “sequence”, or “Verification”.