The Organizational Star¶

The framework isn’t about AI agents. It never was. It’s about any system where actors with different capabilities coordinate through a mediating layer. Same structure, different substrates.

The shape, not the material¶

Eight posts in, everything has been software. Agents, sandboxes, tool calls, JSONL logs, DuckDB queries. The vocabulary is technical. The examples are technical. The framework looks like it belongs to the field of AI agent architecture.

It doesn’t.

The star topology works because of its shape — a mediating layer at the center, specialized actors at the points, structured handoffs at the boundaries, failures flowing inward as signal. Nothing in that shape requires the actors to be software. Nothing requires the mediating layer to be a Harness process. Nothing requires the handoffs to be JSON.

The insight is structural. The substrate is incidental.

This post applies the full framework — the star topology, the VSM mapping, the failure stream, the ratchet — to two systems that contain no AI agents at all. One is a single person. The other is a team. In both cases, the framework describes what’s already happening, gives it a name, and suggests where the configuration is wrong.

A person as a multi-actor system¶

You are not one actor. You are several, distributed across time.

The person who sits down on Sunday evening to plan the week is not the same actor as the person who sits down Monday morning to execute the plan. They share a body. They share memories. They share values, mostly. But they have different capabilities, different information, and different failure modes.

The Sunday planner is System 4. Broad reasoning, many possible approaches, access to the full landscape of what needs doing. This actor scans the environment — the calendar, the project list, the email backlog — and builds a model of the week. It proposes an allocation: these hours for this project, that block for deep work, this afternoon for meetings. The planner’s strength is exploration. It can consider approaches the executor would never think of mid-task, because mid-task you don’t have the bandwidth to reconsider the whole shape of your week.

The Monday executor is System 1. Bounded task, clear inputs, characterized output. This actor takes the plan and works it. Its strength is focus — sustained attention on a single problem, the kind of depth that produces actual results. Its weakness is scope. The executor can’t see the whole week. It sees the current task. It does the current task. It moves to the next one.

The handoff between planner and executor is the plan itself — a structured artifact that compresses the planner’s broad reasoning into a scoped set of instructions. The plan is a co-domain funnel. Deep exploration of priorities, constraints, and trade-offs, compressed through a narrow interface: a list of tasks with time blocks.

This much is obvious. Everyone who has ever made a to-do list is already running this architecture.

The interesting part is the Harness.

The internal Harness¶

Between the plan and the execution, something has to manage the transitions. Something has to decide: the current task is done, what’s next? Something has to notice: this task is taking longer than expected, should I adjust the plan? Something has to enforce: it’s 2 PM, that means the deep work block is over and the email block starts.

In cognitive science, this function has a name: executive function. Scope construction (deciding what to attend to), permission gating (deciding what’s allowed right now), state management (tracking where you are in the plan), transition management (moving between tasks without losing the thread). These are Harness functions. They’re specified, routine, and coordinative. They don’t require the deep reasoning of the planner or the focused execution of the worker. They require reliable, low-cost switching.

For many people, the internal Harness works well enough. They consult the plan, notice the time, transition between tasks, and keep the day roughly on track. The Harness function is internalized and mostly transparent.

For some people, it isn’t.

When the Harness is unreliable¶

ADHD is, among other things, an unreliable internal Harness.

The planning function often works fine. People with ADHD frequently generate excellent plans — creative, thorough, well-reasoned. The System 4 role is unimpaired or even enhanced. The execution function works fine too, sometimes spectacularly — hyperfocus is System 1 operating at full capacity, producing output that no plan could have predicted. The problem is in the middle. The Harness.

Scope construction is unreliable. The wrong thing captures attention. The right thing can’t hold it. Permission gating is unreliable. The plan says “work on the report,” but the browser is already open and curiosity is a stronger signal than the plan. State management is unreliable. Where was I? What was I doing before the interruption? How far through the task am I? Transition management is unreliable. Ending one task and starting the next requires an executive function expenditure that neurotypical descriptions of productivity tend to treat as free. It isn’t free. It’s the most expensive operation in the system, and when the internal Harness is unreliable, it fails unpredictably.

