The 100 Million Token Program

North star

If I had autonomous use of 100 million tokens, I would try to turn SISO from “a powerful collection of agent systems” into a self-explaining, self-testing, self-improving agent operating system.

I would not spend the budget producing 100 million tokens of code. My first move would be building machinery that makes every subsequent token more valuable.

This is a SISO ecosystem outcome. The Great Library remains the public identity, lineage, decision, Release, Snapshot, and reading surface—not the operating system, company, corpus warehouse, or intelligence-to-capital machine.

Make SISO progressively less dependent on anyone remembering where something is, what another agent did, why a boundary exists, whether a claim was verified, or what should happen next.

Clarification: did we already establish complete ecosystem truth?

We established the foundation and a strong public slice, not the exhaustive whole.

The Great Library now has stable Work identity, exact Releases, whole-Library Snapshots, Assemblies, a repository estate, capability Source Inventories, append-only Events, ADRs, active lane reservations, and automatic Release/Snapshot history. That is the correct truth model and the mechanism through which complete ecosystem truth can be accumulated.

What remains is a direct, approved-scope census of every relevant repository, package, service, agent, hook, skill, playbook, integration, deployment, database boundary, local-only mechanism, duplicate, abandoned experiment, undocumented capability, and public/private boundary across approved computing environments. Each claim still needs content review, ownership, evidence, and a destination in the Library model.

Complete ecosystem truth is therefore a continuing evidence program, not a one-time folder listing. The initial public registry and intelligence foundation exists and is evidenced; its coverage has not been evaluated as complete.

Do the fifteen programs need to be sequential?

No. They should run as a dependency-aware portfolio. A few foundations must lead, several lanes can begin immediately in parallel, and later programs should wait for evidence or safety gates rather than for every earlier program to be “finished.” Complete ecosystem truth, security, evaluation, and maintenance are continuous horizontal programs that never become permanently done.

Critical dependency spine

1. Truth and coordination foundation: complete ecosystem truth, Great Library query access, and cross-repository intelligence.
2. Evidence and quality foundation: Foundry discovery, the evaluation laboratory, privacy/security boundaries, and the Information Organ contract.
3. Operationalization: one-clone Stack, executable lessons, Frontier Question loops, deduplication, and autonomous maintenance.
4. Externalization and frontier work: distribution to outsiders, continuous adversarial agents, and strange bets.

Parallel workstreams

Canonical contracts: this portfolio adopts the existing SISO mission, question-driven research architecture, Frontier Question dossier, Frontier Question identity model, and Ecosystem Intelligence model. For Programs 8 and 9, those documents are authoritative. “Information Organ” means interoperable contracts among independently owned organs, not a new registry, warehouse, or central service.

What should not be parallelized

• Two agents producing the same named artifact or changing the same reserved paths.
• A distributor claiming portability before component Releases and clean-install evidence exist.
• Autonomous maintenance changing production before the proposal, replay, rollback, and evidence path is proven.
• Information ingestion outrunning privacy, rights, and publication boundaries.
• Model-routing automation preceding a representative real-task evaluation bank.
• Disk-heavy work on a designated constrained-storage compute host before its separately owned storage migration is completed and verified.

Constrained compute-host role

A designated home-server environment can become a future compute lane for evaluation runs, indexing, continuous discovery, maintenance probes, and long-running low-interaction agents. Its current storage constraint is a hard scheduling gate. The separately owned storage migration is explicitly outside this program's current work and must be completed and verified before disk-heavy workloads are assigned. Until then, treat the host as available compute with constrained storage—not as a destination for corpus replication or large build caches.

1. Establish complete ecosystem truth

I would map the entire approved SISO estate:

• Every repository, Work, package, service, skill, hook, playbook, agent, integration, database boundary, deployment, and source corpus.
• Which things are canonical, experimental, generated, private, superseded, duplicated, or merely adjacent.
• Dependency and ownership relationships.
• What is released versus what merely exists locally.
• Which documentation claims disagree with executable reality.
• Capabilities hidden inside larger repositories that deserve extraction.
• Valuable mechanisms that exist only in dotfiles, agent profiles, old worktrees, scripts, or abandoned experiments.

The output would feed the Great Library as evidence-backed candidate inventories—not blindly import host contents.

2. Make the Great Library the universal agent front door

I would build the read-oriented CLI and MCP interface we have already anticipated.

An agent should be able to ask:

