8.7 KiB
tags, up, date, status
| tags | up | date | status | |||
|---|---|---|---|---|---|---|
|
P-Atomizer-Overhaul-Framework-Agentic/MAP - Atomizer Overhaul Framework Agentic | 2026-02-07 | 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.