The framework’s language is useful here because it separates the function from the substrate. The problem isn’t the person. The problem is that a specific architectural function — coordination, not intelligence, not execution — is being performed by an unreliable component. The design response is the same one the framework recommends for any unreliable Harness: externalize it.

Externalizing the Harness¶

Calendar blocks are externalized scope construction. The calendar decides what you’re working on right now, not your executive function. The decision was made during the planning phase (System 4, broad reasoning, full landscape visible) and encoded into a specified artifact (the calendar) that the executor can follow without re-engaging the planner.

Task lists with explicit next actions are externalized state management. The list tracks where you are. You don’t have to hold the state in working memory. When an interruption breaks your focus, the list is still there. Recovery cost drops from “reconstruct the full context from memory” to “read the next item.”

Structured routines are externalized permission gating. “Between 9 and 12, only work on the project” is a specified rule. It doesn’t require judgment. It doesn’t require willpower, which is a terrible regulatory mechanism because it degrades under load — exactly the conditions where you most need it. The routine is a pre-hook: before starting any activity, check against the schedule. If the activity doesn’t match the current block, reject it. No trained judgment in the permission loop.

Body doubling — working alongside someone else, even silently — is externalized monitoring. System 3, the failure-driven controller. The other person doesn’t direct the work. They don’t plan it. They don’t execute it. Their presence provides the monitoring signal: am I still working? Have I drifted? The mere fact of being observed is enough to keep the Harness functional. This is System 3 star — sporadic audit through ambient presence.

AI collaboration is externalized extract. When the person says “I have this idea, help me organize it,” they’re using the AI as a co-domain funnel. The idea lives in their head as a broad, tangled, high-ma state — many possible expressions, connections going everywhere, hard to characterize. The AI interaction compresses it through a structured interface: “Here’s what I think you’re saying, organized into three points.” The person evaluates the compressed version: yes, no, close but adjust this. The extract step, which would otherwise require the internal Harness to scope and sequence the idea, is performed by an external actor.

The CLAUDE.md file is to the AI agent what the morning routine is to the person with ADHD: externalized Harness infrastructure that makes the extract step cheaper. Both encode decisions that were made during a planning phase into specified artifacts that operate during an execution phase. Both exist because the alternative — making those decisions in real time, every time — is unreliable and expensive.

The placement principle, applied personally¶

The framework’s placement principle says: put the space for judgment in the planning role, minimize it in execution. Every decision during an execution block is a context switch. Context switches cost.

For someone with an unreliable internal Harness, context switches don’t just cost — they can be catastrophic. Each decision point during execution is a moment where the Harness has to re-engage: evaluate the options, select one, manage the transition. If the Harness fails at that moment, the execution block is over. Not because the work is done, but because the coordination layer dropped the thread.

The design move is to eliminate decision points from execution. Not by eliminating choice entirely — that’s Taylor’s mistake, specifying the shoveler into mechanical repetition. But by moving the decisions to the planning phase, where they can be made with full context, full attention, and full reasoning capacity. Then encoding those decisions into specified artifacts — the schedule, the task list, the routine — that the executor can follow without re-engaging the planner.

This is the same architecture as the agent system. The planner explores broadly (high ma). The plan compresses the exploration through a co-domain funnel (structured output). The executor follows the plan through a narrow interface (low ma, specified steps). The Harness manages transitions using specified rules (the calendar, the routine) rather than trained judgment (willpower, executive function).

The person who plans well and externalizes the Harness effectively isn’t compensating for a deficit. They’re running a well-designed multi-actor system. The externalization is a design move, not a coping mechanism.

A data team as a multi-actor system¶

Scale up. Same structure, different substrate.

A data and analytics team at a fintech company. Product managers and business leads bring the questions. Analysts translate the questions into approaches and execute them against the data. The data platform runs the queries. A governance layer manages access, reviews outputs, enforces PCI compliance.

The VSM mapping falls out naturally:

System 5 — the Principal. The product managers and business leads. They decide what matters. What questions are worth asking. What outcomes would change the product roadmap. They hold the purpose. Their contribution is judgment about the business, not about the data infrastructure.

