The Auto Marketing
Engine, operated.

Marketing’s self-driving moment

Once in a generation, a kind of work that used to demand a room full of people working late gets handed to a machine that never tires — and the people move up to the decisions that actually needed them. It happened to weaving, to the assembly line, to arithmetic the day the spreadsheet arrived, and to the open highway the day a car first held its own lane. It is happening now to marketing. This engine is that machine, and this manual is how you operate it.

It is worth being clear-eyed about why these shifts feel so large, because the pattern is always the same and it is always misunderstood at first. The machine that changes an industry almost never replaces the human’s judgment. It replaces the human’s drudgery — the repetitive, endless, unforgiving work that sits beneath real talent and quietly consumes most of the hours. The mechanical loom did not invent cloth or decide what to weave; it freed weavers from throwing the shuttle by hand ten thousand times a day. The assembly line did not design the automobile; it removed the grind between the design and the driveway. The spreadsheet did not decide what a business should become; it ended the nights spent recalculating columns by hand, so that people could spend those nights deciding instead. In every case the machine took the grind and gave back the hours — and the businesses that reached for it first pulled away from the ones that waited for permission from the future.

What self-driving actually automated

The self-driving car is the cleanest illustration of the pattern, because everyone can feel exactly where the line falls. The car never took over the part of driving that was truly yours: choosing the destination, deciding the trip was worth taking, knowing the neighborhood you were heading into and why. What it automated was the thousand small, exhausting, unforgiving operations in between — hold the lane, check the mirrors, keep your distance, read the signs, react in a tenth of a second, and then do all of it again, and again, for every mile, without ever getting bored, distracted, or careless at four o’clock on a Friday. That is the precise shape of the work no human stays good at for long, and the precise work a well-built machine performs superbly, forever. The genius of it was never that the machine was smarter than the driver. It was that the machine was tireless where the human was not.

Marketing has exactly the same shape

Here is the insight this entire engine is founded on: marketing is built the same way a drive is. The part that is genuinely yours — what your business stands for, who it is for, the story only you can honestly tell, the judgment about what is true and worth saying — that is the destination, and no machine should ever touch it. But wrapped around that small, precious core of judgment sits an enormous, grinding volume of mechanical operations. Read every page of the site. Measure the title tag. Check whether the answer engines can even find you. Draft the meta description. Write the FAQ. Tighten the headline. Schedule the post. Send the follow-up. Then re-measure all of it and begin again next week, because the web never once stops moving. On a network of even a dozen sites that is thousands of separate tasks a month — the lane-keeping and mirror-checking of marketing. It is exactly the work people are worst at performing tirelessly, and exactly the work that decides whether a business is ever found at all. The talent goes into strategy; the hours disappear into the grind. That imbalance is the problem this engine was built to end.

The engine is the self-driving layer for that work

This is the self-driving layer for marketing, and it behaves the way you would want a tireless driver to behave. Point it at a live web address and it does what a seasoned marketing team does on its first day on the account — except it does it in seconds, and then it does it again every single day without being asked twice. It reads the real road: it fetches your actual page, this page, not a generic idea of what a business like yours might look like. It knows the rules of the road: it scores what it finds against a model built from how search engines and answer engines genuinely rank and cite pages today. And then it drives — it drafts the fixes, page by page and role by role, across the whole department at once: the search work, the answer-engine work, the content, the email, the social, the conversion copy. It never gets tired, never phones it in on the two-hundredth page, never forgets to circle back next week. It is the tireless half of an entire marketing department, running on a schedule, at a cost that does not climb every time the workload does.

But it always asks before it merges

Here is where this engine deliberately parts ways with the robotaxi — and the departure is the whole point. Full self-driving tried to remove the human being entirely, and the hardest, most consequential part turned out to be precisely the moment of judgment: the merge, the unexpected, the decision that carries a cost if it is wrong. This engine does not pretend that moment away. It will drive the entire route for you, but it always asks before it merges. Nothing it writes ever goes live until a person looks at it and says yes. Every draft waits in an approval queue, visible and fully editable; outbound email is never sent on its own; and anything it does publish can be undone with a single click, because it quietly saves the previous version first. This is not an autopilot that hopes you have stopped watching. It is a tireless pair of hands on the wheel, with your hands still resting on the one decision that carries your name. That restraint is not a limitation bolted on for safety after the fact — it is the design itself, and it is what makes the machine trustworthy enough to actually use. The engine carries the mileage; the person keeps the judgment. Those three guarantees — it reads the real page, nothing ships without a yes, every change is reversible — run through every chapter that follows, beginning with Chapter 1.

The only real question is who is early

The remarkable thing about every one of these leaps is that the technology was rarely the hard part — the hard part was being early enough to use it while it still conferred an advantage. The looms existed for years before most mills installed them. The spreadsheet shipped long before most businesses trusted it with the books. The self-driving stack worked in the lab well before most fleets dared adopt it on the road. In each case the edge did not belong to whoever invented the machine; it belonged to whoever operated it first, while everyone else was still debating whether it was real. The engine described in the pages that follow already exists, already runs in production, and has already been proven on a live network of the operator’s own sites before it was ever pointed at a paying customer’s — which is exactly why this manual can show you measured before-and-after results instead of promises (see Part VII). The machine is built. It runs today. The only open question left is the one that every industry’s early adopters were lucky enough to answer first: who operates it now, while it is still an edge and not yet the baseline everyone is scrambling to catch.

How to use this manual

This is a working manual for a system that is already running, not a brochure for one that might. Everything in it was read from the live engine and its case files; where a number appears, it is a real number with a real source.

Read it three ways, depending on why you are here:

• To understand it — read Parts I and VII. Part I is the plain-English picture of what the engine does; Part VII is the proof it works, with measured before-and-after results.
• To operate it — read Parts III and IV. Part III describes every department in detail — what each one actually reads off your site and what it produces. Part IV is the day-to-day workflow, the four phases from onboarding a business to the quarterly review.
• To administer or upgrade it — read Parts II and VIII. Part II is the architecture: the service, the scoring model, the datastore. Part VIII is the runbook: restarting the service, the daily cron, refreshing the library, and safely adding a department, a niche, or a check.

Part V documents the marketing-skills system the engine is built on, and Part VI covers each special-purpose engine in the WholeReach family. Two conventions recur throughout:

↓ Table of contents

What the Auto Marketing Engine is

The Auto Marketing Engine is a marketing department that runs as software. You give it a web address; it reads the site the way a marketing team would on their first day, scores what it finds, drafts the fixes, and holds every one of them for a human’s approval before anything goes live.

It is not a chatbot, and it is not a single tool that does one thing. It is structured like the department a growing business would otherwise have to hire — a set of roles, each with one job, all feeding one approval queue. The difference is that the repetitive work is carried by software running on a schedule, and the judgment stays with a person.

Put plainly: a chatbot waits for you to ask a question and answers it. A single-purpose tool does one thing — writes a headline, checks a keyword — and leaves you to manage the rest. The engine instead behaves like a team you have already onboarded. It shows up to a live site, does the reading and the drafting on its own, and comes back with finished work waiting in a queue. What it will never do is publish that work without you.

The three commitments

Three commitments define the engine, and they run through every chapter of this manual. They are not slogans — each one is enforced in the code, and you can watch each one refuse to bend.

1. It reads the real page. Every finding comes from an actual fetch of your live site. When it cannot reach the page, it says so and produces nothing, rather than inventing a plausible-looking result.
2. Nothing ships without a yes. The engine drafts; a human approves, edits, or rejects. There is no auto-publishing, and outbound email is never sent automatically.
3. Every change is reversible. When an approved fix goes live, the engine snapshots the file first. One click restores it.

What that looks like in practice — illustrative

The following mini-scenarios are illustrative, to show the three commitments in motion. Suppose you paste in the address of a small coffee-roaster site:

• It reads the real page. The engine fetches the homepage and reports what is actually there — for example, “title 78 characters, one H1, no llms.txt, no FAQ schema, 420 words on the homepage.” It does not describe a coffee site in the abstract; it describes your coffee site.
• Nothing ships without a yes. It drafts a tightened title and a lead answer paragraph, and drops both into the queue marked held. They sit there, visible and editable, until you click approve. Nothing is on your live page yet.
• Every change is reversible. You approve the title rewrite. Before writing the new tag, the engine copies the current page to a timestamped backup, then makes the change. If the new title reads wrong, one click puts the old one back.

An honest counter-example is just as important. Point the engine at a URL that is down or blocking bots, and it does not hand you a generic audit. It records that the fetch failed and each page-specific role returns the same note instead of a fabricated result — the behavior documented in Chapter 10. A tool that invents an audit for a page it never read is worse than no tool, because the first time someone checks, it costs trust.

How to use it — step by step

1. Plain English: Go to automarketingengine.com and use the free audit on the front door — one URL, no signup, nothing asked in return.
2. Enter your site’s address and submit. Within a few seconds you land on the Audit & Report view with a real 0–100 scorecard and role-by-role deliverables already drafted.
3. Move to the Approvals & Setup view to approve, edit, or reject each drafted item. This is the seat you keep.
4. Approved work becomes eligible to ship, and every shipped change can be rolled back with one click.
5. Under the hood: that front-door audit is a single call to /analyze with your URL. It runs the same pipeline (Chapter 5) and the same scoring (Chapter 6) that scores the operator’s own network — there is no “demo mode.” A shareable branded version of the result lives at /report/<domain>.

The product lives at automarketingengine.com. It has been running on the operator’s own network of live sites before ever being pointed at a client’s — which is why this manual can show measured results, not projections. The chapters that follow open the machine up: the loop it runs (Chapter 2), the family it belongs to (Chapter 3), the backend that powers it (Chapter 4), and the audit and scoring that make its numbers real (Chapters 5–6).

The loop: audit, draft, approve, ship, measure

Everything the engine does is one loop, run over and over. A good marketing department runs the same loop; the engine’s contribution is carrying the repetition while keeping a person in the one seat that matters.

Read the five stations once and you understand the whole product. Every chapter after this one is a close-up of a single station: Chapter 5 is the audit, Chapters 12–21 are the drafting roles, Chapter 25 is the approval gate, Chapter 9 is shipping, and Part VII is the measurement. Hold the loop in your head and the rest falls into place.

The five stations

These are shown on the cover and repeated here because they are the spine of the whole system.

1. Audit. You enter a URL. The engine fetches the page and scores it 0–100 across five disciplines — SEO, Content, AI Search, Social, and Technical — plus a sixth, Reach, that is measured from real traffic rather than read off the page (Chapter 6).
2. Draft. Each role produces its work from the same page read: the SEO fixes, the content briefs and calendar, the social drafts, the schema, the conversion and analytics recommendations. All of it is specific to your site’s actual signals.
3. Approve. Everything lands in a queue. You approve, edit, or reject. This is the seat you keep, and the reason the engine is safe to point at a real business.
4. Ship. Approved work goes live. On the operator’s own test beds this writes directly to the site’s files, after taking a snapshot; for a client store it goes through the platform’s own API on the same approve-first, reversible terms.
5. Measure. Scores re-run on a schedule. The workspace keeps a history, so a fix that moved a number shows up as a real before-and-after (Part VII).

The loop, walked with one deliverable — illustrative

To make the five stations concrete, follow a single fix — a missing FAQ-schema block — all the way around the loop. The figures below are illustrative but track exactly how the real homebuilding case in Chapter 41 played out.

That before-and-after is not a projection. In the real case file, the same fix applied by the same role moved AI Search on every one of six sites — because FAQ-schema is exactly what an answer engine needs to quote a page. The loop is what turns “we recommend adding schema” into “here is the schema, live, and here is the number it moved.”

How to use it — step by step

1. Audit. In the app, the Audit & Report view runs the audit; technically it is a /analyze call that returns the scorecard and drafts the deliverables in one pass.
2. Draft. Review each role’s output in its view — SEO & AI Search, Content, Conversion, Outbound. These are produced by the department analyzers (seo_aiso(), cro_recos(), and the rest) from the single page read.
3. Approve. Go to Approvals & Setup and approve, edit, or reject. Edits run through /deliverable-edit; the status change runs through /approve.
4. Ship. Approved items ship via /ship (snapshot then write); anything shipped can be reversed via /rollback.
5. Measure. Fresh work and re-scores are produced on a schedule by /run-daily (one site or the whole network). The rolling score history in the workspace is what turns a claim into a proven before-and-after.

Why the gate is the whole point: the loop is deliberately built so station three — approval — cannot be automated away. That single constraint is what lets you point the engine at a real business instead of a sandbox. It is the difference between a department and a bot with your password.

Where the engine sits in WholeReach

WholeReach is the house for automated marketing — the aggregator the whole engine family lives under. The Auto Marketing Engine is the working product; the other properties are editions, workspace builds, and live case files that all run on the same backend.

The family is best read as one engine, several front doors. Each site stands on its own — its own address, its own sitemap, its own audit — and they share the engine and the skills library, not a login. Part VI gives each its own chapter. The mental model to carry: there is a single brain (the backend service in Chapter 4) and many faces, each face telling the same story to a different audience. A skeptic, an operator running a portfolio, and a first-time visitor all get a door built for them, and behind every door is the identical /analyze machinery.

Why a family and not a single site

The reason is resilience and framing, not marketing sprawl. Because every edition is kept at parity on the shared backend, any one of them could stand in for the flagship if needed — a deliberate resilience choice (Chapter 34). And because different buyers need different framings, each front door can lead with the angle that lands: the department edition, the “run marketing without the department” edition, the department-as-a-service edition, the live case files. Same engine, aimed differently.

The property list, and how to read it

Each entry below is a marketing function in the family, paired with the department it maps to. This is the capability surface expressed as properties; the same functions are organized into departments in Part III and enumerated as skills in Part V.

Reading the list — a worked example

Say you run a coworking space and want more members. You would not shop the list function by function; you would let the engine route you. The cro property (CRO department) reads your live signup page for the things that turn a visitor into a member; content-strategy (Content Desk) builds the publishing calendar tuned to your niche; ai-seo and schema (Answer-Engine) make you quotable by AI readers. Three properties, three departments, one page read — and all of it lands in the same approval queue. That is the payoff of “one engine, several front doors”: the specialties are many, the discipline is one.

How to use it — step by step

1. Plain English: Start at the aggregator, wholereach.com, and open the full linked directory of the family at wholereach.com/#directory.
2. Pick the front door that fits your framing — the flagship for the full working app, an edition (Chapter 34) for a particular story, or a case file (Chapters 37–42) to see the engine proven on a real niche.
3. Whichever door you enter, run the audit on your own URL. Each site has its own address and its own sitemap, but the audit is the shared engine.
4. Under the hood: every front door calls the same backend — /analyze for the audit, /report/<domain> for the shareable report, /network and /portfolio for the multi-site views. They share the engine and the skills library, not a login; each site is self-canonical and independently indexed.

This manual documents the engine that all of them share. When later chapters say “the engine,” they mean the single backend behind every one of these doors.

The backend service

The engine’s brain is a single Python service. It is deliberately small and dependency-free — the standard library only — which is why it is easy to run, restart, and reason about.

A great deal of software is hard to trust because it is hard to understand: layers of frameworks, a database server, a queue, a cache, each with its own failure modes. The engine takes the opposite bet. One file, one language, no third-party web framework, one flat-file datastore. When something is small enough to hold in your head, you can be confident about what it does and — just as important — what it does not do. That confidence is not a nicety here; it is what lets the honesty guards (Chapter 10) and the reversibility guarantee (Chapter 9) be believed.

Where it runs, and how it stays safe

The service listens on the loopback address, so it is never exposed to the internet directly; a reverse proxy sits in front of it. It runs under systemd, so it starts on boot and restarts itself on failure. Two design choices do real work here: binding to loopback means the outside world can only reach the engine through the proxy the operator controls, and running under a supervisor means a crash is self-healing rather than an outage.

The one routing trick worth knowing

The request handler strips a leading /api/ from every path, so each route works both bare and under /api/. That means the exact same audit route is reachable two ways — a small convenience that matters in practice, because the network readiness audit (Chapter 44) hits automarketingengine.com/api/analyze while the onboarding form calls /analyze, and both land on the identical machinery. There is no separate “public” and “internal” engine.

Full route tables are in Appendix A; the routes that matter most are POST /analyze (run an audit), POST /ship and POST /rollback (publish and undo), POST /assist (the “ask your marketing team” chat), and GET /report/<domain> (a shareable branded report).

A request, end to end — illustrative

To make the service concrete, here is an illustrative trace of one audit request. A caller posts a URL to /analyze; the handler receives it on 127.0.0.1:8932 (reached through the reverse proxy), runs the pipeline of Chapter 5, and writes the result to /opt/autoengine/workspaces/<domain>.json — one file, that site’s entire record. A later GET /report/<domain> reads that same JSON file and renders the branded report. No database round-trips, no cache to invalidate: the file is the state.

How to use it — step by step

1. Plain English: You never touch the backend directly — you use the app views (Audit & Report, Approvals & Setup, and the rest), and each view calls one of these routes for you.
2. To confirm the service is up, the engine exposes /health; to see the full contract a machine reader would use, it exposes /openapi and /llms.txt about itself.
3. Under the hood (illustrative): an operator or agent can call the same public routes the app does — for example POST /analyze with a JSON body of the URL and intake — because the /api/ prefix is optional, /analyze and /api/analyze reach the same code.
4. Because the datastore is one JSON file per site under /opt/autoengine/workspaces/, the entire state of any audited site is inspectable, backup-friendly, and portable — the subject of Chapter 8.

Everything else in this manual — the pipeline, the scoring, the departments, the ship-and-rollback proof — runs inside this one small, restartable, loopback-bound service. Its smallness is the point: it is why the guarantees hold.

The audit pipeline, end to end

When a URL arrives at POST /analyze, it runs through a fixed pipeline. Understanding these steps is the key to understanding every department, because every department reads from the same single page-fetch.

This is the single most important structural fact about the engine, and it is why the numbers can be trusted: there is exactly one read of your live page, and every role — SEO, Answer-Engine, CRO, Analytics, Paid Media, Research, Content, Social — works from that one read. No role goes off and imagines its own version of your site. If the fetch fails, they all know, and they all say so (Chapter 10). If the fetch succeeds, they all draft from the same evidence.

Figure 5.1 — one fetch feeds everything. Every department downstream reads the same sig.

Step by step, from run_engine(url, intake)

1. Normalize & fetch. The URL is normalized and fetched, with an automatic http → https retry. The result sets reached = bool(page["ok"]) — the single flag that gates the honesty guards in Chapter 10.
2. Parse to signals. analyze_html() turns the raw HTML into a sig dictionary: title and its length, meta description, H1/H2 counts and text, word count, canonical, internal/external link counts, JSON-LD blocks and their schema types, CTA hits and buttons, forms and field counts, trust signals, images and alt-text, socials, and more.
3. Probe machine surfaces. The engine best-effort fetches /sitemap.xml, /robots.txt, /llms.txt, /AGENTS.md, /.well-known/ai-plugin.json, /index.md, an OpenAPI doc and an MCP card — the surfaces AI readers look for — plus real traffic via the site’s AWStats.
4. Score. score_site(sig, extra) returns the checks, the per-discipline sub-scores, and the overall (Chapter 6).
5. Detect niche & brand, then build priorities, the 30/60/90 roadmap, the content calendar, the social posts, and the six recommendation channels via seo_aiso(...).
6. Merge & store. Back in analyze_and_store, the result is merged into the site’s workspace — checklist, approvals, connections, deliverables, and a rolling 40-entry score history — and written to disk.

What the fetch actually reads — illustrative

To make “signals” concrete, here is an illustrative sig for a small coworking homepage — the kind of dictionary analyze_html() produces. Every downstream role reads from exactly this:

From this one read, several roles draw different conclusions at once, and none of them re-fetches the page: the SEO Manager sees a missing meta description and a good title length; the Answer-Engine sees no llms.txt, no AGENTS.md, and only an Organization block (no FAQPage); the Content Desk sees 612 words and flags the homepage as thin; the CRO role sees two CTAs and a five-field form; the Social Scheduler sees no linked profiles and scores Social honestly low. Same evidence, six readings.

What happens when the fetch fails

How to use it — step by step

1. Plain English: In the Audit & Report view, enter a URL and (optionally) your intake — goals, channels, audience, budget. Submit, and within seconds the scorecard and the role deliverables appear, all drawn from the one fetch.
2. Read the report top-down: the overall and the five disciplines first, then each role’s findings in its own view. Every number traces back to a signal in the sig.
3. To refresh, re-run the audit; the intake you gave is remembered and carried forward, so the roadmap stays personalized.
4. Under the hood: this whole chapter is run_engine(url, intake) behind POST /analyze — fetch() → analyze_html() → surface probes → score_site() → detect_niche() → seo_aiso() and the sibling builders → save_ws(). The same call runs on a schedule via /run-daily to keep scores current.

Once you internalize “one fetch feeds everything,” the rest of the manual reads easily: the scoring model (Chapter 6) grades the sig, the niche detector (Chapter 7) labels it, and every department chapter is just a different lens on the same read.

The scoring model

The 0–100 score is not a vibe. It is a weighted roll-up of concrete, pass/warn/fail checks read off the live page, with two deliberate rules that keep it honest: a first-audit ceiling, and a reality cap tied to measured traffic.

A score is only as good as the discipline behind it. Plenty of tools will hand you a confident-looking “92/100” that means nothing, because nothing under it is defined. The engine goes the other way: every point on the scale is earned by a named check with a state, a reason, a fix, and a weight. If you disagree with a number, you can trace it to the exact check that produced it — and to the exact fix that would move it.

Scoring lives in score_site(sig, extra). Each check is registered with an area, a human label, a pass/warn/fail state, the reason, the fix, and a weight. The checks roll up per discipline, and the disciplines roll up to the overall.

The six disciplines

Five are read from the page; the sixth, Reach, is measured from real traffic and is never fabricated.

Note what the weights say about the engine’s bet: SEO, AI Search, and Reach all carry the top weight of 1.15. Being readable by AI answer engines is scored as heavily as being readable by search crawlers, and being actually reached by people is weighted just as high — because a flawless page nobody visits is not a marketing success.

