A field map of how an AI operator learns a merchant, decides what to write, checks its own work, and — as of yesterday — finally notices when it's gone quiet.
Otto is not one model. It is a nervous system built from five separate organs that produce content, a sequential deliberation pipeline nicknamed the octopus, a weekly strategist that plans but deliberately never acts alone, a quality-control layer that grades Otto's own writing before it ships, and — as of this week — a safety net that pages a human the instant the whole thing goes deaf. This report is a direct account of what is actually running in RunOctopus's production code today, not the roadmap. Where a piece is still a blueprint rather than a running system, it is labeled as such. Every claim below traces to a real file in the codebase; see References.
One note up front: an internal shorthand has circulated calling this "seven independent brains." That phrase does not match anything in the code. §8 addresses it directly.
Otto exists to do the SEO and content work a busy 6-to-8-figure Shopify operator doesn't have hours in the day for — not by handing them a blank text box and a prompt, but by running it programmatically: learning the store, writing the content, checking the content, and deciding what to do next week, largely without being asked. The goal stated internally is blunt — get the merchant recommended by AI search without the merchant doing the work.
Everything in this report is in service of that one sentence. The rest is mechanism.
Content does not come from one generator. It comes from five, each suited to a different rhythm of merchant behavior.
| Organ | Rhythm | What it's for |
|---|---|---|
| Drip | tick, every minute | The default autonomous cadence. Merchant turns it on, tier-driven volume of articles/tools/collections just keeps arriving. |
| Campaign | on launch | A themed, sequenced cluster of pieces around one goal — hand-triggered or launched by the Goal Brain (§3). |
| Chat / AI Create | on request | Interactive, typed or one-tap generation. Drafts land in an "AI Vault" holding area before publish. |
| Tools v2 | queue, every minute | Programmatic-SEO variant spawning from one parent tool, across a frozen taxonomy of seven archetypes — finder, calculator, quiz, sizer, configurator, comparator, diagnostic. |
| Collections | tick + refresh | Catalog-destination pages, generated and periodically refreshed as the store's inventory changes. |
The seven archetypes above are a real, frozen taxonomy in lib/tool-archetypes.js — a different "seven" from the Living Loop's seven beats in §5. Worth not conflating the two.
Internally, the codebase calls this pipeline the octopus — not a metaphor invented for this report, but the actual name used in the source comments. It runs in three sequential stages, called Arms. Nothing here votes or runs independently; each Arm hands a finished decision to the next.
lib/territories/goal-brain.js, lib/article-strategist.js, lib/campaigns.js.Separate from any one campaign, Otto also runs a standing weekly cycle over the merchant's whole account — internally called the Otto Cycle. Its most deliberate design choice is a split: the part that decides is a different cron, running on a different schedule, from the part that acts.
auto, propose, or monitor — only auto runs immediately. propose moves sit until a merchant (or an operator) says yes, on purpose, so a merchant always has a window to veto before Otto acts on its own account. Source: lib/otto-strategist.js, lib/otto-executor.js, lib/model-router.js.Where §3 and §4 are about deciding what to write, the Living Loop is about learning who the merchant even is — and staying honest about how much of that learning is actually turned on. All seven beats share one gate (octopusEnabled(flag, merchantId)), so each can be switched on globally, on a canary list of specific merchants, or left off, independently of the others.
| Beat | What it does | Status |
|---|---|---|
| Whole catalog | Paginate past Shopify's 250-item page limit so the crawl sees the real catalog, not a slice. | Live, global |
| Never wipe a real catalog | Guard rail against a crawl mistaking "nothing found" for "delete everything." | Live, global |
| Never work a dead store | Checks the connection is actually healthy before doing anything with it. | Built, canaried |
| Learn the soul | Deep positioning — mission, value props, founding story — not just products. | Proven live on one real merchant |
| Feedback loop | Learn from what actually performed, not just what got published. | Built, off — no performance data yet |
| Living refresh | Re-learn the merchant on demand, not just at first connection. | Built, canaried |
| One shared brain | Every surface reads the merchant through one loader, not five copies drifting apart. | Done, migration complete |
All seven are code-complete. What's left is rollout — an operational decision, not an engineering one.
Before anything Otto writes reaches a merchant's storefront, it passes through a quality engine with two layers: cheap deterministic checks first (right length, no banned filler phrases, has the keyword), and only if those pass, a second, more expensive Claude Haiku judge that scores the writing against a rubric — does this actually read like something a real buyer would search for, or does it read like an internal label.
Nine content types are covered today: article, guide, collection, comparison, drop-in, hub, recovery, tool, and FAQ. Every one runs in OBSERVE mode by default — scored and logged, never blocking. As of this week, two of the nine — article and guide — have been moved into soft ENFORCE in production: a piece that fails the bar gets marked held and withheld from publish, though a merchant can always override it. The other seven are not yet enforceable at all — they don't have a "held" state to enforce into yet.
An older tracking issue (GitHub #1335) proposed holding all enforcement off pending more observation data. The soft-enforce rollout above appears to supersede that decision, but the issue's current open/closed state on GitHub wasn't verified live for this report. Check before treating either state as current.
All of the above — every organ, every Arm, every judge — runs on Anthropic's API. On 2026-07-07, that API ran out of credit balance for about eighteen to twenty hours, and nothing paged anyone. Building on the very question this report exists to answer — has the whole loop actually been thought through — two real gaps were found and closed the same day.
A page-an-operator alert already existed, built after an earlier, separate outage. It was wired into exactly one of the places that generate content. The other three said, in the merchant-facing error message, "the team's been notified" — which was false for all three, including the one that had actually failed. Fixed: the same alert, added everywhere it was missing.
Pushed one layer further: the eighteen separate places that grade content — not write it, grade it — had the identical blind spot. Any Anthropic error there was treated as a quiet pass, with zero signal to anyone. Fixed the same way, plus a standing check that fails the build automatically if a future call site ever copies the old, silent pattern again.
Every real place in the codebase that calls Anthropic — for writing or for grading — pages an operator the moment the whole API goes down. What it does not guarantee: there is still exactly one API key with no fallback provider, and roughly three dozen smaller call sites for content generation (not grading) still call the API directly, uncentralized. Both are known, both are deliberately deferred, neither is silent anymore.
A phrase has circulated describing Otto as "seven independent brains." It is worth retiring precisely, because two real sevens exist in the code and neither one is that:
The actual decision-making architecture is the three-Arm octopus (§3, sequential, not independent) plus the weekly strategist (§4, one planner with a separate executor). Neither is "seven" of anything.
Separately, a founding specification — OTTO_AGENT_FOUNDATION.md, explicitly marked as not gating launch — describes seven longer-term components for a fully autonomous Otto. Checked against the real codebase:
| Component | Status |
|---|---|
| Strategy Planner | Built — this is §4 |
| Network Learning Substrate | Built, under the name "federation" |
| Conversational Operator Interface | Built — the chat surface in §2 |
| Content Graph | Not found in code |
| Cluster Authority Map | Not found in code |
| AISVI + Real-Time Surveillance | Not found as specified — a narrower, differently-named citation-tracking feature exists instead |
| Self-Improving Generation Layer | Not found in code |
No single document in the repository currently describes Otto's as-built architecture end to end — this report is a first attempt at one, assembled by reading the code directly rather than the roadmap.