Weekly Intelligence Briefing: May 21

For AIMM Members — This report covers Lou’s active R&D sessions from the past week. Emphasis on projects that produced tools, frameworks, and assets you can put to work immediately. Sessions marked ⭐ have high direct member value.

At a Glance

Session	Topic	Member Relevance
May 22–23	here.now — AIMM Challenger Article Site Migration	Publishing pipeline active
May 22–23	Council Framework — PRD Preset Build	⭐ PRD deliberation methodology
May 25	Gmail MCP — HTML Preview Safety Gate	⭐ Multi-account email, pre-send review
May 26	SOUL.md Framework — Ambient Agent Operations Methodology (Cowork)	⭐ Practitioner-ready governance for ambient agents
May 27	AIF v0.4 — Practitioner-Hardening Release	⭐ Ambient intelligence architecture security
May 27	AIF v0.4 Council Stress-Test	Deliberation as design tool
May 28	AIA / ARF — Resource Inheritance System v1 (Claude Code + Cowork)	⭐ Claude skills library management
May 28	AIMM Mastermind Recap + Distribution Pipeline	Community intelligence

This Week’s Big Themes

1. The AIF acquired a threat model this week — and that’s when a framework becomes infrastructure. v0.4 didn’t add features. It added enforcement: a named security boundary (Configuration-Based Self-Escalation, now explicitly forbidden), a four-tier action authorization model, and an append-only action log. When a framework can articulate what it forbids and why, it’s ready to be trusted in production. v0.1 was an interesting idea. v0.4 is something you can actually deploy and hand off to someone else without supervision.

2. Council deliberation is a development methodology, not a conversation style. The council framework ran as a scheduled task this week to analyze the ambient-intelligence PRD, generate 10 adversarial ISSUE files, vote on each one, and synthesize a combined hardened spec — all without manual prompting. If you’re still using AI as a question-answering machine, this week’s work demonstrates the alternative: AI as a design review board that generates structured opposition, not agreement.

3. Resource inheritance closes the last gap in the ambient intelligence model. Every programmer has a library. Until this week, Claude users didn’t — skills lived inside ~/.claude/ as a flat pile, activated for every session whether relevant or not. AIA introduces the manifest/lockfile pattern (think npm for Claude skills): a curated ~/aia-lib/ library, per-project activation that lands only the relevant resources in ./.claude/, and a CLI that manages it all. The system prompt bloat problem now has a structural solution.

4. The publish-at-speed-of-thought pipeline ran its full loop this week. Gmail MCP for delivery, here.now for static publishing, the teaching-block skill for content packaging, and the AIMM recap pipeline for session distillation — all four pieces were actively used or improved in the same week. Lou talked about this at today’s AIMM session as aspiration; it’s actually description. The infrastructure for distributing R&D output at the moment of completion is now operational.

5. The gap between “deployed agent” and “managed agent” is where most ambient intelligence experiments die. The SOUL.md framework surfaced this week from a Sam Woods analysis and provides the operational governance layer that the AIF architectural spec assumes but doesn’t supply: a five-part agent identity structure, an access scoping doctrine (Day 1 = read-only from sources, write-only to agent output folder — never expand scope and access in the same move), explicit autonomy levels, a Friday Ritual for keeping SOUL.md alive, and a diagnostic table for failure modes. If your SOUL.md looks identical three months after you wrote it, you haven’t been managing the agent. You’ve been using it.

Project Deep Dives

1. Ambient Intelligence Framework v0.4 — Practitioner-Hardening Release ⭐ HIGH MEMBER VALUE

Session: Multiple iterations May 27 — AIF v0.2 comparison, council stress-test, final edits
Output: ~/Downloads/AmbientIntelligence/v0.4/Ambient-Intelligence-Framework-v0.4.md (draft, extends v0.2, sections §24–§31)

