Mechanism

Bidirectional Task Assignment for Continuous Forward Progress

How sending tasks upward to experts and downward to delegates kept me in continuous forward progress -- never blocked by my own limitations, never slowed by work beneath my level.

596,903
Lines of production code across 10 systems in 4 months

The Problem

I cover the full stack. Front-end, back-end, DevOps, QA, marketing, operations -- the entire operation depends on one person. No individual excels at every layer. When execution reached a layer where my capability was insufficient, I had three bad options. Learn it: stop executing for days or weeks while I acquired the skill. Hack through it: ship a substandard solution and accumulate technical debt that would cost more to fix later than doing it right the first time. Hire a specialist: introduce coordination overhead, scope definition, review cycles, and financial cost. Each response created drag. None of them kept me moving forward.

The problem ran in both directions simultaneously. While I was blocked at the top by tasks above my ceiling, I was wasted at the bottom by tasks below my level. File organization, basic formatting, repetitive data entry, routine deployments -- work that consumed my time but required a fraction of my capability. If my highest-value work produced five hundred dollars per hour of equivalent value and I spent an hour on twenty-five-dollar work, the opportunity cost was four hundred and seventy-five dollars. Not ego. Economics. A finite resource -- my time -- allocated to its lowest-value use.

The specialization paradox made it worse. Traditional division of labor solves both problems through dedicated specialists at every layer. Solo operators cannot specialize -- and micro teams cannot afford full-time specialists for every domain. I needed specialization's benefits without specialization's structure. Per-task routing, not permanent roles. Individual tasks finding the right capability level without requiring an org chart.

What Routing Actually Is

Routing is a bidirectional task assignment system that keeps the operator in continuous forward progress. Tasks above the operator's ceiling route upward to subject matter experts. Tasks below the operator's floor route downward to VAs or agents. Everything between ceiling and floor is where the operator creates maximum value -- and that is where the operator stays.

What it provides:

  • Upward escalation -- when you hit your ceiling, the task moves to someone with the right expertise; you define the scope, receive the work, and capture the learning so the ceiling rises permanently
  • Downward delegation -- when a task sits below your level, it moves to an appropriate resource; you define the task, review the output, and keep your attention on high-value execution

What it does not provide:

  • Elimination of coordination cost -- every routed task requires scope definition, context sharing, review, and integration; if coordination cost exceeds the cost of doing it yourself, routing is net negative
  • Permanent support structure -- routing should make itself unnecessary over time; upward patches return learning that raises your ceiling, and automation raises your floor; if your routing dependency stays flat, you are building dependency, not capability

The capability band is not static. As Foundation grows and I develop, the ceiling rises -- tasks that once required specialists become manageable. The floor rises -- tasks that once required attention become automatable. The band shifts upward over time, and routing patterns shift with it. The trajectory from heavy external routing to near-independence is the proof that the mechanism works.

The Capability Band and Business-Model Displacement

Routing creates a capability band -- the range between ceiling and floor where the operator executes. Tasks above the ceiling route up. Tasks below the floor route down. The operator's goal is to stay in that band. But the band itself is not fixed. Every upward patch returns learning that raises the ceiling. Every automation that replaces a below-floor task raises the floor. Over time, the band shifts upward and the operator handles work that previously required external routing.

This played out at business-model scale, not just task scale. Before CEM, my revenue model routed virtually all value-generating activity through external parties. The affiliate payout structure told the story: AFF-01 (PRJ-12) at 38.9% commission, AFF-02 (PRJ-12) at 39.1%, AFF-03 (PRJ-12) at 45.4% -- all producing negative margin. AFF-08 (PRJ-13) hit a 94.6% payout ratio: $17,670 in peak revenue, $16,716 paid out, $954 retained. Portfolio-wide: $848K in total affiliate payouts against $868K in total revenue -- a 97.7% payout ratio. For every dollar of revenue, I kept two cents.