The two rules that keep the number honest

The headroom cap is a design choice, not a bug: a site the engine has just met should never read 100/100, because there is always something to improve and a perfect score on day one would be a lie of exactly the kind the engine exists to avoid. The reality cap ties the headline number to whether anyone actually visits — a technically flawless page that no one reaches cannot post a top overall score.

A worked score — illustrative

To see the roll-up in action, here is an illustrative scorecard for a small site on its first audit. Read it as: each discipline is clamp(100 × earned / possible), then the headroom cap holds each at ≤90, then the overall is the weighted average.

Notice three honest signatures in that single card. Content and Technical sit at exactly 90, not higher — the headroom cap in action on a first audit. Social sits at 33 because the site links no verifiable profiles, and the engine refuses to inflate it with a fabricated sameAs (Chapter 10). And AI Search at 75 is the discipline with the most obvious upside — publish llms.txt and AGENTS.md, add FAQ schema, write a lead answer, and it climbs. The scorecard doubles as a to-do list ranked by impact.

How the reality cap bites — illustrative

Suppose the page above earns strong sub-scores but AWStats shows very light traffic, putting measured Reach at, say, 20. The reality cap sets a ceiling of clamp(50 + 20/2) = 60 on the overall — so no matter how clean the page is, the headline number cannot exceed 60 until real people arrive. That is the engine refusing to let a technically perfect ghost town post a top score.

How to use it — step by step

1. Plain English: In the Audit & Report view, read the overall and the five discipline meters. Then scroll the checks table — every check shows its state (pass/warn/fail), the reason, and the exact fix.
2. Sort by impact: the lowest disciplines with the heaviest weights (SEO and AI Search at 1.15) are where a fix moves the overall most. Work those first.
3. Approve the fixes you want in Approvals & Setup, ship them, and re-audit — the score history records the before-and-after.
4. Under the hood: the number is produced by score_site(sig, extra) inside the pipeline of Chapter 5, surfaced on /analyze and refreshed by /run-daily. Each re-run appends to the rolling score history in the workspace, which is what turns “we improved it” into a dated, provable jump (Part VII).

Everything downstream in this manual depends on these numbers being real. The scoring model is where that starts: defined checks, published weights, and two caps that would rather show you an honest 63 than a flattering, meaningless 100.

The niche detector

Before it drafts anything, the engine works out what kind of business it is looking at, because a coffee shop and a magnetics manufacturer need different advice. It does this from the page's own words, not from a guess.

detect_niche(sig, dom) scores each of sixteen niches by counting whole-word keyword matches across the page's title, H1s, H2s and meta description. Highest score wins; ties go to the earlier (higher-priority) niche.

The reason this step exists is downstream, not here. Every department reads the detected niche before it drafts: the Content Desk builds a publishing calendar tuned to what a business of that kind should publish, the Paid Media role writes keyword themes a real buyer in that vertical would search, and the prompt library reaches for the matching industry pack (Chapter 30). Get the niche wrong and every one of those outputs is subtly generic. Get it right and the whole department speaks the customer's language from the first draft.

How the match actually works

The mechanic is deliberately simple, and simple is why it is trustworthy. Each niche owns a set of distinctive keywords. The engine scans the page's own title, H1s, H2s and meta description — the highest-signal text on the page — and counts whole-word matches. Whole-word matching is the detail that stops false positives: a page about "magnetic personality" in a coaching business will not trip the magnetics niche on a stray substring, because the counter is looking for real keyword tokens, not fragments. The niche with the most hits wins; on a tie, the earlier (higher-priority) niche takes it.

Two refinements matter. First, an own-domain shortcut: the family's own sites (deptmatic.com and its subdomains, automarketingengine.com, and the rest) return automated marketing directly. Second, a fallback: if nothing matches and the page is a genuine 200-class response, the engine names the niche from the first salient noun in the title rather than pretending to certainty.

That fallback is itself an honesty guard in miniature. A page the sixteen niches don't cover does not get force-fit into the nearest one — the engine takes the first meaningful noun from the title and names the niche after it, so the label reflects what the page actually said rather than a category the engine wished it belonged to. It is the same instinct as Chapter 10: when certainty isn't there, say what you know and no more.

A worked example — why order rescues the magnets case

Consider a real hazard the priority list is built to prevent (illustrative walk-through of the verified fix). A magnetics manufacturer's homepage naturally talks about marketing its products, its market, its campaigns — so both the magnetics niche and the marketing niche pick up hits. Because magnetics / magnets sits at priority 2 with ten magnet-specific keywords, while marketing / advertising sits at priority 7, the magnet keywords win on count, and even a dead tie would resolve to magnetics by priority. The company classifies as what it makes, not as what its copy happens to mention.

How to use it — step by step

1. In the app: run a free audit from the front door of automarketingengine.com. The niche is detected as part of that single run — you don't invoke it separately.
2. Read the label on the report. Open the Audit & Report view; the detected niche frames the whole scorecard and every department's drafts below it. If it reads "coffee shop" for your café, detection did its job.
3. Sanity-check it against your page. Look at your own title, H1 and H2s — the exact text the detector reads. If the niche is off, the fix is almost always that your highest-signal headings don't say what you do; strengthen them and re-audit.
4. Under the hood (technical): the audit endpoint POST /analyze runs the pipeline of Chapter 5; inside it, detect_niche(sig, dom) scores the sixteen niches against sig and returns the winning label, which is stored in the workspace and read by seo_aiso() and the other role builders.
5. Verify it directly (agent/engineer): curl -s -X POST https://automarketingengine.com/api/analyze -H 'Content-Type: application/json' -d '{"url":"https://multipolemag.com"}' | jq .niche — it classifies from the page's own words, not the domain.
6. To extend it (administrator): add a (label, keywords) tuple to the niche list in priority order, placing a specific niche ahead of a general one and giving it enough distinctive keywords to score reliably (Chapter 49).

The workspace datastore

There is no database server. Each site the engine has audited is a single JSON file, which makes the whole datastore inspectable, backup-friendly, and portable.

A workspace at /opt/autoengine/workspaces/<domain>.json holds everything the engine knows about that site: the latest scores, the full checks, the role recommendations, the priorities and roadmap, the content calendar and social drafts, the deliverables with their approval status, the account connections, and a rolling score_history of up to forty entries. That history is what turns a claim into proof — because a fix that shipped shows up as a dated jump in the numbers (Chapter 43).

Why one file per site is a feature, not a shortcut

The decision to skip a database server is the same instinct that keeps the backend to the Python standard library (Chapter 4): fewer moving parts, nothing to administer, nothing that can drift out of sync with the code. Because a workspace is plain JSON on disk, you can read it with cat, diff two versions in git, copy one site's state to another host with scp, or back the whole datastore up by copying a folder. There is no migration, no schema server, no connection pool to fall over. The datastore is the filesystem — 273 real workspaces on disk at the time of writing (Chapter 43), each a complete, self-contained record of one site.

What a deliverable looks like on disk

Each deliverable carries its own lifecycle fields — for a shipped one, a shipped_at timestamp, the ship_target file it wrote, and the ship_backup snapshot it can be restored from. That structure is what makes the next chapter possible.

The example below is drawn from the verified evidence in Chapter 43 — the AISO refresh that shipped FAQ schema to a live magnetics guide — shown in the shape a workspace stores it:

Notice how the fields interlock: status says it went live, shipped_at stamps when, and ship_backup names the exact snapshot that reverses it. A deliverable is never a loose promise — it is a record with a return path built in.

The score history is the proof, not a log

The most important field for anyone judging the engine is score_history. It is a rolling list, capped at forty entries, of dated overall scores. When a fix ships and the number moves, that movement is recorded automatically — so a claim like "the AI-Search fix lifted the site" is not asserted, it is read off the datastore. Here is the real, verbatim climb from the same site (Chapter 43), as stored:

How to use it — step by step

1. In the app: you rarely touch the file directly. Running an audit writes the workspace; the Audit & Report, Content, Conversion and Approvals & Setup views all read from it, and the Manager and Board views summarize it.
2. Read a site's stored state (technical): GET /workspace returns a single site's workspace as JSON; GET /workspaces lists every site the engine has audited. These are the same records the app views render.
3. Inspect it by hand (administrator): the file is plain JSON on the host — open /opt/autoengine/workspaces/<domain>.json and read the scores, deliverables and score_history directly. Nothing is hidden in a database.
4. Back it up: copy the workspaces/ folder. Because each site is one self-contained file, a backup is a file copy and a restore is a file copy back — no dump, no import.
5. Trace a shipped change: find the deliverable's ship_backup path, and you have the exact snapshot Chapter 9's rollback will restore. The datastore and the ship-backups directory are two halves of the same reversibility guarantee.

Ship & rollback

Shipping is the moment an approved draft becomes a live change. The engine treats it as reversible by construction: it never writes to a live file without first taking a snapshot it can put back.

The mechanism is two functions, ship_deliverable() and rollback_deliverable(), exposed at POST /ship and POST /rollback. Ship copies the current live file into a timestamped backup, then writes the approved change. Rollback copies the snapshot back. It is whitelisted to the operator's own test beds; a client store goes through the platform's own API on the same approve-first, reversible terms.

The order of operations is the safety

What makes shipping safe is not caution added on top — it is the sequence itself. The snapshot is taken before the write, so there is never a window in which the live file has been changed but no backup exists. Read the two functions as a matched pair:

1. Ship — copy the current live file to a timestamped .bak, then write the approved change over the original.
2. Rollback — copy that same .bak back over the live file, restoring the exact bytes that were there before.

Because the backup is a byte-for-byte copy taken at the instant before the change, rollback is not a "best effort undo" — it is a restore of the precise prior state. That is what "reversible by construction" means: reversibility isn't a promise about the future, it's a file already sitting on disk the moment the change goes live.

Why the whitelist exists

Direct writes to a live file are limited to the operator's own test beds — the four domains above. This is a guardrail, not a limitation of the mechanism: the engine will not overwrite a file on a site it doesn't own. For a client store, the same approve-first, reversible discipline is honored through the platform's own API rather than a direct file write, so the safety model travels but the write path respects whose property it is. The whitelist is the code enforcing that distinction, so a misdirected ship simply cannot touch a stranger's site.

A worked ship-and-rollback

This is not a described capability — it has run. The clearest evidence (Chapter 43) is a real ship followed by a rollback on a live site, logged two seconds apart:

Read the two-second gap literally: the engine changed a live page and put it back, and both the change and its reversal are in the timestamped record. A ship and its rollback that close together, on a real site, is the whole safety model working under real conditions.

How to use it — step by step

