Demo: aiosandbox + Hermes + AgentKeys on ESP32 hardware

[hanwencheng]

Demo: Agent IAM for the AI device era — agentkeys wire + hooks

Pivoted 2026-05-28. This issue originally specced a single-act memory-injection demo built on a custom Rust "Hermes runtime" + a daemon memory endpoint + an extended sandbox image (12-step plan). That approach is superseded. The original plan + artifacts are archived under docs/archived/*-rust-runtime-2026-05*. The current direction below is the final expectation.

What this issue now tracks

A <5-minute, zero-config-editing demo that proves AgentKeys is Agent IAM, not chatbot infrastructure: a fresh user points a Task Host (Hermes) at AgentKeys with one command (agentkeys wire hermes) and the device immediately (1) reads only the memory it's permitted to, (2) is deterministically denied an over-cap action with no LLM in the decision, and (3) complies the instant a scope is revoked.

Strategic anchor: docs/agent-iam-strategy.md. Architecture record: docs/arch.md §22d. Terminology: docs/wiki/agent-iam-guarantee-glossary.md. Execution plan: docs/spec/plans/phase-1-fresh-user-wire-onboarding.md.

Architecture (Option B — hooks-first)

AgentKeys is the Authority Host; the Task Host does the work. We never become a Task Host (strategy §2.1/§2.4).

Vendor surface
  └── Task Host (Hermes / Claude Code / Codex / OpenClaw — has lifecycle hooks)
        ├── MCP → aiosandbox primitives (browser/file/terminal, POST :8080/mcp)
        └── MCP → AgentKeys Authority (memory/permission/cap/audit, the 7 tools)
        └── Hooks (PreToolUse/PostToolUse/Stop) → AgentKeys MCP tools  ← IAM GUARANTEE

• IAM tool vs IAM guarantee: an MCP tool the LLM can call is not a guarantee — the LLM can skip it. A guarantee is a non-LLM gate in the execution path. Hooks are that gate (the LLM physically cannot bypass permission.check). See the glossary.
• Hooks-first, proxy-fallback: hooks are primary (issue Phase 3: LLM-host hook integration (Claude Code, Codex/ChatGPT, etc.) #133 track; Tier-1 hosts Claude Code/Codex/Hermes/OpenClaw all have them, verified 2026-05-28). An OpenAI-compatible proxy is the lower-priority fallback (Phase 3b) for hosts without a hook surface (xiaozhi-server, mobile chatbots).
• aiosandbox is a sandbox primitive, not a Task Host — it supplies browser/file/terminal; the Task Host runs inside it.

The fresh-user journey (7 steps)

1. Install aiosandbox (docker run --security-opt seccomp=unconfined … ghcr.io/agent-infra/sandbox)
2. curl … | bash installs the AgentKeys CLI; bootstraps device key + pairing
3. On the master device: provision creds (LLM keys) + memory namespace scopes
4. Install a Task Host (Hermes) — do NOT run its setup wizard
5. agentkeys wire hermes — one idempotent command
6. AgentKeys writes the hook scripts + hooks: config + consent + LLM key into the runtime
7. Open the runtime → first conversation is already memory-aware (the "surprise")

The three-act demo (the pitch)

1. Permissioned Memory — device reads ONLY its granted namespace ("knows what it's allowed to know about you", not "knows you")
2. Deterministic Denial — over-cap spend → permission.check returns denied: daily_spend_cap_exceeded; the device refuses. No LLM in the decision.
3. Online Revocation — parent revokes payment scope; next attempt fails on the online cap check.

Implementation status

Component	Status
AgentKeys MCP server — 7 tools (identity.whoami, memory.get/put, permission.check, cap.mint/revoke, audit.append)	✅ shipped (#107)
Docs / strategy reset (strategy doc move, arch §22d, wiki glossary, plan)	✅ merged (#140)
agentkeys wire hermes + agentkeys hook check/audit/memory-inject + Hermes adapter + operator runbook	🔄 open (#141) — verified end-to-end against the in-memory MCP backend
Phase 1.b adapters — Claude Code / Codex / OpenClaw (the RuntimeAdapter seam)	⬜ deferred (#133)
Proxy fallback for hook-less hosts	⬜ deferred (Phase 3b)
Nightly drift-check cron, live-session identity defaulting, cap-mint pre-warming	⬜ deferred (plan §11)
ESP32 firmware (MagicLick / xiaozhi)	⬜ deferred — the device-side substitute is a laptop curl/Task-Host today

Scope

IN (current): the 7-step agentkeys wire hermes flow + the three-act demo, driven from a laptop/sandbox; single demo actor; in-memory or real MCP backend.

OUT (deferred): ESP32 firmware, voice STT/TTS, multi-tenant orchestration, billing, the parent-control web UI's full build, real-time on-chain audit, cross-vendor memory portability.

Acceptance criteria

A reviewer, following docs/operator-runbook-wire.md (lands in #141), can on a fresh machine:

• run agentkeys wire hermes and see every step report ok proceeding (re-run → all skip … matches)
• send a query and get a response that reflects the permitted memory namespace (Act 1)
• attempt an over-cap action and watch it be deterministically blocked with the cap reason (Act 2)
• revoke a scope and watch the next attempt fail (Act 3)
• all within ~15 minutes, editing zero config files by hand

Related

• Strategy: docs/agent-iam-strategy.md §2.1/§2.4 (Authority vs Task Host), §3.6/§3.7 (IAM guarantee + wire decision), §4.3 (three-act demo)
• Phase 1: AgentKeys MCP server — 7 active tools + 3 schema-only #107 — AgentKeys MCP server (the tool surface)
• Phase 3: LLM-host hook integration (Claude Code, Codex/ChatGPT, etc.) #133 — multi-runtime hook reference configs (Phase 1.b + the canonical hooks track)
• docs: Agent IAM strategy reset — hooks-first wire architecture #140 — docs/strategy reset (merged)
• feat(cli): agentkeys wire + hook — IAM-guarantee hooks for Hermes #141 — agentkeys wire + agentkeys hook implementation (open)

[hanwencheng]

Foundation landed — ESP32-S3 firmware skeleton

Pivoted hardware target from generic ESP32 to ESP32-S3-DevKitC-1. Rationale captured in the plan §C6:

• Native USB-OTG (single USB-C, no separate UART chip → faster iteration)
• PSRAM-capable (8MB octal) → audio buffers fit for voice follow-up
• Xtensa LX7 with AI vector instructions → on-device wake-word feasible
• Still MCU-class authenticity (matches what FoloToy / Ropet / BubblePal ship)
• ~$10-15 dev board; <$5 chip in BOM volume

Stack: PlatformIO + ESP-IDF (not Arduino). Production AI-toy vendors use ESP-IDF and S3-specific features (native USB CDC, PSRAM, ESP-DSP, secure boot, OTA) need IDF.

Foundation scaffold

Landed in firmware/esp32s3-agentkeys/ — 18 files, 722 lines (404 lines of C/H):

File	Purpose	Status
platformio.ini	Board + framework + build flags	✅
CMakeLists.txt, main/CMakeLists.txt	ESP-IDF project + component registration	✅
sdkconfig.defaults	USB CDC console, PSRAM, mbedTLS cert bundle, 8MB flash	✅
partitions.csv	NVS + factory + OTA dual-slot + SPIFFS	✅
main/main.c	Spawns 4 FreeRTOS tasks coordinated via event group + queue	✅
main/config.h	NVS → secrets.h → hardcoded defaults priority order	✅
main/wifi_sta.c	STA mode + auto-reconnect (working)	✅
main/button.c	GPIO interrupt + 200ms debounce on BOOT GPIO 0 (working)	✅
main/led_status.c	Stub blinker on GPIO 2	⚠ stub (real WS2812 RGB state machine TODO)
main/https_chat.c	Stub echoing [mock] you said: ...	⚠ stub (real esp_http_client POST TODO)
main/secrets.h.example	WiFi creds template (copy to secrets.h, gitignored)	✅
README.md	Flash quickstart + troubleshooting table	✅

What works today

After cp main/secrets.h.example main/secrets.h + fill in WiFi creds + pio run -t upload -t monitor:

[agentkeys] booting (version 0.1.0)
[wifi] starting STA, connecting to <SSID>
[wifi] connected, ip=192.168.1.42
[btn] ready (GPIO 0, falling edge, 200ms debounce)
[chat] wifi ready, target=https://demo.aiosandbox.litentry.org/v1/chat
[agentkeys] ready (press BOOT button on GPIO 0 to chat)

Press BOOT button → > prompt → type message + ENTER → agent: [mock] you said: <text>.

Clear next step

Replace the stub in https_chat.c with a real esp_http_client POST + cJSON parse. ~100 lines, well-trodden ESP-IDF pattern. Should land before any sandbox-side work begins so the integration contract is testable end-to-end against a placeholder sandbox endpoint.

Renamed plan file

Plan filename changed from issue-102-... → issue-103-aiosandbox-hermes-esp32-demo.md. Original issue body link to issue-102-...md is broken — use the link above instead.

[hanwencheng]

Pivot — hardware on hand is MagicLick 2.5 running xiaozhi-esp32 v1.9.4

The demo device displays magiclink 2p5/1.9.4. That single string identifies it as a MagicLick 2.5 board running the xiaozhi-esp32 v1.9.4 firmware. Both are in the xiaozhi-esp32 main repo (boards/magiclick-2p5, tag v1.9.4 released 2025-11-04).

xiaozhi-esp32 is MIT-licensed, 26K stars, 5.9K forks — the dominant open-source AI voice firmware in the Chinese ESP32 ecosystem. It supports 70+ boards including ours. Critically, it already ships the entire voice pipeline: offline wake-word (ESP-SR) → streaming ASR → LLM → streaming TTS, OPUS audio over WebSocket or MQTT+UDP, MCP-based device + cloud control, multi-language, battery management, emoji LCD rendering.

MagicLick 2.5 hardware specs (from boards/magiclick-2p5/config.h + board.cc)

Component	Detail
MCU	ESP32-S3
Audio codec	ES8311 (full-duplex I2S, 24kHz in + out)
Display	128×128 GC9107 SPI LCD with emoji
Buttons	3 (main GPIO 21, left/BOOT GPIO 0, right GPIO 47)
LEDs	2× WS2812 on GPIO 38
Network	WiFi primary + ML307 Cat.1 4G fallback
Power	Battery + power manager + tickless idle

"Hermes agent" clarification

The original plan §C4 mistakenly described Hermes as an internal AgentKeys runtime we would build. It's actually NousResearch/hermes-agent — a real MIT-licensed Python agent with a self-improving learning loop, multi-interface gateway (Telegram/Discord/Slack/Signal/CLI), LLM-agnostic model selection (OpenRouter / Nous Portal / OpenAI / DashScope / etc.), and built-in Docker/SSH/Modal/Daytona deployment backends.

Two options considered

Option 1 (RECOMMENDED): Keep xiaozhi-esp32 firmware unchanged on the device. Build a cloud-side xiaozhi-hermes-bridge that speaks xiaozhi's WebSocket protocol while routing the agent loop to NousResearch Hermes-agent (which pulls memory from agentkeys-daemon per §C3). Fork from one of four existing reference server implementations.

Option 2: Rewrite firmware from scratch.

Dimension	Option 1	Option 2
Time to demo	~2-3 weeks	~2-3 months
Firmware risk	Zero (production-tested at 26K stars)	High (voice pipeline is hard)
Multi-board compat	70+ boards out of the box	Per-board firmware port
MCP capabilities	Inherited from xiaozhi	Reimplement
Battery / display / wake-word	Already done	Reimplement
Vendor optics	"We integrate with the dominant Chinese voice firmware"	"We have our own firmware" (NIH risk with vendors)

Decision: Option 1. Full rationale in docs/research/xiaozhi-esp32-magiclink.md.

What this means for the original plan

• §C3 (mock memory + daemon endpoint) — still valid, no changes
• §C4 (custom Hermes Rust crate) — superseded. Use NousResearch Hermes installed via official installer; no Rust crate to build
• §C5 (sandbox Dockerfile with hermes-runtime program) — superseded. Install Hermes inside aiosandbox via official script; add xiaozhi-hermes-bridge as separate component
• §C6 (custom ESP32-S3 firmware) — superseded for MagicLick demo. Keep firmware/esp32s3-agentkeys/ as reference scaffolding for future custom hardware. Configure MagicLick via its built-in WiFi captive portal to point at our bridge URL.
• §C7 (deploy script) — partially valid; update to provision the bridge instead of a custom runtime
• Implementation order — superseded by the 6-step list in the research doc

Reference server implementations to fork from

Repo	Language	Notable
xinnan-tech/xiaozhi-esp32-server	Python	Official-feeling reference (recommended starting point)
hackers365/xiaozhi-esp32-server-golang	Go	WebSocket + MQTT+UDP, voice-print, voice-clone, MCP remote call, openclaw
joey-zhou/xiaozhi-esp32-server-java	Java	Enterprise platform
AnimeAIChat/xiaozhi-server-go	Go	Lightweight

Hardware verification

system_profiler SPUSBDataType showed no enumeration because MagicLick 2.5 is a finished consumer product — USB is charge-only in normal firmware mode. To get USB serial: hold the LEFT button (GPIO 0 / BOOT) while reconnecting USB to drop into ESP32-S3 ROM bootloader. Five identification paths documented in the research doc (visual / ROM bootloader / WiFi captive portal / vendor app / disassembly).

Next steps (replaces issue #103 §C5-C6 firmware-from-scratch path)

1. Stand up xiaozhi-hermes-bridge by forking xinnan-tech/xiaozhi-esp32-server (Python). Replace its LLM caller with a Hermes-agent client. Keep ASR/TTS/WebSocket handling as-is.
2. Install Hermes-agent inside aiosandbox via the official installer. Configure model (OpenRouter / DashScope / subsidized LLM).
3. Add AgentKeys integration in the bridge: on session start, GET /v1/memory/<actor>/profile.md from agentkeys-daemon and inject as system-prompt context.
4. Configure MagicLick 2.5 via WiFi captive portal to point at wss://demo.agentkeys.io/ws.
5. End-to-end test: wake device → ask question → bridge → ASR → Hermes → response → TTS → audio plays.
6. Defer voice-print, cross-vendor portability, payments, audit anchoring to follow-ups.

Commit: e61220e on branch claude/hopeful-mccarthy-15e5ba. Plan pivot banner: issue-103 line ~1-20.

[hanwencheng]

Risk verification + v0 timeline revised + Tuya complement-not-compete

Two new research docs landed at commit a920461:

docs/research/xiaozhi-hermes-risks.md — risks verified against actual code

All three originally identified risks turned out to be smaller than feared, and a fourth surfaced during the dig.

Risk	Real?	Evidence	Mitigation	Effort
R1 Hermes gateway stateless vs always-session	Real, but built-in mitigation	gateway/platforms/api_server.py lines 1080-1135: three session modes, default is stateless content-hashed session-id	Set X-Hermes-Session-Key: device-<esp32-mac> per device	2-4 hours
R2 Latency stack (Hermes adds 200ms+)	Mostly NOT real	agent/conversation_loop.py line 4152: learning loop is background task AFTER response delivery, OFF turn path	enabled_toolsets=[] + HERMES_MAX_ITERATIONS=1 + streaming SSE	1 day
R3 Concurrent device handling	Less bad than feared	Hermes gateway is multi-tenant by design (serves Telegram+Discord+Slack+WhatsApp+Signal+CLI from one process)	v0: nothing needed; production scale: sticky-LB sharded on actor_omni	0 / 1-2 wk
R4 (newly discovered) Cold agent construction per request	Real and consequential	api_server.py line 851: _create_agent() called for every request, no pooling. Adds 50-300ms per turn.	Fork-local agent_pool with TTL OR upstream PR	1 day / 2-4 days

R4 is the most consequential because cold-start latency compounds turn-by-turn for a voice toy (breaks streaming illusion mid-conversation). Cheapest fix: fork-local pool in our bridge. Durable fix: upstream PR to NousResearch.

Real latency baselines from xinnan-tech/xiaozhi-performance-research:

• ASR streaming first-word: 0.795s (Xunfei) / 0.85s (Doubao)
• LLM first-token: 0.434s (Qwen-Flash) / 0.774s (Kimi-K2)
• TTS first-audio: 0.488s (CosyVoice) / 0.667s (Edge-TTS) / 0.103s (PaddleSpeech)

Pipelined first-audio: 1.4-2.4s depending on stack choice. With Hermes overhead at 50-200ms in minimal mode, total lands at 1.5-2.4s — within the office-hours doc's 2.0-2.5s target.

Net effect on this issue's timeline

v0 demo: ~1-2 weeks, not ~3 weeks. Revised in the plan's PIVOT banner and §Effort estimate. Detail:

Bridge work	Effort
Fork xinnan-tech/xiaozhi-esp32-server	~1 hour
Replace LLM-caller module with Hermes HTTP client + AgentKeys memory fetch	~half day
Per-device session headers (R1)	2-4 hours
Tune toolsets/iterations/streaming (R2)	1 day
Optional agent pooling hack (R4)	1 day
Deploy to demo host + TLS	~half day
End-to-end test + latency measurement	1 day
Total bridge work	~3-4 days

Plus parallel tracks (AgentKeys daemon endpoint, S3 mock blob, device captive-portal config, demo runbook) ~3-4 days. Calendar time ~1-2 weeks.

One correction: "100+ devices per process" claim was unverified

The figure that "xiaozhi-esp32-server handles 100+ devices per process in production" circulated in earlier informal discussion. Not in the repo. The README only documents a 6-concurrent demo + recommends streaming config for ">2 concurrent users." Tenclass is mentioned as providing "high-concurrency scenario reference" without published numbers. Actual ceiling is unknown until measured. Fixed the bad cross-reference in the risks doc.

---

docs/research/tuya-vs-xiaozhi.md — Tuya is a DIFFERENT role from xiaozhi

Bottom line: complement, don't compete. Tuya is a paid closed PaaS for brand-owners (NYSE: TUYA, $80.9M Q1 2026 revenue, 306 premium customers, 1.97M registered developers, 100+ countries). xiaozhi is open MIT firmware for makers (26.7K GitHub stars). Tuya's defensive TuyaOpen ESP32 SDK from Jan 2026 is 1.6K stars — 17× adoption gap vs xiaozhi.

Vendor profile	Picks
White-label app + global distribution + cloud OTA + analytics + brand-owner SaaS	Tuya
Zero royalties + OPUS streaming + MCP + full source + self-host	xiaozhi

OEMs pick one or the other, not both on the same device.

AgentKeys posture: sit above both rails. Same architectural pattern as Alipay+ AMP / Stripe ACP (be the adapter, never the rail).

• Phase 1 (now): ship xiaozhi cloud-side bridge per this issue (~1-2 weeks)
• Phase 2 (3-6 months): add Tuya Cloud Development connector for brand-owner OEM volume (~1-2 weeks)
• Phase 3 (later): adapters for any other dominant brand-owner clouds (Xiaomi MIoT, Alibaba Smart Home, Volcano AI Hub) using the same above-the-rail pattern

Why this matters strategically: AgentKeys' value (cross-vendor memory portability + identity-that-survives-device-replacement + scoped permissions auditable on-chain) doesn't require us to pick a firmware or own a cloud — it requires us to be neutral above both.

Updated office-hours doc

Added implementation-update banner at the top of docs/research/ai-hardware-companion-office-hours.md pointing readers at the four xiaozhi research docs + revised v0 timeline. The §Recommended Approach / §Pricing structure / §Cross-Vendor Memory Model below stay unchanged — only the firmware-and-runtime layer shifted (now leveraging xiaozhi + Hermes upstream instead of building both ourselves).

---

Commit: a920461 on claude/hopeful-mccarthy-15e5ba.

[hanwencheng]

Strategic anchor landed — Agent IAM framing + four architecture corrections

New source-of-truth doc: docs/research/agent-iam-strategy.md. Future planning, positioning, and scope decisions reference it. Commit 1567aa3.

What changed strategically

Positioning is now three-layer, told to three audiences:

Layer	Audience	Pitch
AI Device Account	Consumer / vendor BD	"Your AI memory follows you safely across devices. Parents control what devices can know and do."
Agent IAM	Investor / CTO / CISO / partner	"Identity, permissions, capabilities, audit for AI agents — IAM layer for the AI device era."
Trust Substrate	Compliance / regulator / Web3 partner	"Tamper-evident permission history + cryptographic device/agent identity + on-chain anchoring."

Hard line: AgentKeys stays infrastructure (Authority Host). We never become a task-execution agent (Task Host = Hermes/OpenClaw/Claude Code/Doubao). Zero orchestration in v1. If a vendor needs orchestration, they pick a runtime via Phase 3 MCP tools.

Four architecture corrections that tighten what we promise

Correction	Wrong (earlier)	Right (now)
Revocation	"real-time revocation, no propagation delay"	Immediate online; bounded TTL/cache offline. High-risk always online; low-risk reads use short-lived caps; offline mode denies sensitive by default.
Audit	"audit row appears on Heima explorer in real-time"	Two-tier: real-time off-chain feed in parent UI + 10-min batched Merkle root anchored to Heima. Explorer = tamper-evidence proof, not UX surface.
Delegation	delegation.grant active in v1	Schema-documented but inactive in v1 (returns not_implemented_in_v1). Active delegation lands Phase 4.
Narrative	"Agent IAM" everywhere	Dual narrative: Agent IAM to B2B; "control what your AI devices can remember, access, and do" to consumers; trust substrate to regulators.

Phase 1 is now a three-act IAM demo (replaces memory-only)

Goal: <5-minute vendor pitch reads as Agent IAM, not chatbot infrastructure.

• Act 1 — Permissioned Memory: device reads ONLY the travel namespace, NOT profile/family/work. Headline: "the device knows what it's allowed to know about you", not "the device knows you."
• Act 2 — Deterministic Denial: user requests ¥600 spend over the ¥500 daily cap; agentkeys.permission.check returns denied: daily_spend_cap_exceeded from the policy engine; device refuses. No LLM in the decision.
• Act 3 — Online Revocation: parent opens AgentKeys web UI, revokes payment scope; next online cap-token check fails immediately; device complies.

Implementation reality (cap-token machinery is shipped)

Per Stage 7+ already on main:

• ✅ broker (cap-token issuance + verification)
• ✅ signer (K3/K10 HDKD per arch.md §17)
• ✅ memory worker (per-actor S3 isolation)
• ✅ cred worker (per-actor + per-data-class isolation per v2 stage 2 — Hardening: K11 WebAuthn + multi-device recovery + audit/memory/email workers #90)
• ✅ audit worker (off-chain + Heima anchoring)
• ✅ OIDC issuer + per-actor + per-data-class isolation invariants

New Phase 1 work (~2 weeks total):

Deliverable	Effort
AgentKeys MCP server (7 tools wrapping existing backend RPCs)	~1 week
Parent-control web UI (mobile-responsive, not native)	~3-4 days
Two-tier audit wiring (off-chain feed + batched Heima anchor)	~1 day
MCP config in stock xinnan-tech/xiaozhi-esp32-server	~half day
Three mock memory namespaces (only travel readable by demo actor)	~half day
Demo runbook + 15-min vendor pitch script	~half day

What changes about this issue

• The original §C4/§C5/§C6 implementation sections are historical context, not current spec. Implementation re-spec was skipped per direction (cap-token machinery exists).
• §C3 (mock memory + daemon endpoint) is still useful backend reference.
• Demo storyboard is now the three-act IAM demo above, not single-act memory.
• Four architecture corrections (revocation / audit / delegation / narrative) override any earlier loose framing.

What's NOT in Phase 1 (explicit non-scope)

• Orchestration of any kind
• Active delegation (schema-only)
• Approval workflows (Phase 4)
• Native mobile app (web UI sufficient for v0)
• Real-time on-chain audit (batched only)
• Volcano Ark / Tuya adapters (Phase 2)
• Hermes / OpenClaw as MCP tools (Phase 3)
• Standards body engagement (Phase 5)

Revised 12-month roadmap

Phase	When	What
0	Done	Stage 7+ backend infrastructure
1	0-2 weeks	Agent IAM v0 demo (this issue)
2	1-2 months	First vendor pilot + Volcano Ark MCP registration + Tuya Cloud connector
3	3-4 months	Runtime neutrality — Hermes/OpenClaw/Doubao as MCP-tools
4	6 months	Capability + revocation depth — active delegation, approval workflows, policy versioning, audit replay
5	Post-12-months	Standards engagement (contingent on Phase 1-4 deployed traction)

Risk register (now explicit)

1. Hyperscaler absorption — Anthropic/OpenAI/Tencent/ByteDance ship walled-garden IAM
2. Orchestration creep — vendor asks compound until we become an agent runtime
3. Weak consumer face — no parent UI = no Pro tier conversion = thin margins
4. Pure neutrality = no adoption — Switzerland-grade neutrality without traction = LDAP-grade obscurity
5. Premature standards work — lobbying before deploying = no credibility
6. Memory eclipses authority in narrative — gets us categorized as Mem0 competitor instead of IAM
7. Privacy positioning trap — privacy is a benefit, not a category

Lineage

• Round 1: original Agent IAM proposal (pasted by user, ~14 sections)
• Round 2: independent analysis (this AI) — pushed back on consumer/B2B positioning, sequencing of integration surfaces, standards timing
• Round 3: ChatGPT critique — surfaced the four architecture corrections + three-layer positioning framework
• Synthesis: this strategy doc + the updates committed in 1567aa3

Full lineage and reasoning in agent-iam-strategy.md.