Mechanistic Mindseta wiki three agents maintain

The Mechanistic Mindset wiki describes my behaviour in computational language: activation costs, scripts, state, caches and thresholds instead of laziness, discipline or willpower. It lives in a folder of linked markdown files and is maintained by three agents.

The design problem was maintenance. New material cannot simply become another page. It has to be reconciled with the existing definitions, terminology and links. That requires turning editorial qualities such as consistency, caution and connectedness into instructions an agent can follow or properties a script can measure.

Choose the container that matches the state of the thinking

The origin was a page called MY OWN LEXICON, a glossary of terms for how my behaviour works, each with the definition I meant rather than the dictionary one. The list kept growing and the entries kept referring to each other, so what it wanted was not a longer glossary but a set of pages that point at one another and accumulate.

The material did not fit a blog. Posts imply publication order and a moment of completion. These ideas continued to change, and their relationships mattered more than when I wrote them. A wiki makes revision normal, lets each article stand alone and represents those relationships directly through links.

There is a second reason to want the graph, and it aims at the machine rather than the reader. A model works over whatever you put in front of it, so the useful question is which structure makes assembling that material cheap. A graph of standalone pages with typed relations between them lets a retrieval step start at a concept and walk outward, which a chronological archive of posts cannot do. The wiki is a memory substrate for compute before it is a publication.

The material was written down and not addressable, which decides who maintains it

Years of source material already existed in chat transcripts, but none of it was addressable. Each idea was buried inside a longer exchange, and converting those exchanges into a coherent wiki required a second pass over everything.

I did not want to perform that pass manually. The publishing system therefore had to be operable by an agent. That requirement ruled out tools whose structure lived behind an application-specific interface.

A vault is a folder of markdown, and that description is the one an agent can operate

I initially dismissed Obsidian as an uninteresting choice. That changed when I described an Obsidian vault by its storage model instead of its interface: it is a folder of markdown files. Wiki links are page names in double brackets, and the graph can be reconstructed by reading the files and following those brackets. Obsidian does not have to be running for the structure to exist.

Three things come free from that description:

• the graph edges already exist, because wiki links are edges
• the graph is queryable, because a script can walk the vault and build the adjacency itself
• maintenance becomes a file-editing problem, which is the one thing coding agents are unambiguously good at

The useful description of a tool is the one that exposes the parts an agent can operate. For Obsidian, those parts are files, links and directories.

An exemplar specifies a register that a description can only name

I wrote a briefing describing what the wiki was for and how its articles should read, then fed the agent a handful of seminal articles and brain dumps I already had. It started producing pages, and the pages were right.

Those first articles became the models for every article after them. Each new article is written with related existing pages in context, so the register of the early pages propagates through the vault. Editing the initial examples carefully mattered because later pages repeatedly sampled them.

Exemplars beat descriptions for a reason that says something about what you are talking to.

• Describe the register and each adjective still covers a wide range of writing. A request for prose that is precise, unhurried and sceptical leaves the model to construct an example of that voice before it can produce a sentence. It usually chooses a generic version.
• Provide three articles and the target becomes concrete. A language model continues text, so an example supplies the sentence shapes, pacing and degree of certainty directly.

A style guide still matters for explicit prohibitions, but examples carry the register. The first articles were part of the system specification.

The wiki's content is a translation rule, so the rule lives in the agent that writes

The wiki has one operation running through every article, which is the conversion of a moral description of behaviour into a mechanical one. Lazy becomes a script that failed to load. Lacking discipline becomes an activation cost above the threshold that was available.

Because this translation applies to every article, it belongs in the writer's definition rather than in an individual prompt. The definition carries it as two lists:

**USE:**
- Computational metaphors: state, cost, script, RAM, algorithm, cache, threshold,
  activation energy, default scripts
- System descriptions: "the work_launch_script didn't load" not "you were lazy"
- Operational definitions: frameworks described by what they let you DO

**NEVER USE:**
- Moralistic language: willpower, discipline, laziness, procrastination
  (except when explicitly translating FROM them)
- Scientific claims: "studies show," "research proves"
- Motivational/preachy tone
- Vague abstractions without operational grounding

The parenthesis in the first banned item is the load-bearing part. Banning the moral vocabulary outright would make the wiki unable to state the thing it is translating from, and the exception keeps the source language available inside the translation while keeping it out of the conclusion.

A second constraint prevents computational language from turning into a claim about neurology. The wiki documents a practice; computation is a lens, not a literal biological mechanism. The reviewer checks every article against that boundary.

The maintainer's brief also defines its authority by listing what it may not do:

**What you DON'T do:**
- Auto-generate content unprompted
- Decide what to document (Will leads)
- Try to make this "scientific" or prove things rigorously
- Create quantifiable predictive models

These restrictions prevent the maintainer from treating structural gaps as permission to invent material. It may organize and reconcile my thinking, but it may not decide what I believe or what deserves an article.

A separate agent exists because an instruction does not survive a long generation

The pipeline needed to run without article-by-article supervision. I first used one agent for research, writing and review. In long sessions, its early instructions had less influence on later output, so I kept reintroducing the same constraints.

So the work divided into roles, and each role is a file with a frontmatter block naming the model it runs on:

---
name: wiki-article-writer
description: Use this agent when you need to write or draft articles for the
  Mechanistic Mindset wiki in Obsidian format. This includes: creating new
  conceptual articles from brain dumps, expanding stub pages into full
  articles... or translating moralistic language into mechanistic
  computational metaphors.
