Demo: aiosandbox + Hermes + AgentKeys on ESP32 hardware

[hanwencheng]

Summary

End-to-end v0 demo for the AgentKeys hardware-vendor wedge: an ESP32 device, configured with one URL + one actor token, talks to a cloud-hosted agent-infra/sandbox running a Hermes agent runtime + agentkeys-daemon that auto-injects a mock user-memory MD blob from S3 at agent boot. The device sounds personalized from the first conversation.

This is the v0 buyer-pitch demo called for in the office-hours design doc §9.6 Storyboard, scoped to single device, single sandbox, single mock memory blob.

Full plan: docs/spec/plans/issue-102-aiosandbox-hermes-esp32-demo.md

Why now

The office-hours diagnostic surfaced that the next critical step is a working demo a vendor can SEE — not more architecture docs. Approach D (AgentKeys-native sandbox) was chosen specifically because vendor integration friction collapses from "embed SDK in firmware" (2 months) to "point your device at a URL" (1 day). This issue ships that 1-day vendor onboarding story end-to-end so we can take it to FoloToy / Ropet / BubblePal.

Scope

IN scope (v0):

• One ESP32 board talking to one cloud-hosted sandbox
• Mock memory injected from one S3 MD blob at agent boot
• Single hardcoded actor (O_demo_001)
• Text-mode interaction (voice mode deferred to follow-up)
• Subsidized LLM (DashScope Qwen-Plus default; OpenRouter / OpenAI configurable)
• Public demo URL https://demo.aiosandbox.litentry.org (or chosen subdomain)
• One-command idempotent setup script per CLAUDE.md "Idempotent remote-setup rule"
• Demo runbook for live walk-throughs

NOT in scope (deferred):

• Voice STT/TTS pipeline
• Real agentkeys-worker-memory integration (demo uses static S3 blob)
• Cross-vendor memory portability
• Multi-tenant sandbox orchestration
• Pricing / billing / activation flow
• Cap-token enforcement on the memory read path
• Parent-control / consumer mobile app
• Audit anchoring to Heima (off-chain audit only)
• Real-time revocation UI

Architecture (summary; full diagram in plan)

ESP32 → HTTPS POST /v1/chat → nginx → hermes-runtime → LLM → response → ESP32
                                  ↑
                                  uses memory injected at agent boot via
                                  agentkeys-daemon GET /v1/memory/{actor}/profile.md
                                  → S3 (bots/<actor>/memory/profile.md)

Reuses canonical AgentKeys primitives from docs/arch.md:

• agent-infra/sandbox (already arch.md's chosen agent runtime substrate)
• HDKD actor model (single O_demo_001 for v0)
• Memory bucket layout bots/<actor_omni_hex>/memory/<path>
• supervisord lifecycle (per Round 13 runtime probe)
• agentkeys-daemon extended with one new GET endpoint

Implementation order (12 steps)

#	Deliverable	Verify by
1	Mock memory MD fixture	File exists, markdown-lint passes
2	agentkeys-hermes-runtime crate scaffold + /v1/chat stub	cargo test -p agentkeys-hermes-runtime
3	Hook hermes-runtime to DashScope Qwen-Plus	curl localhost:8090/v1/chat -d '{"query":"hi"}' returns LLM response
4	Add /v1/memory/{actor}/profile.md to agentkeys-daemon (test fixture, no S3 yet)	curl returns fixture
5	Hermes-runtime fetches memory from daemon at startup; injects into system prompt	Chat response references profile facts (Kevin, Chengdu, spicy)
6	Provision S3 bucket + upload fixture via setup script	aws s3 ls s3://agentkeys-demo-memory/bots/O_demo_001/memory/
7	agentkeys-daemon reads from S3 (not hardcoded)	Swap S3 file, restart, chat reflects new content
8	Build extended sandbox Dockerfile with supervisord configs	docker run agentkeys/aiosandbox-demo:latest boots clean
9	Deploy to demo host with TLS	curl https://demo.aiosandbox.litentry.org/v1/chat works
10	ESP32 firmware (text mode); flash to board	Button press → text query → response on serial
11	End-to-end ESP32 → sandbox → LLM → memory-aware response	Live demo
12	docs/demo-aiosandbox-runbook.md	Operator can re-run from doc alone

Acceptance criteria

A reviewer takes the runbook, runs bash scripts/setup-demo-aiosandbox.sh on a fresh demo host, flashes the ESP32 firmware, and within 15 minutes can:

• Send a text query from the ESP32
• Receive a response that demonstrably reflects the mock memory content
• Swap the S3 memory blob and see the next response reflect the new content
• Read the demo runbook to understand every command they ran

Open questions (resolve before step 3)

1. "Hermes" naming — confirm vs. OSS conflict; potential rename to agentkeys-companion-runtime or agentkeys-shell
2. LLM provider — DashScope (default, China-friendly) vs. OpenRouter vs. Claude/OpenAI
3. Demo host — reuse Heima broker host or spin up separate VM (recommend separate)
4. Voice mode — defer to follow-up issue (recommend yes; text demo validates the pitch)
5. ESP32 board — WROOM-32 ($5-8) for v0; ESP32-S3 for voice follow-up
6. Auth — simple static bearer token tied to actor_omni (recommended for v0 demo)

Effort estimate

• ~3 weeks for v0 working demo
• Steps 1-7 (Rust + S3 + memory injection): ~1.5 weeks
• Steps 8-9 (Dockerfile + deploy): ~3 days
• Steps 10-11 (ESP32 + end-to-end): ~1 week
• Step 12 (runbook): ~2 days

Dependencies

• agent-infra/sandbox (stock image, no fork)
• AgentKeys Stage 7+ stack (extends one endpoint on agentkeys-daemon)
• AWS S3 (existing agentkeys-admin profile, us-east-1)
• DashScope or OpenRouter LLM credit (~$10/mo for demo usage)
• ESP32 hardware (~$5-15 off-the-shelf)
• Demo host (2 vCPU / 4GB VM)
• Let's Encrypt TLS cert

Related

• Office-hours design doc: docs/research/ai-hardware-companion-office-hours.md (Approach D, the chosen direction)
• Wedge business research: docs/research/ai-hardware-companion-wedge.md (market sizing + competitive landscape)
• Sandbox runtime probe: docs/research/aiosandbox/agent-infra-sandbox-runtime-probe.md (supervisord, sudo posture, kernel capabilities)

[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.