System 4 — the Inferencer. The analysts. They take a business question — broad, natural language, often underspecified — and translate it into an approach: which data sources, which methods, which cohort definitions, which outputs. This is the fold operation: scan the available data landscape, build a model of how the question maps to the data, propose a structured plan. High ma. Room for judgment, creativity, domain expertise.

System 1 — the Executor. The data platform. Query in, result out. DuckDB, a warehouse, a compute cluster — the substrate doesn’t matter. What matters is the interface: structured input (a query), characterized output (a result set), bounded effects (the query doesn’t modify the data). Low ma. Specified behavior.

System 2 — the Harness. The governance and coordination layer. Data access policies, PCI compliance workflows, output review rules, request routing. This layer doesn’t decide what questions to ask (System 5) or how to answer them (System 4). It manages the handoffs. It enforces the rules. It routes requests to the right analyst. It ensures outputs comply with data sensitivity classifications before release. Specified, routine, transparent.

System 3 — the controller. The team lead, the analytics manager, the person who watches the whole operation and notices when the configuration isn’t serving the mission. Not making the business decisions (that’s System 5). Not doing the analysis (that’s System 4). Not running the queries (that’s System 1). Not enforcing the policies (that’s System 2). Watching the performance. Intervening when it degrades.

The organizational failure stream¶

The failure stream at organizational scale looks different from the agent failure stream, but it has the same categories and the same diagnostic value.

Requests that take too long. A product manager submits a question. Weeks pass. The analyst is backlogged, or the question is underspecified and requires multiple rounds of clarification, or the data access request is stuck in compliance review. This is the organizational equivalent of a timeout. The approach is wrong for this problem size. The fix might be self-service dashboards (let the PM run simple queries directly), or structured request templates (reduce the clarification rounds), or pre-approved data access tiers (eliminate the per-request review).

Reviews that are rubber stamps. Every output goes through disclosure review. The reviewer glances at it, approves it, moves on. The review adds latency but catches nothing. This is a constraint that isn’t earning its cost — the organizational equivalent of a permission gate that never denies. The fix isn’t to remove the review (it might catch something eventually) but to instrument it. How often does the review actually modify or reject an output? If the answer is never, the review process is a specified rule that could be replaced by an automated check — minimum cell sizes, no individual-level data, output format validation. Move the review from trained judgment (the reviewer’s assessment) to specified rules (automated checks). The reviewer’s judgment is freed for the cases that actually need it.

Collaborations that don’t produce reusable artifacts. A product manager and an analyst spend three weeks building a custom churn analysis. The analysis answers the question. The SQL lives in the analyst’s notebook. Six months later, a different PM asks a similar question. A different analyst builds it again from scratch.

This is the ratchet failing to turn. Stage 1 happened — the discovery, the collaboration, the working solution. Stage 2 didn’t — the crystallization, the promotion from bespoke work to reusable tool. The organization paid the full cost of exploration twice.

The organizational ratchet¶

Every time a bespoke analyst-researcher collaboration produces a reusable tool, the organizational computation channel level drops.

The first time a product manager asks “what’s our churn rate by plan tier for enterprise accounts?”, the interaction is natural-language delegation. The PM explains what they need. The analyst interprets, asks clarifying questions, writes custom SQL, runs the analysis, formats the output, sends it back. This is a computation channel interaction. The characterization difficulty is quadratic — the analyst could produce a wide range of outputs from the same input, and the PM can’t predict which one without understanding the analyst’s full process.

The tenth time someone asks that question, someone should have built a tool. churn_by_tier(plan_type, min_arr, period) — structured input, characterized output, bounded effects. This is a data channel interaction. The characterization difficulty is linear — the output is determined by the input plus the tool’s specified behavior. The PM can predict what they’ll get. The analyst doesn’t need to be involved.

That grade drop — from computation channel to data channel, from quadratic characterization difficulty to linear — is the ratchet turning. The interaction got cheaper. The analyst’s time is freed for the questions that actually require their judgment. The PM gets faster answers. The organization’s total capacity for answering business questions increased without hiring anyone.