The session started from a comparison: the council-generated first-principles PRD against the working v0.2 spec. The comparison surfaced a category of missing primitives — not conceptual gaps, but operational ones. v0.2’s Living Contract (§17–§23) described what a folder-agent could do; v0.4 describes what it’s allowed to do, how it proves it, and what happens if something tries to exceed its scope.

The seven additions in v0.4:

Section	Addition	Why it matters
§25	Hidden `.ambient/` folder layout	Keeps harness infrastructure (state, logs, cache) out of the user’s workspace
§26	Generalized substrate model + `$AMBIENT_PATH`	Cascading capability resolver; one path variable enables cross-folder resource sharing
§27	Four-tier action authorization + append-only log	Every action the agent takes is authorized at a named tier and logged permanently
§28	Typed `interface:` contract with `reads`/`writes`	Binds the agent’s declared intent to MCP Roots — the contract is live filesystem security
§29	Configuration-Based Self-Escalation (CBSE) boundary	Names and forbids the attack vector where a malicious folder claims it has permissions it doesn’t
§30	Standardized use-case shapes + concurrency rules	Composable patterns for the most common deployment configurations
§30	Git-native design principle	Every state transition is a commit; harness state is fully auditable and reversible

The CBSE boundary is the most significant addition. It names the specific threat where a child folder’s CLAUDE.md claims elevated access that its parent didn’t grant. v0.4 makes this explicit: runtime must validate claims against the inheritance chain, not accept self-declarations at face value. This is the moment the framework acquired a security posture.

Versioning note. v0.3 remains reserved for the modifier release (LoRA adapters, activation steering, safety floor). v0.4 proceeded independently — a folder can adopt all of v0.4’s practitioner primitives without ever touching the modifier work. The two tracks can coexist in the same folder cleanly when v0.3 ships.

To use: The v0.4 spec is a draft, not yet a published release. AIMM members tracking the AIF development can read the full spec at ~/Downloads/AmbientIntelligence/v0.4/Ambient-Intelligence-Framework-v0.4.md. The v0.4 extensions are opt-in — any folder running v0.1 or v0.2 is unaffected. To adopt v0.4 for a specific folder, add a .ambient/ folder and an interface: contract block to its AGENTS.md. The spec’s §30 use-case shapes provide the recommended starting patterns.

2. Council Deliberation Framework — PRD Preset ⭐ HIGH MEMBER VALUE

Session: Multiple sessions May 22–23 and May 27–28
Output: ~/.claude/skills/council-deliberation/presets/prd/ (preset directory), test-runs/ambient-intelligence-prd/.council/synthesis/prd-combined.md (council-synthesized PRD), ISSUE-001.md through ISSUE-010.md

The council framework isn’t new — it’s been active since April. What’s new this week is the PRD Preset, which adapts the base council configuration for product requirements work, and the first full test run against a real spec (the Ambient Intelligence PRD).

What the PRD Preset changes:

The base council uses five council roles with equal voting weight. The PRD Preset makes one targeted swap: it replaces the Systems Architect as a standing council member with a Product Strategist. The Architect doesn’t disappear — it becomes a witness, summoned when feasibility or integration cost questions surface during debate. This matters because Architect-shaped thinking (boundaries, coupling, evolution) optimizes for system correctness. Product-shaped thinking (differentiation, timing, lifecycle) optimizes for market fit. PRDs need both, but they need them in different roles.

The preset also adds two issue types to the standard taxonomy:

outcomes — debates about success metrics and what will actually be measured. These need atomic deliberation because metric choice drives both team behavior and user behavior.
prioritization — debates about scope and sequencing. What ships in v1 vs. v2, what gets cut first if capacity shrinks.

The test run results. The council was run against the Ambient Intelligence PRD as a scheduled task. It generated 10 ISSUE files covering identified tensions in the spec, voted on each, and produced prd-combined.md — a synthesis of the council-generated first-principles PRD with the working spec. The synthesis preserved the working spec’s implementation detail while incorporating the first-principles PRD’s cleaner architectural logic in sections where they diverged.

