Biology as a Design Constraint

Most software naming is cosmetic. You call your message queue “Kafka” and your cache “Redis” — the names describe nothing about how they should evolve. When your cache needs a new feature, “Redis” gives you zero guidance.

We tried something different: using cell biology as an engineering manual for an AI agent orchestration system. Not metaphor — constraint. The names don’t just label components, they predict what features to add, what to remove, and how pieces should interact.

The System

mtor dispatches AI coding agents to execute tasks. ribosome is the agent that takes a spec and produces code. Named after their biological counterparts:

• mTOR (mechanistic Target of Rapamycin): the cell’s master regulator that integrates nutrient signals and decides whether to build proteins
• Ribosome: the molecular machine that reads mRNA instructions and assembles proteins

The naming wasn’t arbitrary. We chose it because the mechanisms matched: mTOR decides what to build and when; ribosomes execute. But we didn’t anticipate how much the biology would teach us.

Night One: The Biology Predicts

During an overnight autonomous dispatch session, we hit three problems. Each time, the biology had already solved it.

Problem 1: Empty Results

Tasks completed successfully but the review gate couldn’t see their output — like a factory that produces goods but loses them before inspection. We were checking main..HEAD for diffs, but when the agent committed directly to main, that range was always empty.

What mTOR does: mTOR doesn’t just check one signal. It integrates multiple pathways (Rag GTPases for amino acids, PI3K/Akt for growth factors, AMPK for energy). If one signal is absent, it checks others.

What we built: base_sha fallback — record HEAD before execution, fall back to {pre_sha}..HEAD when main..HEAD is empty. Multiple sensing pathways for the same signal.

Problem 2: Rejected but Valuable

The review gate rejected 7 tasks. Manual investigation revealed all 7 had produced working, tested code. The work existed but was invisible to the gate.

What mTOR does: When nutrients are scarce, mTOR inhibition triggers autophagy — the cell literally eats its own components to recycle valuable materials. Nothing is wasted.

What we designed: mtor salvage — scan rejected tasks, check if ganglion (our build server) has commits that soma (dispatch server) hasn’t merged, recover them automatically. The biology told us: don’t discard rejected work, recycle it.

Problem 3: Dispatch Rate

We dispatched at a constant rate regardless of outcome quality. When the review gate was broken (rejecting everything), we kept dispatching into a broken pipeline.

What mTOR does: S6K1→IRS-1 negative feedback loop. When ribosomes produce misfolded proteins (quality failures), a phosphorylation cascade feeds back to reduce mTOR activity. The cell slows down protein production when quality is poor.

What we designed: Rejection rate tracking in the watch loop. When >60% of recent tasks are rejected, halve the dispatch rate and double the check interval. When quality recovers, restore the original rate. The feedback loop was waiting in the name.

Features the Biology Removed

Equally powerful: the biology told us what to remove.

Satisfaction scoring (0-100): We had a numeric quality score with deductions and bonuses. But mTOR phosphorylates or doesn’t — it’s binary. There’s no “70% phosphorylated.” The score actively confused debugging (“satisfaction 70” told us nothing). Flags like no_commit_on_success were the real diagnostic all along. We killed the score.

Active provider probing: We built a probe command that actively pings providers to check health. But mTOR senses nutrients passively from metabolic byproducts — amino acids activate Rag GTPases as a side effect of normal metabolism, not through dedicated probes. Our circuit breaker already updates passively when tasks complete. The probe was un-biological overhead. We removed it.

The Mechanism, Not the Vocabulary

The common objection: “These are just fancy names for circuit breakers and recycling.”

Yes — but the names generated those designs. We didn’t start with “we need a circuit breaker” and then name it. We started with “mTOR” and asked: what does real mTOR do that our system doesn’t? The biology is a checklist of solved problems:

Biology	Engineering	Status
mTOR activates ribosome biogenesis	mtor dispatches ribosome	✓ Built
Circuit breaker (nutrient sensing)	Provider health routing	✓ Built
No-go decay (stall detection)	Heartbeat stall detection	✓ Built
Autophagy (recycle on starvation)	Salvage rejected tasks	Designed
AMPK (energy sensing)	Worker capacity check	Designed
S6K1 negative feedback	Rejection rate throttling	Designed
Rapamycin inhibition	Pause/resume dispatch	Designed
5’TOP preferential translation	Self-improvement priority	Designed

Eight features. Zero were “designed from requirements.” All were read from biology.

The Constraint That Compounds

Single metaphors exhaust quickly. “Pipeline” gives you input→process→output and then you’re done. Cell biology has 3.5 billion years of solved problems at every level of abstraction. The naming convention doesn’t just label — it generates an infinite roadmap of features that are already proven to work together, because the cell already integrated them.

The test isn’t “is this a clever name?” The test is: does the name tell you what to build next?

If it does, it’s not a metaphor. It’s an engineering manual.