Antoine
cf82de4f06
- Project plan, agent roster, architecture, roadmap - Decision log, full system plan, Discord setup/migration guides - System implementation status (as-built) - Cluster pivot history - Orchestration engine plan (Phases 1-4) - Webster and Auditor reviews
234 lines
11 KiB
Markdown
234 lines
11 KiB
Markdown
|
|
# 📋 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: Agent Self-Maintenance (Mario Bootstraps, Agents Own)
|
|
|
|
**Date:** 2026-02-08
|
|
**Status:** ✅ Accepted
|
|
**Proposed by:** Mario + Antoine
|
|
|
|
**Decision:** Mario (Clawdbot main) handles **initial bootstrap only** — gateway config, Slack bindings, workspace scaffolding, shared skills, connection points (Syncthing job queue). After bootstrap, agents are **fully self-maintaining**:
|
|
- Agents evolve their own SOUL.md, AGENTS.md, TOOLS.md, MEMORY.md
|
|
- Agents manage their own cron jobs, heartbeats, workspace organization
|
|
- Agents install tools, update skills, self-improve from mistakes
|
|
- Agents update their own protocols as they learn
|
|
|
|
**Mario's ongoing role:** Peer/advisor, not infrastructure owner. Only retains oversight on shared system resources (T420 disk, ports, CPU) since both Clawdbot instances share hardware.
|
|
|
|
**Analogy:** Mario is the contractor who builds the house. Once the agents move in, they maintain it, decorate it, expand it. They get the keys and run their own shop.
|
|
**Rationale:** Autonomy is the whole point. If Mario does all infrastructure work, agents are puppets, not autonomous entities. The Atomizer Clawdbot should be as self-directed as Mario's own instance.
|
|
|
|
---
|
|
|
|
## DEC-A016: Delegation via Skill Script (Not SOUL.md Instructions)
|
|
|
|
**Date:** 2026-02-14
|
|
**Status:** ✅ Accepted
|
|
**Proposed by:** Mario + Antoine
|
|
**Context:** Gemini Review 2 recommended a TypeScript skill; Mario initially proposed raw curl in SOUL.md; Antoine pushed back.
|
|
|
|
**Decision:** Build a bash wrapper script (`delegate.sh`) as a shared skill. Manager and Tech Lead get the skill; other agents cannot delegate (must request via Manager/Tech Lead).
|
|
|
|
**Alternatives rejected:**
|
|
- **Raw curl in SOUL.md** — fragile, agents hallucinate ports/headers, no error handling
|
|
- **TypeScript skill** (Gemini's proposal) — overcomplicated for our stack, we don't need npm modules for a curl wrapper
|
|
- **No delegation** — the entire cluster is useless without inter-agent communication
|
|
|
|
**Rationale:** A bash script gives consistency (hardcoded port map, auth), error handling (checks if target is running), and simplicity (no build step, no dependencies). Agents just call `delegate.sh <agent> "<task>"`.
|
|
|
|
---
|
|
|
|
## DEC-A017: Manager as PROJECT_STATUS.md Gatekeeper (Not Secretary)
|
|
|
|
**Date:** 2026-02-14
|
|
**Status:** ✅ Accepted
|
|
**Proposed by:** Mario + Antoine
|
|
**Context:** Gemini Review 2 proposed Secretary as gatekeeper. Antoine and Mario discussed.
|
|
|
|
**Decision:** Manager is the sole writer of `PROJECT_STATUS.md`. All other agents append status updates to `project_log.md` (append-only). Manager periodically synthesizes the log into the status file.
|
|
|
|
**Why not Secretary:** Secretary runs Haiku (cheapest model) — lacks the technical understanding to properly summarize status. Manager already has the big picture and receives all reports.
|
|
|
|
**Why not "no gatekeeper":** While we don't have concurrency issues yet, establishing the pattern early prevents problems when traffic increases. Single writer = no merge conflicts.
|
|
|
|
---
|
|
|
|
## Pending Decisions
|
|
|
|
*No pending decisions at this time.*
|
|
|
|
---
|
|
|
|
*Created: 2026-02-07 by Mario*
|