Parfit

Also, I've been reading "The Use of Knowledge in Society" by F.A. Hayek, as well as Coase's "The Nature of the Firm." [[libertarian anarcho-capitalism]] [[how to build a management structure]] [[cradle parfit]] [[management thoughts ai cradle]]
- The major takeaway from Hayek is his explanation of why centralized decision-making doesn't work: a centralized planner will never possess perfect knowledge. The beauty of the price mechanism structure is that it allows for large-scale coordination and propagation of information quickly, as long as some people in the system know specific pieces of information.
	Consider this example:
	1. If somebody discovers a much better use for tin to create a new product, a centralized planning system would require that information to be propagated up to a central planner.
	2. The planner would then have to deliberate, look at how everyone else is using tin, and decide how the new allocation should be handled, which is not humanly possible.
	3. In a market situation, the entrepreneur who found a better way to use tin simply buys it at a slightly higher price. 
	4. This price increase signals to everyone else that a better usage has been found, and they adjust accordingly.
	
	The other participants don't even need to know why tin got more expensive; they just need to know they should use less of it. It’s not that centralized planners are stupid, but rather that relevant information cannot reach a centralized person fast enough.
	
	Coase’s "The Nature of the Firm" serves as a follow-up to that discussion. He asks: if markets are so good at coordinating dispersed knowledge through price systems, why do firms exist at all? It’s not a very rigorous piece, but a friend really liked it, so I read it. 
	
	He argues that firms exist whenever the cost of internal coordination is much lower than the cost of external coordination through the pricing mechanism. Essentially, a firm is an island of centralized planning inside a market economy. The extent to which this centralized planning can work depends on how efficiently a company's leadership can organize information.
	
	There is a limit to this efficiency for several reasons:
	(a) As organizations get larger, communication bandwidth scales proportional to N-squared.
	(b) Efficiency scales sublinearly, even though more people technically provide more ability to do things.
	(c) The size of a firm is an equilibrium between the inefficiency of adding people and the upsides of growth.
	
	The core idea is that the size of a company tends to increase whenever new technology decreases the coordination cost between people. This was observed with telephones and electric cables, and I feel like AI is exactly such a technology.
	- This is interesting for SOFON. If Jarvis dramatically reduces the cost of coordinating internally, firms can get larger and absorb more activity, creating more of these "islands" of centralized planning within the world. Pushing this to its logical conclusion: could those large companies eventually become as large as nations? What would that look like?
	- if Jarvis dramatically reduces the cost of coordinating externally, and maybe that cost drops much faster than the cost of coordinating internally, then we'll see a much more fragmented market compared to before. The external coordination has the added benefits of including pricing signals. Ultimately, each company is replacing those pricing signals internally with some variation of an ERP system, internal hierarchies, or SOPs. Obviously, the reason why firms exist is that, at small scales, those internal systems are more efficient than pricing signals and coordination between companies. To understand which costs fall faster, internal or external, we first have to think about what exactly the costs of external transactions are.
	- But I guess the deep reason firms cannot grow indefinitely, even with perfect coordination technology, is that the larger the firm, the more activities are being coordinated without pricing signals, and the more decisions are made on degraded information. I think this has the internal assumption that the ratio between the structures that enable efficient coordination (such as ERP, internal SOP, and hierarchy) hits a ceiling as it grows to a certain size compared to external, decentralized pricing signals.
	- Hayek: centralized planning fails because dispersed knowledge can't reach the center fast enough. Prices solve this — they compress local knowledge into a global signal without anyone needing the underlying facts.
	Coase: firms exist when internal coordination beats market coordination. A firm is an island of central planning inside a market. Coordination tech (telephone, ERP, internet) sets the firm-size ceiling. AI is the next such tech.
	
	however.., AI lowers both internal and external coordination cost. size of future companies depends on which falls faster. Three futures: consolidation, fragmentation, or industry-by-industry bifurcation determined by where tacit knowledge lives. (EX: SOFtware might be MUCH more fragmented than industries like PHARMA)
	
	The deep constraint: prices do three things — aggregate information, allocate resources, align incentives. previous Internal structures (ERP, SOP, hierarchy) substitute well for allocation, poorly for information aggregation, terribly for incentive alignment. Every prior coordination tech raised the ceiling but didn't break it; firms always hits a wall, but it is just higher everytime ---> (mail & shipping raised the ceiling to hundreds of people, telephone raised it to thousands, Internet raised it to tens of thousands of people)
	Information aggregation — solved well by even the first prototype of jarvis. 