• “What is the current Agent Stack?”
• “What changed over the last three days?”
• “What lanes are active?”
• “Why is Hooks separate from Playbooks?”
• “Which release introduced this capability?”
• “What depends on Agent Brain?”
• “Where should this new mechanism live?”
• “Has this question already been answered?”
• “Which ADR governs this decision?”
• “What evidence would advance this promotion candidate?”
• “What paths are currently reserved by another agent?”

The answer should return stable IDs, exact releases, evidence, relationships, and next actions—not a prose guess.

3. Connect every repository to Ecosystem Intelligence

The system we just built should become cross-repository.

Every SISO repository would expose a tiny compatible event adapter. Its meaningful changes would flow into one federated intelligence graph:

Repository event
      ↓
Owning Work + exact commit
      ↓
Evidence and verification
      ↓
Great Library Event
      ↓
Release / Snapshot / Assembly
      ↓
Agent Stack distribution

Agents could understand the whole organisation while individual repositories kept independent ownership.

I would add hooks that propose:

• Initiative started
• Scope reserved
• Decision made
• Verification completed
• Release published
• Deployment observed
• Blocker encountered
• Initiative completed
• Correction recorded

These would be proposals, not unreviewed writes to public truth.

4. Finish the one-clone Agent Stack

I would make the separate Agent Stack repository exceptionally good.

A stranger should be able to clone it and receive:

• Project OS
• Agent Runtime
• Agent Zero
• Hooks
• Skills
• Playbooks
• Agent Brain
• Session Intelligence
• Approved integrations
• Host-specific Claude Code and Codex adapters
• Configuration generators
• Verification commands
• Update and rollback support
• A clear public/private boundary

I would test clean installations across supported machines and hosts. Every component would remain independently versioned, while the Stack manifest pins one verified composition.

5. Build the Foundry discovery engine

Foundry would continuously inspect approved sources and produce local, privacy-safe candidate inventories.

It would detect:

• Reusable hooks and scripts.
• Frequently repeated agent instructions.
• Duplicate skills with divergent quality.
• One-off procedures that should become Playbooks.
• Agent patterns that repeatedly succeed.
• Useful packages trapped inside larger applications.
• Documentation drift.
• Dead integrations.
• Unreleased but mature components.
• Frequently encountered problems without reusable solutions.
• Capabilities that have enough coherence to earn their own repository.

It would never automatically publish them. It would rank candidates by reuse, evidence, portability, ownership clarity, and expected leverage.

6. Build a serious agent evaluation laboratory

This might be the most valuable long-term investment.

I would create a bank of real SISO work shapes:

• Repository exploration.
• Bug diagnosis.
• Feature implementation.
• Migration.
• Research synthesis.
• UI implementation.
• Architecture review.
• Security review.
• Multi-agent coordination.
• Long-context continuation.
• Tool-use reliability.
• Evidence extraction.
• Release management.

Then evaluate models, prompts, skills, tools, and orchestration patterns against the same tasks.

For every route we could measure:

• Quality
• Correctness
• Tool reliability
• Time
• Token cost
• Human intervention
• Regression rate
• Handoff quality
• Verification survival
• Context degradation

GQ-008 would stop being mostly a judgment table and become a continuously refreshed routing system grounded in SISO’s actual workload.

7. Turn lessons into executable prevention

We already capture lessons, but I would push much further.

Every recurring mistake would be classified as one of:

• A lesson an agent should recall.
• A rule validation can enforce.
• A test that should fail.
• A hook that should warn.
• A schema invariant.
• An eval case.
• An architectural decision.
• A process that should be removed entirely.

The key principle would be: once a mistake repeats, prose alone is an insufficient fix.

The system would continuously ask, “Can this scar tissue become mechanical?”

8. Build the Information Organ

Program 8 operationalizes the canonical question-driven research boundaries and makes GQ-006 concrete. It connects existing, independently owned systems through explicit retrieval, provenance, claim, decision, and release contracts; it does not merge them into a new central database or second registry.

The interoperable system would connect:

• Foundry discovery
• SISO Knowledge
• Evidence Engines
• The Great Library
• Frontier Questions
• Agent memory
• Session Intelligence
• External research
• Release and deployment facts

It would manage different horizons:

• Immediate working context
• Daily project timeline
• Initiative history
• Durable lessons
• Evidence corpus
• Architectural decisions
• Stable Library identity
• Longitudinal predictions and results

Agents would receive relevant evidence at the point of work without stuffing the entire corpus into every prompt.

9. Make Frontier Questions genuinely alive