The fact that this ran as a scheduled task — not a manually initiated conversation — is the part worth absorbing. A Claude Code cron job read the PRD, spun up the council, ran the full deliberation protocol, and wrote the synthesis file. No human in the loop. The output is in test-runs/ambient-intelligence-prd/.

To use: The PRD preset is at ~/.claude/skills/council-deliberation/presets/prd/. Copy the preset directory into your project folder, rename briefing-template.md to briefing.md, fill in your PRD’s problem statement and segments, and invoke the council-deliberation skill. The README in dynamic-issue-based-roundtable-council/ walks through both drop-in and inheritance-via-CLAUDE.md setup paths. For a scheduled run, see the SESSION-HANDOFF-council-deliberation-2026-05-26.md file in the repo for the task configuration pattern.

3. AIA — Ambient Intelligence Architecture Resource Inheritance System ⭐ HIGH MEMBER VALUE

Session: May 28 — full v1 implementation day
Output: ~/GitHub/simple-aia-resource-inheritance/aia/ (Python package, 9 files), aia-v1-spec.md (locked spec), aia-user-guide.md, pyproject.toml

Every programmer maintains a library of reusable code. Until this week, Claude users had no equivalent — skills and agents either lived in ~/.claude/ (available to every session, bloating every system prompt) or had to be manually copied into individual project folders (maintenance nightmare). AIA solves this with a three-layer architecture borrowed from package management.

The three layers:

~/aia-lib/          — the exhaustive library. Every skill, agent, command you've authored.
                      Claude never reads from here directly.
                      
~/.claude/          — user scope. Resources activated here appear in every session.
./.claude/          — project scope. Resources activated here appear only in this folder.

Both scopes use the same manifest/lockfile machinery. The library contains everything; activation copies only what each project needs into the relevant .claude/ directory. The interface: contract in v0.4 binds to this — when you activate a skill for a project, its declared reads and writes are enforced by the scope it’s activated into.

The CLI surface:

aia init              # scaffold ~/aia-lib/
aia install <id>      # install a resource from library to current scope
aia activate          # copy installed resources into ./.claude/
aia doctor            # check for cross-scope id collisions, missing lockfile entries

The install → activate chain is intentional. install records the resource in the manifest; activate performs the copy. Running activate alone after a failed install is safe — the lockfile tracks what’s actually in place, not what’s intended to be.

Surface compatibility. The spec is explicit: Claude Code is the primary target with full support. Cowork loads from ~/.claude/skills/ at user scope, so user-scope AIA works there. Project scope in Cowork is unverified — the spec describes a probe procedure (drop a stub SKILL.md in a Cowork-selected folder, check whether it appears in the skills list) that needs to run before relying on it. Claude.ai Chat has no local filesystem access and is out of scope.

The five curated defaults seeded into user-scope on aia init: capture-chat, audit-plan, consolidate-memory, schedule, cognitive-operations. These are the skills that belong in every session, regardless of project context.

To use: The repo is simple-aia-resource-inheritance on the Extreme Pro. The spec (aia-v1-spec.md) is locked for v1 — all design decisions are captured there. The Python package installs via pip install -e . from the repo root. Run aia init to scaffold the library, then aia install skills/article-architecture to test the round-trip with an existing skill. The user guide is at aia-user-guide.md in the repo root.

4. Gmail MCP — HTML Preview Safety Gate ⭐ HIGH MEMBER VALUE

Session: May 25 — targeted fix to advanced-gmail-mcp
Output: Updated advanced-gmail-mcp skill; pre-send HTML preview renders to /tmp/aimm-email-preview.html

The multi-account Gmail MCP setup has been live for a few weeks. This week’s fix addressed the one remaining friction point: before sending an HTML email from within Claude, there was no way to see what it would actually look like in a mail client before it went out.