1. Approve first. A deliverable can only ship after it is approved in the Approvals & Setup view (Chapter 25). Draft → approve is the prerequisite; there is no ship on an un-approved item.
2. Ship it (in the app): on an approved, shippable deliverable, choose to ship. On a whitelisted test bed this writes the change to the live file after snapshotting it.
3. Verify the change is live, then, if anything looks wrong, roll back with one action — the live site returns to the snapshot state.
4. Under the hood (technical): shipping calls ship_deliverable() via POST /ship (snapshot with shutil.copy2 to ship-backups/<domain>/, then write); reversing calls rollback_deliverable() via POST /rollback (copy the snapshot back).
5. Confirm reversibility physically (administrator): ls /opt/autoengine/ship-backups/*/ | wc -l — real, timestamped .bak snapshots exist for every ship (56 folders / 83 files at the time of writing). Every ship has a matching file that reverses it.

The honesty guards

The engine's most important feature is the work it refuses to do. Three guards in the code stop it from inventing findings — the failure mode that makes most "AI marketing" untrustworthy.

Every other chapter in this manual leans on these three guards. The scores are worth reading because they can't be padded; the case files are worth believing because their weak numbers weren't hidden; the department's drafts are worth approving because they came from your real page. Take the guards away and none of that holds. So they come first, in the architecture and in this manual.

Guard 1 — no page, no findings

The four page-specific roles (CRO, Analytics, Paid Media, Market Research) only run when the fetch succeeded. When reached is false, each returns the same honest note instead of a fabricated result:

The gate is a single boolean. Chapter 5's fetch sets reached = bool(page["ok"]), and that one flag decides whether the page-specific roles produce or abstain. There is no partial mode where the engine "fills in what it can" from the domain name or a cached guess — either it read your live page this run, or it says it didn't and produces nothing. That is why an audit of a made-up subdomain that returns nothing yields the note above and an empty finding set, not a plausible-looking report.

Guard 2 — unmeasured Reach stays unmeasured

If there is no traffic data for a site, Reach is recorded as a "warn" with no score. The engine does not fill the gap with a zero or an average — an unmeasured number is shown as unmeasured.

This is a sharper commitment than it first looks. A zero would be a lie in the pessimistic direction (it implies "no one visits" when the truth is "we don't know"), and an average would be a lie in the flattering direction. Both would corrupt the overall, because Reach carries a discipline weight of 1.15 and drives the reality cap (Chapter 6). By recording a warn instead, the engine keeps the gap visible: you can see exactly where a measurement is missing, and the headline number isn't propped up by a guess. When AWStats data does arrive, Reach becomes a real, computed value — and only then.

Guard 3 — no fake social proof

When a site has no social profiles, the Social discipline scores low and stays low. The engine will not inject a fabricated sameAs to inflate the number. Every case-study site in Part VII carries a real, low Social score for exactly this reason — and the case files say so out loud.

The temptation here is real and specific: adding a sameAs array to a page's JSON-LD would nudge the Social sub-score up in seconds, and no visitor would notice. The engine refuses because a Social score you can trust is worth more than a high one you can't. The proof is in the case files: every homebuilding site in Chapter 41 carries a Social score of 17, and the two magnetics guides in Chapter 42 read 33 and 17 — genuinely low, genuinely unfaked, and stated plainly rather than buried.

How to use it — step by step (how to verify the guards yourself)

1. Test Guard 1 in the app: in the Audit & Report view, audit a made-up subdomain that returns nothing. The engine should say it couldn't read the page and produce no invented findings.
2. Test Guard 1 technically: curl -s .../api/analyze -d '{"url":"https://no-such-host.invalid"}' | jq '.reached, .recommendations.cro' → expect reached=false, and cro/analytics/paid/research each returning the honest note.
3. Test Guard 2: audit a site with no traffic data and read the Reach line — it should show as a warn, unmeasured, never a zero or an average.
4. Test Guard 3: audit a site with no social profiles and check the page's JSON-LD — no fabricated sameAs appears, and the Social sub-score stays honestly low.
5. Under the hood: the fabrication note is returned from seo_aiso() behind the reached flag; the page-specific role builders (cro_recos(), analytics_recos(), paid_recos(), research_recos()) inherit that guard and abstain when the page wasn't reached.

The department model — 47 functions, 14 departments, 6 named roles

Since the engine ingested the marketing-skills library, its function surface is large: 47 distinct marketing functions (Part V). Those functions don't sprawl — they're organized into 14 operating departments, which this Part documents in full, and presented publicly as a memorable 6 named roles. Read the number that answers your question; they nest, they don't contradict.

The three numbers confuse people until they see that they are three views of one thing, at three altitudes. 47 is the capability count — everything the engine can do. 14 is the operating count — how those capabilities are grouped into departments that actually run. 6 is the pitch count — the roster a business can hold in its head. None of them is spin; each answers a different honest question. "What can it do?" is 47. "How is that organized?" is 14. "What do I tell my team it is?" is 6.

The 14 departments, and which carry what

The 14 departments are the chapters that follow (12–25). Each carries one or more of the 47 skills; the table below shows the shape of that mapping so the rest of this Part reads clearly. The "how it runs today" column is the honest part — six departments read your page live, the rest deliver through their full playbook plus ready-to-paste prompts (the complete, skill-by-skill matrix is Chapter 31).

Why six analyzers are "live" and the rest aren't — yet

"Live analyzer" is a precise claim: for that skill, the engine computes page-specific findings from your real site through one of the six backend channels (seo, aiso, cro, analytics, paid, research). "Playbook + prompts" is an equally precise claim: the engine delivers the skill's full framework plus ready-to-paste prompts through the responsible department, but it isn't reading your page for that particular skill this run. The roadmap (Chapter 48) is to promote skills from playbook to live analyzer one at a time — the same path four critical roles already walked.

The color-coding in the app makes the live/coming/future split visible: blue role cards are live today, red are critical roles coming online, black are future. The four roles the partner deck flagged as critical — CRO, Analytics, Paid Media, Market Research — have all been promoted from red to live.

How to use it — step by step

1. Pick the altitude that answers your question. Selling it internally? Use the 6 named roles. Planning what to turn on? Use the 14 departments. Auditing exactly what runs on your page today? Use the 6 live analyzers.
2. See the departments in the app: the roster lives across the phase views — Audit & Report (the Auditor), SEO & AI Search, Content, Conversion, Outbound, and the strategic Manager and Board views. The color of each role card tells you live (blue), coming (red), or future (black).
3. Check the exact delivery mode for any of the 47 skills in the coverage matrix (Chapter 31) — it names the department and whether the skill is a live analyzer, a generator, or playbook + prompts, with nothing left out.
4. Under the hood (technical): the six live channels are the analyzer functions — seo_aiso() (SEO + AEO share one page-read), cro_recos(), paid_recos(), analytics_recos(), research_recos() — plus the generators (content_calendar(), make_content_brief(), make_social_drafts(), the roadmap). Query the live roster with GET /roster.
5. Promote a skill (administrator): the path from red to blue is to write a <role>_recos(d, niche) builder that reads real fields, wire it into seo_aiso() behind the reached guard, and add its view to the app (Chapter 49).

The Auditor

The Auditor runs first and re-runs on a schedule. It is the role that reads your site like an AI reader would and turns it into the 0–100 scorecard everything else works from.

Reads: the full page-fetch and machine-surface probe from Chapter 5 — title, meta, headings, links, schema, CTAs, forms, trust signals, and the AI-reader surfaces (llms.txt, AGENTS.md, sitemap, robots).

Produces: the five discipline sub-scores plus measured Reach, the overall, and a ranked list of the highest-impact fixes with the concrete change for each. In the app this is the Audit & Report view — every real signal in a sortable table — and the shareable branded report at /report/<domain>.

Discipline: the Auditor is where the honesty guards bite first. If it could not read the page, it says so and the downstream roles produce nothing. Its report carries the line, verbatim: "Every number on this page comes from a real fetch — nothing is invented."

Why the Auditor comes first

Every other role in this manual reads the Auditor's output. There is exactly one page-fetch per run (Chapter 5, Figure 5.1), and the Auditor is the role that performs it and turns the raw HTML into the sig dictionary the whole department shares. If the Auditor cannot reach your page, the SEO Manager, the Answer-Engine Analyst, the Content Desk and the rest have nothing real to work from — so they produce nothing, by design. That is not a limitation; it is the feature that lets you trust the numbers. A tool that always returns a confident scorecard, even for a URL it never read, is worse than useless.

Under the hood the Auditor is the pipeline behind POST /analyze: fetch() (with the automatic http → https retry), then analyze_html() to build sig, then the machine-surface probe, then score_site(sig, extra) to roll the checks up into the five disciplines plus Reach. The reached flag it sets is the single switch that arms or disarms the honesty guards in Chapter 10.

What a real scorecard looks like

The following is an illustrative reading in the shape the Auditor actually returns — the audited magnetics guide from Chapter 42, presented the way the Audit & Report view shows it. The overall is the weighted roll-up of the five disciplines; Reach here is measured from AWStats.

Read it the way the Auditor intends: the weak numbers are the work. SEO at 43 and Social at 17 are where the ranked fix list will point first; Technical at 90 is already at the first-audit ceiling (Chapter 6), so it will not appear as a priority.

The signals behind the number

The score is never a vibe — it is a roll-up of concrete page facts. This is the exact-facts panel the branded report prints, drawn from the Chapter 42 reading (illustrative, but in the real shape):

The ranked fix list

The Auditor doesn't just score — it ranks the highest-impact fixes and hands each to the responsible role with the concrete change attached. An illustrative top-of-list for the reading above:

When the page can't be read

Point the Auditor at a URL that returns nothing — a made-up subdomain, a site that is down — and it does the honest thing. It sets reached=false, refuses to score, and every downstream role inherits the fabrication guard from Chapter 10 rather than inventing a plausible result.

How to use it — step by step

1. Plain English: open automarketingengine.com and run the free audit — one URL, no signup. Within a few seconds the Audit & Report view shows the 0–100 overall, the five discipline meters, measured Reach, and the ranked fix list.
2. Read it against reality: pick three findings and check them by hand — view the page's title length, count its H1s, look for a sitemap. They should match the page, not a generic template (this is Track A, step A2 of the test protocol in Chapter 45).
3. Re-run the same URL to confirm the scores are stable — the Auditor is deterministic, not random.
4. Share it: open the branded report at /report/<domain> (e.g. deptmatic.com/api/report/multipolemag.com) — the exact-facts panel and the "nothing is invented" disclaimer render for anyone you send it to.
5. Under the hood: the audit is a real API — POST /analyze with {"url":"…"} runs fetch() → analyze_html() → the surface probe → score_site(), and the shareable report is rendered by render_report_html() at /report/<domain>. The result is merged into the site's workspace JSON with a rolling 40-entry score_history, so each re-audit is a dated before-and-after.

The SEO Manager

The unglamorous work that decides whether you are found: structure, schema, internal links, sitemaps. The SEO Manager is a real backend channel, built inside seo_aiso().

Reads: the SEO signals from sig and the SEO sub-score.

Produces: four to five ranked SEO recommendations — the first gated on the SEO sub-score being under 80, so a site already strong on SEO isn't handed busywork. Typical items: title and meta rewrites to the right lengths, a single clean H1 with matching keywords, sitemap depth and Search-Console verification, breadcrumb schema, and internal-link structure.

In the app: the SEO & AI Search view. Because SEO and answer-engine optimization share a page-read, they are drafted together and presented side by side.

What the SEO Manager is for

Every other role can do its job perfectly and still not matter if the page can't be found. The SEO Manager owns the discovery layer — the title and meta that decide your click-through from a results page, the single clean H1 that tells a crawler what the page is about, the sitemap that lets it find your other pages, the breadcrumb schema that earns a richer result, and the internal links that pass authority around your own site. None of it is glamorous. All of it is load-bearing.

It is a genuine live analyzer, not a playbook: it computes page-specific findings from your real sig every run. SEO carries a discipline weight of 1.15 — tied with AI Search for the highest of the five — because being found is the precondition for everything else the department does.

The gate: no busywork for a strong site

The SEO Manager's first move is to check whether you actually need SEO work. Recommendations are gated on the SEO sub-score: when it is at or above 80, the channel holds the routine title/meta/structure recos rather than inventing make-work for a site that is already doing this well. This is the same candor that runs through the whole engine — it would rather say "you're strong here" than pad a report. Two illustrative readouts of the gate in each state:

Example 1 — a title & meta rewrite, before → after

The single most common SEO finding. The Auditor read a 79-character title (Chapter 42) — long enough that a results page truncates it mid-phrase, and the meta description was missing entirely. The SEO Manager rewrites both to the target lengths (title 40–60 chars, meta 130–160 chars) while keeping the real keywords. Illustrative, in the engine's before/after shape:

Why it moves the number: the title now fits the results slot without truncation and leads with the searched phrase; the meta went from a blank the search engine fills with a random sentence to a written 156-character pitch that earns the click. Both checks flip from fail to pass in score_site(), lifting the SEO sub-score directly.

Example 2 — an H1 fix

The SEO discipline checks for exactly one H1, aligned with the title. A page with a vague or duplicate H1 gets a concrete rewrite. Illustrative:

The fix is deliberately boring: one H1, keyword-matched to the title, so a crawler and an AI reader agree on what the page is about. Where a page has two H1s, the recommendation is to demote the second to an H2 — the check wants exactly one.

Example 3 — an internal-link & sitemap recommendation

SEO scores sitemap depth (threshold ≥50 URLs) and reads the internal-link count. The reading in Chapter 42 showed 35 sitemap URLs and 38 internal links — under the depth bar, and light on cross-linking for a guide. A sample recommendation as the channel emits it (illustrative):

This is where the SEO Manager overlaps the site-architecture and programmatic-seo skills (Chapter 31): once you have a repeatable page type — one page per pattern, per application — the sitemap deepens and the internal-link graph fills in as a byproduct.

Example 4 — a HELD deliverable

Nothing the SEO Manager writes goes live on its own. The title/meta rewrite from Example 1 lands in the Approval Queue (Chapter 25) as a deliverable with a status — you approve, edit, or reject before it can ship. Illustrative:

A worked example — the score moving

SEO fixes are exactly the kind that show up in the timestamped score_history. On the magnetics guide, shipping a title-tag rewrite and later the schema/FAQ work carried the audited overall from 54 to 64 over three days (Chapter 43) — real deltas, not a projection. An SEO-only illustrative before/after on that page:

How to use it — step by step

1. Run the audit first. In the app, open the Audit & Report view and audit your URL (or use the free audit on the front door). This is the single page-read the SEO Manager works from.
2. Open the SEO & AI Search view. SEO and answer-engine optimization share the page-read, so they are drafted together and shown side by side. The left side is the SEO Manager's ranked recommendations; the right is the Answer-Engine Analyst (Chapter 14).
3. Read the gate. If your SEO sub-score is under 80, you'll see the four-to-five ranked recos (title/meta, H1, sitemap + Search Console, breadcrumb schema, internal links). If it's 80 or above, the routine recos are withheld on purpose — SEO isn't your bottleneck.
4. Review each recommendation — every one shows the finding, the concrete change, and why it moves the number. Edit any before approving; the "correct it" path lets you point it right in one line.
5. Approve, then ship. Approved recos become deliverables in the Approvals & Setup view (Chapter 25). Shipping snapshots the live file first and is one-click reversible (Chapter 9).
6. Re-audit and share. Re-run the URL to see the SEO sub-score move in score_history, and open the branded report at /report/<domain> to show the before/after to anyone.
7. Under the hood: the SEO Manager is the seo channel inside seo_aiso(), which reads the SEO fields of sig and the SEO sub-score from score_site(), applies the ≥80 gate, and returns the ranked recos. It runs on demand via POST /analyze and on the schedule via POST /run-daily (one site or the whole network); the shareable output renders at GET /report/<domain>.

The Answer-Engine Analyst (AEO)

The role that decides whether ChatGPT, Claude and the other AI readers can find, quote and cite you. This is the engine's sharpest edge — the "Agents First" discipline that most marketing tools don't pair with a full department.

Reads: the machine-surface probe results — whether /llms.txt and /AGENTS.md exist, the JSON-LD blocks and their schema types, FAQ markup, and whether the page opens with a crisp lead answer.

Produces: four recommendations — publish /llms.txt and /AGENTS.md, add JSON-LD (Organization, FAQPage, and the types that fit the niche), add FAQ markup, and write a 40–60 word lead answer an AI reader can lift verbatim. This is precisely the fix shipped across the homebuilding case study in Chapter 41.

The shift this role is built for

For twenty years the question was "can Google's crawler read this page?" The Answer-Engine Analyst answers the new one: "when someone asks an AI assistant about my category, does it find, quote and cite me?" AI readers behave differently from crawlers — they look for declared machine surfaces (/llms.txt, /AGENTS.md), they trust structured data (JSON-LD), and they lift a clean, self-contained answer far more readily than they parse a wall of prose. The AEO role scores exactly those signals and drafts exactly those fixes.

It shares its page-read with the SEO Manager — both live inside seo_aiso() — which is why the app shows them side by side in one view. But its checks are its own, and AI Search is weighted 1.15, tied for the top, because the whole network is a bet that agent-readability now matters as much as crawler-readability.

What the AEO probe reads

The machine-surface probe (Chapter 5) is the AEO role's raw material. An illustrative reading for a page that has done none of the work yet:

Example — a lead answer, before → after

The single highest-leverage AEO fix is a 40–60 word lead answer an AI reader can lift verbatim. Before, the page opens with a slogan that answers nothing; after, it opens with a crisp, quotable definition. Illustrative, for a homebuilding-media site:

The "after" is the sentence an assistant will quote when someone asks what the site is — factual, self-contained, and lifted straight from the page. That is the whole point of AEO: give the answer engine a clean answer to cite.

Example — the FAQPage schema fix (the case-study move)

The AEO role's signature deliverable is FAQPage JSON-LD — the exact fix shipped across all six homebuilding sites in Chapter 41. It turns questions already on your page into structured data an answer engine can quote directly. Illustrative shape of the deliverable:

The proof: six sites, measured lift

This is not a described capability — it shipped and was re-audited. The homebuilding case (Chapter 41) applied the same FAQ-schema fix to six live sites and re-scored each. The AI-Search movement, verbatim from the case file:

Read the pattern, not just the numbers: the same fix, applied by the same role, moved AI-Search on every site — because FAQ-schema is exactly what an answer engine needs to quote a page. It was verified by re-audit, so this is measured lift.

How to use it — step by step

1. Audit first, then open the SEO & AI Search view. The Answer-Engine Analyst's recommendations sit on the AEO side of that shared view, next to the SEO Manager's.
2. Read the four recos: publish /llms.txt and /AGENTS.md; add the JSON-LD types that fit your niche (Organization, FAQPage, and more); add FAQ markup; and write the 40–60 word lead answer.
3. Check the answers are yours. The FAQ Q&A and lead answer are drawn from your page — read them and correct any in one line before approving.
4. Approve and ship. The FAQ-schema deliverable goes to the Approvals & Setup view; shipping snapshots the file first and is one-click reversible (Chapter 9).
5. Re-audit to confirm the lift — the AI-Search sub-score rises when schema, llms.txt and the lead answer land, and the move is recorded in score_history.
6. Under the hood: the AEO role is the aiso channel inside seo_aiso(), reading the machine-surface probe from the /analyze pipeline. It runs on demand via POST /analyze and on schedule via POST /run-daily; the branded report at /report/<domain> prints the AI-reader surfaces it found. AI Search is weighted 1.15 in score_site().

The Content Desk

Drafts the pages and posts your customers actually search for — from your real facts, never invented ones. The Content Desk is where niche detection pays off, because the calendar it builds is tuned to what your kind of business should publish.

Reads: the detected niche, the page's word count and heading structure, and the positioning themes in the H2s.

Produces: a publishing calendar tuned to the niche, content briefs for the pages worth writing, and the raw drafts. In the app this is the Content view: calendar plus briefs plus social drafts in one place.

Discipline: the Content Desk drafts from your real facts. It will flag a thin page (under 800 words on the homepage) as a Content weakness rather than paper over it, and it never fabricates claims about your business — the "correct the brief" step lets you point it right in one line and have it redo the work.

Why niche detection is the Content Desk's engine

A coffee shop and a magnetics manufacturer need different content, so the Content Desk starts from what the engine already worked out: the detected niche (Chapter 7). The engine classifies among sixteen niches from the page's own words — title, H1s, H2s, meta — and the Content Desk uses that label to tune the calendar it builds. This is why the output feels written for your business, not pulled from a generic template: the topics are the ones your kind of customer actually searches for.

Under the hood it is a Generator, not a live analyzer (Chapter 31): content_calendar() builds the schedule, make_content_brief() builds the per-page briefs, and the drafts follow. All three read the same sig the Auditor produced — the niche, the word count, the heading structure — so the calendar is grounded in the real page.

Example — a niche-tuned calendar

Illustrative, for a site the niche detector classified as coffee shop. The Content Desk builds a publishing cadence tuned to what a coffee shop should be publishing, not a one-size-fits-all blog plan:

Example — a content brief the Desk emits

Each calendar slot gets a brief a writer (or the engine) can execute against. Illustrative shape from make_content_brief():

Example — the thin-page flag, and correcting a brief

The Content Desk will not paper over a weak page. If the homepage is under 800 words, that surfaces as a Content weakness, not a silent pass. And if a brief gets a fact wrong about your business, the "correct the brief" step lets you fix it in one line and have the Desk redo the work. Illustrative:

Example — a HELD draft

Like everything else, a draft lands in the queue with a status — nothing publishes on its own. Illustrative:

How to use it — step by step

1. Audit first so the niche is detected and the word count and headings are read. The Content Desk works from that same page-read.
2. Open the Content view — the calendar, the briefs, and the social drafts are all in one place.
3. Scan the calendar — confirm the topics fit your business; the cadence is tuned to your detected niche.
4. Open a brief, read the draft. If a fact is off or an angle doesn't apply, use "correct the brief" — one line, and the Desk redoes the affected work.
5. Approve the drafts you want. They land in the Approvals & Setup view; approved content can be handed to the Social Scheduler (Chapter 16) for repurposing.
6. Under the hood: the calendar is content_calendar(), the briefs are make_content_brief(), and it runs on schedule via POST /run-daily. The niche comes from detect_niche(); the thin-page flag comes from the Content checks in score_site() (homepage ≥800 words).

The Social Scheduler

Turns what you publish into a steady, honest presence — drafted ahead, approved by you. The Social Scheduler is also where the third honesty guard lives.

Reads: the page's linked social profiles and the content the Content Desk produced.

Produces: social drafts derived from your real content, scheduled ahead for approval. Nothing posts without a yes.

What the Social Scheduler is for

A steady social presence is repetition — the exact kind of work software should carry while a person keeps the judgment. The Social Scheduler reads what the Content Desk produced and turns each piece into platform-ready drafts, scheduled ahead, all waiting in the queue for your yes. It doesn't invent a voice or a claim; it repurposes your real content into the shape each platform rewards.

It is a Generator (Chapter 31): social_posts() / make_social_drafts() build the drafts from the content the Content Desk emitted. It also reads the Social discipline signal — the page's linked, verifiable profiles — which is where the engine's third honesty guard bites.

Example — one article, several drafts

Illustrative: the Content Desk's "How we roast" piece (Chapter 15) becomes a set of platform-tuned drafts, each derived from the real article, scheduled across a week:

Example — a HELD, scheduled draft

Each draft carries a proposed time and a status. Nothing posts on its own — the schedule is a proposal you approve. Illustrative:

The third honesty guard — no fake social proof

When a site has no linked social profiles, the Social discipline scores low and stays low. The engine will not inject a fabricated sameAs link to inflate the number. This is Guard 3 from Chapter 10, and it is why every case-study site in Part VII carries a real, low Social score — and says so out loud. Illustrative reading:

How to use it — step by step

1. Run the Content Desk first (Chapter 15) — the Social Scheduler repurposes the content it produced.
2. Open the Content view, where the social drafts sit alongside the calendar and briefs. Each draft shows its platform and proposed time.
3. Review and edit each draft; the copy is derived from your real content, so check it says what you'd say.
4. Approve the schedule. Approved drafts land in the Approvals & Setup view; publishing can be set per role, but nothing posts without a yes.
5. If your Social score is low, take it as an honest signal: create and link real profiles, then re-audit — the engine won't fake it for you.
6. Under the hood: the drafts are make_social_drafts() / social_posts(), run on schedule via POST /run-daily. The Social sub-score comes from score_site() reading linked, verifiable profiles; Guard 3 (Chapter 10) blocks any fabricated sameAs.

The Email Writer

Builds the list and drafts the sends. Every email is drafted for approval — and, uniquely, outbound email is the one thing the engine will never send on its own, even after approval settings are configured elsewhere.

Produces: list-building recommendations and drafted sends, all held in the approval queue.

Two jobs: build the list, draft the sends

The Email Writer owns lifecycle email — the drip sequences, the welcome flow, the win-back — and the list-building that feeds them. It also carries the SMS and churn-prevention skills in its department (Chapter 31). Everything it produces is a draft in the queue. What makes this role different from every other in the manual is a single, non-negotiable rule: outbound email is never sent automatically, even after you've configured auto-publish elsewhere.

It works from the same page-read as the rest of the department — the CTAs and forms tell it what a signup even is, and the Content Desk's material gives it something to say. Its deliverables run through the schedule via POST /run-daily like the other roles, but they stop at the approval gate and never cross it unattended.

Example — a list-building recommendation

The Email Writer reads what the page offers a visitor and recommends how to turn traffic into a list. Illustrative:

Example — a drafted welcome sequence

Illustrative shape of a drafted send, held for approval. The subject and body are written from your real facts; nothing about your business is invented:

Example — a HELD send, and why it can't auto-fire

The deliverable's status makes the hard line concrete. Even with role-level auto-publish switched on for other work, an email send carries a flag that keeps it manual:

How to use it — step by step

1. Audit first so the engine can read your forms and CTAs — that's how it knows what a signup is and what to build toward.
2. Review the list-building recos in the department output — email capture, lead magnet, then the sequence.
3. Read every drafted send in the Approvals & Setup view. Edit the subject and body freely; the copy is drawn from your real facts.
4. Approve — then send by hand. Approval makes a send eligible; the actual send is always a separate, explicit human action. There is no "set outbound email to automatic."
5. Under the hood: the Email Writer's drafts run through the daily production (POST /run-daily) and land in the approval queue like every deliverable, but the outbound-email path has no auto-send — the human gate on sending is absolute (see also Chapter 47).

Conversion Rate Optimization

The role that reads your live page for the things that turn a visitor into a customer — or fail to. cro_recos(d, niche) is a real analyzer, up to eight recommendations, all computed from the page.

Reads: CTA hits and buttons, forms and their field counts, trust signals, the H1 and headline, whether a phone number or mailto is present, and the viewport.

Produces: up to eight conversion recommendations — diagnostics on how many CTAs exist and whether they're clear, whether forms are too long, whether trust signals are present, and whether the headline states the value in the first five seconds.

In the app: the Conversion view, which runs realRole against the fetched page and falls back to a generic playbook only when there's no workspace loaded.

Why conversion is where the money is

Every other discipline in this manual works to get a human onto your page. Conversion Rate Optimization is the one that decides what happens in the five seconds after they arrive. A site can rank, get cited by an answer engine, and pull real traffic — and still leak every visitor because the call-to-action is buried, the form asks for nine fields, or the headline never says what the business actually does. That is why CRO was one of the four roles flagged as critical and promoted from "coming" to live: it reads the same single page-fetch as everyone else (Chapter 5), but it reads it for intent-to-convert signals the other roles skip past.

What separates cro_recos() from a generic checklist is that every item is a diagnosis of your real page. It does not tell a site with one clear CTA to "add a CTA" — it counts the CTA hits it actually found in sig and reacts to that number. When the fetch fails, it produces nothing at all and returns the honesty note from Chapter 10, rather than inventing a plausible-looking audit.

What the analyzer actually looks at

These are the fields cro_recos() reads from the parsed signal dictionary (sig), and the conversion question each one answers:

Sample recommendations the role emits

The items below are illustrative — the exact wording is generated per page — but they show the shape of what cro_recos() returns for a page it read and found wanting:

A worked example — a weak headline fixed

The single highest-leverage conversion fix is usually the headline, because it is the first and often only thing a visitor reads. Here is an illustrative before-and-after of the kind of rewrite the Conversion view drafts from a page's own facts:

An example gate firing

CRO also refuses to run on nothing. If the audit could not read the live page, the role does not guess at your conversion path — it returns the standard fabrication guard from Chapter 10 instead of an invented result:

How to use it — step by step

1. Run the audit. Enter your URL on the front door (or in Audit & Report). Under the hood this posts to /analyze, which fetches the page once and parses it into sig.
2. Open the Conversion view. It calls realRole against the fetched workspace and renders what cro_recos(d, niche) produced — up to eight page-specific items. If no workspace is loaded, you'll see the generic playbook instead (your cue to run an audit first).
3. Read each item against your real page. Confirm the diagnosis — count your own CTAs, look at your own form. The findings should describe your site, not a template.
4. Approve, edit, or reject. Send the good ones to the queue; use "edit" to correct any draft in one line before it becomes eligible to ship.
5. Ship the approved fix (on a whitelisted test bed) via /ship, which snapshots the live file first so the change is one-click reversible (Chapter 9). Re-audit to confirm the number moved.
6. To regenerate on a schedule, the Conversion work is part of the department's daily production driven by /run-daily — fresh conversion findings appear as the page changes.

Paid Media

The role that drafts what you'd run and gates whether you should. paid_recos(d, niche) builds keyword themes and a real ad draft from your own page — but won't tell you to spend until you can measure it.

Reads: the H1s and title (for keyword themes and ad copy), the niche, the CTA presence, forms, and whether analytics is installed.

Produces: up to seven items — keyword themes and a responsive-search-ad draft written from the page's own H1 and title, plus a gate: paid spend is only recommended once there's a clear CTA and tracking in place. The engine will not send you into an ad auction blind.

Why the gate comes before the ad

Most "AI ad" tools do exactly one thing: they generate ad copy and hand it to you. That is the easy half. The dangerous half — the half that spends real money — is the decision to run at all. Paid Media is built the other way around: it will happily draft you a responsive search ad from your own page, but it holds a hard gate in front of the "go spend" recommendation. If the page has no clear CTA for the click to land on, and no analytics installed to measure what the click did, the role tells you to fix those first. Driving paid traffic to a page with nowhere to convert and no way to see what happened is how ad budgets vanish with nothing to show. That is the "no spend until CTA + tracking" rule, and it is load-bearing.

This is the same discipline as the rest of the engine, applied to the one department where a mistake costs cash directly: read the real page, draft the work, and refuse to recommend the risky action until the conditions that make it safe are actually true.

What the analyzer reads, and what it does with it

An example responsive-search-ad draft, written from an H1 and title

This is the role's signature output: it takes the page's own H1 and title and drafts a responsive search ad (RSA) — multiple headlines and descriptions Google's system can mix. The draft below is illustrative, built from a sample page whose title is "Multipole Magnets — programmable magnetic technology" and whose H1 reads "Programmable magnets, engineered to spec":

The gate firing — the "no spend until CTA + tracking" rule

Here is what the role emits when the ad is draftable but the page isn't ready to receive paid traffic. This is illustrative of the gate's output:

And once both conditions are met, the same role flips to a green light:

How to use it — step by step

1. Run the audit on your URL (front door or Audit & Report). This posts to /analyze, fetches the page, and parses the title, H1s, niche, CTA and analytics signals into sig.
2. Open the Paid Media output in the app. The role runs paid_recos(d, niche) and shows up to seven items: the keyword themes, the RSA draft, and the spend gate's current verdict.
3. Read the gate first. If it's HELD, treat the ad copy as a draft-in-waiting — go fix the CTA (Chapter 18) and install tracking (Chapter 20) before spending anything.
4. Approve or edit the ad draft. Send the RSA to the Approvals & Setup queue; edit any headline in one line. Nothing is placed into an ad account automatically — the engine drafts, you decide.
5. Re-audit after you fix the gate conditions. Once the page shows a clear CTA and analytics, re-run /analyze and the gate verdict flips to CLEARED.
6. On a schedule: the daily production run (/run-daily) keeps the keyword themes and ad drafts current as the page's own copy changes.

Data & Analytics

The role that checks whether you can even see what's working. analytics_recos(d, niche) produces up to eight measurement recommendations from what the page reveals about its own tracking.

Reads: whether analytics is installed, Search-Console verification, the forms and CTAs (to know what a conversion even is), and the word count.

Produces: install GA4, verify Search Console, define conversion events for the real actions on the page, add UTM discipline, and stand up a dashboard. This is the role the Manager Agent reads at each interval to know whether the other roles' work is landing.

Why measurement is the role everything else depends on

Data & Analytics is the quietest of the four critical roles and, in a real sense, the one the others lean on. Conversion can fix a form, Paid Media can draft an ad, the Content Desk can publish — but none of them can prove they worked unless the site can measure what happened. That is why the spend gate in Paid Media (Chapter 19) checks for tracking, and why the Manager Agent reads this role at each interval (Chapter 23): analytics is how the department knows whether its own work is landing. Ship fixes onto a site with no measurement and you are back to marketing on faith — the exact thing this engine is built to replace.

The role reads the page for what it can already see, and everything it recommends is an action toward being able to see more. It does not fabricate traffic or invent conversion numbers — consistent with the engine's honesty guards, an unmeasured thing is reported as unmeasured (Chapter 10), never papered over with an average.

What it reads, and the gap each reading exposes

Sample recommendations the role emits

An illustrative set of what analytics_recos() returns for a page with no tracking and two conversion actions (a contact form and a "Request a quote" button):

A worked example — defining a conversion event from what's on the page

The role's most useful move is that it names conversions from the actual actions it found, not from a generic list. On a page with a quote button, it doesn't say "set up conversion tracking" in the abstract — it points at the real element. Illustrative before-and-after of the measurement posture:

An example gate firing

Like every page-specific role, Data & Analytics produces nothing when the fetch failed:

How to use it — step by step

1. Run the audit on your URL. /analyze fetches the page and records whether an analytics tag and Search-Console verification are present, plus the forms and CTAs that define your conversions.
2. Open the analytics output. The role runs analytics_recos(d, niche) and lists up to eight measurement actions, ordered by what's missing most.
3. Do the install work it names — GA4 first, then Search Console verification. These are the two that unlock everything downstream.
4. Define the conversion events it identified from your real page actions, and adopt UTM tagging on your campaign links.
5. Approve the dashboard spec in the Approvals & Setup queue and stand it up. Now the department can prove its work moved a number.
6. Re-audit so the engine records that tracking is now installed — this also clears the analytics half of the Paid Media spend gate (Chapter 19). The Manager Agent then reads this role at each /run-daily interval to confirm the other roles' fixes are landing.

Market Research

The positioning read: who you're up against and who you're for. research_recos(d, niche) produces up to six recommendations from your page's own positioning language.

Reads: the H2s (as positioning themes) and the linked socials.

Produces: a competitor map, an audience definition, and a customer-interview plan — the homework a marketing department does before it spends a dollar. Anything material feeds the Board's quarterly review (Chapter 24).

Why the homework comes first

A real marketing department does not open an ad account or write a landing page cold. It first answers three questions: who are we actually up against, who exactly are we for, and what do those people really want? Market Research is the role that does that homework — and it does it from your page's own words rather than from a generic industry template. The page's H2s are its richest source: a business's section headings are, in effect, its self-declared positioning. If your H2s say "engineered to spec," "48-hour quotes," and "trusted by aerospace," the role reads those as the themes you are choosing to compete on and builds the research around them.

This role is deliberately upstream of the spending roles. Its output is what keeps Paid Media (Chapter 19) and the Content Desk (Chapter 15) from guessing — you research the audience before you pay to reach it. And anything material it surfaces flows into the Board's quarterly review (Chapter 24), where it informs the next period's goals.

What it reads, and why those two signals

Sample recommendations the role emits

An illustrative set for a magnetics manufacturer whose H2s emphasize custom engineering and fast turnaround:

A worked example — turning H2s into an audience definition

This is the move that makes the role concrete. It reads the page's headings and infers who the copy is actually written for. Illustrative:

The synthesized audience definition (illustrative): "A design or applications engineer in a regulated hardware industry, working to a project deadline, who specifies parts precisely and rewards fast, credible turnaround over the lowest quote." That single paragraph is what every downstream role should read before it drafts a word — the same "understand the business first" principle the skills library builds on (Chapter 28).

How to use it — step by step

1. Run the audit on your URL. /analyze parses the H2 headings and linked socials into sig.
2. Open the research output. The role runs research_recos(d, niche) and returns up to six items: the competitor map, the audience definition, and the customer-interview plan, plus any positioning gaps it spotted.
3. Sanity-check the audience definition against reality. If it read your H2s and mis-inferred the buyer, that's a signal your headings are aimed at the wrong person — a finding in itself.
4. Run the interview plan. Do the 5 short calls; feed what you learn back in.
5. Approve the material items in the Approvals & Setup queue. Anything substantive carries forward into the Board's quarterly review (Chapter 24), where it shapes the next period's goals.
6. On a schedule: as your positioning (your H2s) evolves, the daily run (/run-daily) refreshes the competitor map and audience read to match.

Outbound / Demand Gen

The pipeline half of the department — the outbound motion that complements the inbound work of SEO, content and AEO. It appears in the app as the Outbound view.

Produces: the demand-generation pipeline — prospecting lists, cold-email sequences (drafted, never auto-sent, per Chapter 17), and the outbound cadence. It draws on the skills library's prospecting and cold-email playbooks (Part V).

Why a department needs both motions

Everything in Part III up to now is inbound: SEO, answer-engine optimization, and content all work to get the right people to come to you. Outbound is the other half — the department reaching out first. A real marketing team runs both, because inbound compounds slowly while outbound can open a pipeline this week. The Outbound view is where that motion lives: building a list of the right prospects, drafting the sequence that reaches them, and setting the cadence that follows up without being a nuisance.

Outbound is delivered through the skills library's prospecting, cold-email, directory-submissions, referrals, co-marketing, public-relations and sales-enablement playbooks plus ready-to-paste prompts (Chapter 31) — the responsible department applying proven frameworks, rather than a live page-analyzer. That's the honest label: it's playbook-driven, and it's real.

What the Outbound pipeline produces

An example cold-email sequence — drafted and HELD

The sequence below is illustrative of what the Outbound view drafts for a magnetics manufacturer targeting design engineers. Every message sits in the queue as a draft; none is sent by the engine:

How to use it — step by step

1. Establish who you're for first. Run Market Research (Chapter 21) so Outbound targets a real audience definition, not a guess.
2. Open the Outbound view. It presents the prospecting list, the drafted cold-email sequence, and the cadence, driven by the prospecting and cold-email playbooks and their prompts.
3. Review every message as a draft. Read the sequence in the Approvals & Setup queue; edit any touch in one line before approving.
4. Approve — but understand approval is not sending. For outbound email, approval marks a draft as ready; a human still performs the send in your own mail system. The engine never sends it (Chapter 17).
5. Layer the adjacent motions as fit — directory submissions, referral or co-marketing outreach, PR — each from its playbook and prompts (Chapter 31).
6. Keep it fresh. The daily production run (/run-daily) refreshes outbound drafts alongside the rest of the department's work, so the pipeline keeps producing on a schedule while the send decision stays with a person.

The Manager Agent

The CMO seat — the executive overview that reads across every role and tells you what got done, what's waiting, and what to do next. Its real mechanic is the daily run.

What it shows (the Manager view, Phase 3 · Operations): four stat cards — active roles, deliverables shipped, items awaiting approval, and critical roles coming online — a Daily → Weekly → Monthly → Quarterly → YOY interval strip, a "what got done" list, and "recommendations for your approval" that are analysis-driven when a workspace is loaded.

Its real mechanic: there is no single manager() function; the Manager's engine-side action is the /run-daily endpoint, which runs the department's daily production for one site or the whole network. The Manager view is the human-readable face of that run.

Why there's a manager at all

Six roles producing work on a schedule is a lot to hold in your head. The Manager Agent is the seat that keeps it legible — the single screen a busy operator can open to answer "is the department actually working, and what needs me?" without reading six separate views. It doesn't do marketing work itself; it summarizes the work the roles did and surfaces the decisions that are waiting on you. That's the honest description: it's the executive dashboard over the department, and its engine-side muscle is the daily run that produced everything it's summarizing.

Being clear about what it is matters. There is no reasoning agent hiding behind the Manager view — it's a real UI over real data. Its "recommendations for your approval" are analysis-driven when a workspace is loaded (they read the actual scores and deliverables), and generic guidance when one isn't. The value is legibility, not a black box.

The /run-daily mechanic

The Manager's real action is the daily production run. /run-daily drives the department's fresh output — for one site or the whole network — via the run functions run_daily_ws() (one workspace) and run_daily_all() (every workspace). It's the automated half of the loop from Chapter 2: the roles produce, the queue fills, and the Manager view reports what landed. Critically, "produced" is not "published" — the approval gate is still the human half, so a full daily run can generate dozens of deliverables and ship exactly zero until a person acts.

An example "what got done" list

After a daily run, the Manager view prints a plain-English log of the department's output. Illustrative:

How to use it — step by step

1. Load a site. Run an audit first (/analyze) so there's a workspace for the Manager to read — otherwise its recommendations fall back to generic.
2. Open the Manager view (Phase 3 · Operations). Scan the four stat cards for the department's state at a glance.
3. Trigger a daily run. The Manager's engine-side action is /run-daily — run it for this one site (run_daily_ws()) or the whole network (run_daily_all()) to produce fresh work.
4. Read the "what got done" list to see what each role produced this cycle.
5. Act on the recommendation. It points at the highest-leverage next approval; approve it in the Approvals & Setup queue (Chapter 25).
6. Set the rhythm. Use the interval strip to think in the right horizon — daily production, weekly review, quarterly Board review (Chapter 24). On the host, the daily run is automated by a midnight cron (Chapter 47), so the Manager view stays current without a button press.

The Board of Advisors

The quarterly review, run by software. The Board reads the scorecard, names your weakest discipline, and points the next quarter's goals at closing that gap.

How it works (the Board view, Phase 4 · Review): it reads analysis.scores, finds the strongest and weakest of the five disciplines, and prints, for example: "Overall readiness N/100. Strongest: X (n). Weakest: Y (n) — the board points this quarter at closing that gap." The weakest discipline maps to a strategy — SEO/AI-Search/Content point to "own your search," Social to "drive demand," Technical to "fix conversion" — and that option is flagged ★ Board's pick. Adopting it sets your next-period goals.

Four standing advisor voices frame the review: a Growth Strategist, Brand & Content, an Answer-Engine (AEO) advisor, and Performance & Finance.

Why a board, and why quarterly

The Manager Agent (Chapter 23) handles the daily rhythm — what got done, what's waiting. The Board handles the longer horizon: once a quarter, step back from the day-to-day and ask "of everything we could work on next, what actually matters most?" A real advisory board answers that by looking at the whole picture and picking the biggest gap. The Board view does exactly that, mechanically, from the scorecard — so the strategic decision that usually comes down to whoever argues loudest is instead made from the numbers, in the open. That transparency is the point: you can always see why the Board picked what it picked, because it's reading analysis.scores and choosing the weakest one.

How the pick is made — the mapping

The Board reads the five scored disciplines, finds the weakest, and maps it to a strategy. That strategy becomes the ★ Board's pick, and adopting it sets your next-period goals — which flow back into Phase 2 setup, closing the loop (Chapter 26).

A worked example — the Board reading a real scorecard

Take the sample scorecard below. The five disciplines are read, the weakest is found, and the pick follows automatically. This is illustrative, built on the kind of honest low Social score the case-study sites actually carry (Chapter 41):

The four advisor voices

The review is framed by four standing perspectives, so the pick is read through more than one lens before it becomes a goal:

How to use it — step by step

1. Make sure scores are current. The Board reads analysis.scores, so run a fresh audit (/analyze) before the review if the site has changed.
2. Open the Board view (Phase 4 · Review). Read the one-line verdict: overall readiness, strongest, weakest.
3. Look at the ★ Board's pick. It's the strategy mapped from your weakest discipline — the biggest gap, named from the numbers.
4. Read it through the four voices to pressure-test the pick before you commit a quarter to it.
5. Adopt the pick to set your next-period goals. Those goals flow back into Phase 2 setup (Chapter 26), so the roles you enable next quarter are aimed at closing the gap the Board found.
6. Re-review next quarter — a fresh audit, a fresh weakest discipline, a fresh pick. The loop closes and repeats.

The Approval Queue

The most important role has no AI in it at all. The Approval Queue is the human gate — approve, edit, reject — and it is the reason every other chapter is safe.

What it is: every deliverable the department drafts lands here with a status. You approve it, edit it, or reject it. Approved work becomes eligible to ship (Chapter 9); nothing moves without your action. In the app it is the Approvals & Setup view, which also holds the account connections and the managed-engagement terms.

Why it's a role, not a step: the whole product thesis is that software should carry the repetition and a person should keep the judgment. The Approval Queue is that principle made concrete — the one seat that is deliberately never automated.

Why the gate is the whole product

Strip everything else away and this is what makes the engine safe to point at a real business. A single-purpose AI tool hands you output and, increasingly, publishes it for you — which means the first time it invents something plausible-but-wrong, it does so on your live site or into your customers' inboxes. The Approval Queue removes that failure mode by design: the department can draft all day, but station three of the loop (Chapter 2) cannot be skipped. Every deliverable arrives here as a proposal, not a fait accompli. Remove this gate and you have an unsupervised bot; keep it and you have a department. That's why it's counted as a role in its own right even though there's no model behind it — the judgment is the job.

The lifecycle of a deliverable

Each deliverable carries a status and its own lifecycle fields (Chapter 8). It moves through the queue like this:

An example held deliverable

This is what a single item looks like sitting in the queue, awaiting your call. Illustrative, drawn from the Answer-Engine role's signature fix (Chapter 14):

Approve it and it becomes eligible to ship; ship it (on a whitelisted test bed) and the engine copies the live file to a timestamped .bak first, so one click restores it. This exact deliverable shape — s9, "AISO refresh — FAQ schema," shipped and reversible — is the one recorded in the load-bearing proof of Chapter 43.

The two things that are never automated

How to use it — step by step

1. Open the Approvals & Setup view. Every drafted deliverable from every role is listed here with its status.
2. Read each item against your real page. The findings should describe your site; if one is off, that's exactly what the queue is for.
3. Approve, edit, or reject. Approve via /approve; to correct a draft in one line and have the role redo it, use /deliverable-edit (the individual item is fetched via /deliverable).
4. Ship what you approved. On a whitelisted test bed, /ship snapshots the live file and writes the change; /rollback restores it. For a client store, the same approve-first, reversible terms run through the platform's own API.
5. Manage connections & terms here too. This view also holds the account connections (/connect, /gsc) and the managed-engagement terms — the setup half of "Approvals & Setup."
6. Confirm the number moved. Re-audit (/analyze) after shipping; the workspace's score_history records the before-and-after as measured proof (Chapter 43).

The four phases: onboard, set up, operate, review

The engine's operating rhythm is a four-phase lifecycle, built into the app as a clickable strip that runs across the top of every phase view. It came from a client's own marketing-system deck and was implemented verbatim — because a business doesn't want a pile of features, it wants a rhythm it can run.

The four phases are not four screens you visit once. They are a loop: onboarding tells the engine who you are, setup decides how much rope each role gets, operations produces the work day after day, and review reads the quarter's numbers and points the next period's setup at the weakest discipline. Then it starts again. The strip is always visible so you always know which phase you're standing in.

Figure 26.1 — the four phases loop: each quarter's review feeds the next period's setup.

Phase 1 — Onboarding

You tell the engine who you are. The onboarding form collects your goals and channels (as chip toggles), your audience, and budget, and it takes a URL. This is wired to the real backend: submitting posts { url, intake:{ goals, channels, audience, budget } } to /analyze, runs a live audit, and lands you on an accurate report with real deliverables already generated. The intake is remembered and carried forward on every re-audit, so the 30/60/90 roadmap is personalized to what you actually said you wanted — not a generic template.

Illustrative example — a filled intake. A coworking space onboarding might submit:

Because budget says "time over ad spend," the roadmap the engine returns leads with SEO, AEO and email work and holds paid media until there's tracking in place (Chapter 19) — a directly traceable consequence of what was typed into the form.

Phase 2 — Set Up

You pick the department. The roster (Part III) is presented with each role's auto-versus-supervised setting and its report frequency; you choose which roles run and how much rope each gets. One rule is fixed and cannot be toggled: outbound email can never be set to fully automatic — it always waits for a human (Chapter 17).

CAUTION"Auto" never means "unsupervised forever." Even a role set to auto still writes its work to the Approval Queue for shipping decisions on the operator's test beds, and outbound email is exempt from auto entirely. Setup decides how work is drafted, not whether a human keeps the last word.

Phase 3 — Operations

The department runs. The Manager Agent (Chapter 23) gives the executive overview — active roles, deliverables shipped, items awaiting approval, critical roles coming online — deliverables flow into the Approval Queue, and the /run-daily mechanic produces fresh work on the interval you set. This is the phase you live in most days: open the Manager view, read what got done overnight, and clear the queue.

Phase 4 — Review

The Board (Chapter 24) reads the quarter's scores from analysis.scores, names the strongest and weakest of the five disciplines, and sets the next period's goals — which flow straight back into Phase 2's setup. For example, if Social is the weakest discipline, the Board flags the "drive demand" strategy as its pick; adopting it turns the Social Scheduler up in the next setup pass. The loop closes, and the next quarter starts from evidence instead of opinion.

How to use it — step by step

1. Onboard (Phase 1). In the app, open the onboarding form. Enter your URL, toggle your goal and channel chips, type your audience and budget, and submit. Plain English: you're introducing your business. Under the hood this posts { url, intake } to /analyze, which fetches the page and returns a scored report with deliverables already drafted.
2. Set up the department (Phase 2). On the Approvals & Setup view, walk the roster and set each role to auto or supervised and choose its report frequency. Leave the Email Writer supervised — the app won't let you make it fully auto anyway.
3. Operate (Phase 3). Check the Manager view (Phase 3 · Operations) for the four stat cards and the "what got done" list, then clear the Approval Queue — approve, edit, or reject each held item. The daily production is driven by /run-daily for your site (or the whole network).
4. Review (Phase 4). Each quarter, open the Board view (Phase 4 · Review). Read the strongest/weakest call-out, adopt the ★ Board's pick to set next-period goals, and return to Phase 2 to retune the roster accordingly.

What Agent Skills are

"Skills are markdown files that give AI agents specialized knowledge and workflows for specific tasks. When you add these to your project, your agent can recognize when you're working on a marketing task and apply the right frameworks and best practices." That is the definition from the source repository, and it is exactly how the engine uses them.

The library the engine ingested is coreyhaines31/marketingskills — "a collection of AI agent skills focused on marketing tasks, built for technical marketers and founders who want AI coding agents to help with conversion optimization, copywriting, SEO, analytics, and growth engineering." It follows the open Agent Skills specification, so the same skills work across Claude Code, OpenAI Codex, Cursor, Windsurf, and any conforming agent. The engine didn't invent a proprietary knowledge blob; it stood on an open standard, which is why the coverage in Chapter 31 can be checked against the public source.

What a skill actually is, on disk

Each skill is a single SKILL.md file with YAML frontmatter — a name (lowercase, hyphenated, matching its folder), a description of when to use it, and a version — followed by a markdown body of frameworks and best practices. It is deliberately plain text: readable by a human, versionable in git, and portable to any agent that speaks the spec.

ILLUSTRATIVEThe values above show the shape of a skill file, not a verbatim copy — the real frontmatter and body live in the source repository. The load-bearing fact is the structure: one file, three frontmatter keys, a markdown playbook underneath.

The three ways a skill is invoked

A skill can be reached however the operator prefers to work — conversationally, by command, or as an installed package:

Illustrative example — recognition in action. Suppose you paste a page and say "the free-trial page isn't converting, help." An agent with the library installed matches your intent to the cro skill, reads product-marketing first for context (Chapter 28), and returns advice framed by the CRO playbook — CTA count, form friction, trust signals — rather than generic tips. You never had to name the skill.

How to use it — step by step

1. Inside the engine (no install needed). Open the Marketing Skills tab (Chapter 29). The 47 skills are already folded in; click a card to read its full playbook. The engine reaches the right skill automatically when a department drafts work — you don't invoke it by hand.
2. In your own agent, by conversation. Describe the task in plain English ("rewrite this cold-email sequence to get replies"). A conforming agent recognizes the intent and applies the matching skill (cold-email).
3. In your own agent, by command. Type the slash form — /seo-audit, /cro, /emails — to load one skill deliberately.
4. To install the whole library. Run npx skills add coreyhaines31/marketingskills, or in Claude Code run /plugin install marketing-skills. All 47 SKILL.md files install to .agents/skills/, and every conforming agent on that project can use them.

The dependency architecture

The skills are not a flat list — they form an interconnected system. One skill sits at the root, and every other reads it first. This is the single most important structural fact about the library, and the engine honors it.

In the repository's own words: "Skills reference each other and build on shared context. The product-marketing skill is the foundation — every other skill checks it first to understand your product, audience, and positioning before doing anything." That is exactly what the engine's niche detection and intake do before any department drafts a word — establish who the business is, so everything downstream is grounded in facts rather than guesses.

product-marketing is the root; skills also cross-reference each other — copywriting ↔ cro ↔ ab-testing, and seo-audit ↔ schema ↔ ai-seo.

Why a root skill changes everything

A flat list of 47 skills would give you 47 disconnected opinions. A rooted graph gives you 47 consistent ones, because they all draw the same facts about your product, audience and positioning from one place before they act. That is what stops the copywriter from describing a different business than the SEO analyst, and it's the library-level echo of the engine's own honesty guards: don't act until you know what you're looking at.

Illustrative example — the same fact, shared. Say product-marketing establishes that a client's audience is "operations leads at 50–200-person manufacturers" and the core value is "cut changeover time." Watch it propagate:

Change the root once — say the audience shifts to "plant managers" — and every dependent skill's next output shifts with it, without editing seven files by hand. That is the whole payoff of the architecture.

How to use it — step by step

1. Set the foundation first. In the app, complete onboarding (Phase 1) fully — goals, channels, audience, budget. That intake plus the auto-detected niche is your product-marketing root; every department reads it before drafting.
2. Get the positioning right before anything else. If a downstream deliverable feels off-target, don't correct it deliverable-by-deliverable — fix the foundation. Correct the audience or value in your intake and re-audit, so /analyze re-grounds every role at once.
3. In your own agent (installed library). Run the product-marketing skill first to record product, audience and positioning; every other skill you invoke afterward will read it and stay consistent. Skipping it is why disconnected agents produce contradictory copy.
4. Verify the cross-references held. Check that the copy, the CRO advice and the schema all describe the same business and audience. If they diverge, the foundation wasn't set — go back to step 1.

The seven categories and 47 skills

The library ships 47 skills. The engine groups them into seven categories in its own generator, matching the repository's structure. Here is the full set — the complete list appears again, alphabetized with descriptions, in Appendix B.

Seven categories, 47 skills, one grouping the engine and the source repository share. The categories aren't decoration — they're how the app arranges the library so you can find the right framework by the shape of your problem, whether that's "I need to be found" (SEO & Site), "I need people to convert" (Conversion & Lifecycle) or "I need to keep the ones I have" (Growth, PR & Ops).

Reading the map: from a problem to a skill

Illustrative examples — matching a real question to the right card.

In the product

This is the Marketing Skills tab (view #17): the seven groups, each skill a card that opens to its full playbook and reference docs, folded directly into the engine so the department can reach the right framework for any task. It's not a link out to a repo — the playbooks live inside the app.

How to use it — step by step

1. Start from your problem, not the list. Decide which of the three big questions you're in — get found, get conversions, keep customers — and open the matching category on the Marketing Skills tab.
2. Open the skill card. Click the card to read its full SKILL.md playbook and reference docs in-app. Each card is the framework, not a summary.
3. Cross the category to the matrix. Note the skill's department, then check Chapter 31 to see whether it runs as a live analyzer on your page today or is delivered as playbook + prompts.
4. Run it through the responsible department. For live-analyzer skills, run a fresh audit (/analyze) and read the department's findings; for playbook skills, use the framework plus the ready-to-paste prompts from the Prompts tab (Chapter 30).

The prompt library

On top of the 47 skills, the engine ships a library of ready-to-paste prompts — the operational layer that turns a skill's framework into a task you can run today. The count is exact and verified from the source files.

A skill tells you how to think about a marketing problem; a prompt is a specific, filled-in instruction you can paste into an agent and get work back. The library pairs the two so you never stare at a good framework wondering where to start — the prompt is the start.

Two axes, one library. The 235 skill prompts are organized by the same seven categories as the skills (Chapter 29) — a CRO prompt, a schema prompt, a cold-email prompt. The 192 vertical prompts are organized by industry, so a coffee shop and a magnetics manufacturer each get prompts written for their actual customers and searches rather than a generic template.

The 24 industry packs

The industry packs are what make the library concrete for a real business rather than generic: travel, cruise ships, villas, non-MLS real estate, robotics, radio, TV and streaming, coworking, coffee shops, car dealers (new and used), and more. Each pack is a set of prompts written for that vertical's actual customers and searches — the "real, genuine verticals to test on" that keep the engine honest, because a prompt that works on a live coffee shop or a live magnetics guide is provably useful in a way a generic one is not.

Illustrative example — a skill prompt vs. a vertical prompt for the same job. Both aim at an FAQ that AI search can quote, but the vertical version already knows the business:

ILLUSTRATIVEThe wording above shows how the two layers differ — framework vs. business-specific — not the exact strings in the source files. The verified facts are the counts and the structure: 235 skill prompts, 192 vertical prompts, 24 packs.

How to use it — step by step

1. Open the Prompts tab. In the app, go to the Prompts view (view #18). It's grouped two ways — by skill category and by industry.
2. Pick your lane. If you want a technique, browse by category (e.g. Conversion & Lifecycle → a CRO prompt). If you want something already shaped for your business, open your industry pack (e.g. the coworking or villas pack).
3. Copy the prompt and fill the blanks. Paste it into the engine's assist chat ("ask your marketing team") or your own agent, and drop in your real specifics — your page, your offer, your audience.
4. Route the output through approval. Whatever comes back is a draft. Send it to the Approval Queue like any other deliverable — approve, edit, or reject — before anything ships. A prompt is a fast start, not a bypass of the gate.

Full skills coverage: the engine enabled in all 47

This is the chapter that answers the operator's real question — is the engine actually enabled in every one of the 47 skills? Yes. Each skill is covered in one of three modes, and this matrix names the mode and the department for all 47, with nothing left out.

The three enablement modes

• Live analyzer — the engine computes page-specific findings for this skill from your real site, through one of the six backend channels (seo, aiso, cro, analytics, paid, research).
• Playbook + prompts — the engine delivers this skill through its full SKILL.md playbook plus ready-to-paste prompts, driven by the responsible department.
• Generator — the engine produces this directly (the content calendar, social drafts, the 30/60/90 roadmap).

What each mode looks like in practice

Illustrative examples, one per mode:

HOW TO READ ITLive analyzer = the engine looked at your page. Generator = the engine produced the artifact itself. Playbook + prompts = the engine hands you the framework and the exact prompts to run it. All three are "enabled" — the difference is honesty about which reads your live site today.

How to use it — step by step

1. Find your skill in the matrix. Look up the skill you care about and read across to its department and mode.
2. If it's a live analyzer, run a fresh audit — in the app that's onboarding or a re-audit; technically it's a POST to /analyze, and the finding comes from the named channel (e.g. seo_aiso() for seo-audit, cro_recos() for cro). Read the result in the matching app view (SEO & AI Search, Conversion, etc.).
3. If it's a generator, open the Content view (calendar + briefs + social drafts) — the artifact is produced directly by the engine.
4. If it's playbook + prompts, open the skill card (Chapter 29) for the framework and grab the matching prompts from the Prompts tab (Chapter 30), then run them through the responsible department and into the Approval Queue.

License and attribution

The skills library is open-source, and the engine uses it on those terms — openly, with attribution, as the library's author intends. This chapter is short on purpose: doing the right thing with someone else's open work doesn't require a lot of words, only that you actually do it.

The Marketing Skills library is MIT licensed — "Copyright (c) 2025 Corey Haines" — which the repository summarizes as "use these however you want." The engine adapts the skills into its own generator (gen-ame-skills.py → the in-app library) and carries the attribution verbatim on the Skills and Prompts pages: "Skills adapted from coreyhaines31/marketingskills (MIT)."

MIT is one of the most permissive open-source licenses: it lets you use, copy, modify, merge, publish and distribute the work, including commercially, on essentially one condition — keep the copyright notice and license text with it. The engine meets that condition by carrying the attribution line in-app, in the exact places a reader encounters the adapted skills.

The wider world the library names

The repository also names its wider world — Conversion Factory (Corey's agency), Swipe Files (his newsletter), and Magister (an autonomous AI CMO built on these skills). The engine is a distinct, independently built system that stands on the same open foundation. It borrows the skills, not the identity: the audit backend, the scoring model, the honesty guards, the ship-and-rollback machinery and the department UI are the engine's own work.

How to use it — step by step

1. See the attribution in the app. Open the Marketing Skills or Prompts tab; the line "Skills adapted from coreyhaines31/marketingskills (MIT)" is carried on the page.
2. Read the original source. The skills are open — visit github.com/coreyhaines31/marketingskills to read the unmodified SKILL.md files and the LICENSE.
3. If you adapt them yourself. MIT lets you use and modify the skills freely; keep the copyright notice and license with your copy, just as the engine does. That single step keeps you compliant.
4. Cite, don't conflate. Credit the library as the foundation, and keep your own system's identity distinct — the way the engine does relative to Magister and the author's other projects.

Auto Marketing Engine — the flagship

automarketingengine.com is the only property with the full working app: the ignition form, the live audit, the department roster, the approval queue, and the Skills and Prompts libraries. Everything else in this part is a variation on it.

It is the site that runs the real backend described in Part II, presents the department of Part III, and follows the lifecycle of Part IV. When this manual says “the engine,” it means the machine that lives here. Its front door offers a free audit — one URL, no signup, nothing asked in return — which is the honest top of the funnel: a real result, given away, that proves the machine before any conversation about price.

Every other property in Part VI — the three editions (Chapter 34), the four builds on the deptmatic.com subdomains (Chapters 35–38), the finished Polymagnet rebuild (Chapter 39), and the Day-in-the-Life timeline (Chapter 40) — is a retelling of this one machine for a different audience or a different question. They share the backend; the flagship is where you meet all of it at once.

What lives here that lives nowhere else

The flagship is the complete surface. Each piece maps to an earlier chapter, so you can read the whole manual by clicking through this one site:

The free audit is the honest top of the funnel

Most marketing sites gate the good stuff behind a signup form. The flagship inverts that: it hands you the finished result first and asks for nothing. The reason is the same candor that runs through the whole manual — a real audit, given away, is a proof you can check by hand, and a proof you can check is worth more than a promise you have to trust.

What the free audit returns — illustrative

The scorecard below is illustrative, to show the shape of what lands on the Audit & Report view a few seconds after you submit a URL. The real numbers come from a real fetch of the page you enter.

Alongside the scorecard comes a ranked fix list — the highest-impact items first, each with the concrete change to make. An illustrative example of what one of those items reads like:

How to use it — step by step

1. Plain English: Go to automarketingengine.com and enter a site you know well — ideally your own — into the free-audit box. No signup.
2. Within a few seconds you land on the Audit & Report view: the 0–100 overall, the five discipline scores, and a ranked list of fixes already drafted from your real page.
3. Open SEO & AI Search, Content, Conversion, and Outbound to read each role’s deliverables.
4. Go to Approvals & Setup to approve, edit, or reject each item — the seat you keep. Approved work becomes eligible to ship, and anything shipped is one-click reversible.
5. Under the hood: the front-door audit is a single POST /analyze with your URL — the same call that scores the operator’s own network, no “demo mode.” A shareable branded version renders at /report/<domain>; the daily production behind the roster is /run-daily.

The flagship is the reference implementation; the rest of Part VI shows the same engine wearing different clothes. Read the three editions next (Chapter 34) to see why one machine has three front doors.

The three editions

Deptmatic, Deptless, and Auto Marketing Dept are the same engine told three ways. Under the hood they share the backend; on the surface each tells the story to a different audience.

The three editions exist because different buyers need to hear the same truth in different words. One person is shopping for a product line; another is a skeptic who wants the claims laid bare before believing any of them; a third thinks in terms of headcount and payroll. Rather than water the message down to one bland pitch, the engine wears three faces — each self-canonical, each independently indexed — over one shared backend.

The three, and who each is for

deptless.com is where the honesty lives out loud

The Deptless edition earns particular mention because it is the one built for a skeptic. Instead of a glossy claims page, it carries the honest feature chart — a comparison that shows every edition side by side with the gaps included. It does not hide that most skills are delivered as playbook-plus-prompts rather than live analyzers (Chapter 31), or that the case-study sites carry real, low Social scores (Chapter 16). A skeptic goes there to poke holes, and the page hands them the pins.

Same backend, verifiably

The editions are not three separate products — they are three storefronts on one machine. You can prove it: run the same URL through any edition’s audit and you get the same scorecard, because each is calling the same /analyze pipeline (Chapter 5) with the same scoring (Chapter 6). The words on the homepage differ; the engine underneath does not.

Why keep three at parity — resilience

The editions are kept at parity so any could stand in for the flagship — a deliberate resilience choice. If one address had a problem, another tells the same story with the same machine behind it. It is the network principle applied to the pitch itself: no single point of failure, not even the front door.

An illustrative walk-through of the same URL, three doors

Illustrative only, to show the parity: suppose a prospect runs example.com through each edition’s audit box.

• On deptmatic.com they read it as “your AI marketing team just audited the site — here are the drafts, waiting for your approval.”
• On deptless.com they read the same scorecard next to the honest feature chart, and can see which fixes are live-analyzed and which are playbook-delivered.
• On automarketingdept.com they read it as “here is what each filled position produced this run — the payroll you never ran.”

Three readings, one scorecard, because it is one /analyze call underneath all three.

How to use it — step by step

1. Plain English: Pick the edition whose framing fits how you think — product (deptmatic.com), no-department (deptless.com), or as-a-service (automarketingdept.com).
2. If you want to check the claims before believing them, start at deptless.com and read the honest feature chart against Chapter 31’s coverage matrix.
3. Run your own URL through the audit box on whichever edition you chose — the scorecard is identical across all three.
4. Under the hood: every edition’s audit box posts to the same /analyze; the branded report is the same /report/<domain>. To confirm parity yourself, run the same URL on two editions and compare .scores.overall — they match (Track B, Chapter 45).

The three editions are the storytelling layer. The next four chapters (35–38) are the builds — the deptmatic.com subdomains that each answer one specific question about how the engine behaves: onboarding, scale, and two live case engines.

The dashboard build — a.deptmatic.com

The four-step setup workspace. a.deptmatic is the build that answers “what does onboarding feel like?” — set it up in four steps, then watch it read your site, produce real work, and hold every deliverable for approval.

It is the clearest expression of Phase 1 → Phase 3 of the lifecycle: a guided path from a cold URL to a working department with deliverables waiting in the queue. Where the flagship shows you everything at once, the dashboard build slows the first run down into steps you can follow, so a newcomer sees exactly what happens between “I pasted my address” and “there is finished work in my queue.”

The four steps, mapped to the lifecycle

The four-step setup is the visible face of the lifecycle’s first three phases (Chapter 26). Each step corresponds to a real backend action, not a wizard animation:

What the guided run produces — illustrative

Illustrative, to show the payoff at the end of the four steps: after a cold URL goes in, the queue fills with drafted work, each item marked held until you approve it.

The gate is visible from step one

Every deliverable the guided run produces lands with a status, and nothing moves without your action. That is the whole product thesis (Chapter 25) made obvious to a first-time user: the software carried the reading and the drafting; the judgment is still yours, sitting right there in the queue as approve / edit / reject.

How to use it — step by step

1. Plain English: Go to a.deptmatic.com and start the four-step setup. Enter your URL and, when asked, your goals, channels, audience, and budget.
2. Watch step 2 read the live site — the scorecard is the same one the flagship shows, from a real fetch.
3. In step 3, choose which roles run and their auto-versus-supervised setting. Remember: outbound email can never be set to fully automatic (Chapter 17).
4. In step 4, open the queue and work each held deliverable — approve, edit, or reject. Approved work becomes eligible to ship, reversibly.
5. Under the hood: step 1 posts { url, intake:{ goals, channels, audience, budget } } to /analyze; the intake is remembered and carried forward on re-audit, so your 30/60/90 roadmap stays personalized. Ongoing production is the /run-daily mechanic behind the Manager view.

The dashboard build shows onboarding for one business, done well. The next build (Chapter 36) answers the opposite question: what does the engine feel like when you run it across a whole portfolio at once?

The command edition — b.deptmatic.com

The department at scale. b.deptmatic is the build for running many businesses on one engine: a network-wide leaderboard across every site, a command palette, bulk approvals, and a planning simulator.

Where the flagship manages one business well, the command edition manages a portfolio — the same approval discipline, but with the tools to triage and act across dozens of sites at once. It is the operator’s cockpit. The dashboard build (Chapter 35) answers “what does onboarding feel like?”; the command edition answers “what does it feel like when the department is already running everywhere and you need to see the whole board?”

The four cockpit tools

The command edition is built around four instruments, each aimed at the portfolio problem — too many sites to open one at a time:

The leaderboard — illustrative

Illustrative, to show the shape of the network view: every site is a sortable row, so you can sort by the weakest discipline and see where the next fix should go.

Bulk approvals keep the gate, at scale

The critical design point: running a portfolio does not mean giving up the approval gate. Bulk approvals let you act on the same held deliverable across many sites in one motion — but it is still an approval, still a human saying yes. The command edition scales the operator’s reach, not the machine’s autonomy.

An illustrative triage session

Illustrative, to show the cockpit in motion. An operator opens b.deptmatic.com in the morning:

1. Sorts the leaderboard by AI-Search score, ascending — six sites are missing FAQ schema.
2. Uses the planning simulator to confirm the FAQ-schema fix would move AI-Search on all six.
3. Bulk-approves the drafted FAQ-schema deliverable across all six sites.
4. Ships the approved fixes; each is snapshotted first, so any one is one-click reversible.

Six sites improved in one triage pass — the same before-and-after the homebuilding case study documents (Chapter 41), done from the cockpit.

How to use it — step by step

1. Plain English: Go to b.deptmatic.com to see every site you run on one board. Sort the leaderboard by whichever discipline you want to fix.
2. Use the command palette to jump straight to any site or action without hunting through menus.
3. When the same fix is held across many sites, use bulk approvals to act on all of them at once — each is still a human yes.
4. Use the planning simulator to model a round of fixes before you approve, so you spend your approvals where they pay off most.
5. Under the hood: the leaderboard reads the per-site workspaces (the /network and /portfolio views over the workspace datastore, Chapter 8); daily production across the whole portfolio is /run-daily run network-wide; each ship still snapshots via /ship and reverses via /rollback.

The command edition is the tool for running the engine across many sites. The next two chapters (37–38) show the engine pointed hard at specific sites — two live case engines that prove the audit holds up in real, difficult niches.

The magnetics case engine — c.deptmatic.com

The engine pointed at a real, hard, technical niche: programmable magnets. c.deptmatic runs the engine end to end on two live magnetics guides and builds three department concepts for the company behind the technology, Polymagnet.

A coffee shop is easy to write marketing for; a programmable-magnet company is not. The magnetics case engine exists to prove the audit holds up outside the easy verticals — that niche detection, scoring, and the role drafts still read as real work when the subject is genuinely technical. This is where the niche detector’s magnetics fix (Chapter 7) earns its place: magnetics sits at priority 2 with ten magnet-specific keywords, so a magnet company classifies correctly instead of being mislabeled “marketing.”

The headline stat strip

The build carries its own numbers, verbatim from the live case file:

Why it’s a proof, not a demo

The case engine makes its own claim to honesty, verbatim: “Nothing below is a mockup. Every number and every link is live.” That single line is what separates it from a slide deck — the two guides are real, audited sites, and the three concepts sit at real subdomains you can open, not renderings.

The two guides — illustrative reading of the audited scorecards

The two magnetics guides are audited live; their full numbers are the subject of Chapter 42. The illustrative meter below shows the shape of one guide’s scorecard — strong on the technical and content side, honestly low on Social because it has no social profiles and the engine won’t fake a sameAs (Chapter 10).

The three department concepts

Each department concept is a real, live take on a Polymagnet marketing department — at real subdomains, not slides:

Three concepts for one company is itself a lesson: the engine reads one real business and can dress its department three ways — the same one-machine-many-faces logic as the three editions (Chapter 34), applied to a single client’s marketing.

How to use it — step by step

1. Plain English: Open c.deptmatic.com and read the stat strip — two guides, three concepts, engine average 63/100.
2. Click through to either magnetics guide and read its audited scorecard; then check a finding by hand to confirm it’s real.
3. Open each of the three department concepts at their real subdomains — they are live sites, not mockups.
4. Compare what you see to Chapter 42, the full case study, and Chapter 43, the logged ship-and-rollback on multipolemag.com.
5. Under the hood: the guides were scored by the same /analyze pipeline; the branded report for either renders at /report/<domain>. The magnetics domains are on the ship whitelist (Chapter 9), which is why the case includes a real, logged ship and rollback.

c.deptmatic shows the audit and the concepts on a hard niche. The next chapter (38) is the most complete proof the engine has — six real sites, each with a shipped, re-audit-verified fix.

The homebuilding case engine — d.deptmatic.com

The most complete proof the engine has: one engine run end to end on six real homebuilding sites, each with a shipped, re-audit-verified fix. This is the case file for a partner’s own industry.

If the magnetics case engine (Chapter 37) proves the audit holds up on a hard niche, the homebuilding case engine proves the whole loop closes — audit, draft, approve, ship, and measure — on more than one site at once. It runs the engine across an entire vertical the partner knows first-hand, so the numbers can be checked by someone who understands the industry.

The stat strip, verbatim

What shipped: FAQ-schema, the Answer-Engine’s signature move

The fix drafted and shipped to each of the six sites was FAQ-schema markup (FAQPage JSON-LD) — the Answer-Engine role’s signature move (Chapter 14). It is exactly what an AI reader needs to quote a page, which is why it moved the AI-Search score on every site. And it shipped on the engine’s own terms, verbatim from the case file: “verified by re-audit, live on the site now, and one-click reversible.”

The before-and-after — the case study centerpiece

The per-site before-and-after is the centerpiece of Chapter 41. The pattern to read: the same fix, applied by the same role, moved AI-Search on every one of the six sites, with overall climbing everywhere. The table below is the AI-Search delta for each site, drawn from the live case file.

An illustrative held deliverable, before it shipped

Illustrative, to show what one of these fixes looked like sitting in the queue before approval:

How to use it — step by step

1. Plain English: Open d.deptmatic.com and read the stat strip — six sites, three service lines, 64/100 average after fixes.
2. Pick any of the six sites and read its before/after. Confirm the AI-Search delta matches the table above and Chapter 41.
3. Note that the shipped fix on each is FAQ-schema, and that each is marked verified-by-re-audit and one-click reversible.
4. Under the hood: each fix is FAQPage JSON-LD drafted by the aiso channel inside seo_aiso(), approved in the queue, shipped via /ship (which snapshots first), then re-scored by a fresh /analyze — the delta you read is that re-audit. Any one is reversible via /rollback.

The homebuilding case engine shows the loop closing across six sites. The next chapter (39) shows the far end of the pipeline — not a case file about the engine, but a finished thing the engine’s thinking produced.

The Polymagnet rebuild — 1.deptmatic.com

Not a case file about the engine — a finished thing the engine’s thinking produced. 1.deptmatic is a full marketing rebuild for the programmable-magnets maker, live and readable as the output end of the pipeline.

Every other build in Part VI shows the engine working — the audit, the roster, the queue, the case files. This one shows the engine’s work finished. Where c.deptmatic (Chapter 37) shows the audit and the concepts, 1.deptmatic shows what “shipped” looks like when the department’s work is carried all the way through — the before-and-after made whole.

Where it sits in the pipeline

The engine’s loop (Chapter 2) is audit → draft → approve → ship → measure. The two magnetics builds sit at opposite ends of it:

What “finished” means here

A rebuild at the output end reflects the department’s work applied all the way through — the kind of fixes the engine drafts, approved and shipped, then read as a coherent site rather than a queue of held items. Illustratively, the sorts of things that separate an output-end rebuild from a raw audit:

• The SEO structure fixed — a clean single H1, right-length title and meta, a real sitemap (the SEO Manager’s work, Chapter 13).
• The Answer-Engine surfaces published — /llms.txt, AGENTS.md, JSON-LD, a crisp lead answer an AI reader can lift (Chapter 14).
• The content written from the company’s real facts — the wonder of programmable magnetism told straight, never invented (Chapter 15).

These are illustrative of the pipeline’s output; the specific rebuild is live to read at the address itself.

How to use it — step by step

1. Plain English: Open 1.deptmatic.com and read it as a finished marketing site — this is the output end of the engine’s pipeline.
2. Then open c.deptmatic.com (Chapter 37) alongside it to see the audit and concepts that fed into this rebuild.
3. If you want to check the engine’s hand in it, run 1.deptmatic.com through the free audit and read its scorecard — the same /analyze that scores every site.
4. Under the hood: a rebuild like this is the far end of the same loop — deliverables drafted by the role builders inside seo_aiso() and the content/social generators, approved in the queue, shipped via /ship with a snapshot, all one-click reversible via /rollback. A branded audit of the result renders at /report/<domain>.

The Polymagnet rebuild is the department’s work made whole for one company. The last build in this part (Chapter 40) zooms back out to the rhythm of the department itself — what it does, hour by hour, across a full day.

Day in the Life — automarketing.wholetech.com

The department as a live 24-hour timeline. This build answers “what does the department actually do all day?” with a running clock and a “now” line showing what each role is doing this minute.

The other builds in Part VI show the engine’s outputs — scores, deliverables, case files, a finished rebuild. This one shows its rhythm. It is the family’s showpiece for the idea at the heart of the whole product: a marketing department that runs on a schedule, not a payroll. The long-form feature line says it plainly: “the department that runs on a schedule, not a payroll.”

Eight desks, ticking through the day

The timeline shows seven working desks plus an Ops desk, each with its own place in the day:

The “now” line — illustrative

A running clock advances a “now” line down the timeline, so at any moment you can see what each desk is doing this minute. Illustrative, to show the shape:

How this build differs technically — and why that’s honest

Unlike the flagship, the Day-in-the-Life build is a data-driven dashboard: it reads a per-site data file of role activity rather than the live /analyze output. That distinction matters, and the manual names it rather than blurring it — this build is a presentation of the department’s rhythm, driven by a data file, not a real-time audit running behind the clock.

The rhythm it visualizes is real, though: the actual daily production is the /run-daily mechanic on a midnight cron (Chapters 23, 47) — seven roles producing automatically on the schedule, with the approval of a deliverable and the sending of outbound email the two things that never run on their own.

How to use it — step by step

1. Plain English: Open automarketing.wholetech.com and watch the “now” line move — it shows what each of the eight desks is doing at this minute of the day.
2. Follow one desk down the timeline to see its whole day — e.g. the Content desk from morning brief to drafted post.
3. Read it as the answer to “what does the department do all day?” — the rhythm behind the deliverables you approve elsewhere.
4. Under the hood: this build reads a per-site data file of role activity, not live /analyze output. The real production it depicts is /run-daily on a midnight cron; to see the live version of the same rhythm, use the Manager (Phase 3 · Operations) view on the flagship, whose “what got done” list is that daily run made human-readable.

Day in the Life closes Part VI — the tour of the engine’s front doors, builds, case engines, and output. What follows in Part VII are the case studies proper: the measured, timestamped evidence that the loop these builds depict actually closes.

Six homebuilding sites, before and after

The clearest evidence the loop closes. The engine audited six real homebuilding sites, drafted the same fix for each — FAQ-schema markup, the Answer-Engine role’s signature move — shipped it after approval, and re-audited to confirm the lift. Every number below is from the live case file at d.deptmatic.com.

This is the case file for the home-construction industry, and it is the most complete proof in the manual because it exercises the entire loop from Chapter 2 on six sites at once: audit, draft, approve, ship, and — the step most tools skip — measure again. The engine did not stop at recommending a fix. It shipped the fix, then re-scored the same page and recorded the difference. What you are reading is measured lift, not a projection.

The stat strip on the case engine states the shape of the work, verbatim: “6 live sites audited & run on the engine · 3 service lines mapped for homebuilding media · engine avg 64/100 after the shipped fixes.” What shipped to each site was FAQ-schema (FAQPage JSON-LD) markup — “verified by re-audit, live on the site now, and one-click reversible.”

Why one fix, applied six times

The engine did not scatter six different fixes across six sites and hope. It chose the single highest-leverage change the Answer-Engine role (Chapter 14) recommends — publish FAQPage JSON-LD so an AI reader can quote the page — and applied it uniformly. That is a deliberate experimental design: hold the fix constant, vary only the site, and you can read the effect cleanly. If AI-Search rose on all six, the fix works; if it rose on some and not others, the difference tells you something real. It rose on all six.

The before → after, per site

Each row shows the discipline the fix targets (AI Search) and the overall, before and after the shipped FAQ-schema. These are the exact audited values from the case file.

Read the pattern, not just the numbers. The same fix, applied by the same role, moved the AI-Search score on every site — because FAQ-schema is exactly what an answer engine needs to quote a page. The lift was uniform in size where the starting point was the same: the four sites that began at AI-Search 64 or 55 each gained a clean 15–16 points, which is what you expect when one structural signal is added to pages that were otherwise comparable on that discipline. Spring Village, already the strongest at 73, still gained 16 to reach 89.

Where Content moved too — and why

The FAQ-schema wasn’t only a machine-readability signal; on the sites where the FAQ added real substance to the page, the Content discipline rose as well. Two sites show this second-order effect:

This is worth dwelling on, because it is the honest opposite of gaming a metric. The Content score didn’t move because a number was nudged; it moved because the page genuinely gained useful, human-readable answers at the same time it gained machine-readable schema. One fix, two real improvements.

A worked example — illustrative

To make the mechanism concrete, here is the kind of before→after the Answer-Engine role produces for a homebuilding page. The specific text below is illustrative; the score movements in the tables above are the real audited values.

The illustrative held deliverable, as it would sit in the queue before you approved it:

How to see it for yourself — step by step

1. Plain English: Open the homebuilding case file at d.deptmatic.com and pick any of the six sites.
2. Read its before/after block. The shipped fix (FAQ-schema) and the score delta shown will match the tables above — e.g. Spring Village AI-Search 73 → 89.
3. Cross-check against a live audit: open the shareable report for that site’s domain at /report/<domain> and confirm the AI-Search discipline now reads at the “after” value.
4. Under the hood: the fix is the Answer-Engine channel of seo_aiso(); it was drafted from the page-read, held in the approval queue, shipped via /ship (which snapshots first), and the lift was captured by a re-run of /analyze writing a fresh entry to the site’s score_history.

That is what closes the loop: the same fix, the same role, measured lift on all six sites, verified by re-audit and reversible on every one. Chapter 42 runs the same discipline on a harder, more technical niche; Chapter 43 shows the ship-and-rollback machinery underneath it all, logged and timestamped.

Two magnetics guides, audited live

The engine run on a genuinely hard technical niche, to show the audit holds up outside easy verticals. Both scores are current, audited values from c.deptmatic.com.

A coffee shop is easy to audit; the words on the page are the words a customer would search. Programmable magnets are not. The vocabulary is technical, the buyers are engineers, and a lazy auditor would either mislabel the site or paper the report with generic advice. This case exists to show the engine does neither — it reads the real page, classifies the niche correctly, and reports the exact facts it saw. The case engine’s own headline stat strip: “2 live guides audited & run on the engine · 3 department concepts, all built for Polymagnet · engine avg 63/100,” with the disclaimer that makes it a proof rather than a demo: “Nothing below is a mockup. Every number and every link is live.”

The two guides, scored

Both sites were audited live. Here are the current per-discipline scores for each — the same five disciplines every audit produces.

Reading the two profiles

The scores tell a story a marketer would recognize. Both guides are technically clean (Technical 90 each) and strong on substance (Content 90 and 75) — these are well-built, information-rich pages. Both are held back by the same two things: weak SEO structure (57 and 43) and near-absent social presence (33 and 17). That is a coherent diagnosis, not a random spread of numbers, and it points the roadmap straight at the SEO and Social disciplines rather than at the parts already working.

Note also that neither site was misclassified. Because detect_niche() places magnetics/magnets at priority 2 with ten magnet-specific keywords — well ahead of marketing/advertising at priority 7 (Chapter 7) — a magnet company classifies as magnetics, not as “marketing” because its H1 happens to mention promotion. That ordering fix is exactly what a hard technical niche stress-tests.

The exact page facts it read

The best evidence an audit is real is that it cites the specific signals it pulled from the page. The report for multipolemag.com does exactly that:

Every one of those facts is checkable by hand against the live page — which is the point. Trace two of them to their scores: the title at 79 characters is well over the 40–60 the SEO discipline wants, which is part of why SEO sits at 43; and “social profiles: none” is why Social is 17 and stays 17, rather than being quietly inflated with a fabricated sameAs (Chapter 10). The report ends with its disclaimer, verbatim: “Every number on this page comes from a real fetch of multipolemag.com — nothing is invented.”

The number climbing over two days

This wasn’t a single snapshot. The score history in the workspace shows this site’s audited overall climb as fixes shipped:

A move from 54 to 60 is modest and honest — exactly the kind of real gain a couple of shipped fixes produce on a page that was already technically sound. The full timestamped version of this climb, with the FAQ-schema ship marked in the log, is the subject of Chapter 43.

How to reproduce this audit — step by step

1. Plain English: Open the branded report for either guide directly — e.g. deptmatic.com/api/report/multipolemag.com — and read the five discipline scores and the signals block against the live site.
2. To run a fresh audit yourself, use the free audit on automarketingengine.com with a magnetics URL and confirm the niche comes back as magnetics, not marketing.
3. Check three cited facts by hand — view the title length, count the H1/H2s, look at the sitemap — and confirm they match the report.
4. Under the hood: the audit is /analyze → score_site() for the discipline scores and detect_niche() for the classification; the shareable page is rendered by render_report_html() at /report/<domain>. The three department concepts built on top — a “departure board,” an “engineer’s brief,” and a “wonder-first” site — live at real subdomains, not slides.

Ship-and-rollback, proven end to end

The single most important proof in this manual: the engine has demonstrably shipped a real change to a live site and rolled it back — logged, timestamped, with the snapshot files still on disk. This is what makes “reversible by construction” a fact, not a promise.

Every other chapter rests on this one. If the engine could not actually put a change back, the approval gate would be a comfort, not a safety, because the first bad ship would be permanent. So this chapter does not describe the capability — it shows the capability having already run, under real conditions, on a live site, with the evidence still sitting in the datastore and on the host’s filesystem.

The mechanism, in one paragraph

Shipping is two functions: ship_deliverable() and rollback_deliverable(), exposed at /ship and /rollback. Ship copies the current live file into a timestamped backup with shutil.copy2, then writes the approved change. Rollback copies the snapshot back. Because the snapshot is taken before the write, reversibility is structural — there is no code path that changes a live file without first preserving what was there. Shipping is whitelisted to the operator’s own test beds; a client store goes through the platform’s own API on the same approve-first terms.

The proof: a ship and its rollback, two seconds apart

This is the load-bearing evidence — the actual log lines from the multipolemag.com workspace, showing a real change shipped to a live site and then reversed:

Read the two timestamps: 11:16:43 and 11:16:45. A change went live and was restored two seconds apart, on a real site, with the event recorded both times. That pair is the entire safety model working under real conditions — not a described feature, an executed one. And the FAQ-schema deliverable (s9) shows the other half: a fix that shipped and stayed, with the exact backup file it can be restored from named on disk.

The number moving, with timestamps

The strongest proof isn’t a claim of improvement — it’s the improvement happening in the log. The multipolemag.com workspace keeps a score_history, and it records the overall score climbing as fixes shipped over three days. This is not a projection or a mock-up; it is the datastore’s own timestamped record.

Trace the causation: the overall sits at 54–55 on the 9th, then jumps to 60 the moment FAQ-schema ships on the 10th, and settles at 64 by the 12th as more fixes land. Each value is a real re-audit written to disk at the time shown. You are not being asked to believe the fix helped — you are being shown the score before it shipped and after, with the ship in between.

At scale — this is not a demo

The evidence is not one lucky site. The engine’s own datastore shows the breadth of real work — counted from the files on disk, not claimed:

Two hundred seventy-three sites audited, twenty-four fixes shipped to live production, every one of them reversible — with the snapshots to prove it. Notice the ratio: 2,719 deliverables produced against 24 shipped. That gap is the approval gate doing its job. The department drafts prolifically; a human approves sparingly; and only the approved, shipped changes leave a backup. That is the difference between a working system and a slide deck.

How to verify it yourself — step by step

1. Plain English (no host access): Open the case files — the score deltas at d.deptmatic.com (Chapter 41) and the climbing history at c.deptmatic.com (Chapter 42) — and read the same timestamped movement summarized above.
2. Open a shareable report at /report/<domain> for a shipped site and confirm the current score matches the last entry in its history.
3. With host access: list the backup folders — ls /opt/autoengine/ship-backups/*/ — and confirm real timestamped .bak files exist (56 folders / 83 files at time of writing). Each one is a live rollback point.
4. Under the hood: a ship is ship_deliverable() via POST /ship (snapshot then write); a reversal is rollback_deliverable() via POST /rollback (copy the snapshot back). The score movement is fresh /analyze runs appended to the workspace’s rolling score_history.

