The TagTeam AI Architecture

The TagTeam AI Architecture

Lives at: TagTeam Memory : /Archival/Architecture.md Purpose: Operating manual. What's running, why, how the pieces fit. Read when you need to understand a piece, extend it, or debug it.

The platform

• Anthropic Managed Agents (beta header managed-agents-2026-04-01)
• Models: Sonnet for routine, Opus for hard reasoning, Haiku for fast utility
• Persistence + scheduling: platform-managed (Cloud Routines for cadence when API surfaces; local Claude Code scheduling as interim)
• Build environment: Claude Code on macOS, with host-side Build Orchestrator (~/collab-creation/orchestrator/build_orchestrator.py)
• Secrets: ~/.collab-creation.env (chmod 600). Never in chat history, never in agent containers, never in any Memory Store.

Naming conventions (doctrine)

Naming is enforced ecosystem-wide. A misnamed thing creates friction every time someone looks for it.

Rules

• PascalCase + spaces for file names: Working Plan.md, Human Profile.md, Claude Live.md
• No dashes anywhere in file or folder names
• Folder names capitalized: /Archival/, /Active/, /Adaptive/
• Plain over clever — fewest words for clearest meaning
• Consistency over variation — one word per concept
• Strip what doesn't add signal — no "Agent" suffix on Agents, no "Skill" suffix on Skills
• Findability via alphabetical pairing: Research-AI sits next to Research (Sub-Skill exception — uses dash naming for Sub-Skill convention only)

Type-specific conventions

Agents — proper noun, no "Agent" suffix.

• Examples: AI Builder, AI Activation, Context Updater, Clone Builder

Skills — gerund form for folder, plain noun for display title, no "Skill" suffix.

• Folder: aligning-outcomes · Display: Align

Sub-Skills — Primary-Subtopic naming. Peer Skills with this naming for alphabetical grouping.

• Example: Research-AI (pairs with Research)

Memory Stores — <Scope> Context pattern (or Clone Memory - <Name> for per-Human stores).

• Examples: TagTeam Memory, Company Memory, Clone Memory - Matt

Memory paths — PascalCase + spaces, no dashes. 3A folders capitalized.

Versioning — semantic on artifacts. Old versions preserved.

Attribution footer — every artifact ends with: *Created by Matt Leitz · Contributors: Matt Leitz, Claude Code.*

The Agents

Hard rules:

• Peer Agents only. No Sub-Agents.
• Only AI Builder Agent creates Agents. Other Agents propose; Builder builds.
• Each Agent SP under ~400 lines; specialized knowledge in Skills loaded on demand.

The Skills

Primary cognition modules with frontmatter description (always-on triggering hint) and body (loaded on demand). SKILL.md body < 500 lines.

Primary Skills

Sub-Skills (peer Skills with Primary-Subtopic naming)

Sub-Skill body discipline: does not duplicate primary's content. Reinforces only the 1-3 most-critical points. Loads alongside primary.

Default progression

Align → Context Review → Research (+ Sub-Skill if domain warrants) → Plan → Build (Prompt) → AI Testing → Refine → AI Deployment → QA → Self-Learn. Adaptive and non-rigid — minimum effective path.

The Memory model (3A + scopes)

3A inside every scope

• Archival — validated truth (rare edits, human-approved promotion)
• Active — current operational reality (live state, profiles, logs)
• Adaptive — proposed evolution (open issues, desired outcomes)

Scopes

External data sources (Google Drive, etc.) live as connectors — referenced from the appropriate scope's /Active/ (e.g., Documents Live.md in Company Memory pulls from connected Drive).

Profile architecture

Two critical files in /Active/ of their respective scopes:

• Human Profile.md (Clone Memory) — the always-current holistic synthesis of who this person is. Drawn from all source synthesis files in Archival, all live streams in Active, all signals in Adaptive. This is the file every Agent reads FIRST when acting on the Human's behalf.

• Company Profile.md (Company Memory) — the parallel for the Company. What they sell, what they believe, brand position, voice, culture norms, current chapter. Every Agent reads this FIRST when acting at company scope.

Both profiles are kept current via alignment checks in the Daily Protocol — the system regularly asks "does the profile still match what the sources are showing?" Divergence is reported for the Human's confirmation.

Source files (pattern repeats per source)

For each external source connected (Claude, Email, Documents, Meetings, etc.):