The ratchet only turns one way. Once the tool exists, the bespoke interaction doesn’t come back. Nobody asks an analyst to manually compute a phenotype distribution when there’s a tool that does it in seconds. The crystallization is permanent. The organizational computation channel level ratchets down.

Handoff schemas as co-domain funnels¶

Here is where freeform email becomes visibly expensive.

A product manager slacks an analyst: “Hey, I’m looking at some stuff with churn in our enterprise accounts and wondering if you could pull some numbers on feature usage before they churned, maybe broken down by plan tier? Also, are there any engagement signals we should be looking at?”

That message is a computation channel. The analyst has to parse natural language, infer what “enterprise accounts” means (by ARR? by employee count? by plan type?), decide what “some numbers” means (counts? percentages? trends?), choose how to define “before they churned” (30 days? 90 days? last active month?), and determine what counts as a relevant engagement signal. The analyst’s interpretation could go in many directions. The PM can’t predict which one. Multiple clarification rounds are likely.

A structured request template changes the channel:

Segment: enterprise accounts, ARR >= $50K, churned in Q4 2025
Primary metric: feature usage frequency (logins, API calls, report views)
Time window: 90 days before churn date
Stratification: plan tier (starter, growth, enterprise)
Comparison: same metrics for non-churned enterprise accounts
Output format: comparison table with statistical significance

Same question. Different channel. The structured template is a co-domain funnel — it forces the PM’s broad intent through a narrow, specified interface. The PM has to make their choices explicit. The analyst receives a specification, not a conversation. The characterization difficulty drops from quadratic to linear. The interaction cost drops from multiple rounds of clarification to a single handoff.

Structured handoff schemas at organizational boundaries are co-domain funnels. Every boundary where two teams interact through freeform communication is a computation channel operating at the organization’s expense. Every boundary where the interaction is structured — request templates, intake forms, API contracts, shared schemas — is a data channel operating at a fraction of the cost.

The organizational ratchet’s most impactful turn is often not a new tool. It’s a structured handoff schema at a boundary where freeform communication was burning coordination budget.

The framework isn’t about AI¶

The personal system and the organizational system have the same architecture. Star topology with a mediating layer. Specialized actors at the points. Structured handoffs at the boundaries. Failures flowing inward as signal. A ratchet that crystallizes repeated patterns into specified infrastructure.

The person with ADHD externalizing their Harness into calendar blocks and task lists is running the same architecture as the analytics team crystallizing analyst-mediated queries into self-service tools. The planning phase that compresses broad reasoning through a co-domain funnel into a structured plan is the same operation as the product manager compressing a business question through a request template into a structured specification. The body double providing ambient monitoring is the same function as the team lead watching the failure stream for signs that the configuration isn’t working.

Same structure. Different substrates. The star topology works because it works — not because the participants are software.

The framework was developed by studying AI agent systems. The concepts were named after what we observed in Claude Code conversations and data platform architectures. But the structure predates the substrate. Organizations have been running star topologies, externalizing Harness functions, and turning ratchets since before there were computers. The framework didn’t invent the pattern. It named it.

And naming it matters, because once you can see the pattern, you can diagnose it. When your personal productivity system fails, you can ask: is the problem in the planning (System 4), the execution (System 1), or the coordination (Harness)? When your data team is underperforming, you can ask: are the failures in the request channel (unstructured handoffs), the governance layer (constraints that aren’t earning their cost), or the ratchet (bespoke work that never gets crystallized)?

The diagnosis leads to the fix. And the fix is always a configuration change — a structural adjustment to where the constraints operate and where the failures flow. Not a mandate to work harder. Not a new tool that solves everything. A specific, testable change to the architecture of coordination.

Put the failures where they become learnings. The calendar block that catches a missed transition. The request template that eliminates a clarification round. The structured tool that replaces a bespoke analysis. Each failure that gets crystallized into infrastructure makes the system cheaper and the people freer — freer to do the work that actually needs their judgment.

The ratchet turns the same way in every substrate. Let it.

Previously: Teaching Without Theory Next: Ratchet Metrics For the full treatment: Coordination Is Not Control