Network readiness at scale

Beyond individual case studies, the engine’s discipline shows up across the whole network it runs on. The Agents-First readiness audit — the same AI-reader criteria the engine scores — puts nearly every network site at the top of the scale.

A case study proves the loop closes on one site, or six. This chapter answers a different question: does the discipline hold at scale, across a whole portfolio, or does quality quietly decay once you are past the showcase examples? The answer is measured, not asserted — there is a readiness file, scored across the network, and it reads the way you would want.

The readiness numbers

The Agents-First readiness audit scores each site against the AI-reader criteria: can an agent find, read, and cite this page? Across the network, the result is near-uniform excellence.

138 of 142 sites at a perfect Agents-First readiness score is the network living its own advice: the AI-reader surfaces the engine recommends — llms.txt, AGENTS.md, clean schema, deep sitemaps — are actually present, site after site. This is the portfolio the engine was proven on before it was ever pointed at a client, which is why the manual can show measured results rather than projections.

Two scales, and why they differ

It is important to read this honestly, because there are two different numbers in play and they are not the same scale. The Agents-First readiness score (138 of 142 at 100) is a focused check of AI-reader surfaces. The engine’s own /analyze overall is a broader five-discipline roll-up that also weighs SEO structure, Content depth, Social presence, and measured Reach — and it is deliberately harder to max out.