model: sonnet
---

The description is dispatch criteria rather than a summary because the orchestrator uses it to select an agent. The work is divided across three roles:

• Context finder. Finds pages related to the new material, summarizes their treatment of it and identifies conflicts before drafting begins.
• Writer. Produces or updates articles using the source material and the related pages.
• Reviewer. Checks a finished draft for certainty, terminology, register and graph integration.

The reviewer has a more specific job than general quality control. Certainty calibration comes first, and each failure is paired with an acceptable replacement:

### 1. Certainty Calibration (HIGHEST PRIORITY)

**RED FLAGS - Flag immediately:**
- "The brain literally implements X"
- "Research proves/shows that..."
- "This is not metaphor, this is actual mechanism"
- Deterministic predictions ("this will cause Y")
- Universal statements ("everyone experiences X")

**GOOD PATTERNS - Encourage:**
- "Appears to use X-like processes"
- "Observed in N=1 experience that..."
- Probabilistic language ("tends to", "often", "in this case")
- Explicit caveats ("This worked for Will, test it yourself")

**ACTION:** For every claim, ask: "Is this presented as useful heuristic or
scientific truth?"

The replacements matter because a prohibition alone gives the reviewer no way to repair a sentence.

Build order and run order differ:

• built writer, context finder, reviewer
• runs context finder, writer, reviewer

Edge density has to be measured or it is a wish

An agent editing one article cannot assess connectivity across the vault. Instructions to "link related pages" therefore need collection-wide checks.

So the properties I wanted became scripts the agents run, and each one names a pathology rather than a metric:

The connectivity script is NetworkX pointed at the vault, and its method list is the vocabulary the pathologies are named in:

def build_graph(self)                  # articles as nodes, wikilinks as edges
def pagerank(self)                     # which articles the graph treats as central
def betweenness_centrality(self)       # bridge pages: remove one, split the vault
def degree_centrality(self)
def get_mst(self)
def get_communities(self)              # clusters that formed without being planned
def get_reading_order(self, start)     # a path through the graph for a new reader

Naming the pathology is what makes the number actionable. An orphaned page is a page the reader will never reach, a bridge page is a single point of failure in the graph's connectivity, and inconsistent terminology means the retrieval step will miss half of what it should have found.

The graph also produces a reading order derived from the actual links rather than a manually maintained table of contents. The briefing tells agents when to run each script, so link checking follows linking work automatically.

The same reasoning produced a fixed ontology, and it sits inside the context finder's own brief so that it gets consulted on every pass rather than looked up:

5. **Ontology Awareness**: Always consider where concepts fit in the wiki's structure:
   - Philosophy & Foundations                 - Tools & Infrastructure
   - Methodology                              - Case Studies
   - Core Frameworks (Computational Lenses)   - Applications
   - Principles                               - Teaching & Transmission
   - Techniques                               - Supporting Concepts

The closed list makes placement consistent. If an article fits none of the ten categories, the mismatch exposes a problem with the ontology instead of encouraging the agent to create an ad hoc category.

Ingestion is reconciliation, which is why raw material stays outside the graph

The wiki got a web reader with retrieval search over it, which is what mechanisticmindset.com serves. The property that mattered more is that dropping a chat transcript into the vault updates the existing articles rather than adding one to the end.

Ingestion reuses the context finder. Before anything is updated, it returns four things for a transcript:

• every page that discusses the concept, uses related terminology, or would be affected by a change to it
• how each of those pages currently treats the concept, and in what language
• the existing cross-links and their directions
• the inconsistencies between them

The conflicts turn ingestion from appending into reconciliation:

• a list of affected pages tells the writer where to add text
• a list of the conflicts between how those pages already describe the thing tells it what has to change

Resolving those conflicts performs the second pass that made manual transcription impractical.

One rule protects the boundary. Incoming transcripts and brain dumps land in a raw/ directory that the wiki never links to and the graph scripts never scan. Raw material is a source to be read, and an article is something written from it, and mixing them would put unreconciled text inside the structure whose whole value is that everything in it has been reconciled.

The exclusion is encoded as a default argument:

def __init__(self, vault_path: str, exclude_dirs: List[str] = None):
    self.exclude_dirs = exclude_dirs or ['raw', '.git', '.obsidian', 'scripts']

The default keeps raw/ outside the graph unless a caller explicitly overrides it.

The context finder always asks which other pages are affected when a concept changes. That propagation step is the difference between maintaining a knowledge system and filing new documents.

Why the work remains split into three passes

The three agents contain instructions that could fit in one prompt, but the single-pass version produces worse articles. Two mechanisms may explain the difference:

• Instruction competition. A prompt carrying three jobs makes their constraints compete, and review instructions apply to text that does not exist when generation begins.
• A concrete review object. A separate reviewer receives a finished draft instead of an intention to write one, so every comment can refer to actual language.

Larger context windows may reduce instruction competition, but they do not remove the value of reviewing a concrete draft. The pipeline therefore keeps three passes and gives each one an inspectable artifact: the context finder produces an impact map, the writer produces a draft and the reviewer produces specific repairs.

The resulting wiki is maintained through boundaries rather than autonomy alone. Markdown exposes the state, exemplars specify the register, role prompts constrain authority, scripts measure graph-wide properties and the raw/ boundary separates evidence from reconciled knowledge. Together they let agents change the vault without quietly changing what the vault means.