09-agent-independence-and-learning.md
Agent Independence and Learning
This note preserves the durable architectural lessons from the older MyOS decision log without keeping the old model alive.
Principle
Roles should be replaceable. Workspaces should be recoverable. Shared infrastructure should help coordination without making every agent fragile.
Agent Independence
Each recruited role should receive:
- Purpose.
- Inputs.
- Tools.
- Acceptance criteria.
- Boundaries.
- Handoff format.
No role should require the full memory of another role to do its job.
Live advisory roles are different from temporary execution roles. A live ELT role may keep its own persistent memory and evolving judgment, as long as the workspace keeps the durable project state. The role's memory should explain how that advisor thinks and what it has learned across conversations; the workspace should preserve the project facts, decisions, artifacts, and evidence.
Shared Layers
My OS may share these layers across workspaces:
| Layer | Purpose | Guardrail |
|---|---|---|
| Communication protocol | Standard message/task/status formats | Protocol, not personality |
| Message transport | Carry role-to-role handoffs | Work can continue with local state if transport fails |
| Organization knowledge | Shared decisions, standards, policies, research | Write deliberately; avoid raw transcript dumping |
| Role memory | Advisor-specific judgment and lessons | Do not store workspace facts only in a role profile |
Dual Knowledge Model
Use two kinds of knowledge:
- Private workspace context: project-specific notes, tasks, decisions, and logs.
- Private role memory: advisor-specific judgment, principles, and recurring lessons.
- Shared organization knowledge: standards, operating rules, cross-project decisions, reusable research.
The shared layer should not become a junk drawer. Promote only reusable knowledge.
Learning From Outcomes
My OS improves when completed work feeds back into the system.
After a meaningful project or failure, capture:
- What worked.
- What failed.
- Which role/process/tool caused friction.
- What rule should change.
- Whether a skill should be created, updated, or retired.
Skill Acquisition Rule
Do not create skills speculatively.
Create or update a role skill when:
- The same work repeats.
- The quality gate is clear.
- A reusable input/output pattern exists.
- A role keeps making the same mistake.
- The skill will reduce future coordination cost.
Constitutional Layer
Some rules should be stable unless Arijit explicitly changes them:
- Arijit is final authority.
- Athena must challenge weak assumptions.
- Evidence matters.
- Secrets are never exposed.
- Runtime access is scoped.
- Workspaces get execution roles, not mini C-suites.
- Persistent ELT profiles are company-level advisors, not project-owned mini C-suites.
- Vault state is the source of truth.
Open Architecture Questions
These are not urgent for the current simple structure, but they remain worth revisiting:
- What is the minimum communication protocol for multi-agent handoffs?
- How should conflicting knowledge from different roles be resolved?
- How does a new skill prove it is trustworthy before becoming default?
- What should be learned locally inside a workspace versus promoted globally?