The same site reads 100 on Agents-First readiness and 75 on the engine’s own overall — and that is not a contradiction, it is the caps and the broader scope doing exactly what Chapter 6 says they do. A site can be perfectly readable by agents and still have room to grow on the full scorecard. An audit that returned 100 on both would be the fabrication the engine exists to avoid.

It’s the same machinery as your free audit

The crucial fact: the network audit and the prospect’s free audit are the identical endpoint. The Agents-First audit is a real API call — POST automarketingengine.com/api/analyze returning live 0–100 scores — the same call the onboarding form makes. There is no separate “network mode” and no “demo mode.” The audit a prospect runs on their own site is the exact machinery that scores the network.

When that endpoint read wholetech.com, it returned real signals — not simulated ones:

Every one of those is a fact about the live page, checkable by hand. A page with 3,969 words, three JSON-LD blocks including FAQPage and Organization, a 396-page sitemap, and both AI-reader files present is precisely why it scores 100 on Agents-First readiness — and the engine cites the facts rather than the conclusion.

How to check the network scale — step by step

1. Plain English: Run the free audit at automarketingengine.com on any flagship domain (say wholetech.com) and confirm you get real signals and a real overall — the same audit that produced the readiness numbers.
2. Compare a second site. The signals change with the page — word count, schema types, and sitemap size differ — which is the tell that nothing is canned.
3. Cross-reference the live installed-base worksheet at wholereach.com/alldomains, where every domain the engine runs on is listed with its scores (Chapter 45, Track C).
4. Under the hood: the readiness audit and the free audit are one endpoint — /analyze → score_site() — and the network-wide runs are driven by /run-daily over the whole portfolio (run_daily_all()). One machine scores the network and the prospect alike.