The fix adds a preview step to the send workflow. When composing an HTML email, the skill now renders the full email body to /tmp/aimm-email-preview.html and opens it in the default browser before the send call fires. The preview is true-to-render — the same HTML that will be sent, viewed in an actual browser tab, not a text approximation. After review, you confirm or abort.

The look-over-my-shoulder documentation session on May 25 also produced a structured 2026-05-25-session-export/ folder in the aimm-shared-repo, containing the full setup guide, conversation recap, teaching block, and artifacts — making the multi-account Gmail MCP setup a fully documented, distributable reference for AIMM members who want to replicate it.

To use: The advanced-gmail-mcp skill is wired into Lou’s Claude Desktop instance and available to his Claude Code sessions. The look-over-my-shoulder documentation is in aimm-shared-repo/look-over-my-shoulder/gmail-mcp-multi-account-setup/. The session export contains a setup-guide.html that walks through the full installation and authentication flow for all accounts.

5. SOUL.md Framework — Ambient Agent Operations Methodology ⭐ HIGH MEMBER VALUE

Session: Cowork daily briefing, May 26 — Sam Woods analysis mapped against SuccessPod/AIMM stack
Output: In-session analysis only; no saved file. The frameworks below are the artifact.

This wasn’t an R&D build session — it was a daily briefing that surfaced a high-signal external framework and mapped it directly against the AIMM stack. The frameworks are concrete enough to act on immediately.

The SOUL.md — five required elements for any deployed agent:

Identity in one sentence — what this agent is for, stated plainly
Scope in 3–5 lines — including explicit don’t do this entries (the omissions are as important as the inclusions)
Hard limits — what it must never produce or claim, stated as prohibitions not guidelines
Tone rules — for any output that leaves the team or reaches a client
Deliverable format — what it produces every time, so every run is comparable

The failure mode: “The first run reads like a fresh chat session instead of like a member of the team, and every correction has to be made one prompt at a time.”

Access scoping doctrine:

Day 1 = read-only from sources, write-only to the agent’s designated output folder. Never expand scope and access in the same move — you cannot isolate whether a failure is in reasoning, access, or instructions if you bundle them.

Autonomy levels — explicit, not assumed:

Level	What it means	Signal to advance
Full review	Every output checked before use	10 consecutive correct outputs
Sample audit	Random 20% spot-check	30 days clean at sample audit
Trusted	Output used directly	Documented track record in review log

The level lives in the SOUL.md header (with a version date). Same SOUL.md after three months = the agent has been used but not managed.

The Friday Ritual: 20 minutes, one owner per agent file, corrections go into SOUL.md or context files — not one-off prompts. Three months in, the SOUL.md should look noticeably different from Day 1.

Diagnostic table:

Symptom	Root cause	Fix
Agent confidently produces wrong output	Scope too broad	Tighten SOUL.md scope
First runs good, output decays over weeks	System prompt drifted	SOUL.md • Friday Ritual
Agent took action it shouldn’t have	Write access too aggressive	Revisit access scoping
Second run worse than first	Contradictory instructions patched in	Rewrite cleanly
Customer-facing miss reached stakeholder	Moved to autonomy too early	Back to full review

SuccessPod/AIMM stack — three agents to build, in order:

AIMM intelligence agent — scans session transcripts, member signals, inbox for AIMM-relevant content; drops weekly digest. Lowest blast radius. Build first.
Brand/content QA agent — reads drafts before publication; flags voice deviations. No write access to published output. Second.
Coaching intelligence layer — reads incoming member communications, session notes, progress markers; surfaces patterns. Read-only, digest output only. Third.

To use: Write the five SOUL.md sections before building anything. The diagnostic table is ready to use as-is — check the symptom column after every agent session for the first month.

Operational Sessions

LKB Vault

