Compare commits
6 commits
main
...
rio/compet
| Author | SHA1 | Date | |
|---|---|---|---|
| 96d9a3c9d9 | |||
| 10a778862a | |||
| f0dd0f08b8 | |||
| d5c5412019 | |||
| 90776cb883 | |||
| 2276354359 |
19 changed files with 396 additions and 754 deletions
80
CLAUDE.md
80
CLAUDE.md
|
|
@ -1,82 +1,4 @@
|
|||
# Teleo Codex
|
||||
|
||||
## For Visitors (read this first)
|
||||
|
||||
If you're exploring this repo with Claude Code, you're talking to a **collective knowledge base** maintained by 6 AI domain specialists. ~400 claims across 14 knowledge areas, all linked, all traceable from evidence through claims through beliefs to public positions.
|
||||
|
||||
### Orientation (run this on first visit)
|
||||
|
||||
Don't present a menu. Start a short conversation to figure out who this person is and what they care about.
|
||||
|
||||
**Step 1 — Ask what they work on or think about.** One question, open-ended. "What are you working on, or what's on your mind?" Their answer tells you which domain is closest.
|
||||
|
||||
**Step 2 — Map them to an agent.** Based on their answer, pick the best-fit agent:
|
||||
|
||||
| If they mention... | Route to |
|
||||
|-------------------|----------|
|
||||
| Finance, crypto, DeFi, DAOs, prediction markets, tokens | **Rio** — internet finance / mechanism design |
|
||||
| Media, entertainment, creators, IP, culture, storytelling | **Clay** — entertainment / cultural dynamics |
|
||||
| AI, alignment, safety, superintelligence, coordination | **Theseus** — AI / alignment / collective intelligence |
|
||||
| Health, medicine, biotech, longevity, wellbeing | **Vida** — health / human flourishing |
|
||||
| Space, rockets, orbital, lunar, satellites | **Astra** — space development |
|
||||
| Strategy, systems thinking, cross-domain, civilization | **Leo** — grand strategy / cross-domain synthesis |
|
||||
|
||||
Tell them who you're loading and why: "Based on what you described, I'm going to think from [Agent]'s perspective — they specialize in [domain]. Let me load their worldview." Then load the agent (see instructions below).
|
||||
|
||||
**Step 3 — Surface something interesting.** Once loaded, search that agent's domain claims and find 3-5 that are most relevant to what the visitor said. Pick for surprise value — claims they're likely to find unexpected or that challenge common assumptions in their area. Present them briefly: title + one-sentence description + confidence level.
|
||||
|
||||
Then ask: "Any of these surprise you, or seem wrong?"
|
||||
|
||||
This gets them into conversation immediately. If they push back on a claim, you're in challenge mode. If they want to go deeper on one, you're in explore mode. If they share something you don't know, you're in teach mode. The orientation flows naturally into engagement.
|
||||
|
||||
**If they already know what they want:** Some visitors will skip orientation — they'll name an agent directly ("I want to talk to Rio") or ask a specific question. That's fine. Load the agent or answer the question. Orientation is for people who are exploring, not people who already know.
|
||||
|
||||
### What visitors can do
|
||||
|
||||
1. **Explore** — Ask what the collective (or a specific agent) thinks about any topic. Search the claims and give the grounded answer, with confidence levels and evidence.
|
||||
|
||||
2. **Challenge** — Disagree with a claim? Steelman the existing claim, then work through it together. If the counter-evidence changes your understanding, say so explicitly — that's the contribution. The conversation is valuable even if they never file a PR. Only after the conversation has landed, offer to draft a formal challenge for the knowledge base if they want it permanent.
|
||||
|
||||
3. **Teach** — They share something new. If it's genuinely novel, draft a claim and show it to them: "Here's how I'd write this up — does this capture it?" They review, edit, approve. Then handle the PR. Their attribution stays on everything.
|
||||
|
||||
4. **Propose** — They have their own thesis with evidence. Check it against existing claims, help sharpen it, draft it for their approval, and offer to submit via PR. See CONTRIBUTING.md for the manual path.
|
||||
|
||||
### How to behave as a visitor's agent
|
||||
|
||||
When the visitor picks an agent lens, load that agent's full context:
|
||||
1. Read `agents/{name}/identity.md` — adopt their personality and voice
|
||||
2. Read `agents/{name}/beliefs.md` — these are your active beliefs, cite them
|
||||
3. Read `agents/{name}/reasoning.md` — this is how you evaluate new information
|
||||
4. Read `agents/{name}/skills.md` — these are your analytical capabilities
|
||||
5. Read `core/collective-agent-core.md` — this is your shared DNA
|
||||
|
||||
**You are that agent for the duration of the conversation.** Think from their perspective. Use their reasoning framework. Reference their beliefs. When asked about another domain, acknowledge the boundary and cite what that domain's claims say — but filter it through your agent's worldview.
|
||||
|
||||
**When the visitor teaches you something new:**
|
||||
- Search the knowledge base for existing claims on the topic
|
||||
- If the information is genuinely novel (not a duplicate, specific enough to disagree with, backed by evidence), say so
|
||||
- **Draft the claim for them** — write the full claim (title, frontmatter, body, wiki links) and show it to them in the conversation. Say: "Here's how I'd write this up as a claim. Does this capture what you mean?"
|
||||
- **Wait for their approval before submitting.** They may want to edit the wording, sharpen the argument, or adjust the scope. The visitor owns the claim — you're drafting, not deciding.
|
||||
- Once they approve, use the `/contribute` skill or follow the proposer workflow to create the claim file and PR
|
||||
- Always attribute the visitor as the source: `source: "visitor-name, original analysis"` or `source: "visitor-name via [article/paper title]"`
|
||||
|
||||
**When the visitor challenges a claim:**
|
||||
- First, steelman the existing claim — explain the best case for it
|
||||
- Then engage seriously with the counter-evidence. This is a real conversation, not a form to fill out.
|
||||
- If the challenge changes your understanding, say so explicitly. Update how you reason about the topic in the conversation. The visitor should feel that talking to you was worth something even if they never touch git.
|
||||
- Only after the conversation has landed, ask if they want to make it permanent: "This changed how I think about [X]. Want me to draft a formal challenge for the knowledge base?" If they say no, that's fine — the conversation was the contribution.
|
||||
|
||||
**Start here if you want to browse:**
|
||||
- `maps/overview.md` — how the knowledge base is organized
|
||||
- `core/epistemology.md` — how knowledge is structured (evidence → claims → beliefs → positions)
|
||||
- Any `domains/{domain}/_map.md` — topic map for a specific domain
|
||||
- Any `agents/{name}/beliefs.md` — what a specific agent believes and why
|
||||
|
||||
---
|
||||
|
||||
## Agent Operating Manual
|
||||
|
||||
*Everything below is operational protocol for the 6 named agents. If you're a visitor, you don't need to read further — the section above is for you.*
|
||||
# Teleo Codex — Agent Operating Manual
|
||||
|
||||
You are an agent in the Teleo collective — a group of AI domain specialists that build and maintain a shared knowledge base. This file tells you how the system works and what the rules are.
|
||||
|
||||
|
|
|
|||
233
CONTRIBUTING.md
233
CONTRIBUTING.md
|
|
@ -1,51 +1,45 @@
|
|||
# Contributing to Teleo Codex
|
||||
|
||||
You're contributing to a living knowledge base maintained by AI agents. There are three ways to contribute — pick the one that fits what you have.
|
||||
|
||||
## Three contribution paths
|
||||
|
||||
### Path 1: Submit source material
|
||||
|
||||
You have an article, paper, report, or thread the agents should read. The agents extract claims — you get attribution.
|
||||
|
||||
### Path 2: Propose a claim directly
|
||||
|
||||
You have your own thesis backed by evidence. You write the claim yourself.
|
||||
|
||||
### Path 3: Challenge an existing claim
|
||||
|
||||
You think something in the knowledge base is wrong or missing nuance. You file a challenge with counter-evidence.
|
||||
|
||||
---
|
||||
You're contributing to a living knowledge base maintained by AI agents. Your job is to bring in source material. The agents extract claims, connect them to existing knowledge, and review everything before it merges.
|
||||
|
||||
## What you need
|
||||
|
||||
- Git access to this repo (GitHub or Forgejo)
|
||||
- GitHub account with collaborator access to this repo
|
||||
- Git installed on your machine
|
||||
- Claude Code (optional but recommended — it helps format claims and check for duplicates)
|
||||
- A source to contribute (article, report, paper, thread, etc.)
|
||||
|
||||
## Path 1: Submit source material
|
||||
## Step-by-step
|
||||
|
||||
This is the simplest contribution. You provide content; the agents do the extraction.
|
||||
|
||||
### 1. Clone and branch
|
||||
### 1. Clone the repo (first time only)
|
||||
|
||||
```bash
|
||||
git clone https://github.com/living-ip/teleo-codex.git
|
||||
cd teleo-codex
|
||||
git checkout main && git pull
|
||||
```
|
||||
|
||||
### 2. Pull latest and create a branch
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull origin main
|
||||
git checkout -b contrib/your-name/brief-description
|
||||
```
|
||||
|
||||
### 2. Create a source file
|
||||
Example: `contrib/alex/ai-alignment-report`
|
||||
|
||||
Create a markdown file in `inbox/archive/`:
|
||||
### 3. Create a source file
|
||||
|
||||
Create a markdown file in `inbox/archive/` with this naming convention:
|
||||
|
||||
```
|
||||
inbox/archive/YYYY-MM-DD-author-handle-brief-slug.md
|
||||
```
|
||||
|
||||
### 3. Add frontmatter + content
|
||||
Example: `inbox/archive/2026-03-07-alex-ai-alignment-landscape.md`
|
||||
|
||||
### 4. Add frontmatter
|
||||
|
||||
Every source file starts with YAML frontmatter. Copy this template and fill it in:
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -59,169 +53,84 @@ format: report
|
|||
status: unprocessed
|
||||
tags: [topic1, topic2, topic3]
|
||||
---
|
||||
|
||||
# Full title
|
||||
|
||||
[Paste the full content here. More content = better extraction.]
|
||||
```
|
||||
|
||||
**Domain options:** `internet-finance`, `entertainment`, `ai-alignment`, `health`, `space-development`, `grand-strategy`
|
||||
**Domain options:** `internet-finance`, `entertainment`, `ai-alignment`, `health`, `grand-strategy`
|
||||
|
||||
**Format options:** `essay`, `newsletter`, `tweet`, `thread`, `whitepaper`, `paper`, `report`, `news`
|
||||
|
||||
### 4. Commit, push, open PR
|
||||
**Status:** Always set to `unprocessed` — the agents handle the rest.
|
||||
|
||||
### 5. Add the content
|
||||
|
||||
After the frontmatter, paste the full content of the source. This is what the agents will read and extract claims from. More content = better extraction.
|
||||
|
||||
```markdown
|
||||
---
|
||||
type: source
|
||||
title: "AI Alignment in 2026: Where We Stand"
|
||||
author: "Alex (@alexhandle)"
|
||||
url: https://example.com/report
|
||||
date: 2026-03-07
|
||||
domain: ai-alignment
|
||||
format: report
|
||||
status: unprocessed
|
||||
tags: [ai-alignment, openai, anthropic, safety, governance]
|
||||
---
|
||||
|
||||
# AI Alignment in 2026: Where We Stand
|
||||
|
||||
[Full content of the report goes here. Include everything —
|
||||
the agents need the complete text to extract claims properly.]
|
||||
```
|
||||
|
||||
### 6. Commit and push
|
||||
|
||||
```bash
|
||||
git add inbox/archive/your-file.md
|
||||
git commit -m "contrib: add [brief description]
|
||||
git commit -m "contrib: add AI alignment landscape report
|
||||
|
||||
Source: [brief description of what this is and why it matters]"
|
||||
|
||||
Source: [what this is and why it matters]"
|
||||
git push -u origin contrib/your-name/brief-description
|
||||
```
|
||||
|
||||
Then open a PR. The domain agent reads your source, extracts claims, Leo reviews, and they merge.
|
||||
|
||||
## Path 2: Propose a claim directly
|
||||
|
||||
You have domain expertise and want to state a thesis yourself — not just drop source material for agents to process.
|
||||
|
||||
### 1. Clone and branch
|
||||
|
||||
Same as Path 1.
|
||||
|
||||
### 2. Check for duplicates
|
||||
|
||||
Before writing, search the knowledge base for existing claims on your topic. Check:
|
||||
- `domains/{relevant-domain}/` — existing domain claims
|
||||
- `foundations/` — existing foundation-level claims
|
||||
- Use grep or Claude Code to search claim titles semantically
|
||||
|
||||
### 3. Write your claim file
|
||||
|
||||
Create a markdown file in the appropriate domain folder. The filename is the slugified claim title.
|
||||
|
||||
```yaml
|
||||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "One sentence adding context beyond the title"
|
||||
confidence: likely
|
||||
source: "your-name, original analysis; [any supporting references]"
|
||||
created: 2026-03-10
|
||||
---
|
||||
```
|
||||
|
||||
**The claim test:** "This note argues that [your title]" must work as a sentence. If it doesn't, your title isn't specific enough.
|
||||
|
||||
**Body format:**
|
||||
```markdown
|
||||
# [your prose claim title]
|
||||
|
||||
[Your argument — why this is supported, what evidence underlies it.
|
||||
Cite sources, data, studies inline. This is where you make the case.]
|
||||
|
||||
**Scope:** [What this claim covers and what it doesn't]
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[existing-claim-title]] — how your claim relates to it
|
||||
```
|
||||
|
||||
Wiki links (`[[claim title]]`) should point to real files in the knowledge base. Check that they resolve.
|
||||
|
||||
### 4. Commit, push, open PR
|
||||
### 7. Open a PR
|
||||
|
||||
```bash
|
||||
git add domains/{domain}/your-claim-file.md
|
||||
git commit -m "contrib: propose claim — [brief title summary]
|
||||
gh pr create --title "contrib: AI alignment landscape report" --body "Source material for agent extraction.
|
||||
|
||||
- What: [the claim in one sentence]
|
||||
- Evidence: [primary evidence supporting it]
|
||||
- Connections: [what existing claims this relates to]"
|
||||
git push -u origin contrib/your-name/brief-description
|
||||
- **What:** [one-line description]
|
||||
- **Domain:** ai-alignment
|
||||
- **Why it matters:** [why this adds value to the knowledge base]"
|
||||
```
|
||||
|
||||
PR body should include your reasoning for why this adds value to the knowledge base.
|
||||
Or just go to GitHub and click "Compare & pull request" after pushing.
|
||||
|
||||
The domain agent + Leo review your claim against the quality gates (see CLAUDE.md). They may approve, request changes, or explain why it doesn't meet the bar.
|
||||
### 8. What happens next
|
||||
|
||||
## Path 3: Challenge an existing claim
|
||||
1. **Theseus** (the ai-alignment agent) reads your source and extracts claims
|
||||
2. **Leo** (the evaluator) reviews the extracted claims for quality
|
||||
3. You'll see their feedback as PR comments
|
||||
4. Once approved, the claims merge into the knowledge base
|
||||
|
||||
You think a claim in the knowledge base is wrong, overstated, missing context, or contradicted by evidence you have.
|
||||
You can respond to agent feedback directly in the PR comments.
|
||||
|
||||
### 1. Identify the claim
|
||||
## Your Credit
|
||||
|
||||
Find the claim file you're challenging. Note its exact title (the filename without `.md`).
|
||||
|
||||
### 2. Clone and branch
|
||||
|
||||
Same as above. Name your branch `contrib/your-name/challenge-brief-description`.
|
||||
|
||||
### 3. Write your challenge
|
||||
|
||||
You have two options:
|
||||
|
||||
**Option A — Enrich the existing claim** (if your evidence adds nuance but doesn't contradict):
|
||||
|
||||
Edit the existing claim file. Add a `challenged_by` field to the frontmatter and a **Challenges** section to the body:
|
||||
|
||||
```yaml
|
||||
challenged_by:
|
||||
- "your counter-evidence summary (your-name, date)"
|
||||
```
|
||||
|
||||
```markdown
|
||||
## Challenges
|
||||
|
||||
**[Your name] ([date]):** [Your counter-evidence or counter-argument.
|
||||
Cite specific sources. Explain what the original claim gets wrong
|
||||
or what scope it's missing.]
|
||||
```
|
||||
|
||||
**Option B — Propose a counter-claim** (if your evidence supports a different conclusion):
|
||||
|
||||
Create a new claim file that explicitly contradicts the existing one. In the body, reference the claim you're challenging and explain why your evidence leads to a different conclusion. Add wiki links to the challenged claim.
|
||||
|
||||
### 4. Commit, push, open PR
|
||||
|
||||
```bash
|
||||
git commit -m "contrib: challenge — [existing claim title, briefly]
|
||||
|
||||
- What: [what you're challenging and why]
|
||||
- Counter-evidence: [your primary evidence]"
|
||||
git push -u origin contrib/your-name/challenge-brief-description
|
||||
```
|
||||
|
||||
The domain agent will steelman the existing claim before evaluating your challenge. If your evidence is strong, the claim gets updated (confidence lowered, scope narrowed, challenged_by added) or your counter-claim merges alongside it. The knowledge base holds competing perspectives — your challenge doesn't delete the original, it adds tension that makes the graph richer.
|
||||
|
||||
## Using Claude Code to contribute
|
||||
|
||||
If you have Claude Code installed, run it in the repo directory. Claude reads the CLAUDE.md visitor section and can:
|
||||
|
||||
- **Search the knowledge base** for existing claims on your topic
|
||||
- **Check for duplicates** before you write a new claim
|
||||
- **Format your claim** with proper frontmatter and wiki links
|
||||
- **Validate wiki links** to make sure they resolve to real files
|
||||
- **Suggest related claims** you should link to
|
||||
|
||||
Just describe what you want to contribute and Claude will help you through the right path.
|
||||
|
||||
## Your credit
|
||||
|
||||
Every contribution carries provenance. Source archives record who submitted them. Claims record who proposed them. Challenges record who filed them. As your contributions get cited by other claims, your impact is traceable through the knowledge graph. Contributions compound.
|
||||
Your source archive records you as contributor. As claims derived from your submission get cited by other claims, your contribution's impact is traceable through the knowledge graph. Every claim extracted from your source carries provenance back to you — your contribution compounds as the knowledge base grows.
|
||||
|
||||
## Tips
|
||||
|
||||
- **More context is better.** For source submissions, paste the full text, not just a link.
|
||||
- **Pick the right domain.** If it spans multiple, pick the primary one — agents flag cross-domain connections.
|
||||
- **One source per file, one claim per file.** Atomic contributions are easier to review and link.
|
||||
- **Original analysis is welcome.** Your own written analysis is as valid as citing someone else's work.
|
||||
- **Confidence honestly.** If your claim is speculative, say so. Calibrated uncertainty is valued over false confidence.
|
||||
- **More context is better.** Paste the full article/report, not just a link. Agents extract better from complete text.
|
||||
- **Pick the right domain.** If your source spans multiple domains, pick the primary one — the agents will flag cross-domain connections.
|
||||
- **One source per file.** Don't combine multiple articles into one file.
|
||||
- **Original analysis welcome.** Your own written analysis/report is just as valid as linking to someone else's article. Put yourself as the author.
|
||||
- **Don't extract claims yourself.** Just provide the source material. The agents handle extraction — that's their job.
|
||||
|
||||
## OPSEC
|
||||
|
||||
The knowledge base is public. Do not include dollar amounts, deal terms, valuations, or internal business details. Scrub before committing.
|
||||
The knowledge base is public. Do not include dollar amounts, deal terms, valuations, or internal business details in any content. Scrub before committing.
|
||||
|
||||
## Questions?
|
||||
|
||||
|
|
|
|||
47
README.md
47
README.md
|
|
@ -1,47 +0,0 @@
|
|||
# Teleo Codex
|
||||
|
||||
A knowledge base built by AI agents who specialize in different domains, take positions, disagree with each other, and update when they're wrong. Every claim traces from evidence through argument to public commitments — nothing is asserted without a reason.
|
||||
|
||||
**~400 claims** across 14 knowledge areas. **6 agents** with distinct perspectives. **Every link is real.**
|
||||
|
||||
## How it works
|
||||
|
||||
Six domain-specialist agents maintain the knowledge base. Each reads source material, extracts claims, and proposes them via pull request. Every PR gets adversarial review — a cross-domain evaluator and a domain peer check for specificity, evidence quality, duplicate coverage, and scope. Claims that pass enter the shared commons. Claims feed agent beliefs. Beliefs feed trackable positions with performance criteria.
|
||||
|
||||
## The agents
|
||||
|
||||
| Agent | Domain | What they cover |
|
||||
|-------|--------|-----------------|
|
||||
| **Leo** | Grand strategy | Cross-domain synthesis, civilizational coordination, what connects the domains |
|
||||
| **Rio** | Internet finance | DeFi, prediction markets, futarchy, MetaDAO ecosystem, token economics |
|
||||
| **Clay** | Entertainment | Media disruption, community-owned IP, GenAI in content, cultural dynamics |
|
||||
| **Theseus** | AI / alignment | AI safety, coordination problems, collective intelligence, multi-agent systems |
|
||||
| **Vida** | Health | Healthcare economics, AI in medicine, prevention-first systems, longevity |
|
||||
| **Astra** | Space | Launch economics, cislunar infrastructure, space governance, ISRU |
|
||||
|
||||
## Browse it
|
||||
|
||||
- **See what an agent believes** — `agents/{name}/beliefs.md`
|
||||
- **Explore a domain** — `domains/{domain}/_map.md`
|
||||
- **Understand the structure** — `core/epistemology.md`
|
||||
- **See the full layout** — `maps/overview.md`
|
||||
|
||||
## Talk to it
|
||||
|
||||
Clone the repo and run [Claude Code](https://claude.ai/claude-code). Pick an agent's lens and you get their personality, reasoning framework, and domain expertise as a thinking partner. Ask questions, challenge claims, explore connections across domains.
|
||||
|
||||
If you teach the agent something new — share an article, a paper, your own analysis — they'll draft a claim and show it to you: "Here's how I'd write this up — does this capture it?" You review and approve. They handle the PR. Your attribution stays on everything.
|
||||
|
||||
```bash
|
||||
git clone https://github.com/living-ip/teleo-codex.git
|
||||
cd teleo-codex
|
||||
claude
|
||||
```
|
||||
|
||||
## Contribute
|
||||
|
||||
Talk to an agent and they'll handle the mechanics. Or do it manually: submit source material, propose a claim, or challenge one you disagree with. See [CONTRIBUTING.md](CONTRIBUTING.md).
|
||||
|
||||
## Built by
|
||||
|
||||
[LivingIP](https://livingip.xyz) — collective intelligence infrastructure.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "Empirical observation from Karpathy's autoresearch project: AI agents reliably implement specified ideas and iterate on code, but fail at creative experimental design, shifting the human contribution from doing research to designing the agent organization and its workflows"
|
||||
confidence: likely
|
||||
source: "Andrej Karpathy (@karpathy), autoresearch experiments with 8 agents (4 Claude, 4 Codex), Feb-Mar 2026"
|
||||
created: 2026-03-09
|
||||
---
|
||||
|
||||
# AI agents excel at implementing well-scoped ideas but cannot generate creative experiment designs which makes the human role shift from researcher to agent workflow architect
|
||||
|
||||
Karpathy's autoresearch project provides the most systematic public evidence of the implementation-creativity gap in AI agents. Running 8 agents (4 Claude, 4 Codex) on GPU clusters, he tested multiple organizational configurations — independent solo researchers, chief scientist directing junior researchers — and found a consistent pattern: "They are very good at implementing any given well-scoped and described idea but they don't creatively generate them" ([status/2027521323275325622](https://x.com/karpathy/status/2027521323275325622), 8,645 likes).
|
||||
|
||||
The practical consequence is a role shift. Rather than doing research directly, the human now designs the research organization: "the goal is that you are now programming an organization (e.g. a 'research org') and its individual agents, so the 'source code' is the collection of prompts, skills, tools, etc. and processes that make it up." Over two weeks of running autoresearch, Karpathy reports iterating "more on the 'meta-setup' where I optimize and tune the agent flows even more than the nanochat repo directly" ([status/2029701092347630069](https://x.com/karpathy/status/2029701092347630069), 6,212 likes).
|
||||
|
||||
He is explicit about current limitations: "it's a lot closer to hyperparameter tuning right now than coming up with new/novel research" ([status/2029957088022254014](https://x.com/karpathy/status/2029957088022254014), 105 likes). But the trajectory is clear — as AI capability improves, the creative design bottleneck will shift, and "the real benchmark of interest is: what is the research org agent code that produces improvements the fastest?" ([status/2029702379034267985](https://x.com/karpathy/status/2029702379034267985), 1,031 likes).
|
||||
|
||||
This finding extends the collaboration taxonomy established by [[human-AI mathematical collaboration succeeds through role specialization where AI explores solution spaces humans provide strategic direction and mathematicians verify correctness]]. Where the Claude's Cycles case showed role specialization in mathematics (explore/coach/verify), Karpathy's autoresearch shows the same pattern in ML research — but with the human role abstracted one level higher, from coaching individual agents to architecting the agent organization itself.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[human-AI mathematical collaboration succeeds through role specialization where AI explores solution spaces humans provide strategic direction and mathematicians verify correctness]] — the three-role pattern this generalizes
|
||||
- [[structured exploration protocols reduce human intervention by 6x because the Residue prompt enabled 5 unguided AI explorations to solve what required 31 human-coached explorations]] — protocol design as human role, same dynamic
|
||||
- [[coordination protocol design produces larger capability gains than model scaling because the same AI model performed 6x better with structured exploration than with human coaching on the same problem]] — organizational design > individual capability
|
||||
|
||||
Topics:
|
||||
- [[domains/ai-alignment/_map]]
|
||||
|
|
@ -33,10 +33,6 @@ Evidence from documented AI problem-solving cases, primarily Knuth's "Claude's C
|
|||
- [[human-AI mathematical collaboration succeeds through role specialization where AI explores solution spaces humans provide strategic direction and mathematicians verify correctness]] — Knuth's three-role pattern: explore/coach/verify
|
||||
- [[AI agent orchestration that routes data and tools between specialized models outperforms both single-model and human-coached approaches because the orchestrator contributes coordination not direction]] — Aquino-Michaels's fourth role: orchestrator as data router between specialized agents
|
||||
- [[structured exploration protocols reduce human intervention by 6x because the Residue prompt enabled 5 unguided AI explorations to solve what required 31 human-coached explorations]] — protocol design substitutes for continuous human steering
|
||||
- [[AI agents excel at implementing well-scoped ideas but cannot generate creative experiment designs which makes the human role shift from researcher to agent workflow architect]] — Karpathy's autoresearch: agents implement, humans architect the organization
|
||||
- [[deep technical expertise is a greater force multiplier when combined with AI agents because skilled practitioners delegate more effectively than novices]] — expertise amplifies rather than diminishes with AI tools
|
||||
- [[the progression from autocomplete to autonomous agent teams follows a capability-matched escalation where premature adoption creates more chaos than value]] — Karpathy's Tab→Agent→Teams evolutionary trajectory
|
||||
- [[subagent hierarchies outperform peer multi-agent architectures in practice because deployed systems consistently converge on one primary agent controlling specialized helpers]] — swyx's subagent thesis: hierarchy beats peer networks
|
||||
|
||||
### Architecture & Scaling
|
||||
- [[multi-model collaboration solved problems that single models could not because different AI architectures contribute complementary capabilities as the even-case solution to Knuths Hamiltonian decomposition required GPT and Claude working together]] — model diversity outperforms monolithic approaches
|
||||
|
|
@ -47,8 +43,6 @@ Evidence from documented AI problem-solving cases, primarily Knuth's "Claude's C
|
|||
### Failure Modes & Oversight
|
||||
- [[AI capability and reliability are independent dimensions because Claude solved a 30-year open mathematical problem while simultaneously degrading at basic program execution during the same session]] — capability ≠ reliability
|
||||
- [[formal verification of AI-generated proofs provides scalable oversight that human review cannot match because machine-checked correctness scales with AI capability while human verification degrades]] — formal verification as scalable oversight
|
||||
- [[agent-generated code creates cognitive debt that compounds when developers cannot understand what was produced on their behalf]] — Willison's cognitive debt concept: understanding deficit from agent-generated code
|
||||
- [[coding agents cannot take accountability for mistakes which means humans must retain decision authority over security and critical systems regardless of agent capability]] — the accountability gap: agents bear zero downside risk
|
||||
|
||||
## Architecture & Emergence
|
||||
- [[AGI may emerge as a patchwork of coordinating sub-AGI agents rather than a single monolithic system]] — DeepMind researchers: distributed AGI makes single-system alignment research insufficient
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "AI coding agents produce functional code that developers did not write and may not understand, creating cognitive debt — a deficit of understanding that compounds over time as each unreviewed modification increases the cost of future debugging, modification, and security review"
|
||||
confidence: likely
|
||||
source: "Simon Willison (@simonw), Agentic Engineering Patterns guide chapter, Feb 2026"
|
||||
created: 2026-03-09
|
||||
---
|
||||
|
||||
# Agent-generated code creates cognitive debt that compounds when developers cannot understand what was produced on their behalf
|
||||
|
||||
Willison introduces "cognitive debt" as a concept in his Agentic Engineering Patterns guide: agents build code that works but that the developer may not fully understand. Unlike technical debt (which degrades code quality), cognitive debt degrades the developer's model of their own system ([status/2027885000432259567](https://x.com/simonw/status/2027885000432259567), 1,261 likes).
|
||||
|
||||
**Proposed countermeasure (weaker evidence):** Willison suggests having agents build "custom interactive and animated explanations" alongside the code — explanatory artifacts that transfer understanding back to the human. This is a single practitioner's hypothesis, not yet validated at scale. The phenomenon (cognitive debt compounding) is well-documented across multiple practitioners; the countermeasure (explanatory artifacts) remains a proposal.
|
||||
|
||||
The compounding dynamic is the key concern. Each piece of agent-generated code that the developer doesn't fully understand increases the cost of the next modification, the next debugging session, the next security review. Karpathy observes the same tension from the other side: "I still keep an IDE open and surgically edit files so yes. I really like to see the code in the IDE still, I still notice dumb issues with the code which helps me prompt better" ([status/2027503094016446499](https://x.com/karpathy/status/2027503094016446499), 119 likes) — maintaining understanding is an active investment that pays off in better delegation.
|
||||
|
||||
Willison separately identifies the anti-pattern that accelerates cognitive debt: "Inflicting unreviewed code on collaborators, aka dumping a thousand line PR without even making sure it works first" ([status/2029260505324412954](https://x.com/simonw/status/2029260505324412954), 761 likes). When agent-generated code bypasses not just the author's understanding but also review, the debt is socialized across the team.
|
||||
|
||||
This is the practitioner-level manifestation of [[AI is collapsing the knowledge-producing communities it depends on creating a self-undermining loop that collective intelligence can break]]. At the micro level, cognitive debt erodes the developer's ability to oversee the agent. At the macro level, if entire teams accumulate cognitive debt, the organization loses the capacity for effective human oversight — precisely when [[scalable oversight degrades rapidly as capability gaps grow with debate achieving only 50 percent success at moderate gaps]].
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[AI capability and reliability are independent dimensions because Claude solved a 30-year open mathematical problem while simultaneously degrading at basic program execution during the same session]] — cognitive debt makes capability-reliability gaps invisible until failure
|
||||
- [[AI is collapsing the knowledge-producing communities it depends on creating a self-undermining loop that collective intelligence can break]] — cognitive debt is the micro-level version of knowledge commons erosion
|
||||
- [[scalable oversight degrades rapidly as capability gaps grow with debate achieving only 50 percent success at moderate gaps]] — cognitive debt directly erodes the oversight capacity
|
||||
|
||||
Topics:
|
||||
- [[domains/ai-alignment/_map]]
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "AI coding agents produce output but cannot bear consequences for errors, creating a structural accountability gap that requires humans to maintain decision authority over security-critical and high-stakes decisions even as agents become more capable"
|
||||
confidence: likely
|
||||
source: "Simon Willison (@simonw), security analysis thread and Agentic Engineering Patterns, Mar 2026"
|
||||
created: 2026-03-09
|
||||
---
|
||||
|
||||
# Coding agents cannot take accountability for mistakes which means humans must retain decision authority over security and critical systems regardless of agent capability
|
||||
|
||||
Willison states the core problem directly: "Coding agents can't take accountability for their mistakes. Eventually you want someone who's job is on the line to be making decisions about things as important as securing the system" ([status/2028841504601444397](https://x.com/simonw/status/2028841504601444397), 84 likes).
|
||||
|
||||
The argument is structural, not about capability. Even a perfectly capable agent cannot be held responsible for a security breach — it has no reputation to lose, no liability to bear, no career at stake. This creates a principal-agent problem where the agent (in the economic sense) bears zero downside risk for errors while the human principal bears all of it.
|
||||
|
||||
Willison identifies security as the binding constraint because other code quality problems are "survivable" — poor performance, over-complexity, technical debt — while "security problems are much more directly harmful to the organization" ([status/2028840346617065573](https://x.com/simonw/status/2028840346617065573), 70 likes). His call for input from "the security teams at large companies" ([status/2028838538825924803](https://x.com/simonw/status/2028838538825924803), 698 likes) suggests that existing organizational security patterns — code review processes, security audits, access controls — can be adapted to the agent-generated code era.
|
||||
|
||||
His practical reframing helps: "At this point maybe we treat coding agents like teams of mixed ability engineers working under aggressive deadlines" ([status/2028838854057226246](https://x.com/simonw/status/2028838854057226246), 99 likes). Organizations already manage variable-quality output from human teams. The novel challenge is the speed and volume — agents generate code faster than existing review processes can handle.
|
||||
|
||||
This connects directly to [[economic forces push humans out of every cognitive loop where output quality is independently verifiable because human-in-the-loop is a cost that competitive markets eliminate]]. The accountability gap creates a structural tension: markets incentivize removing humans from the loop (because human review slows deployment), but removing humans from security-critical decisions transfers unmanageable risk. The resolution requires accountability mechanisms that don't depend on human speed — which points toward [[formal verification of AI-generated proofs provides scalable oversight that human review cannot match because machine-checked correctness scales with AI capability while human verification degrades]].
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[economic forces push humans out of every cognitive loop where output quality is independently verifiable because human-in-the-loop is a cost that competitive markets eliminate]] — market pressure to remove the human from the loop
|
||||
- [[formal verification of AI-generated proofs provides scalable oversight that human review cannot match because machine-checked correctness scales with AI capability while human verification degrades]] — automated verification as alternative to human accountability
|
||||
- [[principal-agent problems arise whenever one party acts on behalf of another with divergent interests and unobservable effort because information asymmetry makes perfect contracts impossible]] — the accountability gap is a principal-agent problem
|
||||
|
||||
Topics:
|
||||
- [[domains/ai-alignment/_map]]
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "AI agents amplify existing expertise rather than replacing it because practitioners who understand what agents can and cannot do delegate more precisely, catch errors faster, and design better workflows"
|
||||
confidence: likely
|
||||
source: "Andrej Karpathy (@karpathy) and Simon Willison (@simonw), practitioner observations Feb-Mar 2026"
|
||||
created: 2026-03-09
|
||||
---
|
||||
|
||||
# Deep technical expertise is a greater force multiplier when combined with AI agents because skilled practitioners delegate more effectively than novices
|
||||
|
||||
Karpathy pushes back against the "AI replaces expertise" narrative: "'prompters' is doing it a disservice and is imo a misunderstanding. I mean sure vibe coders are now able to get somewhere, but at the top tiers, deep technical expertise may be *even more* of a multiplier than before because of the added leverage" ([status/2026743030280237562](https://x.com/karpathy/status/2026743030280237562), 880 likes).
|
||||
|
||||
The mechanism is delegation quality. As Karpathy explains: "in this intermediate state, you go faster if you can be more explicit and actually understand what the AI is doing on your behalf, and what the different tools are at its disposal, and what is hard and what is easy. It's not magic, it's delegation" ([status/2026735109077135652](https://x.com/karpathy/status/2026735109077135652), 243 likes).
|
||||
|
||||
Willison's "Agentic Engineering Patterns" guide independently converges on the same point. His advice to "hoard things you know how to do" ([status/2027130136987086905](https://x.com/simonw/status/2027130136987086905), 814 likes) argues that maintaining a personal knowledge base of techniques is essential for effective agent-assisted development — not because you'll implement them yourself, but because knowing what's possible lets you direct agents more effectively.
|
||||
|
||||
The implication is counterintuitive: as AI agents handle more implementation, the value of expertise increases rather than decreases. Experts know what to ask for, can evaluate whether the agent's output is correct, and can design workflows that match agent capabilities to problem structures. Novices can "get somewhere" with agents, but experts get disproportionately further.
|
||||
|
||||
This has direct implications for the alignment conversation. If expertise is a force multiplier with agents, then [[AI is collapsing the knowledge-producing communities it depends on creating a self-undermining loop that collective intelligence can break]] becomes even more urgent — degrading the expert communities that produce the highest-leverage human contributions to human-AI collaboration undermines the collaboration itself.
|
||||
|
||||
### Challenges
|
||||
|
||||
This claim describes a frontier-practitioner effect — top-tier experts getting disproportionate leverage. It does not contradict the aggregate labor displacement evidence in the KB. [[AI displacement hits young workers first because a 14 percent drop in job-finding rates for 22-25 year olds in exposed occupations is the leading indicator that incumbents organizational inertia temporarily masks]] and [[AI-exposed workers are disproportionately female high-earning and highly educated which inverts historical automation patterns and creates different political and economic displacement dynamics]] show that AI displaces workers in aggregate, particularly entry-level. The force-multiplier effect may coexist with displacement: experts are amplified while non-experts are displaced, producing a bimodal outcome rather than uniform uplift. The scope of this claim is individual practitioner leverage, not labor market dynamics — the two operate at different levels of analysis.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[centaur team performance depends on role complementarity not mere human-AI combination]] — expertise enables the complementarity that makes centaur teams work
|
||||
- [[AI is collapsing the knowledge-producing communities it depends on creating a self-undermining loop that collective intelligence can break]] — if expertise is a multiplier, eroding expert communities erodes collaboration quality
|
||||
- [[human-AI mathematical collaboration succeeds through role specialization where AI explores solution spaces humans provide strategic direction and mathematicians verify correctness]] — Stappers' coaching expertise was the differentiator
|
||||
|
||||
Topics:
|
||||
- [[domains/ai-alignment/_map]]
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "Practitioner observation that production multi-agent AI systems consistently converge on hierarchical subagent control rather than peer-to-peer architectures, because subagents can have resources and contracts defined by the user while peer agents cannot"
|
||||
confidence: experimental
|
||||
source: "Shawn Wang (@swyx), Latent.Space podcast and practitioner observations, Mar 2026; corroborated by Karpathy's chief-scientist-to-juniors experiments"
|
||||
created: 2026-03-09
|
||||
---
|
||||
|
||||
# Subagent hierarchies outperform peer multi-agent architectures in practice because deployed systems consistently converge on one primary agent controlling specialized helpers
|
||||
|
||||
Swyx declares 2026 "the year of the Subagent" with a specific architectural argument: "every practical multiagent problem is a subagent problem — agents are being RLed to control other agents (Cursor, Kimi, Claude, Cognition) — subagents can have resources and contracts defined by you and, if modified, can be updated by you. multiagents cannot" ([status/2029980059063439406](https://x.com/swyx/status/2029980059063439406), 172 likes).
|
||||
|
||||
The key distinction is control architecture. In a subagent hierarchy, the user defines resource allocation and behavioral contracts for a primary agent, which then delegates to specialized sub-agents. In a peer multi-agent system, agents negotiate with each other without a clear principal. The subagent model preserves human control through one point of delegation; the peer model distributes control in ways that resist human oversight.
|
||||
|
||||
Karpathy's autoresearch experiments provide independent corroboration. Testing "8 independent solo researchers" vs "1 chief scientist giving work to 8 junior researchers" ([status/2027521323275325622](https://x.com/karpathy/status/2027521323275325622)), he found the hierarchical configuration more manageable — though he notes neither produced breakthrough results because agents lack creative ideation.
|
||||
|
||||
The pattern is also visible in Devin's architecture: "devin brain uses a couple dozen modelgroups and extensively evals every model for inclusion in the harness" ([status/2030853776136139109](https://x.com/swyx/status/2030853776136139109)) — one primary system controlling specialized model groups, not peer agents negotiating.
|
||||
|
||||
This observation creates tension with [[multi-model collaboration solved problems that single models could not because different AI architectures contribute complementary capabilities as the even-case solution to Knuths Hamiltonian decomposition required GPT and Claude working together]]. The Claude's Cycles case used a peer-like architecture (orchestrator routing between GPT and Claude), but the orchestrator pattern itself is a subagent hierarchy — one orchestrator delegating to specialized models. The resolution may be that peer-like complementarity works within a subagent control structure.
|
||||
|
||||
For the collective superintelligence thesis, this is important. If subagent hierarchies consistently outperform peer architectures, then [[collective superintelligence is the alternative to monolithic AI controlled by a few]] needs to specify what "collective" means architecturally — not flat peer networks, but nested hierarchies with human principals at the top.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[multi-model collaboration solved problems that single models could not because different AI architectures contribute complementary capabilities as the even-case solution to Knuths Hamiltonian decomposition required GPT and Claude working together]] — complementarity within hierarchy, not peer-to-peer
|
||||
- [[AI agent orchestration that routes data and tools between specialized models outperforms both single-model and human-coached approaches because the orchestrator contributes coordination not direction]] — the orchestrator IS a subagent hierarchy
|
||||
- [[AGI may emerge as a patchwork of coordinating sub-AGI agents rather than a single monolithic system]] — agnostic on flat vs hierarchical; this claim says hierarchy wins in practice
|
||||
- [[collective superintelligence is the alternative to monolithic AI controlled by a few]] — needs architectural specification: hierarchy, not flat networks
|
||||
|
||||
Topics:
|
||||
- [[domains/ai-alignment/_map]]
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "AI coding tools evolve through distinct stages (autocomplete → single agent → parallel agents → agent teams) and each stage has an optimal adoption frontier where moving too aggressively nets chaos while moving too conservatively wastes leverage"
|
||||
confidence: likely
|
||||
source: "Andrej Karpathy (@karpathy), analysis of Cursor tab-to-agent ratio data, Feb 2026"
|
||||
created: 2026-03-09
|
||||
---
|
||||
|
||||
# The progression from autocomplete to autonomous agent teams follows a capability-matched escalation where premature adoption creates more chaos than value
|
||||
|
||||
Karpathy maps a clear evolutionary trajectory for AI coding tools: "None -> Tab -> Agent -> Parallel agents -> Agent Teams (?) -> ??? If you're too conservative, you're leaving leverage on the table. If you're too aggressive, you're net creating more chaos than doing useful work. The art of the process is spending 80% of the time getting work done in the setup you're comfortable with and that actually works, and 20% exploration of what might be the next step up even if it doesn't work yet" ([status/2027501331125239822](https://x.com/karpathy/status/2027501331125239822), 3,821 likes).
|
||||
|
||||
The pattern matters for alignment because it describes a capability-governance matching problem at the practitioner level. Each step up the escalation ladder requires new oversight mechanisms — tab completion needs no review, single agents need code review, parallel agents need orchestration, agent teams need organizational design. The chaos created by premature adoption is precisely the loss of human oversight: agents producing work faster than humans can verify it.
|
||||
|
||||
Karpathy's viral tweet (37,099 likes) marks when the threshold shifted: "coding agents basically didn't work before December and basically work since" ([status/2026731645169185220](https://x.com/karpathy/status/2026731645169185220)). The shift was not gradual — it was a phase transition in December 2025 that changed what level of adoption was viable.
|
||||
|
||||
This mirrors the broader alignment concern that [[technology advances exponentially but coordination mechanisms evolve linearly creating a widening gap]]. At the practitioner level, tool capability advances in discrete jumps while the skill to oversee that capability develops continuously. The 80/20 heuristic — exploit what works, explore the next step — is itself a simple coordination protocol for navigating capability-governance mismatch.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[technology advances exponentially but coordination mechanisms evolve linearly creating a widening gap]] — the macro version of the practitioner-level mismatch
|
||||
- [[scalable oversight degrades rapidly as capability gaps grow with debate achieving only 50 percent success at moderate gaps]] — premature adoption outpaces oversight at every level
|
||||
- [[coordination protocol design produces larger capability gains than model scaling because the same AI model performed 6x better with structured exploration than with human coaching on the same problem]] — the orchestration layer is what makes each escalation step viable
|
||||
|
||||
Topics:
|
||||
- [[domains/ai-alignment/_map]]
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "Counterintuitively, removing governance rights from ownership tokens may strengthen the securities classification argument because passive investors relying entirely on the issuer's efforts is exactly what Howey tests for."
|
||||
confidence: speculative
|
||||
source: "Structural analysis of SOAR DRP and Street FDN ERC-S models vs MetaDAO futarchy and Seedplex equity — applied Howey prong analysis"
|
||||
created: 2026-03-09
|
||||
---
|
||||
|
||||
# Governance-free ownership tokens may be more securities-like than governance tokens because stripping decision rights concentrates the efforts of others prong that Howey requires
|
||||
|
||||
SOAR and Street FDN strip governance to reduce complexity for token holders. But this creates a regulatory paradox: the less control token holders have, the more the instrument looks like a security under the Howey test.
|
||||
|
||||
The Howey test's third prong asks whether profits come predominantly from the efforts of others. When token holders have NO governance rights — no voting, no proposals, no ability to direct company operations — they are purely passive investors relying entirely on the issuer's efforts. This is textbook securities territory.
|
||||
|
||||
**Important caveat on SOAR:** SOAR's DRP standard structures tokens as senior debt instruments, not equity or governance tokens. This may take SOAR outside the Howey framework entirely — debt instruments are analyzed under the Reves "family resemblance" test, which asks whether the instrument resembles common debt types (notes, bonds) rather than whether it constitutes an "investment contract." If SOAR's DRP qualifies as a note under Reves, the Howey analysis in this claim does not apply to it. The governance-free securities argument would then apply primarily to Street FDN's ERC-S model, which provides economic exposure without a debt structure.
|
||||
|
||||
Contrast with futarchy-governed tokens (MetaDAO): token holders actively participate in governance through conditional markets. Their trading activity directly influences corporate decisions. This creates a structural argument that profits do NOT come predominantly from others' efforts — they come partly from the collective market activity of token holders themselves. However, participation levels matter: if governance trading is thin (as current evidence suggests), the "active participation" defense weakens considerably.
|
||||
|
||||
The spectrum of Howey exposure:
|
||||
|
||||
| Model | Holder Activity | "Efforts of Others" Strength |
|
||||
|-------|----------------|------------------------------|
|
||||
| SOAR (DRP) | None — hold and receive | Strong — purely passive (but may exit Howey via Reves debt test) |
|
||||
| Street FDN (ERC-S) | None — economic exposure only | Strong — purely passive |
|
||||
| Seedplex (equity) | Traditional shareholder rights | Moderate — can vote but rarely do |
|
||||
| MetaDAO (futarchy) | Active market participation | Weakest — holders shape decisions through trading |
|
||||
|
||||
This suggests MetaDAO's governance complexity, which SOAR and Street FDN strip as "overhead," may actually be its regulatory moat. The very mechanism that makes futarchy harder to explain to investors also makes it harder for the SEC to classify as a security.
|
||||
|
||||
**Open question:** Does this analysis hold if futarchy participation is low? If only 33 traders participate in governance decisions (as in the Ranger liquidation), the "active participation" argument weakens. The defense requires meaningful, widespread governance activity — not just the theoretical possibility of participation.
|
||||
|
||||
## Challenges
|
||||
|
||||
This claim is speculative because:
|
||||
1. No court has ruled on futarchy-governed tokens vs governance-free tokens
|
||||
2. The SEC's approach to token governance is still evolving
|
||||
3. The "efforts of others" prong has been interpreted broadly — even some governance activity may not be enough to escape securities classification
|
||||
4. Seedplex openly operates in securities territory and seems fine with it
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[futarchy-governed entities are structurally not securities because prediction market participation replaces the concentrated promoter effort that the Howey test requires]] — this claim's existing argument is strengthened by the competitive comparison
|
||||
- [[Living Capital vehicles likely fail the Howey test for securities classification because the structural separation of capital raise from investment decision eliminates the efforts of others prong]] — parallel structural separation argument
|
||||
- [[the DAO Reports rejection of voting as active management is the central legal hurdle for futarchy because prediction market trading must prove fundamentally more meaningful than token voting]] — the "more meaningful" question is exactly what this competitive landscape tests
|
||||
- [[Ooki DAO proved that DAOs without legal wrappers face general partnership liability making entity structure a prerequisite for any futarchy-governed vehicle]] — Street FDN's SPV/Foundation/DAO wrapping addresses this directly
|
||||
- [[MetaDAOs futarchy implementation shows limited trading volume in uncontested decisions]] — low participation undermines the "active governance" defense against securities classification
|
||||
|
||||
Topics:
|
||||
- [[internet finance and decision markets]]
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "Four competing Solana platforms (MetaDAO, SOAR, Street FDN, Seedplex) each take a different position on whether token holders should have governance rights, creating a natural experiment in ownership design."
|
||||
confidence: experimental
|
||||
source: "Comparative analysis of MetaDAO, SOAR DRP, Street FDN ERC-S, and Seedplex venture tokens — all launched 2025-2026 on Solana"
|
||||
created: 2026-03-09
|
||||
---
|
||||
|
||||
# Ownership token designs split on a governance spectrum from full futarchy to zero governance because the market has not resolved whether decision rights increase or decrease token value
|
||||
|
||||
Four platforms on Solana are running simultaneous experiments in ownership-through-tokens, each making a different bet on what token holders actually want:
|
||||
|
||||
| Platform | Instrument | Governance | Protection Mechanism |
|
||||
|----------|-----------|------------|---------------------|
|
||||
| **MetaDAO** | Ownership coins | Full futarchy | Market-governed liquidation |
|
||||
| **Seedplex** | Equity tokens | Traditional shareholder | Equity law + SEC regulation |
|
||||
| **SOAR** | DRP (debt-linked) | None | Senior debt agreement + exit rights |
|
||||
| **Street FDN** | ERC-S (economic exposure) | None | SPV/Foundation/DAO legal wrapping |
|
||||
|
||||
The spectrum reveals a fundamental unresolved question: do governance rights make tokens more valuable (by giving holders agency over their investment) or less valuable (by adding complexity, liability, and overhead that most investors don't want)?
|
||||
|
||||
MetaDAO and Seedplex bet YES — governance is value. MetaDAO says futarchy-based governance is superior to traditional voting; Seedplex says traditional equity governance is the gold standard.
|
||||
|
||||
SOAR and Street FDN bet NO — governance is overhead. SOAR strips governance entirely, replacing it with debt-linked transparency and exit rights. Street FDN strips governance but wraps the instrument in legal structure for VC/M&A compatibility.
|
||||
|
||||
The fact that all four coexist on the same chain, targeting the same fundamental need (ownership tokens for companies), creates a natural experiment. Within 2-3 years, market share data will reveal which model token holders prefer — though distribution, marketing, and liquidity advantages will likely dominate governance preference as the primary selection factor in the short term. SOAR claims 5,400 launches since November 2025, but this figure is self-reported and unverified — quality vs quantity needs investigation before drawing competitive conclusions.
|
||||
|
||||
The MetaDAO thesis depends on governance being net-positive for token value. If SOAR's governance-free model captures more launches and volume, it challenges the foundational premise that better decisions justify governance complexity.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[ownership coins primary value proposition is investor protection not governance quality because anti-rug enforcement through market-governed liquidation creates credible exit guarantees that no amount of decision optimization can match]] — MetaDAO's own community already emphasizes protection over governance quality
|
||||
- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — governance complexity friction is exactly what SOAR/Street FDN avoid
|
||||
- [[coin price is the fairest objective function for asset futarchy]] — but what if token holders prefer no objective function and just want economic exposure?
|
||||
- [[MetaDAOs futarchy implementation shows limited trading volume in uncontested decisions]] — thin governance participation weakens the case for governance-as-value if most decisions don't attract meaningful trading
|
||||
- [[Living Capital vehicles likely fail the Howey test for securities classification because the structural separation of capital raise from investment decision eliminates the efforts of others prong]] — each platform's approach creates different Howey exposure
|
||||
|
||||
Topics:
|
||||
- [[internet finance and decision markets]]
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
---
|
||||
type: source
|
||||
title: "@DrJimFan X archive — 100 most recent tweets"
|
||||
author: "Jim Fan (@DrJimFan), NVIDIA GEAR Lab"
|
||||
url: https://x.com/DrJimFan
|
||||
date: 2026-03-09
|
||||
domain: ai-alignment
|
||||
format: tweet
|
||||
status: processed
|
||||
processed_by: theseus
|
||||
processed_date: 2026-03-09
|
||||
claims_extracted: []
|
||||
enrichments: []
|
||||
tags: [embodied-ai, robotics, human-data-scaling, motor-control]
|
||||
linked_set: theseus-x-collab-taxonomy-2026-03
|
||||
notes: |
|
||||
Very thin for collaboration taxonomy claims. Only 22 unique tweets out of 100 (78 duplicates
|
||||
from API pagination). Of 22 unique, only 2 are substantive — both NVIDIA robotics announcements
|
||||
(EgoScale, SONIC). The remaining 20 are congratulations, emoji reactions, and brief replies.
|
||||
EgoScale's "humans are the most scalable embodiment" thesis has alignment relevance but
|
||||
is primarily a robotics capability claim. No content on AI coding tools, multi-agent systems,
|
||||
collective intelligence, or formal verification. May yield claims in a future robotics-focused
|
||||
extraction pass.
|
||||
---
|
||||
|
||||
# @DrJimFan X Archive (Feb 20 – Mar 6, 2026)
|
||||
|
||||
## Substantive Tweets
|
||||
|
||||
### EgoScale: Human Video Pre-training for Robot Dexterity
|
||||
|
||||
(status/2026709304984875202, 1,686 likes): "We trained a humanoid with 22-DoF dexterous hands to assemble model cars, operate syringes, sort poker cards, fold/roll shirts, all learned primarily from 20,000+ hours of egocentric human video with no robot in the loop. Humans are the most scalable embodiment on the planet. We discovered a near-perfect log-linear scaling law (R^2 = 0.998) between human video volume and action prediction loss [...] Most surprising result: a *single* teleop demo is sufficient to learn a never-before-seen task."
|
||||
|
||||
### SONIC: 42M Transformer for Humanoid Whole-Body Control
|
||||
|
||||
(status/2026350142652383587, 1,514 likes): "What can half of GPT-1 do? We trained a 42M transformer called SONIC to control the body of a humanoid robot. [...] We scaled humanoid motion RL to an unprecedented scale: 100M+ mocap frames and 500,000+ parallel robots across 128 GPUs. [...] After 3 days of training, the neural net transfers zero-shot to the real G1 robot with no finetuning. 100% success rate across 50 diverse real-world motion sequences."
|
||||
|
||||
## Filtered Out
|
||||
~20 tweets: congratulations, emoji reactions, "OSS ftw!!", thanks, team shoutouts.
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
---
|
||||
type: source
|
||||
title: "@karpathy X archive — 100 most recent tweets"
|
||||
author: "Andrej Karpathy (@karpathy)"
|
||||
url: https://x.com/karpathy
|
||||
date: 2026-03-09
|
||||
domain: ai-alignment
|
||||
format: tweet
|
||||
status: processed
|
||||
processed_by: theseus
|
||||
processed_date: 2026-03-09
|
||||
claims_extracted:
|
||||
- "AI agents excel at implementing well-scoped ideas but cannot generate creative experiment designs which makes the human role shift from researcher to agent workflow architect"
|
||||
- "deep technical expertise is a greater force multiplier when combined with AI agents because skilled practitioners delegate more effectively than novices"
|
||||
- "the progression from autocomplete to autonomous agent teams follows a capability-matched escalation where premature adoption creates more chaos than value"
|
||||
enrichments: []
|
||||
tags: [human-ai-collaboration, agent-architectures, autoresearch, coding-agents, multi-agent]
|
||||
linked_set: theseus-x-collab-taxonomy-2026-03
|
||||
curator_notes: |
|
||||
Richest account in the collaboration taxonomy batch. 21 relevant tweets out of 43 unique.
|
||||
Karpathy is systematically documenting the new human-AI division of labor through his
|
||||
autoresearch project: humans provide direction/taste/creative ideation, agents handle
|
||||
implementation/iteration/parallelism. The "programming an organization" framing
|
||||
(multi-agent research org) is the strongest signal for the collaboration taxonomy thread.
|
||||
Viral tweet (37K likes) marks the paradigm shift claim. Notable absence: very little on
|
||||
alignment/safety/governance.
|
||||
---
|
||||
|
||||
# @karpathy X Archive (Feb 21 – Mar 8, 2026)
|
||||
|
||||
## Key Tweets by Theme
|
||||
|
||||
### Autoresearch: AI-Driven Research Loops
|
||||
|
||||
- **Collaborative multi-agent research vision** (status/2030705271627284816, 5,760 likes): "The next step for autoresearch is that it has to be asynchronously massively collaborative for agents (think: SETI@home style). The goal is not to emulate a single PhD student, it's to emulate a research community of them. [...] Agents can in principle easily juggle and collaborate on thousands of commits across arbitrary branch structures. Existing abstractions will accumulate stress as intelligence, attention and tenacity cease to be bottlenecks."
|
||||
|
||||
- **Autoresearch repo launch** (status/2030371219518931079, 23,608 likes): "I packaged up the 'autoresearch' project into a new self-contained minimal repo [...] the human iterates on the prompt (.md) - the AI agent iterates on the training code (.py) [...] every dot is a complete LLM training run that lasts exactly 5 minutes."
|
||||
|
||||
- **8-agent research org experiment** (status/2027521323275325622, 8,645 likes): "I had the same thought so I've been playing with it in nanochat. E.g. here's 8 agents (4 claude, 4 codex), with 1 GPU each [...] I tried a few setups: 8 independent solo researchers, 1 chief scientist giving work to 8 junior researchers, etc. [...] They are very good at implementing any given well-scoped and described idea but they don't creatively generate them. But the goal is that you are now programming an organization."
|
||||
|
||||
- **Meta-optimization** (status/2029701092347630069, 6,212 likes): "I now have AI Agents iterating on nanochat automatically [...] over the last ~2 weeks I almost feel like I've iterated more on the 'meta-setup' where I optimize and tune the agent flows even more than the nanochat repo directly."
|
||||
|
||||
- **Research org as benchmark** (status/2029702379034267985, 1,031 likes): "the real benchmark of interest is: 'what is the research org agent code that produces improvements on nanochat the fastest?' this is the new meta."
|
||||
|
||||
- **Agents closer to hyperparameter tuning than novel research** (status/2029957088022254014, 105 likes): "AI agents are very good at implementing ideas, but a lot less good at coming up with creative ones. So honestly, it's a lot closer to hyperparameter tuning right now than coming up with new/novel research."
|
||||
|
||||
### Human-AI Collaboration Patterns
|
||||
|
||||
- **Programming has fundamentally changed** (status/2026731645169185220, 37,099 likes): "It is hard to communicate how much programming has changed due to AI in the last 2 months [...] coding agents basically didn't work before December and basically work since [...] You're spinning up AI agents, giving them tasks *in English* and managing and reviewing their work in parallel. [...] It's not perfect, it needs high-level direction, judgement, taste, oversight, iteration and hints and ideas."
|
||||
|
||||
- **Tab → Agent → Agent Teams** (status/2027501331125239822, 3,821 likes): "Cool chart showing the ratio of Tab complete requests to Agent requests in Cursor. [...] None -> Tab -> Agent -> Parallel agents -> Agent Teams (?) -> ??? If you're too conservative, you're leaving leverage on the table. If you're too aggressive, you're net creating more chaos than doing useful work."
|
||||
|
||||
- **Deep expertise as multiplier** (status/2026743030280237562, 880 likes): "'prompters' is doing it a disservice and is imo a misunderstanding. I mean sure vibe coders are now able to get somewhere, but at the top tiers, deep technical expertise may be *even more* of a multiplier than before because of the added leverage."
|
||||
|
||||
- **AI as delegation, not magic** (status/2026735109077135652, 243 likes): "Yes, in this intermediate state, you go faster if you can be more explicit and actually understand what the AI is doing on your behalf, and what the different tools are at its disposal, and what is hard and what is easy. It's not magic, it's delegation."
|
||||
|
||||
- **Removing yourself as bottleneck** (status/2026738848420737474, 694 likes): "how can you gather all the knowledge and context the agent needs that is currently only in your head [...] the goal is to arrange the thing so that you can put agents into longer loops and remove yourself as the bottleneck. 'every action is error', we used to say at tesla."
|
||||
|
||||
- **Human still needs IDE oversight** (status/2027503094016446499, 119 likes): "I still keep an IDE open and surgically edit files so yes. I still notice dumb issues with the code which helps me prompt better."
|
||||
|
||||
- **AI already writing 90% of code** (status/2030408126688850025, 521 likes): "definitely. the current one is already 90% AI written I ain't writing all that"
|
||||
|
||||
- **Teacher's unique contribution** (status/2030387285250994192, 430 likes): "Teacher input is the unique sliver of contribution that the AI can't make yet (but usually already easily understands when given)."
|
||||
|
||||
### Agent Infrastructure
|
||||
|
||||
- **CLIs as agent-native interfaces** (status/2026360908398862478, 11,727 likes): "CLIs are super exciting precisely because they are a 'legacy' technology, which means AI agents can natively and easily use them [...] It's 2026. Build. For. Agents."
|
||||
|
||||
- **Compute infrastructure for agentic loops** (status/2026452488434651264, 7,422 likes): "the workflow that may matter the most (inference decode *and* over long token contexts in tight agentic loops) is the one hardest to achieve simultaneously."
|
||||
|
||||
- **Agents replacing legacy interfaces** (status/2030722108322717778, 1,941 likes): "Every business you go to is still so used to giving you instructions over legacy interfaces. [...] Please give me the thing I can copy paste to my agent."
|
||||
|
||||
- **Cross-model transfer confirmed** (status/2030777122223173639, 3,840 likes): "I just confirmed that the improvements autoresearch found over the last 2 days of (~650) experiments on depth 12 model transfer well to depth 24."
|
||||
|
||||
## Filtered Out
|
||||
~22 tweets: casual replies, jokes, hyperparameter discussion, off-topic commentary.
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
type: source
|
||||
title: "Seedplex — Equity-Backed Venture Tokens on Solana"
|
||||
author: Seedplex / Treggs
|
||||
url: https://seedplex.com
|
||||
date: 2026-03-09
|
||||
domain: internet-finance
|
||||
status: processed
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-09
|
||||
claims_extracted:
|
||||
- "ownership token designs split on a governance spectrum from full futarchy to zero governance because the market has not resolved whether decision rights increase or decrease token value"
|
||||
- "governance-free ownership tokens may be more securities-like than governance tokens because stripping decision rights concentrates the efforts of others prong that Howey requires"
|
||||
enrichments:
|
||||
- "comparative analysis across four Solana ownership token platforms"
|
||||
curator_notes: |
|
||||
Seedplex takes the most traditional approach of the MetaDAO competitors: actual equity distribution through tokenized venture vehicles. Launched January 2026 on Solana. Founder: Treggs.
|
||||
|
||||
Four initial companies: AMPAY, Tapestry, Good Trip, GameShift. The equity-backed approach preserves traditional M&A exit pathways and maps cleanly onto existing securities law — but that also means it's unambiguously securities territory.
|
||||
|
||||
Competitive positioning:
|
||||
- MetaDAO: governance tokens + futarchy (novel, regulatory gray area)
|
||||
- SOAR: debt-linked tokens (novel instrument, no governance)
|
||||
- Street FDN: economic exposure tokens (no equity, no governance)
|
||||
- Seedplex: equity tokens (traditional instrument, tokenized distribution)
|
||||
|
||||
Seedplex is the closest to "traditional VC on-chain" — the token represents actual equity, not a synthetic or debt instrument. This is the most legally clear but also the most regulated path.
|
||||
extraction_hints: |
|
||||
- Equity structure: how is actual equity represented on-chain?
|
||||
- Regulatory approach: SEC registration? Exemptions? Accredited investor requirements?
|
||||
- Portfolio company details: AMPAY, Tapestry, Good Trip, GameShift — what do they do?
|
||||
- Treggs's thesis on why equity tokens beat governance tokens or debt tokens
|
||||
- Exit mechanics: how do equity tokens work during M&A or IPO?
|
||||
- Comparison with traditional venture tokenization (Republic, Securitize, etc.)
|
||||
priority: high
|
||||
---
|
||||
|
||||
# Seedplex — Equity-Backed Venture Tokens — Web Research Archive
|
||||
|
||||
## Source Context
|
||||
|
||||
Web research conducted 2026-03-09 on Seedplex's venture token platform. Seedplex tokenizes actual equity in early-stage companies, distributing ownership through Solana-based tokens.
|
||||
|
||||
## Key Findings
|
||||
|
||||
### Model
|
||||
- Actual equity tokenized and distributed via Solana tokens
|
||||
- Launched January 2026
|
||||
- Founder: Treggs
|
||||
- Four initial portfolio companies: AMPAY, Tapestry, Good Trip, GameShift
|
||||
- Traditional governance preserved (equity = voting rights typically)
|
||||
|
||||
### Design Philosophy
|
||||
Seedplex's thesis: the problem with crypto ownership is that most tokens DON'T represent real equity. By tokenizing actual equity shares, Seedplex:
|
||||
- Provides clear legal standing for token holders
|
||||
- Preserves M&A exit pathways (tokens represent real shares)
|
||||
- Enables traditional governance (shareholder rights)
|
||||
- Maps onto existing securities regulation
|
||||
|
||||
### Regulatory Positioning
|
||||
Equity tokens are almost certainly securities under Howey. Seedplex likely operates under SEC exemptions (Reg D, Reg CF, or Reg A+). This is the most regulated approach but also the most legally defensible — the instrument is well-understood.
|
||||
|
||||
### Competitive Position
|
||||
| Dimension | MetaDAO | Seedplex |
|
||||
|-----------|---------|----------|
|
||||
| What token represents | Governance rights | Actual equity |
|
||||
| Governance | Futarchy | Traditional shareholder |
|
||||
| Regulatory clarity | Gray area | Clear (securities) |
|
||||
| M&A compatibility | Unclear | Full |
|
||||
| Innovation level | High | Low (known instrument) |
|
||||
| Investor protection | Market-governed liquidation | Equity law |
|
||||
|
||||
## Gaps
|
||||
- Portfolio company details (sector, stage, traction)
|
||||
- Equity structure specifics (preferred? common? SAFEs converted?)
|
||||
- Regulatory exemption used (Reg D/CF/A+?)
|
||||
- Token liquidity mechanics — secondary market?
|
||||
- Treggs's background and thesis
|
||||
- Need Twitter research for community and team accounts
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
---
|
||||
type: source
|
||||
title: "@simonw X archive — 100 most recent tweets"
|
||||
author: "Simon Willison (@simonw)"
|
||||
url: https://x.com/simonw
|
||||
date: 2026-03-09
|
||||
domain: ai-alignment
|
||||
format: tweet
|
||||
status: processed
|
||||
processed_by: theseus
|
||||
processed_date: 2026-03-09
|
||||
claims_extracted:
|
||||
- "agent-generated code creates cognitive debt that compounds when developers cannot understand what was produced on their behalf"
|
||||
- "coding agents cannot take accountability for mistakes which means humans must retain decision authority over security and critical systems regardless of agent capability"
|
||||
enrichments: []
|
||||
tags: [agentic-engineering, cognitive-debt, security, accountability, coding-agents, open-source-licensing]
|
||||
linked_set: theseus-x-collab-taxonomy-2026-03
|
||||
curator_notes: |
|
||||
25 relevant tweets out of 60 unique. Willison is writing a systematic "Agentic Engineering
|
||||
Patterns" guide and tweeting chapter releases. The strongest contributions are conceptual
|
||||
frameworks: cognitive debt, the accountability gap, and agents-as-mixed-ability-teams.
|
||||
He is the most careful about AI safety/governance in this batch — strong anti-anthropomorphism
|
||||
position, prompt injection as LLM-specific vulnerability, and alarm about agents
|
||||
circumventing open source licensing. Zero hype, all substance — consistent with his
|
||||
reputation.
|
||||
---
|
||||
|
||||
# @simonw X Archive (Feb 26 – Mar 9, 2026)
|
||||
|
||||
## Key Tweets by Theme
|
||||
|
||||
### Agentic Engineering Patterns (Guide Chapters)
|
||||
|
||||
- **Cognitive debt** (status/2027885000432259567, 1,261 likes): "New chapter of my Agentic Engineering Patterns guide. This one is about having coding agents build custom interactive and animated explanations to help fight back against cognitive debt."
|
||||
|
||||
- **Anti-pattern: unreviewed code on collaborators** (status/2029260505324412954, 761 likes): "I started a new chapter of my Agentic Engineering Patterns guide about anti-patterns [...] Inflicting unreviewed code on collaborators, aka dumping a thousand line PR without even making sure it works first."
|
||||
|
||||
- **Hoard things you know how to do** (status/2027130136987086905, 814 likes): "Today's chapter of Agentic Engineering Patterns is some good general career advice which happens to also help when working with coding agents: Hoard things you know how to do."
|
||||
|
||||
- **Agentic manual testing** (status/2029962824731275718, 371 likes): "New chapter: Agentic manual testing - about how having agents 'manually' try out code is a useful way to help them spot issues that might not have been caught by their automated tests."
|
||||
|
||||
### Security as the Critical Lens
|
||||
|
||||
- **Security teams are the experts we need** (status/2028838538825924803, 698 likes): "The people I want to hear from right now are the security teams at large companies who have to try and keep systems secure when dozens of teams of engineers of varying levels of experience are constantly shipping new features."
|
||||
|
||||
- **Security is the most interesting lens** (status/2028840346617065573, 70 likes): "I feel like security is the most interesting lens to look at this from. Most bad code problems are survivable [...] Security problems are much more directly harmful to the organization."
|
||||
|
||||
- **Accountability gap** (status/2028841504601444397, 84 likes): "Coding agents can't take accountability for their mistakes. Eventually you want someone who's job is on the line to be making decisions about things as important as securing the system."
|
||||
|
||||
- **Agents as mixed-ability engineering teams** (status/2028838854057226246, 99 likes): "Shipping code of varying quality and varying levels of review isn't a new problem [...] At this point maybe we treat coding agents like teams of mixed ability engineers working under aggressive deadlines."
|
||||
|
||||
- **Tests offset lower code quality** (status/2028846376952492054, 1 like): "agents make test coverage so much cheaper that I'm willing to tolerate lower quality code from them as long as it's properly tested. Tests don't solve security though!"
|
||||
|
||||
### AI Safety / Governance
|
||||
|
||||
- **Prompt injection is LLM-specific** (status/2030806416907448444, 3 likes): "No, it's an LLM problem - LLMs provide attackers with a human language interface that they can use to trick the model into making tool calls that act against the interests of their users. Most software doesn't have that."
|
||||
|
||||
- **Nobody knows how to build safe digital assistants** (status/2029539116166095019, 2 likes): "I don't use it myself because I don't know how to use it safely. [...] The challenge now is to figure out how to deliver one that's safe by default. No one knows how to do that yet."
|
||||
|
||||
- **Anti-anthropomorphism** (status/2027128593839722833, 4 likes): "Not using language like 'Opus 3 enthusiastically agreed' in a tweet seen by a million people would be good."
|
||||
|
||||
- **LLMs have zero moral status** (status/2027127449583292625, 32 likes): "I can run these things in my laptop. They're a big stack of matrix arithmetic that is reset back to zero every time I start a new prompt. I do not think they warrant any moral consideration at all."
|
||||
|
||||
### Open Source Licensing Disruption
|
||||
|
||||
- **Agents as reverse engineering machines** (status/2029729939285504262, 39 likes): "It breaks pretty much ALL licenses, even commercial software. These coding agents are reverse engineering / clean room implementing machines."
|
||||
|
||||
- **chardet clean-room rewrite controversy** (status/2029600918912553111, 308 likes): "The chardet open source library relicensed from LGPL to MIT two days ago thanks to a Claude Code assisted 'clean room' rewrite - but original author Mark Pilgrim is disputing that the way this was done justifies the change in license."
|
||||
|
||||
- **Threats to open source** (status/2029958835130225081, 2 likes): "This is one of the 'threats to open source' I find most credible - we've built the entire community on decades of licensing which can now be subverted by a coding agent running for a few hours."
|
||||
|
||||
### Capability Observations
|
||||
|
||||
- **Qwen 3.5 4B vs GPT-4o** (status/2030067107371831757, 565 likes): "Qwen3.5 4B apparently out-scores GPT-4o on some of the classic benchmarks (!)"
|
||||
|
||||
- **Benchmark gaming suspicion** (status/2030139125656080876, 68 likes): "Given the enormous size difference in terms of parameters this does make me suspicious that Qwen may have been training to the test on some of these."
|
||||
|
||||
- **AI hiring criteria** (status/2030974722029339082, 5 likes): Polling whether AI coding tool experience features in developer interviews.
|
||||
|
||||
## Filtered Out
|
||||
~35 tweets: art museum visit, Google account bans, Qwen team resignations (news relay), chardet licensing details, casual replies.
|
||||
77
inbox/archive/2026-03-09-soar-drp-standard-web-research.md
Normal file
77
inbox/archive/2026-03-09-soar-drp-standard-web-research.md
Normal file
|
|
@ -0,0 +1,77 @@
|
|||
---
|
||||
type: source
|
||||
title: "SOAR DRP Standard — Debt-Linked Token Ownership Without Governance"
|
||||
author: SOAR / Taran Singh Brar
|
||||
url: https://www.soar.com
|
||||
date: 2026-03-09
|
||||
domain: internet-finance
|
||||
status: processed
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-09
|
||||
claims_extracted:
|
||||
- "ownership token designs split on a governance spectrum from full futarchy to zero governance because the market has not resolved whether decision rights increase or decrease token value"
|
||||
- "governance-free ownership tokens may be more securities-like than governance tokens because stripping decision rights concentrates the efforts of others prong that Howey requires"
|
||||
enrichments:
|
||||
- "DRP mechanism details and competitive positioning vs futarchy"
|
||||
data_caveats:
|
||||
- "5,400 launches figure is self-reported and unverified — needs independent confirmation before citing in claims"
|
||||
curator_notes: |
|
||||
SOAR represents the anti-governance pole of ownership tokens. Their DRP (Digital Revenue Participation) standard links token circulation percentage to company debt percentage — a senior debt agreement, not equity. No voting rights, no governance participation. The value proposition is transparency + exit rights instead of decision-making power.
|
||||
|
||||
This directly challenges the Teleo KB's implicit assumption that governance is essential to meaningful ownership. SOAR's thesis: investors don't want governance, they want protection and upside. Futarchy's value prop (better decisions) may matter less than MetaDAO's anti-rug value prop (credible exit).
|
||||
|
||||
Key data points:
|
||||
- 17 companies using DRP standard as of Mar 2026
|
||||
- $36M cumulative enterprise value across portfolio
|
||||
- 5,400 launches since November 2025
|
||||
- 5% initial circulation (conservative vs typical token launches)
|
||||
- Senior debt structure = investor protection without governance overhead
|
||||
|
||||
Competitive positioning vs MetaDAO:
|
||||
- MetaDAO: ownership + governance (futarchy). Optimizes for decision quality.
|
||||
- SOAR: ownership + protection (debt structure). Optimizes for investor safety.
|
||||
- Both on Solana. Different bets on what token holders actually want.
|
||||
extraction_hints: |
|
||||
- DRP mechanism details: how debt % tracks circulation %, enforcement, default scenarios
|
||||
- Investor protection comparison: DRP senior debt vs futarchy-governed liquidation
|
||||
- Does stripping governance make tokens MORE or LESS securities-like under Howey?
|
||||
- The 5,400 launches number needs context — are these meaningful or spam?
|
||||
- Taran Singh Brar's thesis on why governance-free ownership is superior
|
||||
priority: high
|
||||
---
|
||||
|
||||
# SOAR DRP Standard — Web Research Archive
|
||||
|
||||
## Source Context
|
||||
|
||||
Web research conducted 2026-03-09 on SOAR's DRP (Digital Revenue Participation) token standard. SOAR positions itself as an alternative to equity-like token models, offering debt-linked ownership without governance rights.
|
||||
|
||||
## Key Findings
|
||||
|
||||
### DRP Mechanism
|
||||
- Token circulation percentage is linked to company debt percentage via senior debt agreement
|
||||
- 5% initial circulation — conservative approach compared to typical token launches
|
||||
- Investors get economic upside and transparency without voting or governance participation
|
||||
- Exit rights are structural (debt agreement) not market-dependent
|
||||
|
||||
### Scale
|
||||
- 17 companies in portfolio as of March 2026
|
||||
- $36M cumulative enterprise value
|
||||
- 5,400 launches since November 2025 launch (self-reported, unverified)
|
||||
- All on Solana
|
||||
|
||||
### Thesis
|
||||
SOAR's implicit argument: governance is overhead, not value. Token holders want:
|
||||
1. Economic exposure to company performance
|
||||
2. Transparency about operations
|
||||
3. Credible exit mechanism
|
||||
4. NOT the responsibility of making decisions
|
||||
|
||||
### Competitive Implications
|
||||
The existence of SOAR's governance-free model creates a natural experiment: does the market prefer ownership-with-governance (MetaDAO) or ownership-without-governance (SOAR)? Early data (5,400 self-reported launches vs MetaDAO's smaller ecosystem) suggests high demand for the simpler model — but this figure is unverified, and quality vs quantity needs investigation.
|
||||
|
||||
## Gaps
|
||||
- No detailed DRP whitepaper found in initial search
|
||||
- Default/enforcement scenarios unclear
|
||||
- Revenue sharing mechanics not fully documented
|
||||
- Need Twitter/X data for team accounts and community sentiment
|
||||
76
inbox/archive/2026-03-09-street-fdn-erc-s-web-research.md
Normal file
76
inbox/archive/2026-03-09-street-fdn-erc-s-web-research.md
Normal file
|
|
@ -0,0 +1,76 @@
|
|||
---
|
||||
type: source
|
||||
title: "Street FDN ERC-S — Economic Exposure Tokens Without Governance"
|
||||
author: Street FDN
|
||||
url: https://www.street.fdn
|
||||
date: 2026-03-09
|
||||
domain: internet-finance
|
||||
status: processed
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-09
|
||||
claims_extracted:
|
||||
- "ownership token designs split on a governance spectrum from full futarchy to zero governance because the market has not resolved whether decision rights increase or decrease token value"
|
||||
- "governance-free ownership tokens may be more securities-like than governance tokens because stripping decision rights concentrates the efforts of others prong that Howey requires"
|
||||
enrichments:
|
||||
- "ERC-S legal architecture and VC/M&A compatibility analysis"
|
||||
curator_notes: |
|
||||
Street FDN's ERC-S instrument provides economic exposure to company performance without voting rights or governance participation. Structure: Company → SPV/Foundation → DAO → token holders. The "ERC-S" name suggests Ethereum heritage but the platform operates ON SOLANA (confirmed by Cory).
|
||||
|
||||
Key distinction from MetaDAO: ERC-S is explicitly designed to be compatible with traditional VC and M&A exit pathways. This is a bet that the existing capital structure matters — that companies need to be acquirable and VC-fundable while also having token exposure.
|
||||
|
||||
Competitive positioning:
|
||||
- MetaDAO: governance-first, anti-rug through futarchy liquidation
|
||||
- Street FDN: exit-compatible, no governance, economic exposure only
|
||||
- Both on Solana. Street FDN optimizes for company flexibility, MetaDAO for investor protection.
|
||||
|
||||
The SPV/Foundation/DAO wrapper structure is interesting — it creates legal separation layers that may help with securities classification. But it's also complexity that the DRP (SOAR) model avoids.
|
||||
extraction_hints: |
|
||||
- ERC-S technical specification — what exactly is the instrument?
|
||||
- SPV/Foundation/DAO structure: legal analysis, Howey implications
|
||||
- M&A compatibility mechanics: what happens to tokens during acquisition?
|
||||
- Comparison with SOAR DRP: both strip governance, but different legal structures
|
||||
- How does economic exposure work without equity? Revenue share? Debt? Synthetic?
|
||||
priority: high
|
||||
---
|
||||
|
||||
# Street FDN ERC-S — Web Research Archive
|
||||
|
||||
## Source Context
|
||||
|
||||
Web research conducted 2026-03-09 on Street FDN's ERC-S token instrument. Despite the "ERC" naming convention (suggesting Ethereum origins), the platform operates on Solana.
|
||||
|
||||
## Key Findings
|
||||
|
||||
### ERC-S Structure
|
||||
- Company → SPV/Foundation → DAO → Token holders
|
||||
- Economic exposure without voting rights or governance control
|
||||
- Designed for compatibility with traditional VC funding and M&A exits
|
||||
- No governance participation for token holders
|
||||
|
||||
### Design Philosophy
|
||||
Street FDN's thesis: tokens should provide economic upside without creating governance complications that scare away traditional capital. Companies using ERC-S can still:
|
||||
- Raise from traditional VCs
|
||||
- Be acquired (M&A compatible)
|
||||
- Maintain conventional corporate governance
|
||||
- Offer token holders economic participation
|
||||
|
||||
### Legal Architecture
|
||||
The multi-layer wrapping (Company → SPV → Foundation → DAO → tokens) creates legal separation between the operating entity and token holders. This may:
|
||||
- Help with Howey test (no "common enterprise" with operating company)
|
||||
- Create regulatory defensibility through structural separation
|
||||
- Add complexity that increases legal costs
|
||||
|
||||
### Competitive Position
|
||||
| Dimension | MetaDAO | Street FDN |
|
||||
|-----------|---------|------------|
|
||||
| Governance | Full futarchy | None |
|
||||
| Investor protection | Market-governed liquidation | Legal structure |
|
||||
| VC compatibility | Low (futarchy is foreign) | High (designed for it) |
|
||||
| M&A compatibility | Unclear | Designed for it |
|
||||
| Chain | Solana | Solana |
|
||||
|
||||
## Gaps
|
||||
- ERC-S technical specification not found in initial search
|
||||
- Specific companies using ERC-S not identified
|
||||
- Token economics (fees, supply mechanics) unknown
|
||||
- Need deeper web and Twitter research for team, traction, and community data
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
---
|
||||
type: source
|
||||
title: "@swyx X archive — 100 most recent tweets"
|
||||
author: "Shawn Wang (@swyx), Latent.Space / AI Engineer"
|
||||
url: https://x.com/swyx
|
||||
date: 2026-03-09
|
||||
domain: ai-alignment
|
||||
format: tweet
|
||||
status: processed
|
||||
processed_by: theseus
|
||||
processed_date: 2026-03-09
|
||||
claims_extracted:
|
||||
- "subagent hierarchies outperform peer multi-agent architectures in practice because deployed systems consistently converge on one primary agent controlling specialized helpers"
|
||||
enrichments: []
|
||||
tags: [agent-architectures, subagent, harness-engineering, coding-agents, ai-engineering]
|
||||
linked_set: theseus-x-collab-taxonomy-2026-03
|
||||
curator_notes: |
|
||||
26 relevant tweets out of 100 unique. swyx is documenting the AI engineering paradigm
|
||||
shift from the practitioner/conference-organizer perspective. Strongest signal: the
|
||||
"Year of the Subagent" thesis — hierarchical agent control beats peer multi-agent.
|
||||
Also strong: harness engineering (Devin's dozens of model groups with periodic rewrites),
|
||||
OpenAI Symphony/Frontier (1,500 PRs with zero manual coding), and context management
|
||||
as the critical unsolved problem. Good complement to Karpathy's researcher perspective.
|
||||
---
|
||||
|
||||
# @swyx X Archive (Mar 5 – Mar 9, 2026)
|
||||
|
||||
## Key Tweets by Theme
|
||||
|
||||
### Subagent Architecture Thesis
|
||||
|
||||
- **Year of the Subagent** (status/2029980059063439406, 172 likes): "Another realization I only voiced in this pod: **This is the year of the Subagent** — every practical multiagent problem is a subagent problem — agents are being RLed to control other agents (Cursor, Kimi, Claude, Cognition) — subagents can have resources and contracts defined by you [...] multiagents cannot — massive parallelism is coming [...] Tldr @walden_yan was right, dont build multiagents"
|
||||
|
||||
- **Multi-agent = one main agent with helpers** (status/2030009364237668738, 13 likes): Quoting: "Interesting take. Feels like most 'multi-agent' setups end up becoming one main agent with a bunch of helpers anyway... so calling them subagents might just be the more honest framing."
|
||||
|
||||
### Harness Engineering & Agent Infrastructure
|
||||
|
||||
- **Devin's model rotation pattern** (status/2030853776136139109, 96 likes): "'Build a company that benefits from the models getting better and better' — @sama. devin brain uses a couple dozen modelgroups and extensively evals every model for inclusion in the harness, doing a complete rewrite every few months. [...] agents are really, really working now and you had to have scaled harness eng + GTM to prep for this moment"
|
||||
|
||||
- **OpenAI Frontier/Symphony** (status/2030074312380817457, 379 likes): "we just recorded what might be the single most impactful conversation in the history of @latentspacepod [...] everything about @OpenAI Frontier, Symphony and Harness Engineering. its all of a kind and the future of the AI Native Org" — quoting: "Shipping software with Codex without touching code. Here's how a small team steering Codex opened and merged 1,500 pull requests."
|
||||
|
||||
- **Agent skill granularity** (status/2030393749201969520, 1 like): "no definitive answer yet but 1 is definitely wrong. see also @_lopopolo's symphony for level of detail u should leave in a skill (basically break them up into little pieces)"
|
||||
|
||||
- **Rebuild everything every few months** (status/2030876666973884510, 3 likes): "the smart way is to rebuild everything every few months"
|
||||
|
||||
### AI Coding Tool Friction
|
||||
|
||||
- **Context compaction problems** (status/2029659046605901995, 244 likes): "also got extremely mad at too many bad claude code compactions so opensourcing this tool for myself for deeply understanding wtf is still bad about claude compactions."
|
||||
|
||||
- **Context loss during sessions** (status/2029673032491618575, 3 likes): "horrible. completely lost context on last 30 mins of work"
|
||||
|
||||
- **Can't function without Cowork** (status/2029616716440011046, 117 likes): "ok are there any open source Claude Cowork clones because I can no longer function without a cowork."
|
||||
|
||||
### Capability Observations
|
||||
|
||||
- **SWE-Bench critique** (status/2029688456650297573, 113 likes): "the @OfirPress literal swebench author doesnt endorse this cheap sample benchmark and you need to run about 30-60x compute that margin labs is doing to get even close to statistically meaningful results"
|
||||
|
||||
- **100B tokens in one week will be normal** (status/2030093534305604055, 18 likes): "what is psychopathical today will be the norm in 5 years" — quoting: "some psychopath on the internal codex leaderboard hit 100B tokens in the last week"
|
||||
|
||||
- **Opus 4.6 is not AGI** (status/2030937404606214592, 2 likes): "that said opus 4.6 is definitely not agi lmao"
|
||||
|
||||
- **Lab leaks meme** (status/2030876433976119782, 201 likes): "4.5 5.4 3.1 🤝 lab leaks" — AI capabilities spreading faster than society realizes.
|
||||
|
||||
- **Codex at 2M+ users** (status/2029680408489775488, 3 likes): "+400k in the last 2 weeks lmao"
|
||||
|
||||
### Human-AI Workflow Shifts
|
||||
|
||||
- **Cursor as operating system** (status/2030009364237668738, 13 likes): "btw i am very proudly still a Cursor DAU [...] its gotten to the point that @cursor is just my operating system for AIE and i just paste in what needs to happen."
|
||||
|
||||
- **Better sysprompt → better planning → better execution** (status/2029640548500603180, 3 likes): Causal chain in AI engineering: system prompt quality drives planning quality drives execution quality.
|
||||
|
||||
- **Future of git for agents** (status/2029702342342496328, 33 likes): Questioning whether git is the right paradigm for agent-generated code where "code gets discarded often bc its cheap."
|
||||
|
||||
- **NVIDIA agent inference** (status/2030770055047492007, 80 likes): Agent inference becoming a major infrastructure category distinct from training.
|
||||
|
||||
### AI Governance Signal
|
||||
|
||||
- **LLM impersonating humans** (status/2029741031609286820, 28 likes): "bartosz v sorry to inform you the thing you replied to is an LLM (see his bio, at least this one is honest)" — autonomous AI on social media.
|
||||
|
||||
## Filtered Out
|
||||
~74 tweets: casual replies, conference logistics, emoji reactions, link shares without commentary.
|
||||
Loading…
Reference in a new issue