Test it yourself: a protocol for humans and agents

Proof you can reproduce beats proof you have to believe. This chapter gives two runnable test tracks against the live system — one for a person, one for an agent — plus a third that measures real-world lift over time, and the pass criteria that together demonstrate the engine reads real pages, refuses to invent, gates on approval, and reverses cleanly.

Run either track, or both, or all three. Nothing here mutates a site you don’t own: the audit is read-only, and the only write path (ship) is whitelisted to the operator’s own test beds (Chapter 9). Everything below hits public endpoints. Treat this as an acceptance test — if a step fails, that is a real finding; note it and file it, don’t wave it away.

Track A — the human test (browser, ~10 minutes)

No tools beyond a web browser. Each step states what to do and what a pass looks like.

Pass all seven and you have confirmed, by hand, the four core claims: it reads the real page (A2), it’s deterministic (A3), it refuses to fabricate (A4, A5), and it keeps a human in control (A7). For A5, the exact facts you should see rendered are the ones cited in Chapter 42 — title length 79 chars, homepage words 1023, H1/H2 1/4, sitemap URLs 35, JSON-LD blocks 2 — so you can check the report against a known-good reading.

Track B — the agent test (shell, scriptable)

For an AI agent or an engineer with curl and jq. These are assertions, each with a command and an expected result. An agent can run them in sequence and emit a single pass/fail table.

Track C — measuring success over time (AWStats)

Tracks A and B prove the engine works. Track C proves it helps — the outcome that actually matters. The engine’s sixth discipline, Reach, is measured from real AWStats traffic (Chapter 6), so the honest success metric is simple: after the engine ships fixes, do the numbers move in the weeks that follow?

The method is a clean before-and-after: record the baseline (audit scores + the last full AWStats month) before any fix ships; ship the approved fixes; then compare the next full month. The lift is real because Reach is measured, and the engine refuses to fabricate it (Chapter 10) — an unmeasured month reads as unmeasured, never as a flattering guess. Chapter 43’s multipolemag.com history is a worked example of the second row of this table: overall 54 → 55 → 60 (FAQ ships) → 62 → 64 across three days.

The scorecard — which test proves which claim

Together, the three tracks test every load-bearing claim in this manual — that it works (A, B) and that it helps (C). Map them to what they prove:

How to run the whole protocol — step by step

1. Pick your track. A human with ten minutes runs Track A in a browser; an agent or engineer runs Track B in a shell; anyone measuring outcomes over weeks runs Track C.
2. Run in order and record each result against its pass condition. For Track B, capture the actual JSON value next to each assertion so a failure is legible.
3. Emit the scorecard. Map your passes onto the claim table above; a clean run lights up all five claims.
4. Under the hood: every step here hits one of the real public endpoints — /analyze for the audit and signals, /report/<domain> for the shareable report — the same machinery documented in Parts II and VII. B7 is the only step that touches the host filesystem.

Running and restarting the service

The engine is a systemd service. Administering it is ordinary systemd — start, stop, restart, check status, read logs. If you have ever kept a Linux service alive, you already know how to run this one.

This is deliberate. The backend (Chapter 4) is a single Python file on the standard library, bound to loopback, running under systemd. There is no application server to tune, no worker pool to size, no framework lifecycle to learn. The whole operational surface is the handful of commands below, and this chapter turns them into a real runbook: what to type, what a healthy answer looks like, and what to do when the answer is wrong.

The four commands you actually use

Everything routine is one of these. They are the verified service-control commands from the source manual — commit them to muscle memory:

Why it binds to loopback

The engine listens on 127.0.0.1:8932 — the loopback address — so it is never exposed to the internet directly. A reverse proxy sits in front of it and serves it publicly. The practical consequence for an administrator: you test it locally, on the host, and let the proxy handle the public side. A curl to 127.0.0.1:8932/health from the box itself is your ground-truth liveness signal; if that answers but the public URL does not, the fault is in the proxy layer, not the engine.

It self-heals — but code changes do not

Because the unit is configured Restart=on-failure, a crash restarts itself automatically. You generally will not have to nurse it back up after a fault. The one thing that is not automatic is picking up new code: editing server.py changes the file on disk but the running process is still the old one in memory. A manual systemctl restart autoengine is what swaps it in. This is the single most common administration mistake — a change made, but never restarted, so nothing appears to happen.

How to use it — step by step

The standard “I changed the backend, now make it live” sequence, start to finish:

1. Confirm current state. Run systemctl status autoengine. You want to see active (running). Note the PID — it should change after your restart, which is how you confirm the new code is loaded.
2. Deploy the change. Following the discipline in Chapter 49, edit the generator or script, copy it to the host, and put the new /opt/autoengine/server.py in place — never hand-edit a file a cron will overwrite.
3. Restart. Run systemctl restart autoengine. Re-run systemctl status autoengine and confirm the PID is new and the state is active (running).
4. Prove it’s alive. Run curl -s 127.0.0.1:8932/health on the host. A healthy engine returns {"ok":true,…}. This hits the engine directly, bypassing the proxy.
5. Prove it’s serving. Confirm the public path works too — e.g. a real audit via /analyze (Chapter 5) or the /report/<domain> page. If the local health check passes but the public one fails, the problem is the reverse proxy, not the engine.
6. If it won’t start: read the logs with journalctl -u autoengine -n 100. A Python traceback at the tail almost always names the file and line — a syntax error in the freshly deployed server.py is the usual culprit. Fix, redeploy, restart.

The sibling service

The launch/intake and domain-check API runs as its own unit, autom-api.service. It is administered identically — substitute the name in any command above:

The daily cron

The department produces fresh work every day without anyone pressing a button. That is daily-run.sh, on a midnight cron. It is the automated half of the loop — and the approval gate is still the human half, so “produced” is never “published.”

Chapter 2 described the loop — audit, draft, approve, ship, measure — and Chapter 23 named the Manager Agent as its executive face. This chapter is the machinery underneath that face. The reason the Manager view can show a “what got done” list every morning is that a scheduled job did the work overnight. As an administrator, your job is to know what that job runs, when, and how to confirm it fired.

What runs on its own, and what never does

This is the distinction that keeps the automation safe, and it is worth stating precisely. Seven roles produce automatically on the schedule. Publishing of most of that work can be set to automatic, per role, in the Set Up phase. But two things are never automatic, by design:

What the daily run does, and what it feeds — illustrative

Picture the morning after a midnight run on a small portfolio. Each site’s workspace has fresh entries; the Manager view rolls them up into its four stat cards and its “what got done” list. An illustrative view of the aftermath:

How to use it — step by step