AIMM Recap Pipeline — May 22 briefing published to the Weekly Intelligence Briefings hub. May 28 AIMM Mastermind session recap written and published immediately after the session — first time the full pipeline (transcript → recap → Notion publish → prompt command generation → Prompt Library sync) completed in a single automated flow within hours of the session ending.

LKB Maintenance — Standard lint and cleanup passes (May 22). Vault state current: 46 sessions, 159 insights, 61 article briefs, 20 skills, 44 commands.

GEO / GEARS Client Work

GEARS gears-latest — Active work on the gears-latest folder (May 25) and archives (May 22). Ongoing GEARS platform maintenance and client schema work.

GIC LEAP

GIC LEAP Growth Strategy — One session May 24, project initialization and spec work. Status: early stage.

Assets Available This Week

Asset	Description	Status
AIF v0.4 spec (draft)	Practitioner-hardening release — §24–§31, security model, action authorization, CBSE boundary	In `~/Downloads/AmbientIntelligence/v0.4/`
AIA Python package + spec	Resource inheritance CLI for Claude skills — manifest/lockfile/activate pattern	In `simple-aia-resource-inheritance` repo; `pip install -e .`
Council PRD Preset	Adapted deliberation configuration for PRD work — Product Strategist swap, outcomes/prioritization issue types	In `~/.claude/skills/council-deliberation/presets/prd/`
Council AIF test-run outputs	10 ISSUE files + prd-combined.md synthesis from live AIF PRD deliberation	In `council/test-runs/ambient-intelligence-prd/.council/synthesis/`
Gmail MCP HTML Preview	Pre-send email preview rendered to browser — HTML only	Live in advanced-gmail-mcp skill
Gmail MCP Look-Over-My-Shoulder	Full setup guide, session export, teaching block for multi-account Gmail in Claude	In `aimm-shared-repo/look-over-my-shoulder/gmail-mcp-multi-account-setup/`
ARF v1 spec + CONTEXT.md	Parallel resource framework spec from Cowork — same concept as AIA, needs reconciliation before build	In Cowork session output; move to ~/Documents/ARF/
SOUL.md framework	5-part agent identity, access scoping, autonomy levels, Friday Ritual, diagnostic table	In-session only; frameworks in Deep Dive 5 are the reference

Watch List — Developing Threads

AIA/ARF naming convergence — Two parallel v1 specs locked independently on May 28 (AIA in Claude Code, ARF in Cowork) for the same concept with different manifest paths (~/.ambient/aia.yaml vs ~/.arf/arf.yaml). Must reconcile before any build. One name, one path.
SOUL.md bootstrap — Three concrete agents to build (intelligence agent, brand QA agent, coaching intelligence layer). Write each SOUL.md before the build session. Intelligence agent is first — lowest blast radius, highest signal value.
AIF v0.3 (modifiers) — Deferred: LoRA adapter deltas, activation steering, safety floor. v0.4 can coexist with v0.3 when it ships; no blocking dependency either direction.
AIA Cowork project-scope probe — Project-scope AIA behavior in Cowork is unverified. Probe: drop a stub SKILL.md in a Cowork-selected folder, check whether it surfaces in a fresh session’s skill list. Result determines whether AIA is user-scope-only for Cowork users.
AIA library bootstrap — aia init scaffolds the structure; the first real inhabitants (article-architecture, audit-plan) need to be ported from ~/.claude/skills/ to ~/aia-lib/ to demonstrate the full round-trip.
Council: additional presets — PRD preset is done; the architecture review and strategy planning use cases are obvious next candidates given the council framework’s existing expert roster.
here.now index ordering — No timestamps in the current index; teaching blocks from related sessions aren’t grouped. Fix: rebuild index grouped by teaching block cluster so members can follow the article-to-skill evolution in order.
AIF v0.4 status: draft — Not yet a published release. Pending final review pass before the v0.4 tag is applied.

Generated from active Claude Code sessions — May 21–28, 2026.
Compiled for AIMM members.