The CEM infrastructure build systematically internalized what had been externally routed. SaaS platforms displaced: $19,909 total -- Konnektive, TrackDesk, Socioboard, SendGrid, Klaviyo, Sonetel. Monthly run rate from $1,565/month to $0/month. PRJ-01 replaced six vendor platforms with internal infrastructure. Contractors displaced: $62,731 total -- CON-02 (dev shop), CON-03 (individual contributor). Peak monthly from $9,046/month to $0/month. Total displacement: $82,640 in external costs eliminated. The code-level routing and business-model routing moved in the same direction simultaneously -- external dependency decreased across every dimension as internal capability increased.

What the Data Shows

Routing was validated across ten production systems totaling 596,903 lines of code and 2,561 commits over four months (October 7, 2025 through February 2, 2026). Contributor patterns in git data provide direct evidence of routing in operation.

Project External Cost Primary % Routing Context
PRJ-08 $7,995 31.4% Heavy upward routing; developing capability
PRJ-11 $1,680 43.3% Reduced routing; capability growing
PRJ-03 $90 96% Minimal routing; mature capability band
PRJ-04 $0 100% No external routing needed

The cost trajectory from $7,995 to $0 reflects routing maturation. Early projects routed heavily -- high cost, external dependency. Later projects routed minimally -- low cost, operator independence. Foundation absorbed the knowledge from early routing, raising my ceiling with each upward patch.

The December 21 transition was the defining routing event. Before that date, execution was routed primarily to an outsourced dev shop -- approximately 14 months of external development (Oct 2024 -- Dec 2025). Velocity: 5.8 commits/day. After December 21, I transitioned to solo execution with AI as enabling environment. Velocity: 24.1 commits/day -- a 4.2x increase. That transition was not abrupt abandonment. It was informed by 14 months of routed work that had contributed patterns, architecture, and domain knowledge into Foundation. The external routing phase built the Foundation that made the solo execution phase possible.

The infrastructure displacement timeline confirmed the pattern at business-model scale. Monthly operating costs moved from $5,887 average to $0 -- an 87% reduction. By January 2026, SaaS vendors stood at $0, contractors at $0, and all vendor costs were eliminated. Platform routing collapsed from six SaaS vendors to one internal system (PRJ-01). Every dimension moved in the same direction: contributor commits, platform costs, contractor costs, and affiliate payout ratios all shifted from external dependency to internal capability.

How to Apply It

1. Identify Your Ceiling and Floor Map your capability band honestly. What tasks are above your current expertise? What tasks consume your time but require a fraction of your capability? The ceiling and floor define where routing activates. Everything between them is where you execute. Be specific -- "DevOps" is a ceiling, "file organization" is a floor. Name the actual tasks, not the categories.

2. Build Routing Relationships Before You Need Them Identify SMEs for above-ceiling domains and VAs or agents for below-floor tasks before the routing need arises. Establishing relationships under execution pressure is expensive and slow. Have the DevOps specialist, the legal reviewer, the database expert already identified. Have the VA onboarded, the AI agent configured, the automation ready. When the routing trigger fires, the path should already exist.

3. Route Early, Not Late The operator who recognizes a ceiling task immediately and routes it loses minimal time. The operator who struggles with the ceiling task for days before routing loses the struggling time plus the routing time. The same applies below the floor: routing a low-value task immediately frees your time; doing it first and routing later wastes the time you cannot recover. The moment you recognize the signal -- stuck above ceiling, wasting time below floor -- route it.

4. Capture the Learning to Shrink the Routing Every upward patch is a learning event, not just a delivery. When the specialist returns the work, capture the pattern so the ceiling rises permanently. Every downward patch that gets automated raises the floor permanently. Your routing dependency should decline over time. If it stays flat or grows, you are consuming answers instead of absorbing capability. Track the trajectory: 31% primary commits to 100% is the curve you want.

References

  1. Smith, A. (1776). An Inquiry into the Nature and Causes of the Wealth of Nations.
  2. Keating, M.G. (2026). "Vision." Stealth Labz CEM Papers. Read paper
  3. Keating, M.G. (2026). "Foundation." Stealth Labz CEM Papers. Read paper
  4. Keating, M.G. (2026). "Scaffold." Stealth Labz CEM Papers. Read paper
  5. Keating, M.G. (2026). "Enabling Environment." Stealth Labz CEM Papers. Read paper