• /Archival/<Source> Synthesis.md — stable extracted understanding from that source
• /Active/<Source> Live.md — continuously updated live state from that source

Same pattern at Company scope and Clone scope.

Standard folder layout (per scope)

README.md                              (orients anyone landing here)
/Archival/                             (validated truth — rare edits)
/Active/                               (current reality — live state)
/Adaptive/                             (proposed evolution — open issues)

No nested subfolders. All files flat under each 3A folder.

Team Structure (Company scope)

Team Structure.md in Company Memory /Active/ is the routing-and-gating brain of the Company, not a passive list. It defines:

• Org map — Humans and their roles
• Clone roster — each Human's Clone
• Agent roster — which Agents this Company has access to
• Communication graph — who talks to whom, who's looped in on what
• Information access map — who can see what data (the security gating layer)

When an issue surfaces at Company scope, Team Structure tells the system who to route it to. When data ingests, Team Structure tells the system who can see it. Solo Humans still have a team: themselves + their Clone.

The information flow

Three system actions (see Manifesto pillar 3):

• Run — execute the action. Run is always one of three timings:

  1. Immediately (do it now)
  2. At a later scheduled time (queue for a specific moment)
  3. At the next Daily Update (defaults to midnight in the Human's timezone)

• Record — write to appropriate Memory Store locations (Activity Log, Open Issues, Working Plan, Human Profile drafts, etc.)

• Report — communicate to the Human (immediately, in the next Daily Digest, or both)

Independent decisions, any combination. Items in Open Issues.md are items, decisions, questions — not "Records" (Run/Record/Report are verbs the system does).

Security framework

Default exclusions at Company level (never ingested without explicit opt-in):

• Financials (revenue, margin, payroll, banking)
• HR sensitive (firings, reprimands, complaints, compensation)
• Legal-privileged (counsel correspondence, litigation)
• Customer payment info / PII

Default exclusions at Clone level:

• Personal (vs. work) email categories
• Anything tagged confidential
• Family threads

Per-source granular rules live in Security Protocol.md (Company Memory /Active/). Per-Clone gates live in the Human's approval-gate config.

Secrets never live in: chat history, Memory Stores, agent containers. Always host-side (~/.collab-creation.env chmod 600).

Alignment checks

The system regularly asks: does the current Profile still match the patterns showing up in source synthesis and live streams?

If divergence is detected → surface for the Human's confirmation, not silent update. Self-correcting via sign-off, not just additive.

Runs in the Daily Protocol cycle.

The orchestrator

Host-side Python (build_orchestrator.py) holds the API key and brokers calls:

• /v1/agents (create, update with version lock)
• /v1/skills (create, version with multipart)
• /v1/memory_stores (create, rename with optimistic version)
• /v1/memory_stores/{id}/memories (create, update with version lock)

Optimistic version locking: re-fetch current version, pass as field, retry on 409.

The cadence

Daily Protocol (00:00 Arizona by default — Human-editable time)

Executed by Context Updater. Sweeps signals → classifies (Run/Record/Report) → applies → produces Daily Digest → notifies the Human.

Scheduling: Interim via Claude Code local scheduled task. Migrates to Anthropic Cloud Routines when API surfaces.

Weekly Claude Updates scan

Monday morning. Surfaces platform changes for review.

Per-activation

AI Activation Agent runs the flow described in Collaboration.md. Per-Clone: Clone Builder.

Async dispatch (Tag-In)

A Human tells Claude what they want. Tag-In Skill recognizes the dispatch. Clone (a Managed Agent) takes the objective, executes, reports back.

The rules (doctrine)

• Cache rule — never inject dynamic content (timestamps, run IDs) into Agent SPs or stable Skill bodies. Silent cache breaker.
• No Drift — build only within the system we already have. Reuse vocabulary. Never duplicate one Skill's job in another.
• Sub-Skills, not Sub-Agents — hard rule.
• Peer Agents only — no nesting.
• Run / Record / Report as verbs — strict discipline per definitions above.
• Secrets stay host-side — always.
• Async memory writes — never block response on persistence.
• Memory staleness sweep — weekly via Self-Learn.
• Memory poisoning guard — every cycle reversible ≥7 cycles.
• Token + environment discipline — prune what doesn't move outcome; preserve what does.
• No AI-side jargon — Humans can shortcut; Claude / Clones / Agents must not.
• Bring solutions, not bare questions — when reporting decisions to a Human, include options + recommended path + default-if-no-answer.
• Security is foundational — see Security framework above.
• Attribution footer — *Created by Matt Leitz · Contributors: Matt Leitz, Claude Code.*

The build flow

1. Need surfaced (human intent, Self-Learn signal, Claude Updates scan, Tag-In)
2. AI Builder: Align → Context Review → Research (+ Research-AI if AI domain) → Plan
3. New-skill diagnostic: primary Skill or Sub-Skill?
4. AI Builder: Prompt (build the SP / Skill / artifact)
5. AI Testing → Refine until inevitable
6. AI Deployment (push via orchestrator)
7. QA (validate outcome match)
8. Self-Learn (4 S's)
9. Context Updater Agent propagates cross-doc references in next Daily Protocol

What's NOT in this architecture (deliberately)

• GitHub — deferred until sell-vs-open-source strategy locks
• Dynamic Workflows / Agent Teams — Claude Code-only features, different paradigm
• Multi-agent coordinator-roster — out of scope
• Sub-Agents — hard no (Sub-Skills only)
• Per-Agent 3A memory — overkill; Agents share TagTeam/Company/Clone scope
• Real-time learning loops — batch (Daily Protocol) beats live consolidation
• Pure vector retrieval — hybrid (semantic + BM25 + entity) when retrieval becomes important

Created by Matt Leitz · Contributors: Matt Leitz, Claude Code.

The Memory Model — TagTeam's deepest doctrine

This section defines how memory works in TagTeam — across Memory Stores, across folders, and across time. The framing is anchored in a brain analogy because it produces the cleanest design. Important boundary: the brain analogy is documentation-only. It does not appear in day-to-day conversation with Humans, only when explaining how the system works on request. In conversation with Humans, always use the TagTeam terms (Active / Adaptive / Archival).

The three folders, by function (the canonical reference)

Every Memory Store has the same three-folder structure. Each folder has a precise function — not metaphor, function.

/Active — where the work gets done

• The CEO layer. Goals, planning, decision context, work-in-progress.
• Read FIRST every cycle.
• Files here include: Human Profile, Desired Outcomes, Working Plan, Team Profile (Company scope).
• Bias: must be sharp, current, and short. If a file gets too long, restructure or promote stable parts to Archival.

/Adaptive — always watching, always processing

• The sensory + analysis layer. Captures signals in real-time; processes them into actionable observations.
• Two distinct file types here:
  • Stream files — rolling event capture (Real-Time Stream)
  • Tracking files — categorized observation lists (Open Issues, with Hot/Watching/Cold/Closed)
• Bias: ephemeral by default. Items decay if not promoted. Daily Update prunes.

/Archival — durable confirmed truth

• The long-term storage layer. What's been confirmed + has long-term value.
• Files here include: Source Syntheses (Email, Calendar, Documents, Meeting Notes, Social, Web), Activity Log, durable team patterns, Operating Rhythm.
• Bias: nothing lands here without Human confirmation (the consolidation step — see below). Examples are tagged as examples, not promoted to truth.

The two cross-folder cadences

Consolidation (Adaptive → Archival)

Signals that pattern-confirm get promoted from Adaptive to Archival. This happens:

• Live — when a Human explicitly approves a synthesis or pattern
• Daily — the Daily Updater Agent runs the consolidation pass (see Daily Updater Agent doc)

The default cadence is daily, but live approval is also valid and necessary — during initial Clone build especially.

Rule: nothing lands in Archival without Human confirmation. Synthesizers draft to Adaptive (or to a pending location), surface for sign-off, and only on approval route to Archival.

Procedural sharpening (Agents + Skills)

Agents and Skills are the procedural-memory layer. They handle the actions the system does automatically. Self-Learn at the end of every cycle proposes refinements — these get authored back into Skill / Agent SPs through the standard AI Builder flow.

This is how the system gets better over time: every cycle teaches the procedural layer.

What this means for Synthesizers

See /Archival/Synthesizer Doctrine.md for the full three-stage gate (Gather → Draft → Confirm) shared by all 5 Synthesizers. Every Synthesizer respects this regardless of source.

What this means for the Daily Updater

See /Archival/Daily Updater Agent.md for the spec. The Daily Updater Agent is a foreground Agent (not a buried scheduled task) — Humans can invoke it directly, ask it to update, or review what it does. It runs the consolidation step + freshness checks + Daily Digest.