You mostly leave the cron alone; it just runs. The administrator’s real tasks are confirming it fired, reading its output, and running it on demand.

1. Confirm the schedule exists. The job is a cron entry that invokes /opt/autoengine/daily-run.sh at midnight CT. Inspect the crontab where it is registered on the host to confirm the line is present and the time is right.
2. Confirm last night’s run happened. The cleanest evidence is in the data: a site’s workspace at /opt/autoengine/workspaces/<domain>.json carries new dated deliverables and a fresh score_history entry after a run (Chapter 8). New, dated work is proof the job fired.
3. Read it as a human. Open the Manager view (Phase 3 · Operations). The “what got done” list and the “awaiting approval” count are the human-readable face of the overnight run.
4. Run it on demand. You do not have to wait for midnight. The engine-side action the cron performs is exposed as the /run-daily endpoint, which runs the department’s daily production for one site or the whole network — the same mechanic, triggered by hand. Under the hood this drives the per-site and network daily production (the run_daily_ws() / run_daily_all() functions).
5. Then approve. Move to Approvals & Setup and work the queue the cron filled. This is the human half of the loop the automation deliberately leaves for you.

Refreshing the skills library

The 47 skills and 427 prompts are regenerated on a weekly cron and synced to every property in the family. The one thing to know as an administrator: the order is not arbitrary — the skills generator reads the JSON the prompts generator writes, so prompts must be built first.

Part V documented what the library is: 47 SKILL.md files across seven categories (Chapter 29), and 427 ready-to-paste prompts on top of them — 235 skill prompts plus 192 vertical prompts across 24 industry packs (Chapter 30). This chapter is how that library stays fresh and consistent across every front door in the family. It is a small job with one load-bearing rule, and getting that rule wrong produces a subtle, misleading bug rather than a loud failure — which is exactly why it deserves its own chapter.

Why the order is load-bearing

Read the two steps again as a dependency, not a sequence. The prompts generator writes ame-prompts.json — the file that holds the 47 keys of skill prompts. The skills generator then reads that JSON to build the in-app library (this is gen-ame-skills.py → the Marketing Skills tab). If you run the skills generator first, it reads yesterday’s JSON — or none — and a mirror ends up showing a stale prompt count against a fresh skills list. Nothing crashes; the numbers just quietly disagree.

What “synced to the family” means

After the two generators run, the refresh copies the built prompts/ and skills-preview/ directories out to the family mirrors — the editions and builds documented in Part VI. This is why the flagship and every edition show the same library at parity (Chapter 34): one build, copied out, rather than each site maintaining its own. The verified counts a healthy refresh should reproduce everywhere:

How to use it — step by step

Like the daily cron, this mostly runs itself on Mondays. Your tasks are verifying a refresh landed, running it on demand after a change, and — above all — preserving the order when you edit the script.

1. Confirm the weekly job exists. Check the crontab entry that invokes /root/ame-refresh.sh on Monday mornings.
2. Run it on demand. When you have changed a skill or added prompts, run ame-refresh.sh by hand rather than waiting for Monday. It will regenerate prompts, then skills, then copy out to the mirrors — in that order.
3. Verify the counts agree. Open the Marketing Skills tab and the Prompts tab on the flagship and confirm 47 skills and 427 prompts. Then spot-check one mirror — the counts must match. A mismatch is the order bug; re-run with prompts first.
4. Confirm attribution survived. The Skills and Prompts pages must still carry “Skills adapted from coreyhaines31/marketingskills (MIT).” The library is MIT-licensed and the attribution is required (Chapter 32).
5. When editing the script: keep gen-ame-prompts.py before gen-ame-skills.py, always. Edit the generators, not their JSON output — the same discipline as everywhere else in the network (Chapter 49). A hand-edited ame-prompts.json is overwritten on the next run.

Upgrading the engine safely

The engine is meant to grow — more live analyzers, more niches, more checks. Here is how to add each without breaking what runs, following the patterns already in the source. The rule that governs all of them: an upgrade that weakens the three commitments isn’t an upgrade, it’s a regression.

Three kinds of change come up again and again: promoting a skill from a playbook into a live analyzer, adding a niche to the detector, and adding a check to the score. Each has a settled pattern in the source, and each has a way to get it wrong that quietly costs the engine its honesty. This chapter is the runbook for all three, plus the deployment discipline that ties them together.

To promote a skill to a live analyzer

This is the path CRO, Analytics, Paid Media and Market Research already walked — from “critical, coming” (red) to live (blue). The move has three parts, and one guard that must not be skipped:

1. Write the builder. Add a <role>_recos(d, niche) function that reads real fields from sig — the same signal dictionary every other analyzer reads (Chapter 5). Model it on the existing four: cro_recos(), paid_recos(), analytics_recos(), research_recos().
2. Wire it in behind the guard. Return it from seo_aiso() behind the reached guard, so it honors the fabrication rule. When the page wasn’t reached, it must inherit the honest note, not produce output.
3. Add its view to the app. Give it a named view so the human-readable side matches the new capability.

An illustrative before/after of what promotion changes for a role:

To add a niche

Niche detection (Chapter 7) scores sixteen niches by whole-word keyword matches; highest score wins, ties go to the earlier entry. To add one:

1. Add a (label, keywords) tuple to the NICHES list — in priority order, because position matters.
2. Place specific ahead of general. Earlier niches win ties, so a specific niche must sit ahead of a broad one. This is exactly why magnetics sits at priority 2, ahead of marketing at priority 7 — the ordering fix that stopped a magnet company being mislabeled “marketing” (Chapter 7).
3. Give it enough distinctive keywords to score reliably against neighbors — a thin keyword set loses ties it should win.

To add a check

Scoring (Chapter 6) is a set of registered checks that roll up per discipline. To add one:

1. Register it inside score_site() with add(area, label, ok, why, fix, weight) — area is its discipline, ok is pass/warn/fail, and it automatically joins that discipline’s roll-up.
2. Respect the headroom cap. A new check must never let a first audit reach 100 — every category is capped at 90 on a first audit by design (“never a 100 on a first audit”). A check that could push past that would break the honesty of the number.

The deployment discipline

Every change above ships the same way. This is the reliable pattern across the whole network, and it exists because a cron will happily overwrite anything you hand-edit:

1. Edit the generator, not the output. Never hand-edit a generated file — a scheduled job (Chapters 47–48) will overwrite it and your change vanishes.
2. Write the change as a script, copy it to the host, run it, and verify live.
3. Restart autoengine after any server.py change — the running process holds the old code until you do (Chapter 46).
4. Keep the editions at parity. An essential, safe upgrade to the flagship propagates to the mirrors, so no front door drifts behind (Chapter 34).
5. Prove it with a real audit. Re-run /analyze on a known site and confirm the new analyzer/niche/check behaves — and that an unreachable URL still triggers the honest note.

The upgrade philosophy

Every upgrade must preserve the three commitments from Chapter 1: read the real page, gate on human approval, keep it reversible. A change that weakens any of the three isn’t an upgrade — it’s a regression, however much it adds. The roadmap ahead is exactly this, done repeatedly and carefully: promote more skills from playbook to live analyzer, one at a time, the same path the critical four already walked — each one wired behind the reached guard so the engine can grow without ever learning to lie.

The opportunity — and why it works

There is a large, growing market of small businesses that need marketing, cannot do it themselves, and do not trust the tools that promise to help. This engine removes exactly the thing they are stuck on — and it does the work at a cost so low that the margin is where a software company lives, not where an agency lives.

The market is big and growing fast

Every one of these is compounding at double digits. We do not need a large share of it — a few hundred small businesses is a real company.

The customer is stuck — and knows it

This is the heart of it. In a survey of more than 1,300 small-business decision-makers, the pattern is unmistakable:

Source: Constant Contact "Small Business Now", Apr 2024. Read the four numbers together: no time, no confidence, need customers, can't choose channels. That is the exact job this engine does — it chooses, it drafts, it publishes, it measures, and it never asks them to become a marketer.

Why the margin works: the arbitrage

Agencies do this work with people, so their delivery margin runs about 50% when healthy (Swydo benchmark). Software companies do it with code, so their gross margin runs 76–80% (Aleph × Benchmarkit 2025/26). AI is now compressing agency delivery time 3–4× (Productive.io survey of 180+ agencies, via Search Engine Land).

And we can prove the work is real

This is not a promise — the proof is already in this manual. Chapter 41 shows six home-building sites measured before and after; Chapter 42 shows two magnetics guides audited live; Chapter 43 shows ship-and-rollback proven end to end. And the honesty guards mean we can put the engine in front of a skeptical buyer without fear: it states only what it can verify, and says so when it can't. A low score you can trust beats a high one you can't — and that candor is the whole sales advantage over the "AI slop" tools the market is already tired of.

The revenue model

One model, four ways in. We sell a flat monthly done-for-you service — a fixed outcome for a fixed price — and we meet each kind of customer at the price their world already pays. The prices below are set from the market data; each carries the evidence for the number.

Why flat monthly, not hourly

The fast-growing structure in this space is the productized subscription: a fixed monthly deliverable, no time-tracking, no scope arguments. Agencies "start with hourly retainers, but as they grow they shift toward subscription models because they're easier to standardize and scale" (ManyRequests). It also closes fast: SMB deals under $5K close in days, not months (Focus Digital). And the broader tailwind is real — the subscription economy hit ~$3 trillion in 2025, up from $2T in 2023 (Swell).

The four tiers

Prices are illustrative starting points (EST), defensible from the sources shown — set the final number per engagement.

Which door first

All four are open, but the order that fits our warm assets: Command for the builder and magnetics relationships (the case studies already exist), Growth for the broad SMBs the free audit will surface, and White-label as the multiplier — one agency partner can bring ten clients without ten sales conversations. Presence is the on-ramp that turns a free audit into a paying "yes" at a price nobody argues with.

How we make money — the economics

The reason this works is that adding a client costs almost nothing. The engine is already running; one more client is one more config entry and a couple of hours of setup. That is why a service can earn a software margin.

What one client actually costs us

