--- tags: - Project/Atomizer - Agentic - Decisions up: "[[P-Atomizer-Overhaul-Framework-Agentic/MAP - Atomizer Overhaul Framework Agentic]]" date: 2026-02-07 status: active --- # πŸ“‹ Decision Log β€” Atomizer Overhaul: Framework Agentic --- ## DEC-A001: Use Clawdbot Multi-Agent (Not Custom Framework) **Date:** 2026-02-07 **Status:** 🟑 Proposed (awaiting Antoine's review) **Proposed by:** Mario **Options Considered:** | Option | Pros | Cons | |--------|------|------| | A) Clawdbot Multi-Agent | Already running, Slack native, proven patterns, per-agent isolation | Tied to Clawdbot's architecture, some multi-agent features still maturing | | B) Agent Zero | Designed for multi-agent | Less mature, no Slack native support, would need integration | | C) CrewAI | Purpose-built for agent teams | Limited isolation, less flexible memory, Slack needs adapters | | D) Custom Framework | Full control | Massive build effort, reinventing wheels | **Recommendation:** Option A β€” Clawdbot Multi-Agent **Rationale:** We already have a running Clawdbot instance with Slack integration. Multi-agent routing is a built-in feature. The infrastructure exists; we just need to configure it. Building from scratch would take months and delay the actual value. --- ## DEC-A002: Phased Rollout (Not Big Bang) **Date:** 2026-02-07 **Status:** 🟑 Proposed **Proposed by:** Mario **Decision:** Start with 3 agents (Phase 0), scale to 12 over 10 weeks. **Rationale:** Risk of over-engineering. Multi-agent coordination has emergent complexity β€” better to discover issues with 3 agents than debug 12 simultaneously. --- ## DEC-A003: Manager as Communication Bottleneck **Date:** 2026-02-07 **Status:** 🟑 Proposed **Proposed by:** Mario **Decision:** Only the Manager initiates cross-agent work in project channels. Other agents respond when @-mentioned, but don't independently reach out to each other. **Rationale:** Prevents "agent storm" where agents endlessly ping each other. Manager maintains control and traceability. This can be relaxed later if agents prove reliable. --- ## DEC-A004: Single Gateway, Multiple Agents **Date:** 2026-02-07 **Status:** 🟑 Proposed **Proposed by:** Mario **Decision:** Run all agents on one Clawdbot gateway process. **Rationale:** Simpler to manage, enables `sessions_send` between agents, single config. Can split later if resources demand it. --- ## DEC-A005: Model Tiering Strategy **Date:** 2026-02-07 **Status:** ❌ Superseded by DEC-A008 **Proposed by:** Mario **Original Decision (superseded):** Tiered model approach with older models. **Replaced by:** DEC-A008 β€” use latest models (Sonnet 5, GPT-5.3-Codex, Gemini 3.0). **Rationale still valid:** Cost optimization via tiering. Not every role needs Opus 4.6. Match model capability to role complexity. --- ## DEC-A006: Dedicated Slack Workspace **Date:** 2026-02-07 **Status:** βœ… Accepted (Antoine's request) **Proposed by:** Antoine **Decision:** Create a dedicated Slack workspace for Atomizer Engineering β€” separate from Antoine's personal workspace. **Rationale:** This is a product. Antoine will make videos, demos. Needs to look professional and clean. No personal channels mixed in. Each agent gets proper identity with avatar + name. --- ## DEC-A007: Study Builder Agent (Separate from Optimizer) **Date:** 2026-02-07 **Status:** βœ… Accepted **Proposed by:** Antoine + Mario **Decision:** Add a Study Builder agent that writes the actual Python code (run_optimization.py), separate from the Optimizer who designs the strategy. **Rationale:** Optimizer designs, Study Builder implements. Clean separation. Study Builder can use a coding-specialized model (GPT-5.3-Codex). Code must run on Windows with NX. --- ## DEC-A008: Use Latest Models (Sonnet 5, Codex 5.3, Gemini 3.0) **Date:** 2026-02-07 **Status:** βœ… Accepted **Proposed by:** Antoine **Decision:** Use cutting-edge models: Opus 4.6 for reasoning, Sonnet 5 (when released) for technical work, GPT-5.3-Codex for code generation, Gemini 3.0 for research. **Rationale:** This is a showcase product. Use the best available. Architecture is model-agnostic β€” swap models via config. --- ## DEC-A009: Autonomous with Approval Gates **Date:** 2026-02-07 **Status:** βœ… Accepted **Proposed by:** Antoine **Decision:** Agents are maximally autonomous for routine work but require Antoine's approval for: new tools/features, divergent approaches, client deliverables, scope changes, framework modifications. **Rationale:** Balance between efficiency and control. Antoine doesn't want to micromanage but needs to steer. Secretary learns what to escalate over time. --- ## DEC-A010: Framework Steward = Manager Sub-Role **Date:** 2026-02-07 **Status:** βœ… Accepted **Proposed by:** Mario **Decision:** The Manager agent also serves as Framework Steward β€” ensuring the Atomizer framework evolves properly, learnings are captured, and protocols improve over time. Not a separate agent. **Rationale:** Avoids agent bloat. Manager already has the visibility across all projects. Framework evolution is a management responsibility. --- ## DEC-A011: Windows Execution β€” Syncthing + Manual Script Launch **Date:** 2026-02-08 **Status:** βœ… Accepted **Proposed by:** Mario | **Decided by:** Antoine **Decision:** Syncthing delivers job files to Windows. Antoine runs `run_optimization.py` manually to kick off the full iteration loop. The script handles all iterations autonomously (NX solve β†’ extract β†’ evaluate β†’ next trial). No SSH/API needed for Phase 1. **Rationale:** Matches existing Atomizer workflow. Simple, reliable. Can upgrade to remote exec later if manual trigger becomes a bottleneck. --- ## DEC-A012: Separate Clawdbot Gateway (Docker) **Date:** 2026-02-08 **Status:** βœ… Accepted **Proposed by:** Mario | **Decided by:** Antoine **Decision:** Atomizer gets a **separate Clawdbot gateway** running in Docker on the T420. Mario's personal Clawdbot stays native (systemd). Eventually, Atomizer moves to a dedicated machine. **Rationale:** Complete isolation β€” independent config, Slack workspace, restarts. Mario's personal assistant is unaffected. T420 is the incubator, not the final home. **Note:** Docker is not yet installed on T420 β€” needs to be set up before Phase 0. --- ## DEC-A013: Single Bot with Per-Agent Identity **Date:** 2026-02-08 **Status:** βœ… Accepted **Proposed by:** Mario | **Decided by:** Antoine **Decision:** Single Clawdbot Slack bot app managing all agents. Each agent has its own name, emoji, and personality via Clawdbot's identity system. The UX should feel like interacting with individual people β€” organic, @-mentionable β€” even though one process orchestrates everything behind the scenes. **Rationale:** Don't over-complicate the plumbing. One "god" process, but the Slack experience feels like a real team. Implementation simplicity with great UX. --- ## DEC-A014: KB Agent β€” Semi-Auto Ingestion + Inherited CAD Documenter Skill **Date:** 2026-02-08 **Status:** βœ… Accepted **Proposed by:** Mario + Antoine **Decision:** Semi-automatic β€” KB Agent flags new CAD Documenter output, Antoine approves before ingestion. The skill architecture uses inheritance: - **Base layer:** General Atomaste CAD Documenter skill (lives in Mario's workspace) β€” whisper transcription, frame extraction, engineering KB - **Atomizer layer:** KB Agent over-specializes with Atomizer-specific behaviors β€” auto-tagging part numbers, linking to optimization studies, extracting FEA parameters, feeding into LAC system The general skill remains a broad Atomaste tool; Atomizer's version adds domain-specific intelligence on top. **Rationale:** CAD Documenter is too valuable to lock inside Atomizer. Keep the general tool for all Atomaste work; let Atomizer extend it. --- ## DEC-A015: Nightly Memory Digestion (β€œRestore β†’ Sort β†’ Dream β†’ Resolve”) **Date:** 2026-02-12 **Status:** βœ… Accepted **Proposed by:** Manager | **Decided by:** Antoine **Decision:** Adopt the nightly memory methodology (Restore β†’ Sort β†’ Dream β†’ Resolve), run automatically at **00:00 America/Toronto**, and post the brief to **#all-atomizer-hq**. **Rationale:** Ensures daily work compounds into durable memory + actionable next steps, while preventing noise from polluting long-term context. --- ## Pending Decisions *No pending decisions at this time.* --- *Created: 2026-02-07 by Mario* --- ## DEC-2026-02-16-A: Lightweight Bracket Material Selection - **Date:** 2026-02-16 - **Project:** Lightweight Bracket - **Decision:** Prioritize structural performance over thermal management, cost, or weldability. - **Outcome:** Selected **7075-T6 Aluminum** for the next design and optimization phase. - **Rationale:** Directive from CEO. - **Status:** Decided.