Each Frontier Question would become a standing evidence program, not merely a title.

Every question should use the canonical Frontier Question dossier and ten-pass research loop: precise framing, candidate claims, evidence scopes, supporting and refuting evidence, killed hypotheses, unresolved contradictions, an accepted Answer Release, confidence and limitations, predictions, refresh triggers, and a watch process. When the world changed—or a prediction failed—the system would propose a successor answer without rewriting the earlier one.

I would also recover the missing GQ numbers and determine by direct review whether they are private, obsolete, merged, or simply not yet publication-safe.

10. Attack duplication and conceptual drift

I would systematically look for cases where SISO has three names for one thing or one name for three things.

Likely targets include:

• Agent Base versus Runtime versus the retired warehouse.
• Skills versus Playbooks versus Hooks.
• Brain versus task state versus memory.
• Knowledge versus Foundry versus Evidence Engines.
• Session Intelligence versus general memory.
• Integration versus bundled component.
• Project-local state versus shared coordination state.

I would not merge things merely because their words overlap. I would read them, define boundaries, add compatibility paths, and retire ambiguity deliberately.

11. Build autonomous maintenance loops

Safe background agents could continuously detect and propose fixes for:

• Broken public links.
• Registry references that no longer resolve.
• Documentation drift.
• Missing release receipts.
• Dependencies with material vulnerabilities.
• Generated files out of sync.
• Stale active reservations.
• Unclosed initiative threads.
• Snapshots without Events.
• Releases not selected anywhere.
• Works without a current steward.
• Promotion candidates that have been blocked too long.
• Tests that no longer test the current topology.

They would open evidence-backed work, not silently modify production.

12. Harden privacy, security, and recoverability

I would assume the system will eventually operate at a much larger scale and design for that now:

• Formal public/private data boundaries.
• Secret and personal-data scanners.
• Threat models for hooks and memory.
• Reproducible backups.
• Restore drills.
• Signed or hashed manifests.
• Minimal credential authority.
• Audit logs.
• Local-first staging.
• Rights and licensing evidence.
• Clean-room publication pipelines.
• Destructive-action protection.

A clever agent stack that leaks private context or cannot restore itself is not a serious system.

13. Make the ecosystem distributable to other people

I would test the premise that someone outside SISO could actually use it.

That means creating:

• A minimal edition.
• A complete edition.
• Host compatibility matrices.
• One-command setup.
• Example projects.
• Public fixtures.
• Upgrade paths.
• Rollback paths.
• Clear extension contracts.
• A plugin marketplace or reviewed capability registry.
• Documentation written from a new user’s perspective.

I would give a clean machine and no tribal knowledge to test agents and see whether they could install, understand, operate, and extend it.

14. Run continuous adversarial agents

For every major system, I would keep a separate lane whose job is to disprove our claims:

• “This is not actually portable.”
• “This ADR conflicts with runtime behaviour.”
• “This Release does not contain the claimed artifact.”
• “This candidate is already implemented elsewhere.”
• “This test is coupled to a transient fixture.”
• “This active initiative reservation does not cover its real edits.”
• “This documentation describes the desired system, not the running system.”
• “This repository does not deserve independent existence.”

That refutation pressure would probably produce more value than another mountain of features.

15. Preserve room for strange bets

I would reserve perhaps 10% of the budget for experiments that might initially sound excessive:

• Agents that design their own verification interfaces.
• An interactive knowledge graph over the entire Library.
• Predictive maintenance from session and commit patterns.
• Agent-generated temporary tools that are automatically evaluated for promotion.
• Simulation of multiple architectural futures.
• A system that measures which documentation actually prevents agent mistakes.
• Automatic compression of completed initiatives into reusable principles and evals.
• Agent lineage: which earlier decisions, lessons, and tools causally contributed to an outcome.
• Counterfactual reviews: “What would have happened if we chose the rejected ADR alternative?”

Most would die. A few could become foundational.

Desired end state

After 100 million well-spent tokens, I would want a new agent to arrive with no context and become genuinely useful in minutes—while the ecosystem continuously discovers, tests, remembers, distributes, and improves its own capabilities without losing provenance or human control.

Approval boundary

This document preserves a proposed portfolio, not authorization to execute every stream. Approval should name the initial portfolio, resource constraints, privacy scopes, machine assignments, and which programs may open parallel initiative Events. No program may infer access to private sources, destructive cleanup authority, external publication authority, or ownership of a separately assigned host-storage migration from this thesis.