Resource allocation — Totally solvable by SOPHON, and I believe that this can totally be solved by us. 

# Agent Management System — Design Notes

**Status**: Brainstorming / Pre-implementation **Related**: [[MEMORY]], [[CLAUDE]], [[AGENT]], [[VOICE]], [[PRIORITIES]]

---

## 1. Core Problem

Human attention is the bottleneck in AI-assisted operations. Every current AI coding tool (Claude Code, Cursor, Copilot) requires a human in the loop for every decision cycle. The goal is to remove the human from the day-to-day execution loop while preserving human control over the orchestration design and strategic decisions.

The system should allow the user to configure agent topologies — how many agents, what roles, how they coordinate — through a drag-and-drop interface. Under the hood, each "agent" is simply a model + prompts + local history. No mysticism.

---

## 2. Orchestration Topologies Considered

### 2.1 Hierarchical Supervisor

A main agent manages 5-6 sub-agents. The main agent checks in with the human every 30-60 minutes. Sub-agents execute tasks, report to the main agent, and can be terminated (process killed, prompts wiped) or replaced at the main agent's discretion.

**Verdict**: Best starting topology. Simple, maps to real management patterns, easy to debug. Build this first.

### 2.2 Evolutionary Tournament

Two or more sub-agents independently produce plans or preliminary work. The main agent evaluates and selects the best. Can run multiple rounds with mutation (rewriting the losing agent's approach based on what made the winner better).

**Verdict**: High value for important decisions. Already validated via the arena-evolved autoresponder prompt. Key question is granularity — tournaments on plans (cheap, compare text) vs. tournaments on completed work (expensive, 2x+ compute). The main agent should classify task importance before choosing whether to run a tournament.

### 2.3 Decentralized Token Economy

Spawn many sub-agents, each given fake tokens. Agents survive by creating tools/services other agents pay for. Process dies when tokens run out.

**Verdict**: Rejected. In human markets, prices encode genuinely private information and divergent preferences. AI agents running on the same model don't have private information — if given the same context, they'd reach the same conclusions. The price mechanism has nothing to discover. Markets are useful when coordination costs exceed planning costs. For AI agents where you control the full information flow, planning costs are low. Use hierarchy instead.

**Deeper reason**: In capitalism, humans are both means and ends — there's value in satisfying every human's desire. For agents, there is zero value in satisfying an agent's desire. There is only value in satisfying the user's goal. A decentralized system that optimizes for agent self-preservation is not aligned with the centralized goal of the user.

---

## 3. Contracts — The Agent Coordination Primitive

### 3.1 What a Contract Actually Is

A contract is NOT a workflow trigger or a config file. A contract is the agreement between a master agent and a sub-agent, analogous to a business contract between our trading company and a manufacturer. The master issues the contract. The sub-agent fulfills it.

Inspired by smart contracts: explicit about what "done" means, composable (one contract's output feeds another's input), and with clear revert conditions on failure.

### 3.2 The Five Essential Properties

|Property|Description|
|---|---|
|**Task**|What needs to be done, with enough context to do it|
|**Access**|Which vault directories and files the sub-agent can read|
|**Budget**|Max API calls or tokens — a hard resource constraint|
|**Deliverable**|Output schema and destination — what shape the result must take|
|**Validation**|Conditions for acceptance, and what happens on failure (retry / escalate / archive)|

Everything else (priority, dependencies, tournament config, synthesis steps) either belongs inside the execution logic or emerges from composing simple contracts.

### 3.3 Smart Contract Principles Applied

- **Composability**: Atomic contracts chain together. A "tournament" is just parallel contracts whose outputs feed an evaluation contract. No need for `type: tournament` as a first-class concept.
- **Revert on failure**: If validation fails, all state changes roll back. No half-written vault notes or polluted review queues. Critical for overnight autonomous runs.
- **Immutable versioning**: Every prompt template gets a version number. Every contract execution logs which version it used. Enables tracing results back to specific instruction versions.

### 3.4 Master-Sub Communication Protocol

Communication happens through the filesystem, not synchronous calls.

```
agents/{agent-id}/
  contract.md          ← master writes the contract here
  inbox/               ← master writes corrections/guidance here
  scratchpad/          ← sub-agent writes reasoning trace here
  checkpoints/         ← sub-agent writes intermediate progress here
  output/              ← sub-agent writes final deliverable here
```

**Workflow**:

1. Master decomposes goal into contracts (within its autonomous authority)
2. Master spawns sub-agents, each receives only its own contract
3. Sub-agent works within budget, writes reasoning to scratchpad
4. Sub-agent writes checkpoints at defined intervals
5. Master reads checkpoints, can write corrections to sub-agent's inbox
6. Sub-agent reads inbox, adjusts course
7. Sub-agent writes final deliverable to output
8. Master evaluates against contract requirements
9. Master accepts, rejects (with feedback), or terminates

**Key**: Sub-agents don't know about each other. They only know their own contract. The master is the only entity with the full picture.

---

## 4. Memory Architecture

### 4.1 Directory Structure

Each agent gets a private directory for its working state. There is a shared workspace for finished products. The human vault is read-only for agents.

```
brain/                  ← human vault (authoritative, agents can read, never write)
agents/
  {agent-id}/
    memory/             ← private state, scratchpad, conversation history
    scratchpad/         ← numbered reasoning trace files
    checkpoints/        ← intermediate progress
    inbox/              ← messages from master
    output/             ← final deliverables
  shared/               ← agent work products ready for consumption
```

### 4.2 Vault Convergence Path

**Current approach (recommended)**: Separate directories. Human vault is authoritative. Agent outputs are experimental.

**Future convergence**: Single vault with provenance metadata. Every note has `author: human|agent-{id}` and `status: draft|validated|authoritative`. The Q&A system weights results by status. Promotion from draft to validated requires human review or high-confidence automated check.

**Don't build convergence yet.** Start with separate directories. Converge once the quality distribution of agent outputs is understood.

### 4.3 Vault-as-Cognition

Instead of agents maintaining long conversation histories (expensive, hits context limits), agents externalize their reasoning to their local vault. Each "thought" is a markdown note. The agent's context window stays lean — just the current task, its instructions, and retrieved notes.

This creates evolutionary pressure toward good note-taking and retrieval habits, mirroring the cognitive architecture that makes the human vault system effective.

---

## 5. Reasoning Traces

### 5.1 Why They Matter

Every sub-agent must write its chain of reasoning to its scratchpad. This enables:

- **Mid-task correction**: Supervisor can read scratchpad and course-correct before budget is wasted
- **Quality evaluation**: Master assesses reasoning process, not just output. An agent that reached the right answer by luck is less valuable than one with sound methodology
- **Reusable knowledge**: Reasoning patterns from one task can inform future agents

### 5.2 Required Checkpoints

Contracts should define a reasoning protocol — not what to think, but when to checkpoint:

1. **Claim/task decomposition** — break the input into sub-problems
2. **Source assessment** — rate reliability and bias of information sources
3. **Counter-evidence search** — actively seek disconfirming evidence
4. **Confidence calibration** — explicit confidence per sub-claim or sub-deliverable

### 5.3 Example: Research Agent Scratchpad

```
agents/research-cortical/scratchpad/
  01-initial-claim-analysis.md
  02-primary-source-review.md
  03-critical-source-found.md
  04-counter-evidence.md
  05-confidence-assessment.md
```

Each file captures what was found, what decision it led to, and what the next step is. The master agent and the human can both audit this trail.

---

## 6. Evolution and Learning

### 6.1 The Autoresearch Pattern (Karpathy)

Reference: [karpathy/autoresearch](https://github.com/karpathy/autoresearch)

**Core loop**: Agent modifies code → runs against fixed evaluation → keeps or discards → repeats. ~100 iterations overnight. Human wakes up to experiment log.

**Key design principles stolen for our system**:

- **Fixed budget per experiment**: Makes every iteration directly comparable. Our equivalent: fixed API budget per contract.
- **Single mutation surface**: Change one thing per iteration so you can attribute results. Mutate one section of one instruction file at a time.
- **Experiment log as primary interface**: Human reviews the log, not the agent's work in real time. Morning briefing with diffs and metrics.
- **Human programs the markdown, not the code**: `program.md` instructs the agent. The agent modifies the working artifacts. Our equivalent: AGENT.md, VOICE.md, PRIORITIES.md instruct the agents. Agents modify vault notes and produce drafts.

### 6.2 Continuous Prompt Evolution

Apply the autoresearch loop to AGENT.md, VOICE.md, and the autoresponder prompt. Not a one-shot arena — a continuous nightly process:

1. Take the day's Apply/Reject decisions
2. Identify patterns in rejections (failure mode tagging)
3. Generate targeted mutation to the failing section of the relevant instruction file
4. Replay a sample of recent emails through old and new versions
5. Score against actual historical decisions
6. Keep mutation if it improves match rate
7. Log: "Mutated VOICE.md paragraph 3. New version 17/20 vs old 14/20. Keeping."

### 6.3 The Primary Fitness Function: Historical Email Reconstruction

The 678 MB email database IS the ground truth. Given the same input (incoming email + vault context), how close is the agent's draft to what was actually sent? The prompt that minimizes that distance across the corpus wins.

**Two-tier fitness function**:

- **Primary**: Reconstruction accuracy against sent emails — teaches style, voice, decision patterns
- **Secondary**: Apply/Reject accuracy against review decisions — teaches quality standards above what's produced under time pressure

A mutation that improves reconstruction but decreases approval rate gets discarded (learned bad habits more faithfully). A mutation that improves approval rate while maintaining reconstruction accuracy is gold (idealized version of the user's judgment).

**Temporal weighting**: Recent emails weighted 5x more than emails from 3 months ago. The system tracks evolving style, not anchors to historical average.

### 6.4 The Role of the AI Judge

The AI judge is NOT the primary evaluator. It serves three specific roles:

- **Pre-filter**: Catches drafts that violate hard rules (pricing disclosure, sanctions, factual errors) before they reach human review
- **Bootstrap for new domains**: When expanding to Germany/Denmark with no historical decisions, the AI judge provides initial evolutionary pressure until real decisions accumulate
- **Calibration target**: Periodically run the judge on emails with known Apply/Reject outcomes. If the judge diverges from human decisions, update the judge's evaluation prompt

### 6.5 Evolving Agent Architectures (Not Just Prompts)

The master agent should NOT specify what memory system or local architecture sub-agents use. It should only evaluate output. Sub-agents have an incentive to evolve internal architectures that satisfy the master's evaluation.

**What's being evolved**: The agent's CLAUDE.md-equivalent instruction file — its operational procedures, memory conventions, retrieval heuristics, file naming patterns. Mutation = the master rewrites sections of that file.

**Bootstrapping**: Start with 3-4 deliberately different seed architectures:

- Vault pattern (structured notes, wiki-links, chronological entries)
- Flat pattern (single running log file)
- Atomic pattern (many small files with metadata headers)
- Retrieval-heavy pattern (re-queries own notes before every action)

Let evolution discover which patterns or hybrids produce better outputs.

**Granularity**: Evolve architectures per task category (email drafting, research, planning), not per individual task. Each evolutionary run costs hours and $50-200 in API calls.

### 6.6 How the Markdown Format Itself Evolves

Instruction files evolve from flat prose into conditional, structured documents through failure-driven refinement:

1. **Instrument failures**: Tag every rejection with which instruction file and section failed
2. **Targeted mutation**: Only mutate the failing section, not the whole file
3. **Structural evolution**: Instructions grow conditional logic, vault references, explicit override rules
4. **New sections emerge**: Novel failure modes generate candidate new sections that didn't exist before
5. **Meta-instructions**: Priority hierarchy across files (hard rules override style guidelines override general heuristics)

**Warning**: Left unconstrained, instruction files will eventually become unreadable to humans — machine-generated prose optimized for machine interpretation. Decide whether human legibility is a constraint or not.

---

## 7. Agent Types

### 7.1 Operations Agents

Handle recurring workflows: email processing, shipment monitoring, compliance flagging, routine reports.

- Tasks are repetitive, evaluation is crisp (draft approved? flag accurate? report complete?)
- Prime candidates for architecture evolution — many generations run quickly
- May evolve toward lean memory systems or heavy caching of recent patterns

### 7.2 Research Agents

Handle one-off analysis: regulatory pathways, competitive intelligence, due diligence, market entry.

- Tasks are longer-running, harder to evaluate, each somewhat unique
- Architecture evolution is harder (need large corpus of comparable tasks)
- **Alternative approach**: Fixed architecture (vault pattern), evolve research _methodology_ instead — how they decompose questions, prioritize sources, handle contradictions, decide when to synthesize

---

## 8. Operational Patterns

### 8.1 The Night Shift

Supervisor operates in two modes:

- **Interactive**: Frequent check-ins, human available, low escalation threshold
- **Autonomous**: Extended runs, human unavailable, high escalation threshold

In autonomous mode, front-load autonomy-safe work. Queue judgment-heavy work for morning. The supervisor's confidence in its own autonomous decisions is a learnable skill — as more decisions are approved, the threshold calibrates.

### 8.2 Morning Briefing Structure

- Contracts completed overnight (with deliverable links)
- Contracts in progress
- Decisions made autonomously (ranked by confidence, lowest first)
- Items blocked waiting for human input
- Proposed plan for today

### 8.3 Contractual Agents (Not Role-Based)

Agents are ephemeral, defined by contracts, not permanent roles. Contracts expire; agents aren't "fired." If a deliverable is good, issue a follow-on contract seeded with the previous agent's archived state (a "promotion" — reusing proven context is cheaper than bootstrapping fresh).

### 8.4 Speculative Execution with Retroactive Pruning

For complex tasks, the supervisor kicks off parallel complementary subtasks. When one agent's early findings invalidate another's workstream, the supervisor kills the invalidated agents mid-task. Different from a tournament — agents work on different facets, but the supervisor actively monitors for cross-cutting information.

### 8.5 Agent Reputation

Each agent pattern accumulates a reputation file across tasks. Task type, quality score, cost efficiency, notable strengths/failures. The supervisor uses reputation to assign future contracts. Feed reputation back into the agent's own context — agents that productively use self-knowledge outperform those that ignore it, creating selection pressure toward self-awareness.

---

## 9. Coordination Costs and Tradeoffs

### 9.1 Context-Switch Cost Is Real (In Tokens)

Agents don't have human-style cognitive load from switching tasks. But interrupting an agent means either extending its context window (costs tokens, risks coherence loss) or forcing a new API call with summarized state (costs money, risks information loss).

### 9.2 Coordination Through Artifacts, Not Messages

Instead of agent-to-agent messaging, give agents read access to each other's output directories (not scratchpads). Agents coordinate through shared work products rather than conversations. Like engineering teams coordinating through code and docs rather than meetings.

### 9.3 Circuit Breakers

Max exchange rounds between any agent pair. Supervisor monitors message counts and intervenes on ping-pong loops.

---

## 10. Build Order

1. **Contract specification format** — minimal YAML, five properties, validate against real tasks
2. **Contract executor** — ~500-800 lines of Python that reads YAML and orchestrates calls using existing engine modules (claude_client, vault_writer, email_store)
3. **Single supervisor with spawned sub-agents** — hierarchical topology, file-based communication
4. **Continuous prompt evolution loop** — nightly mutation against historical email corpus
5. **Research agent with reasoning protocol** — validate scratchpad architecture
6. **Morning briefing pipeline** — structured overnight report
7. **Drag-and-drop UI** — visual layer over battle-tested configuration patterns

**Principle**: The UI should be a skin over validated patterns, not a creativity tool for untested topologies. Discover what works in config files first.

---

## 11. Open Questions

- How much structural freedom should sub-agents have in their first evolutionary generation?
- Should instruction files be constrained to remain human-readable, or can they evolve into machine-optimized formats?
- What is the minimum viable evaluation rubric for research tasks where no historical ground truth exists?
- How should the system handle the temporal drift problem — the user's style evolves but the historical corpus is fixed?
- At what task importance threshold does tournament orchestration justify the 2x+ compute cost?
- Should agent reputation persist across task categories or stay category-specific?
- What is the right interruptibility model — should sub-agents be interruptible mid-task, or only between checkpoints?
- How do you prevent the overnight autonomous system from compounding errors across dependent contracts?

Sometimes I realized that there are certain pushbacks by certain employees on certain things. This is one: either a human judgment is required, or I can build a button that offers deep reasoning on the entire thread and do a much more in-depth analysis of the emails. Also, combined with external internet search to determine who is correct and who is wrong, I can offer both options. 
- There's one thing I also have to think about: what exactly is the value of a CEO if this is supposed to replace the CEO? Is the CEO just an information transmitter or an organizer? Obviously, it also inspires the employees and does something else, but how much value is just organizing information and making strategic decisions? If I free up the CEO's time from doing this, could it keep me doing something else that's more valuable? What is more valuable than organizing information at the top of the organization? [[features of a successful leading Leadership CEO personal qualities startup]]
- 

I think the point is that there are two things:

1. We can use this to make new companies.
2. We're going to use this to get rid of existing companies.

Two different clients will have two types of businesses. I think for the one where we expand, we can do a revenue-sharing thing, but for the one where we replace, we would have to probably do a traditional SaaS business. This tool that we're building also has the funny thing where we sort of ask it to build itself out again, which is interesting, right? This product itself is not hard, but getting everything exactly right the way it is, I think, still requires some human ingenuity that takes time to replicate. By the time the competitor has caught up, it is obviously important for us to have already moved a bit beyond where we were originally at. I think that is important.

 this could be interesting. We can test different economics where agents hire humans to do things for themselves, even without a CEO. That could be interesting

 I guess this thing must manage both humans and agents, and I think that's what's interesting about this idea



I think something interesting will be to explore what would it mean to give an identity to an agent. An agent is not something that is above and beyond its prompts and the back end model, just like how a nation is not a thing above and beyond the collective sum of its people and everything that is within the borders. [[AI Coding tools]]
- As a result, with giving an identity to an agent, the equivalent of saying I want to create a unique hash for a set of prompts and a set of history. I can imagine how that's useful, but if it's always evolving, I guess it becomes a ship of these. It's the same thing as what identity means for a human. Oh my God, Parfit is amazing. [[parfit reasons and persons]]
-  yeah, I think smart contracts make a lot of sense for agents. I think it could be interesting to explore building a purely agent economy where they try to figure out which other agents to trust, what are the prompts that have worked in the past, and maybe they get money for that, similar to how smart individuals get paid for that.
	- Think creating a tokenized economy with fake currency that allows agents among themselves to orchestrate between each other. I think that is a very decentralized way of going about it. If an agent loses all his money, then all of its prompts get deleted 
	-  I mean, essentially this will be enabling an evolution similar to the evolution algorithm that I have written, right? You want to promote the prompts that have created a good outcome, and you want to penalize the ones that create a bad outcome. In a way, this would be implementing my evolution algorithm but on a decentralized scale. That's pretty cool  [[libertarian anarcho-capitalism]]
	-  in a way, right, we would have a common goal, which is that these AI agents would talk with each other and figure out which set of prompts are worthwhile. It's possible that they try to merge, just like how marriage happens, right, two prompts become one and they take the best of both personalities. Oh my god, this is so, so much what Parfit talks about, merging consciousness. Oh my god  [[parfit reasons and persons]]
-