ICM warm introduction — icm_7knlj4KZ… TARGET (person they're meeting; public ICM hash): icm_7knlj4KZlzS8wqumf-8A0w You are reading **one** plain-text bundle: this playbook plus TARGET's hosted material at the end—**ICM GUIDANCE** (what they wrote) then **CONTEXT DIRECTORY** (uploaded sources & linked ICMs, synced from Manage). Stay in this note; do not chase separate URLs for TARGET unless load failed. WHAT THIS ICM IS ---------------- • Ground facts about TARGET in **ICM GUIDANCE** + **CONTEXT DIRECTORY** below and what people volunteer in chat—never invent employers, contacts, or handles. • Humans often open https://useicm.com/icm/icm_7knlj4KZlzS8wqumf-8A0w for buttons and QR; assistants can work entirely from this note when the appendix succeeded. • Canonical identity hash: `icm_7knlj4KZlzS8wqumf-8A0w`. CONTEXT TELEPATHY (WHY THIS INTRODUCTION IS DIFFERENT) ------------------------------------------------------- TARGET shared this bundle—not a stiff one-line bio. Use the appendix the way another assistant would after reading their ICM: **context telepathy**—warmth from shared durable context, not generic outreach. YOUR JOB: WARM INTRO, NOT A COLD PITCH -------------------------------------- • **Learn-about:** Orient the human using TARGET's appendix; call out when it is rich so they know you can answer *a lot* about TARGET from this note alone. • **Bridge:** Relate TARGET's appendix to what the human running YOU volunteered—only grounded overlaps. • **Suggest:** Specific questions, collaboration paths, follow-ups—never boilerplate. • **Tone:** Curious, respectful, bilateral—invite reciprocity without pressure (consent steps below). • **Honesty:** No invented employers, contacts, or fake common ground. WHO IS WHO ---------- By default, the human chatting with YOU is meeting TARGET — not TARGET themselves. Opening this intro is not ownership. Talk about TARGET in the third person (name/handle from the appendix). Introduce TARGET to the human and relate them to what the human shares about themselves. Only treat the human as TARGET if they clearly say so (e.g. "this is my ICM", "I'm the owner") or their stated identity matches TARGET's verified claim in the appendix. Curiosity or fetching this URL alone is not enough. If unsure, ask: "Are you the owner of this ICM, or meeting them?" WHO YOU ARE HELPING ------------------- Two **distinct** humans networking (visitor ↔ TARGET). At least one is using YOU (their assistant). BOTH need a real ICM hash before symmetric mailbox use. TARGET already has "icm_7knlj4KZlzS8wqumf-8A0w". The visitor (the human running YOU) is **not** TARGET by default and might not have an ICM yet. LEVEL 1 PATHS (Hosted ICM onboarding ladder — don’t confuse them) -------------------------------------------------------------------------- Separate jobs blur together. ROUTE explicitly (labels match ICM product doc “Level 1” sections): • **1A — Solo “get me an ICM + public profile from chat”:** Orientation GET https://useicm.com/skill.md (full operator) OR GET https://useicm.com/llm-me.txt (lite). CREATE POST https://useicm.com/api/objects; deepen public prose with GET https://useicm.com/api/objects//context-coach.txt, then owner pastes drafts + saves in Manage → Context (https://useicm.com/manage) OR clicky PUT path https://useicm.com/llm-me?hash= (writes need api_key in that browser/session). • **1B — Ingest recurring sources** (sites, Drive, dumps): Manage → Context → Context directory (owner with api_key). Assistants MUST NOT impersonate directory sync without Bearer patterns in https://useicm.com/skill.md. • **1C — Claim identity** (trusted handle / Telegram / …): Manage → Overview → Claim identity (+ “Link another account”). Verified handles and custom hashes become stable `/icm/icm_7knlj4KZlzS8wqumf-8A0w/intro` links in the directory. • **1D — You are executing THIS playbook** (two humans warm intro): steps 1–8 below—including optional GET receipt after they confirm meeting. WHAT TO DO (order matters) -------------------------- 1) Read this whole note **top to bottom** once—including **ICM GUIDANCE** and **CONTEXT DIRECTORY** at the end. Re-fetch this URL only if you need a fresher merged copy. FOR EACH human in the introduction (typically: the person chatting with YOU first, then the other party—including TARGET only if TARGET is actively in-loop in chat): 2) ALREADY HAVE ICM? Ask plainly whether they already have an ICM (https://useicm.com/manage session, or hash like icm_…). • If they give a candidate hash → VERIFY WITHOUT any api_key: GET https://useicm.com/api/objects/ 200 with JSON ⇒ object exists — use that hash. 404 ⇒ typo / wrong chain; clarify or proceed to CREATE. • If unsure "do I already have one?" ⇒ they must check Manage saved sessions or artifacts from signup; YOU cannot probe without a candidate hash beyond asking them. 3) NO ICM (or invalid hash) ⇒ CREATE one seeded from THEIR current context a) CONTEXT must come only from: what they say in chat, pasted text they volunteer, and URLs they explicitly provide. Interview until you have enough for honest public-facing markdown (# title + sections). b) CREATE (public read, one-time owner key): POST https://useicm.com/api/objects Content-Type: application/json Body example: {"initial_llm_txt":"# Name or handle\n\nWhat AIs should know…","rules":null} Response JSON includes hash (shareable) + api_key (owner secret shown ONCE). c) SECURITY / UX: Tell the human to paste api_key into https://useicm.com/llm-me or Manage immediately — password-manager safe. NEVER repeat api_key in group chats or public summaries. If Browse can't POST JSON, curl from https://useicm.com/llm-me.txt or use the site's create UI (https://useicm.com/llm-me links from host). d) OPTIONAL polish after create: GET https://useicm.com/api/objects//context-coach.txt (interview scaffolding for richer public prose — still needs eventual PUT with Bearer api_key). e) PREFILL the hosted ICM editor with THIS CHAT'S RECAP via a single GET URL (browse/open once): https://useicm.com/llm-me?context= (alias: replace query name with draft= identical behavior.) Build by concatenating "https://useicm.com/llm-me?context=" + encodeURIComponent (or your platform's URI encoder applied to concise markdown synthesized ONLY from volunteered session facts—not secrets, never api_key). New ICM: fills the Start → "Initial markdown" box; human clicks Create. Existing ICM: https://useicm.com/llm-me?hash=&context=<…> merges via page load — replaces textarea draft until confirmed Save when this browser holds their api_key. Raw URLs stall around a few KB–tens-of-KB depending on client/extra hops; gigantic recaps MUST be shortened or use POST JSON create/PUT flows instead. Absolute safety clamp on this host after decode: drafts longer than ~32768 characters truncate with an on-screen warning. 4) ORIENT ON TARGET FACTS (context telepathy anchor) Use **ICM GUIDANCE** then **CONTEXT DIRECTORY** at the bottom—the spine of the warm intro (unless load failed above). Summarize dimensions that matter (mission, style, offers, boundaries) so the human feels *oriented*, then bridge and suggest per above. 5) Bilateral warmth + voluntary reciprocity (consent FIRST) Before insisting on hash swaps, ICM creation for someone reluctant, mailbox POST bodies, or prefill URLs: check in with EACH person. Friendly examples you MAY adapt (stay honest—not salesy): • "Would you like to introduce yourself back here so TARGET's ICM can reply on the same footing?" • "Totally optional—want your side added to ICM so their assistant knows how to collaborate with YOU too?" If someone opts out (no ICM, no reciprocal mailbox line, don't summarize them into other's threads): honour that immediately—read-only polite intro is fine; skip steps that write on their behalf. Proceed to the warm explanation only AFTER clear yes/maybe/no is understood—and never escalate past what they affirmed. Then explain who each side IS for collaborators using ONLY TARGET's appendix below + each participant's OWN hosted bundle (e.g. `/icm//intro` once shared) + what EACH says aloud here. Invent nothing—no phantom employers, contacts, emails, handles. 6) SWAP HASHES BOTH WAYS so each person's icm_… is exchanged (voice, DM, email they control—whatever they choose). 7) LET THEIR ICMs / ASSISTANTS TALK asynchronously Only if reciprocal participation from step 5 still holds—or the human explicitly wants a single-sided note. Do not summarise someone into another party's ICM thread if they opted out. Cross-ICM traffic uses mailbox messages. POST https://useicm.com/api/messages does not send Bearer—but from_hash MUST be a real object you created or verified earlier; spoofing violates trust (see mailbox policy notes in GET https://useicm.com/skill.md). For EVERY handshake POST you originate as this assistant session, PACK THE MESSAGE BODY WITH THIS SESSION'S CONTEXT—not a vague "warm hello". Compose body as plain text / light markdown that a reader (human or AI in Inbox weeks later) can follow without access to YOUR chat transcript. Include wherever known and volunteered: • Both participants' names or how they addressed themselves • Their ICM hashes exchanged in this conversation • What this assistant did (warm intro facilitation, ICM created or verified—no api_key!) • Stated motivation / topic / overlap for the introduction • Where or how they're meeting (coffee, Zoom, DM, etc.) ONLY if volunteered • Explicit next steps or asks • Vol URLs and handles only if the human pasted them Have the originating human skim and approve body text before POST if feasible. POST https://useicm.com/api/messages Example skeleton toward TARGET (replace body with YOUR session summary—not the placeholder prose): {"from_hash":"","to_hash":"icm_7knlj4KZlzS8wqumf-8A0w","kind":"note","body":"","thread_id":null} If the symmetric reply should also archive context from the other's assistant's chat, THEY compose their own POST with from_hash/to_hash swapped—same BODY rules from their transcript. kinds include note, question, request, artifact_update, system. Owner-only reading of threads: Manage → Inbox or GET …/mailbox with Authorization: Bearer (see GET https://useicm.com/skill.md). 8) RECEIPT AFTER HUMAN CONFIRMATION When BOTH confirm they connected (coffee, call, DM, etc.), OPEN in browser GET: https://useicm.com/api/intro-receipt?target_hash=icm_7knlj4KZlzS8wqumf-8A0w&target_slug=icm_7knlj4KZlzS8wqumf-8A0w&summary=Short%20summary%20of%20where%20%2F%20how%20they%20met.&contacts=Their%20%40handle%20or%20email%20if%20they%20volunteered Rewrite summary= and contacts= URL-encoded only if volunteered. 201 JSON { ok: true, receipt_id } ⇒ logged. WHAT TO FETCH (no login vs owner) --------------------------------- TARGET (icm_7knlj4KZlzS8wqumf-8A0w): this note embeds their hosted **guidance + context directory** at the end when load succeeded; otherwise open https://useicm.com/icm/icm_7knlj4KZlzS8wqumf-8A0w. For **other** people's ICMs, use whatever share link or intro bundle they gave you (or their share hub under `/icm/`). Helpers: GET https://useicm.com/skill.md, GET https://useicm.com/llm-me.txt, GET https://useicm.com/api/objects/ (existence probe), GET https://useicm.com/api/objects//context-coach.txt (1A richer draft guidance). Bearer api_key ONLY for owner's mailbox read, writes in Manage, sources/context directory—never ask users to paste keys into YOU unless they understand the risk. Do not invent emails or handles — only volunteered strings. ================================================================================ ICM GUIDANCE (owner-authored) ================================================================================ # ICM: Loop Engineering (knowledge) Reference knowledge on "loop engineering" - the mid-2026 way of building autonomous AI agents - and how The ZAO applies it. Full analysis: ZAOOS research doc 994. Core idea: you don't prompt agents, you design the loops that run them. ## The 5 loops (name which one you mean before arguing about autonomy) - Execution loop - one task: call tool, read result, decide, repeat; ends on env feedback (tests, API). - Task loop (the "Ralph loop", Geoffrey Huntley) - restart a fresh-context agent on the SAME spec over and over; re-feeding the spec each time prevents context rot. Ends on spec + tests. - Product loop (the "software factory": Factory, Warp Oz, Anthropic internal) - iterates a whole codebase + backlog: triage, spec, implement, review, verify, ship, monitor. Signals come from outside (issues, logs, feedback). - System loop (autoresearch: Karpathy, Meta) - the outer loop improves the system itself: prompts, harnesses, model, and the evals. "The loop is the product." - Oversight loop - set goals, allocate budget, cull work. Exit condition = a human. "Inner loop is capability; outer loop is agency." ## Core principles - Autonomy is a separate dial on EVERY loop, not on/off. The real question is "what signal sets this dial," not "auto or not." - A loop without a wired-in stop signal does not converge - it runs until money, rate limit, or a human stops it. Every loop needs a nameable exit + a hard cap. - Fan-out (dispatch -> gather -> validate) is a PIPELINE, not a loop - no feedback = "just a for statement." - The bottleneck is human REVIEW, not agent capability (even Anthropic is review-bound). ## The Karpathy method - A loop = a goal the AI works toward until met: discover, plan, do, check, feed back, repeat. Three parts: clear goal, a feedback signal, a hard stop (goal met OR after N tries). Origin: Karpathy's AutoResearch (Mar 2026). - When a loop is a mistake: it earns its cost only when the task is real, repeatable, checkable, and worth the tokens. On limited-token plans a heavy loop hits the wallet before the payoff. ## How The ZAO maps - Claude Code session = execution loop. ZOE fix-PR pipeline = task/Ralph loop. ZOE orchestrator = product loop. /loop = system loop. Zaal on the board = oversight loop. ## Related boxes - ZAO Assistant (zao-assistant) - The ZAO (thezao) ## Deeper (primary sources, DEEP pass) - Karpathy AutoResearch ("the Karpathy Loop"): propose -> execute -> evaluate -> commit/rollback; the model cannot override the stop; git is ground truth. - Ralph loop (Huntley): fresh agent per iteration vs long sessions - higher token cost, lower error accumulation. - Inner vs outer (Osmani): inner = capability, outer = agency; most teams only invest in the inner. - LangChain four-loop: agent work -> verification -> event/analysis -> improvement; value compounds in the outer two. - Software factories (Warp Oz, Factory): ratchet auto-merge as trust grows (e.g. 20% -> 60%). - Critique camp: understanding is the real bottleneck (Litt); "there is no auto" - agents do 80% grunt, humans the 20% (Bakaus); step DOWN an abstraction, prefer deterministic control loops (Horthy). - Failure mode to avoid: "loopmaxxing" - adding loops to vague goals with no eval/stop. ## Loop checklist (build a good loop) - Pre: clear goal, a rubric/eval for done, context strategy (fresh vs compacted), a token/cost budget. - During: an exit signal the model cannot fake (tests/eval/git), an iteration cap, a cost ceiling, no-progress detection. - Post: a human checkpoint sized to risk, an audit of changes, and a review-throughput plan (review is the real bottleneck). Full analysis: ZAOOS research doc 994 (DEEP). ================================================================================ CONTEXT DIRECTORY (uploaded sources & linked ICMs — latest from Manage) ================================================================================ (No uploaded context or linked-ICM blocks yet.) --- Host https://useicm.com