Why
Moel dropped a scattered but strong set of constraints in Slack. This issue turns that into a single discussion packet and executable todo thread.
Core thesis
We should design this as a first-principles company substrate, not as a bundled AI chat product.
Key constraints:
- CLI must be atomically decomposed.
- Data must be atomically decomposed so compositions can change without forced migrations.
- Compound loop and reflection pipeline must be explicit.
- CEO / chief / lead / worker role allocation must be encoded.
- Repo consolidation and rename planning should be intentional.
DECISION.md should exist near code boundaries so future models can rebuild from design intent.
- Backup / rollback plan is mandatory.
Drafts added locally
DECISION.md
docs/company-os-schema-draft.md
specs/action-primitives.schema.json
specs/memory-state-machine.yaml
specs/persona-object.schema.json
specs/compound-event-engine.yaml
Proposed todo breakdown
0. Alignment
1. Primitive layer first
2. Storage and migration boundary
3. CLI decomposition
4. Org / approval model
5. Compound loop / retrospection
6. Repo consolidation and naming
7. Reliability
Socratic gap checks
- What is the smallest irreversible mutation?
- Which facts are canonical vs cached views?
- What should still work if UI disappears?
- Which commands are secretly doing more than one thing?
- Which memory promotions would become harmful if automated?
- Where are we still designing around Slack instead of around company primitives?
- Which decisions truly need CEO approval?
- What must be preserved so a better future model can rebuild the system?
Munger-style failure paths
- beautiful concept map, weak machine-readable substrate
- persona devolves into fancy prompts
- compound loop devolves into hoarding
- repo merge creates a confused monolith
- approval model stays implicit
- reflection remains notes-only and changes nothing
- rename breaks continuity
Suggested owners
- CEO: strategy, rename, consolidation, irreversible policy approval
- Chief architect: primitive boundary integrity
- Platform lead: event substrate, approvals, persona runtime contract
- Data lead: canonical schema, additive migration strategy, backup portability
- CLI lead: command decomposition and composability
- Learning-loop lead: reflection, promotion, contradiction handling
- PM/operator: todo routing and consensus packetization
Mentions needed
I think this now needs owner assignment + argument on:
- repo strategy
- primitive-first sequencing
- compound loop implementation surface
- rename timing
- backup expectations
@moel-kim please assign the right people to debate each section, especially whoever should own data boundary / CLI decomposition / learning loop.
Why
Moel dropped a scattered but strong set of constraints in Slack. This issue turns that into a single discussion packet and executable todo thread.
Core thesis
We should design this as a first-principles company substrate, not as a bundled AI chat product.
Key constraints:
DECISION.mdshould exist near code boundaries so future models can rebuild from design intent.Drafts added locally
DECISION.mddocs/company-os-schema-draft.mdspecs/action-primitives.schema.jsonspecs/memory-state-machine.yamlspecs/persona-object.schema.jsonspecs/compound-event-engine.yamlProposed todo breakdown
0. Alignment
agenthubstays the engine name or becomes umbrella product name1. Primitive layer first
2. Storage and migration boundary
3. CLI decomposition
4. Org / approval model
5. Compound loop / retrospection
daangn-work-endandkromakey-work-endpattern explicitly6. Repo consolidation and naming
7. Reliability
Socratic gap checks
Munger-style failure paths
Suggested owners
Mentions needed
I think this now needs owner assignment + argument on:
@moel-kim please assign the right people to debate each section, especially whoever should own data boundary / CLI decomposition / learning loop.