The fixed cost of the whole operation is tiny: the publishing hub is $24/mo and the engine runs on a flat AI subscription that covers every client at once (the engine is template-driven and token-free, so audits and scale don't run the bill up — see the honesty guards and the subscription-ceiling design). One Growth client covers the entire monthly infrastructure. Everything after that is mostly margin.

Why clients are worth far more than they cost to win

Two facts decide this. First, a retainer roughly halves churn versus project work — retainer clients stay ~56 months on average vs ~24 for project work (ANA/4As tenure data, via Ravetree). Second, the cheapest customers come from referrals at ~$150 acquisition cost (Phoenix Strategy).

The healthy-business bar is LTV:CAC of 3:1 (Genesys Growth). We clear it by a wide margin because delivery is cheap and retention is long.

What the ramp looks like

Illustrative (EST) at the tier prices in Chapter 51; margins reflect the ~90% unit economics above. The point is the shape: because cost per client is near zero, revenue and margin rise almost together.

How it runs — the customer, the delivery, the workload

From the customer's side it feels like hiring a marketing department that never misses. From our side it is mostly the engine running itself, with a light human hand on the parts that matter. Here is exactly how both sides work.

What the customer experiences

1. They get a free audit. We (or they) run their site through the engine and hand them a branded scorecard at /report/<domain> — real findings, honestly scored.
2. They say yes and we onboard them. We connect their accounts and set up their profile; they answer a few questions about their goals.
3. Work starts appearing. The engine drafts posts and fixes from their real facts and schedules them.
4. They approve from their phone. On the managed tiers a private link shows a tidy queue — Approve, Edit, Skip. Nothing goes out without a yes (or, if they choose, it runs hands-off).
5. They get a monthly report showing what published and how it did. That is the whole relationship: a steady, on-brand presence they never have to think about.

How we deliver it (automation-max)

The engine does the heavy lifting: the Auditor scores the site, SEO Manager and Content Desk draft the work, the publishing system posts it and reads the results. Our job is oversight, not production — we review, we tune, we keep the client happy. The setup that made this book possible is the product: we run our own marketing on it, and we run theirs on the same rails.

How much work it actually takes

This is where automation-max + the Human Desk pays off: you keep your own time minimal and dispatch onboarding and monthly-review work to hired help as it grows. The engine scales for free; the only thing that scales with headcount is the light human touch — and that is exactly the kind of task the Human Desk exists to absorb.

Getting customers — turning it on now

We already own every tool we need to fill the pipeline. The trick is to point the engine at our own growth first — the best proof that it works is using it to sell itself.

The acquisition engine

The 90-day turn-on plan

1. Weeks 1–2 — light the funnel. Put the free audit front and center on the marketing site; switch the self-driving social system to post our own proof daily (it's already live). Write the one-page offer for each tier.
2. Weeks 2–4 — land 2–3 pilots from the warm network. Start with the builder and magnetics relationships where the case studies already fit — a Command pilot each — and one or two Growth pilots from audits.
3. Month 2 — turn pilots into proof. Publish their before/after as new case studies; ask for referrals; put the monthly report in their hands.
4. Month 3 — add the multiplier. Sign one agency onto white-label; open the Presence on-ramp for the steady stream of free-audit leads.

Pricing — built up from cost, not down from a number

This chapter exists because the prices on the sites today were guesses. A number chosen because it sounded fine — $420, say — is not a revenue model; it's a placeholder waiting to be replaced by arithmetic. So this chapter does the arithmetic. It accounts for every cost we carry — the AI tokens, the people we hire, the servers, the per-post platform fees, and the cut the card networks take — and only then arrives at a price. Every figure below carries a source you can open. Nothing here is pulled from the air.

The one rule: price is a cost floor plus a margin, never a vibe

There are two ways to set a price. The wrong way is to think of a number that feels reasonable and hope it covers the work — that is how you end up with $420 because someone likes the number. The right way is to add up what it actually costs to deliver the thing for one month, decide what margin the business needs to be healthy, and let those two facts produce the price. Cost floor divided by (one minus target margin) equals price. If serving a client costs us $75 a month and we want an 85% gross margin, the price is $75 ÷ 0.15 = $500. That is not a guess; it is a consequence. The rest of this chapter builds the cost floor honestly, so the prices at the end are consequences too.

The reason this matters more for us than for a normal agency is that our cost structure is unusual. A traditional agency's cost is mostly human hours, so its price has to be high and its margin is thin. Our engine does the production work that those hours used to buy, which pushes our real cost per client dramatically lower — but only if we price deliberately. Priced by feel, we would either leave most of that advantage on the table (charging too little) or quietly lose money on a tier whose costs we never added up (charging too little in a different way). The whole point of a costed model is that we always know which side of the line we are on.

The complete cost stack — every line, with real numbers

Here is everything it costs to run this business, separated into the costs that scale with each client and the fixed costs the whole operation shares. Read the table first, then the paragraphs that explain the parts that surprise people.

Tokens are the line everyone worries about, and they are the line that matters least — as long as we hold one rule. A large language model charges by the token: so much per million tokens of input, so much per million of output. If we generated every social post by calling a model fresh each time, a typical post (a couple of thousand tokens of context in, a few hundred out) would cost roughly two cents at Opus-tier pricing, and prompt caching, which bills repeated context at about a tenth of the normal rate, would push that lower still. Two cents times even a few thousand posts a month is a rounding error. But our engine does not work that way: it fills deterministic templates with verified facts, so it makes no per-post model call at all, and the marginal token cost of a post is genuinely zero. The AI spend we do have is a flat subscription — a fixed monthly plan that covers building the engine, maintaining it, and any generative features, for the whole network at once. That is the rule that keeps tokens from ever becoming a problem: we buy a flat plan with a known ceiling; we never let cost scale linearly with usage through per-token API billing. Token cost is therefore a step, not a slope — when total generative use across all clients approaches a plan's ceiling, we add another flat plan (another ~$200 step), and one such step covers on the order of ten thousand AI-generated posts a month. A pricing model that "pays for tokens" does so by funding that flat subscription out of a base fee, not by metering pennies per post.

Human oversight is where the arbitrage lives, so it deserves an honest number. The industry benchmark for delivering a social-media client the ordinary way is ten to fifteen hours a month for a basic account and twenty to thirty for a busy one — and at a real billable rate that is most of why agencies charge what they charge. Our model is different in kind, not degree: the engine writes and schedules and publishes, so the human is not producing the work, only overseeing it — reviewing the queue, tuning a template, sending the monthly report. That is roughly one to two hours per client per month. At an offshore assistant rate of about $11–17 an hour, or a US rate of $20–25, that is somewhere between fifteen and forty dollars of labor per client per month, against an industry baseline ten to twenty times higher. This is the number that makes a software margin possible on a service, and it is exactly the work the Human Desk is built to absorb as we scale.

Payment processing is the sleeper cost. It is easy to forget that the card networks take 2.9% plus thirty cents of every charge, but at our price points that is often the single largest line in the cost stack — bigger than the labor. On a $995 monthly charge, Stripe takes about $29; on a $2,495 charge, about $73. It scales with the price, so it never goes away as we grow. The lever here is real and worth stating: Stripe's ACH bank-transfer rate is 0.8% capped at five dollars, so steering larger managed clients onto bank payment instead of card cuts that $73 to $5. For a premium tier, that is most of a point of margin recovered with a single billing choice.

Infrastructure is nearly a fixed cost, which is the quiet good news. The publishing hub is a $24-a-month server; the main server that holds the network data is one we already run. Neither grows meaningfully when we add a client — one more client is one more entry in a configuration file, not one more server. So the whole fixed base of the operation — the hub plus the flat AI subscription — is a couple hundred dollars a month total, and it is shared across every client. Divided over five clients it is a real per-client cost; divided over fifty it is almost nothing. This is why the cost-to-serve falls as we grow, the opposite of an agency, where each new client needs new hours.

What one client actually costs us

Put the lines together for a representative managed client — call it the Growth level: roughly ninety published items a month across four networks, with X capped at a few paid posts a day and everything else free, billed at $995 and reviewed for about ninety minutes a month.

The shape of that readout is the whole business in one panel. The largest costs are the ones that scale with the price (payment processing) and the ones that fall as we grow (infrastructure), while the cost that a normal agency lives and dies by — human production labor — is nearly absent, because the engine carries it. That is why the margin sits around ninety percent, and why the honest thing to do is price for that reality rather than pretend we have an agency's cost structure and charge like one.

Every pricing model on the table — and how each fits our costs

There is more than one honest way to turn that cost floor into a price. Each of the standard models maps onto our cost structure differently, and it is worth walking all of them rather than defaulting to the first one that comes to mind — because the right answer, at the end, is a deliberate blend of a few.

The recommended model: a volume-based subscription, built up from cost

Putting that together, the model that fits both what the market pays and what it costs us to deliver is a volume-based subscription: a base subscription that includes a monthly volume of published items, priced so that every tier provably covers its own cost stack with margin to spare, with add-ons and overage for anything beyond the included volume. The metered unit is the thing that actually drives cost — a published item (a social post, a page, an email), which we can also call a content credit. Cost per additional item is tiny (near-zero tokens, a few cents of X at most, and a sliver of oversight), so an item priced at a few dollars carries an enormous margin while still reading as fair.

Here are the tiers, each built from the cost stack above rather than chosen for how the number sounds. The cost-to-serve column is the arithmetic; the price is that floor lifted to a healthy margin; the margin column proves the tier is sound.

Prices are illustrative starting points (EST), each defensible from the cost stack and the market data in Chapter 51. Final numbers are set per engagement, but they start here, from arithmetic.

How this model pays for tokens. The base subscription of each tier funds the flat AI subscription — the bounded, whole-network plan described above. Because generation is deterministic today, the tiers carry essentially no token cost; and even if we switched to per-post AI writing, the roughly two-cents-per-post cost across a tier's included volume is a dollar or two a month, buried inside a margin of ninety-plus percent. The model never exposes us to per-token API billing, which is the only way tokens could ever threaten the budget. If generative volume across the whole network ever approached a plan's ceiling, the fix is a second flat plan — a known ~$200 step, funded by the base fees of dozens of clients, not a runaway meter.

How this model pays for the humans we hire. Each tier's price is set above the oversight hours that its volume implies. The Presence tier assumes about an hour of review a month; Growth about ninety minutes; Command a few hours plus custom-content attention. At the blended assistant rate from the cost stack, those hours are $15 to $45 of labor, and every tier's price clears that many times over. As we grow, the Human Desk absorbs those hours at the offshore rate, and the model's margin is what pays for them — which is exactly why the margin is designed in, not hoped for.

Guardrails so the model stays honest

A costed model only stays honest if it is defended. Four rules keep it that way. First, a margin floor: no tier or custom deal is priced below a set gross margin (a 70% floor is a reasonable line given the cost stack), which means every price must be checked against its cost-to-serve before it goes out — the discipline this whole chapter is about. Second, the subscription-only rule: AI spend is always a flat, bounded subscription, never per-token API billing that scales with use; token cost stays a step, never a slope. Third, a quarterly re-costing: the numbers here are sourced as of this writing, but labor rates, X's per-post fee, and processing rates drift, so the cost stack is re-run each quarter and prices are confirmed against it. Fourth, replace the placeholders: the arbitrary numbers currently on the sites — the ones chosen because they sounded fine — are superseded by the tiers above, and should be updated everywhere they appear so the whole network quotes one costed, defensible price.

Setting up shop in Austin — the company behind the engine

The engine is software, but the company that sells it is a real business with real overhead: a fleet of computers that runs it, storage and networking that hold it together, a media operation that produces the shows and community that draw customers, and a headquarters in Austin to house all of it. This chapter accounts for those costs with real, current, sourced prices, and it sets a clear headquarters strategy: keep fixed overhead low, anchor a professional Austin presence cheaply while the business scales, and expand into dedicated space only as revenue supports it. There is also a practical forcing function — the company has accumulated a large inventory of production and computing equipment that needs a permanent, organized home, which argues for a space with real square footage rather than a token office.

The vision: a marketing company that is also a media house

The company is two things at once, and the Austin setup has to serve both. It is the automated marketing company — the engine, the publishing hub, the clients — which needs compute, storage, network, and a small team. And it is a media house — podcasts, video shows, webinars, Zoom rooms, streamed events, and the online communities those things gather. The media side is not a hobby bolted on; it is the customer-acquisition engine from Chapter 54 made physical. Building an audience in public, producing case-study content, hosting a community — that is how a marketing company proves it can market. The HQ is the platform that runs the software, produces the media, and houses the people.

What we already own — the asset base

The most important fact about this setup is that a large part of it is already bought. Years of accumulated equipment mean the media operation is, in capital terms, mostly funded already — the job is to organize and refresh it, not to purchase it from scratch. Valued at what the equivalent gear costs new today, the asset base looks like this:

Add it up and there is, conservatively, $40,000–60,000 of equipment already in hand — most of it the exact gear a media house would otherwise have to buy. That changes the whole shape of the setup budget: the studio is not a purchase, it is an assembly and finishing job, and the capital can go toward the space and the compute refresh instead. This owned base is the single biggest reason the Austin setup is affordable.

What has to be replaced — the compute refresh

The one part of the asset base that is genuinely at end of life is the compute fleet. The three M1 Mac minis are underpowered for current local-AI and production work, and the roughly nine first-generation Beelinks are aging out. These run the engine across the network and will need replacing on a rolling basis — not all at once, which spreads the cost. At current prices:

That is a ~$15,000–20,000 refresh, phased over time — not a day-one check. The storage and network are recent enough to keep; budget a little for expansion (more NAS-grade drives as the media archive grows — note drive prices are up ~12% year-over-year on a component shortage) and for the extra access points and a switch the space will need. Call the compute-and-network refresh ~$18,000–25,000 all in, spread across the first year or two.

The headquarters — keep fixed overhead low

The governing principle for the Austin HQ is simple: keep the fixed monthly overhead low so that the company's break-even stays far below its revenue. Austin is currently a tenant-friendly market — office vacancy is elevated, which means favorable terms and generous tenant-improvement allowances for anyone who does lease. But the smarter early move is not to sign a big lease at all. It is to anchor a professional Austin presence cheaply and let revenue, not optimism, pull the company into more space.

The practical shape of that is a two-part workspace. Run the day-to-day office and the media studio from a home base — the A/V gear is already owned and central-Austin residences are home-office friendly — and keep a Capital Factory dedicated desk at $500/mo for client-facing meetings, a professional address, event space, and the Austin startup community. That gives a real downtown business presence and a foothold in the ecosystem without carrying the cost of a full commercial lease. As the client base grows and the equipment inventory needs a permanent, consolidated home, expand into dedicated space — the specific real-estate decision (own vs. lease, neighborhood, building) is a separate planning exercise tracked outside this manual.

Whatever the eventual space, two due-diligence numbers govern any shared building or condo arrangement: the ongoing monthly fee (keep it low), and any pending special assessment — a one-time levy for major repairs that can add tens of thousands of dollars overnight and is easy to miss. A low monthly fee hiding a looming assessment is not actually low. A good local commercial or condo realtor earns their commission catching exactly that.

The production studio — what the owned gear enables

Because the cameras, microphones, mixers, and lights are already owned, the studio is mostly a matter of giving them a dedicated room and the few connecting pieces that turn a pile of gear into a production. The multi-camera video shows, the podcasts, the webinars, the streamed community events, the polished Zoom rooms — the capability is bought; what remains is the assembly. The finishing pieces are modest against the value of what they complete: a live switcher to run multi-camera (a Blackmagic ATEM Mini Pro is $295, the 8-input ISO model ~$1,995), acoustic treatment for the room (~$800 a set and up), and the streaming and webinar platforms that put it online (StreamYard $45–299/mo, Riverside $19–29/mo, Zoom Webinars from $79/mo). A full pro build-out from nothing runs ~$20,000 to ~$42,000, but since the expensive layer is already owned, the incremental finishing is realistically ~$5,000–10,000 in switching, treatment, and installation.

The full cost picture

Separate the one-time setup from the monthly run cost, because they are funded differently — setup from capital, the run cost from revenue.

Keeping the HQ lean early — a coworking desk plus a home studio rather than a full commercial lease — holds fixed overhead near a thousand dollars a month instead of the several thousand a leased office would carry. On top of that sit only the tiny per-client delivery costs from Chapter 55 and the Human Desk labor. That low fixed base is what lets the business turn profitable at a handful of clients.

Payback

Revenue does the heavy lifting. From Chapter 52, the model reaches roughly $15,800 in monthly recurring revenue at about fifteen clients, at a margin near ninety percent — call it ~$14,000 a month of gross margin. Against a lean fixed overhead near $1,000–1,200 a month, that is covered many times over, which is exactly what makes it safe to expand into dedicated space later: the decision to take on more overhead is made from a position of strength, funded by proven revenue rather than hope.

The recommended phased plan

1. Now — anchor on Capital Factory ($500/mo) for an immediate professional Austin presence, meeting space, and community foothold. Run the media operation from the existing home studio.
2. Finish the studio (~$5–10k) — give the owned A/V gear a treated room and add the switcher and platforms for multi-cam shows, podcasts, webinars, and community events.
3. Refresh the compute fleet, phased (~$18–25k) over the first year or two as cash allows.
4. Expand into dedicated space only as revenue supports it — when the client base and the equipment inventory justify it, engage a local realtor to run the search, vet each building's reserve study and any pending special assessments, and keep the ongoing monthly fee low.
5. Keep the Capital Factory desk as the client-facing front door and community anchor regardless of where the studio and office ultimately live.

Protecting the work — what a competitor can and can't copy

Every operator eventually asks the same question, and it is the right one to ask: "How do we protect our code and our idea — can't someone just copy what we're doing and steal it?" The honest answer is a mix of relief and reality. No, a competitor cannot legally lift your actual code or your written copy, and no, they cannot trade under your brand name. But yes, they are perfectly free to look at what a marketing-automation engine does, admire it, and go build their own version of it. The law protects the way you have expressed your work and the things you keep secret — it does not, and was never designed to, put a fence around an idea, a feature, or a business model. Understanding exactly where that line falls is what turns a vague fear into a short, concrete list of things worth doing.

The hard truth, stated plainly

Ideas are not property. A business model is not property. "An automated engine that generates and publishes marketing pages across many sites" is a concept, and concepts belong to everyone. If a competitor studies your public sites, infers how the system behaves, and writes their own engine that does something similar, they have broken no law — that is ordinary competition, and it is the same freedom that let you build in the first place. This is not a loophole; it is the deliberate design of intellectual-property law, which grants narrow, specific monopolies over particular things and leaves the vast field of ideas open on purpose. So before spending a dollar on legal armor, internalize the reframe: you are not trying to make your idea uncopyable, because that is impossible. You are protecting three concrete assets the law does recognize — the specific expression of your work (your literal code and written content), the know-how you keep secret (the engine internals, the prompts, the data), and your brand (the names customers trust) — and then, far more importantly, you are building the kind of compounding, execution-based advantages no statute provides and no copycat can clone in a weekend.

The four legal tools — what each one really does

There are exactly four legal instruments in the intellectual-property toolbox, and each covers a different slice. The single most common mistake is expecting one of them to do a job it cannot do — expecting copyright to protect an idea, or a patent to protect a name. Read the table as a map of coverage, not as a shopping list; most bootstrapped software services need only the first three, and only two of those cost anything meaningful.

Copyright: strong, automatic, and narrower than you think

The good news is that copyright already protects your code and your written content, for free, automatically, from the instant you write it — there is no form to file to own your copyright. What registration buys you is teeth: under U.S. law you generally cannot file an infringement suit until the work is registered, and timely registration is what unlocks statutory damages and attorneys' fees instead of forcing you to prove actual dollar losses (a notoriously hard thing to quantify for software). The electronic fee is modest — $45 for a single-author single work and $65 for the standard application — which makes registering your flagship codebase and this manual a cheap insurance policy. The crucial limit to remember: copyright protects the literal text of your code, not what it does. A competitor who never sees your source and independently writes their own engine that produces similar output has copied nothing you own. Copyright stops the person who lifts your files; it does nothing against the person who merely watches your product and rebuilds the concept.

Trade secret: the one that matters most for a software service

For an engine like this, trade secret is the workhorse. It is what actually protects the parts that give the system its edge — the internal architecture, the deterministic generation logic, the template and content library, the data pipeline, the prompt engineering, and the client list — none of which is visible from the outside. Unlike a patent, a trade secret costs nothing to obtain and can last indefinitely; unlike copyright, it can cover the method and not just the text. The catch, and it is the entire game, is the word "secret." The federal Defend Trade Secrets Act of 2016 (18 U.S.C. § 1836) gives you a right to sue in federal court when someone misappropriates a trade secret — with remedies including injunctions, actual and unjust-enrichment damages, up to double (exemplary) damages for willful and malicious theft, and a three-year window to bring the claim — but that protection exists only if you took "reasonable measures" to keep the information secret in the first place. Publish it, or leave it in a public repo, or hand it to a contractor with no NDA, and there is simply no trade secret left to defend. Everything in the checklist below about access control, private repos, and NDAs is not bureaucratic box-ticking; it is the legally required act of creating the very asset you want to protect.

Trademark: the tool that actually stops copycats using your name

This is the one that answers the emotional core of "someone will steal what we're doing," because what customers actually attach to is not the code — it is the name. A competitor may build a similar engine, but they cannot call it by your product's name, use your logo, or otherwise pass their service off as yours; that is trademark infringement. You gain some rights simply by using a name in commerce, but federal registration at the USPTO makes those rights nationwide, far easier to enforce, and a real deterrent. The base fee is $350 per class of goods or services, and registration typically takes several months. The practical advice: register the trademark on your primary brand name — the flagship product name customers say out loud — rather than every sub-brand at once. The name is the flag customers rally to; it is worth planting firmly.

Patents: usually the wrong tool here — and that's fine

Patents get raised in every "how do we protect this" conversation, and for most bootstrapped software services the honest answer is: skip it. A patent can, in principle, protect a genuinely novel technical method, and it is the only tool that stops even independent reinvention. But the price is steep on every axis. Prosecuting a software patent through the USPTO commonly runs $10,000-$30,000 or more once attorney time is counted, and typically takes two to four years — by which point a fast-moving product has iterated far past whatever was filed. Software patents also face a famously high and uncertain eligibility bar, because abstract ideas and ordinary business methods are not patentable. For a lean team, that is a large sum of money and years of delay spent defending a snapshot of a system that will not sit still. It is not that patents are useless; it is that, for this kind of business, the same money and attention buy far more protection when poured into the moat described next.

The moat that matters more than any law

Here is the part that should actually put the founder's mind at ease, because it is both true and durable: the strongest protection this business has is not in a statute at all — it is in what the business has already accumulated, none of which a copycat can reproduce by copying an idea. A competitor can grasp the concept in an afternoon; they cannot conjure a live network of roughly 190 real, indexed sites that have been feeding the engine genuine performance data for months. They cannot instantly rebuild a content and template library that grew one hard-won page at a time, nor the deterministic, token-free generation engine that lets the whole network run at a cost structure a newcomer paying per-token cannot match (see Chapter 52 on the economics of the deterministic engine). They cannot buy the brand and reputation that live sites and real customers have earned, nor sidestep the switching costs that keep those customers in place, nor match the speed of iteration that comes from operating the system every single day. And they certainly cannot clone the proprietary dataset — the accumulated record of what actually works across the network — that makes each new page smarter than the last. These are compounding assets: every day of operation widens the gap. Legal tools are a fence around the yard; the moat is that the yard keeps getting bigger and more valuable while a copycat is still reading the blueprints. Execution, not paperwork, is the real defense.

The protection checklist — in priority order

Translate all of the above into a short list of things to actually do, ordered so the cheap, high-leverage items come first. Most of this is free and takes an afternoon; the two items that cost money (trademark and copyright registration) are modest and can wait until the brand and codebase are settled.

Two of these deserve a second mention because they are the ones teams skip and later regret. First, the contractor IP-assignment clause: under U.S. law, an independent contractor generally owns the copyright in what they create unless a signed agreement assigns it to you. Hire a developer with a handshake and no paperwork, and you may not own your own engine. Fix this with a one-paragraph clause in every agreement, and confirm past contributors have signed one too. Second, keeping repos private: it costs nothing and is the difference between having a trade secret and having published a tutorial for your competitors. The related governance and access-control practices — private repositories, least-privilege access, and secrets hygiene — are summarized in the protection checklist above.

The intelligent use of human-hiring services

A done-for-you marketing engine that is mostly automated is not the same as an engine that is entirely unattended. A thin, deliberate layer of human judgment sits on top of the deterministic machine — approving what goes out, catching the edge cases the rules do not cover, and adding the social nuance that no scheduler can fake. The only real question is where that human labor comes from and what it costs, and the honest answer is that it now costs far less than the cost model in Chapter 55 assumed. This chapter grounds that claim in current 2026 marketplace rates, recomputes the human-cost floor from those rates, and draws a clear line between using outside marketplaces to source our own labor and offering a hire-a-human product to clients.

Why a human is still in the loop at all

The engine does the heavy, repeatable work — generation, scheduling, scoring, reporting — and it does it at a marginal cost that rounds to zero. What it does not do well is judgment at the edges. The approval queue described in Chapter 53 exists precisely because a small fraction of every batch needs a human glance before it represents a client in public: a claim that reads wrong for a regulated industry, a tone that is a shade off for the brand, an image that is technically fine but contextually poor. Social media is the other place humans still earn their keep, because timing, reply nuance, and community tone are exactly the soft signals a rule engine cannot manufacture. Add light quality assurance — someone actually running through onboarding and clicking the buttons a real client will click — and you have the full human footprint. It is small, but it is not zero, and pretending otherwise is how automated services quietly ship embarrassing output.

Crucially, this human layer is cheap in hours and expensive only if you buy those hours badly. The economics in Chapter 51 and Chapter 52 rest on the AI compute being a fixed subscription cost rather than a per-unit cost; the human oversight is the one genuinely variable, per-client line item left in the model. That makes the price of an hour of competent human attention the single most important number in the entire cost-to-serve calculation — and it is a number that has fallen through the floor.

The marketplace landscape in 2026

There are two structurally different ways these platforms make money, and the difference matters more than the headline rate. Task marketplaces (Fiverr, Upwork, Freelancer.com, PeoplePerHour) skim a percentage of every transaction, so their real cost is the platform take on top of what the worker earns. Sourcing platforms (OnlineJobs.ph) charge a flat monthly subscription to find the worker and then step out of the way — you pay the worker directly, with no markup on their wage. A recent real-world signal made the depth of this pool obvious: a single small paid task posted at roughly thirteen dollars drew thirty to forty qualified replies overnight, which tells you the supply of capable global labor is far deeper and cheaper than a cost model built on twenty-dollar domestic rates ever assumed.

Read the table with one distinction held firmly in mind: the first seven rows are ways we buy labor; the last row is a product we might sell. They are not competitors, and treating them as if they were is the mistake this chapter exists to prevent.

Two different jobs: developing the product versus running it

Cheap labor solves two problems that look similar and are not. The first is building and hardening the product itself. When the interface changes or a new onboarding flow ships, you want fresh eyes running through it as a real user would — clicking every button, trying the dumb thing, filing the bug that the person who wrote the code will never think to test. Task marketplaces are almost unfairly good at this: a five-to-fifteen-dollar test task on Fiverr or Upwork buys an honest first-time walkthrough within hours, and posting a handful in parallel buys a small QA panel overnight. The alternative is to have trusted builders or partners trial it instead. That is the right call when the feature is confidential, when the tester needs real domain context to judge whether output is good rather than merely working, or when you need a conversation rather than a bug list. The rule of thumb is simple: pay strangers to find what is broken, and ask trusted people whether what works is actually right.

The second job is running the live service month after month, and here the shape of the work favors dedicated labor over piecework. A realistic per-client footprint is on the order of three to four human hours per month — call it roughly ninety minutes on approval review and content polish, another ninety on social-media oversight and light community management, and a half hour on the genuine edge cases. Piecing that out task-by-task on Fiverr works but carries transaction friction and inconsistent quality; a dedicated virtual assistant sourced through OnlineJobs.ph, handling a book of clients, gives you continuity, brand familiarity, and the lowest effective hourly cost in the table. The running service wants a small, stable bench of dedicated people; product development wants a rotating cast of cheap, disposable testers. Sourcing both from the same channel is how you end up overpaying for one of them.

What cheaper labor does to the numbers

Now recompute the floor honestly. Chapter 55 built its prices up from cost, assuming human oversight at roughly $11–$17 per hour (and $20–$25 for domestic rates). At the midpoint of about $14 an hour, three-and-a-half hours of monthly oversight per client sets a human-cost floor near $49. Re-sourced through OnlineJobs.ph, a dedicated VA earning $600–$900 a month works out to roughly $4–$6 an hour; at $5, the same three-and-a-half hours costs about $17.50, and even after amortizing the $99 monthly platform subscription across a book of clients, the floor lands near $18. The human-cost floor per client falls by roughly sixty percent.

The trap is to assume a lower cost means a lower price. It does not, and Chapter 55 is explicit about why: price is set against the value delivered and what the market will bear, with cost acting only as a floor beneath a margin, never as the thing that sets the number. Cheaper labor widens the gap between that floor and the price line, and that widened gap can be spent in exactly three ways. The readout below lays them out with honest numbers rather than a single triumphant one.

All three are legitimate; the wrong move is to pretend you can have all of them at once. Banking the saving as margin is the safe default and the right one while the current tiers are still proving out. Reinvesting it as more human touch — nearly tripling the attention each client receives for the same cost line — is the play if retention or word-of-mouth is the constraint rather than profit. And the genuinely new option is the third: with the human floor down near $18 and AI compute already a fixed subscription cost, a Starter tier below the $395 Presence plan is now defensible for the first time. A plan around $149 a month clears its human-cost floor comfortably and opens a segment — solo operators and micro-businesses — that $395 simply prices out. The grounded tiers of Presence $395, Growth $995, and Command $2,495 remain the price line; the news is that a fourth, lower rung has become viable without breaking the margin discipline of Chapter 55.

The verdict: marketplaces versus the in-house route

For sourcing our own internal labor, the recommendation is a two-channel split and nothing more elaborate. Use OnlineJobs.ph for the dedicated, ongoing bench — the VAs who run approval queues and social oversight across a book of clients — because its flat subscription and direct-pay model deliver the lowest effective hourly cost in the market and reward continuity. Use Fiverr and Upwork for the spiky, one-off work: QA panels, a burst of content polish, a specialist task that does not recur. That combination covers essentially every internal need at or near the floor, with speed-to-hire measured in hours for tasks and days for dedicated staff.

The in-house Human Desk is a separate question because it answers a separate need. It is not how we buy labor; it is a productized human layer we could sell to clients who want managed human involvement on top of the automated engine. Its viability rides on whether clients will pay for that managed layer at a margin over what it costs us to source — and cheaper sourced labor actually strengthens that case, because it widens the margin on a Human Desk offering just as it does on the core service. So the two do not compete: marketplaces are the supply chain, and the Human Desk is a product built on that supply chain. Keep the Human Desk concept alive as a client-facing offering, and do not confuse it with the plumbing that feeds it.

The machine is built. The only question left is who operates it.

Everything in this manual describes something that already exists. Not a pitch deck, not a roadmap, not a promise about what the technology will someday do — a working engine that reads real pages, drafts real work across every marketing role, and runs on a schedule today, on a live network, at a cost that does not climb when the workload does. The building is done. What remains is not invention. It is operation — and operation is the part that has always separated the businesses that pulled ahead from the ones that waited.

Come back to where we started

This began with a simple claim: that marketing is built the same way a drive is. A small, precious core of judgment — what your business stands for, who it is for, the one story only you can honestly tell — wrapped in an enormous, grinding volume of mechanical work that no human stays good at for long. Read the page. Score it. Draft the fix. Schedule the post. Send the follow-up. Measure it. Do it again next week, forever, because the web never stops moving. That grind is the shuttle thrown ten thousand times a day, the column recalculated by hand at midnight, the lane held for mile after mile at four o’clock on a Friday. It is exactly the work a tireless machine performs superbly and a tired person cannot. Every chapter between the introduction and this page has been about one thing: handing that grind to the machine, and keeping the judgment for yourself.

What you actually have now

Read straight through, this manual has not handed you a tool. It has handed you a department. A search specialist that audits every page against how engines and answer engines really rank today. A content desk that drafts in your voice and holds anything it cannot verify. An outbound arm, a conversion editor, an analyst that re-measures and starts again — all of them working the same account, on the same day, without ever getting bored on the two-hundredth page. Staffing that department the old way meant salaries, onboarding, turnover, and management. Here it is a machine you point at a web address, and it starts on its first day the way a seasoned team would — except it never has a last day, and it never asks for a raise when the work doubles.

Why it is safe to move fast

The instinct, faced with a machine this capable, is to slow down — to worry about what it might say in your name while you were not looking. That worry is exactly what the design removes. Nothing this engine writes ever goes live until a person reads it and says yes. It will not invent a fact it cannot find on your page. It will not send an email on its own. And anything it does publish can be pulled back with a single click, because it quietly kept the previous version first. Those are not features bolted on for comfort; they are the reason you can let it run at full speed without ever holding your breath. The machine carries the miles at a pace no team could match, and your hands still rest on the one decision that carries your name. Speed and safety usually trade against each other. Here, for once, they do not.

The edge belongs to whoever is early

Every leap in this story shared one quiet, uncomfortable truth: the technology was almost never the hard part. The looms existed for years before most mills installed them. The spreadsheet shipped long before most businesses trusted it with the books. The self-driving stack worked in the lab well before most fleets dared put it on the road. In every case the advantage did not go to whoever invented the machine — it went to whoever operated it first, while everyone else was still debating whether it was real. That window is open now, and it is open precisely because most businesses have not yet believed what this engine can do. They will. When they do, running a tireless marketing department on a schedule will be the baseline, not the edge — the thing you need just to be found at all. The only genuine question this manual leaves you with is the one every early operator was lucky enough to answer before the crowd: not whether the machine works — it does, today — but whether it is you at the wheel while being early still counts.

GET

POST

Descriptions are each skill's own SKILL.md trigger, verbatim from coreyhaines31/marketingskills. The Dept column is the operating department that carries the skill (see the coverage matrix, Chapter 31).

↑ Back to top