What I Actually Run on Cowork

The Operating Picture

Most “AI automation” content is a demo: a clever prompt, a one-off result, a screen recording. This is the opposite. The systems below have run day after day, and the numbers in The Numbers come from the live YouTube Studio and the live academy hub, dated the day this class was built.

The mental model is simple. Cowork is the orchestrator — the architect that plans, writes the automation code, schedules the unattended tasks, drives the browser when needed, manages files, and audits the output. When a job needs a different tool, Cowork hands it off: hands-on coding to Claude Code, deployment and runtime to Google Antigravity with Gemini, and bulk autonomous production to a local model running on a single consumer GPU at zero marginal cost. Four brains, one operator.

Everything that follows is grounded in a sanitized operational record. Where a number is a positioning label rather than an audited result — the app valuations in the case studies — it is marked as such. The rule on camera and on the page is the same: teach the build, not the valuation.

Source: DDS Cowork operational record (sanitized, teaching-grade), 2026-06-29; live academy hub; YouTube Studio.

The Standing Systems

A standing system is the difference between a tool you operate and a system that runs. Every row below is a scheduled or per-event task with its tool grants pre-approved, so the unattended run never stalls waiting for a permission click.

The teaching point is not any single task. It is that the cadence holds: the nightly build, the weekday publish, and the Monday health check fire on their own, and the queue caps and verification gates keep a bad run from shipping. A standing system you can trust is built one pre-approved grant and one guardrail at a time.

Source: DDS Cowork operational record (sanitized), 2026-06-29. Verified standing systems; cadences as configured.

The Production Pipeline

The standing systems are the cadence. The pipeline is the craft — how each asset gets made, end to end:

1. One class to a five-block pack

A locked workflow skill turns one class URL into five paste-ready blocks: a premium thumbnail spec, an intro-video prompt, a multi-module script, a slide deck, and the video metadata. Facts are grounded in the real class page; everything is a draft until I approve it.

2. Brand voice, enforced

A brand-voice skill gates every draft against one question: would I actually write this? No hype, no emojis, free and no-signup everywhere. The skill carries the same banned-words discipline into every session instead of being re-explained each time.

3. Premium thumbnail

A sandbox script drives my logged-in image model to compose the locked brand thumbnail template, then sizes it for upload. The template is fixed; the output is reviewed before it goes live.

4. Intro video

A second sandbox script generates a short photoreal founder intro with synced dialogue against a locked beat sheet, produced as a draft asset for review.

5. Upload, schedule, pin

A resumable upload through the platform's official Data API publishes private-then-scheduled — never instant — with metadata written in my voice, and the launch-comment task pins the opening comment a few minutes later.

Source: DDS Cowork operational record (sanitized), 2026-06-29.

The Four-Brain Stack

The headline of the whole operation is orchestration. No single tool does everything; Cowork decides which brain a job belongs to and coordinates the handoff.

The cleanest worked example is the academy hub itself. Claude authors the code, Antigravity deploys it through the commerce MCP, and Cowork QA-audits the result — link checks, schema checks, layout checks — before anything is trusted. That division of labor is not a guess; the page prints its own record of it, which is the subject of the next section.

The reason to split work this way is the same reason a studio has sections instead of one player doing everything: each tool is sharper in its lane, and the orchestrator's job is to keep the handoffs clean and the output checked.

Source: DDS Cowork operational record (sanitized), 2026-06-29; live academy hub build manifest.

The Auto-Poster (Taught at the Discipline Level)

Cowork did not just “write a script.” It architected a posting system, wired it into a scheduler, and hardened it with fail-safes. The implementation details — timing, pacing, selectors, any anti-detection technique — are intentionally not published, because a public how-to there would be both unsafe and against the spirit of the platforms involved. One sentence on the why and no more: it operates a real, already-logged-in browser session so posts come from genuine authenticated accounts.

What you should take from it is the guardrail design, which is the actually transferable part:

• Dry-run by default. Nothing posts unless the run is explicitly armed. The safe state is “show me what you would do.”
• A STOP kill-switch. A single signal halts the system mid-run.
• Draft-only on blocked platforms. Where automation is disallowed, the agent drafts and I post by hand. No exceptions.
• Per-platform de-duplication. The system will not double-post the same content to the same place.

Source: DDS Cowork operational record (sanitized) — disciplines only; implementation deliberately excluded.

The Build Manifest Receipt

A Build Manifest turns a black-box result into an auditable chain. The hub's published manifest, read live the day this class was built, records the multi-IDE handoff exactly:

These figures are quoted as the live page records them, not asserted independently. The model versions are the manifest's own labels for the agents in that build.

Source: live DDS Vibe Academy hub, published build manifest, read 2026-06-29.

Apps & Pages Shipped

The systems on this page produced a body of shipped work. The honest framing matters here, so it is stated up front: where you see a dollar figure on an app, treat it as a case-study label, never as audited revenue or a verified valuation.

• Atelier OS — a multi-agent system, framed as “$15.5M, built in 52 hours.” A build story, not an audit.
• AGI Nexus — framed as a “$1M autonomous digital office.” Again, positioning.
• Synthetic Director — a multi-platform content engine that runs against a local model server. Exists as a class; scale claims are framing.
• Sovereign Orchestrator, NicheForge, VibeTube, and a desktop-apps portfolio — additional case-study classes.
• The academy itself — 52 unique class pages and the hub — is the largest worked example: built by agents, deployed via MCP, audited by Cowork.

The pages are built on the same SEO Magnet System this masterclass uses — structured data, answer-engine optimization, and an FAQ matched to schema — which is why they surface in AI search. The apparatus that makes a page citable is itself part of the stack.

Source: DDS Cowork operational record (sanitized), 2026-06-29. Valuations marked as framing, not audited.

Control Plane & Guardrails

An always-on agent with access to your accounts is a liability until you bound it. These are the seven rules that bound mine:

• Scheduled, not instant. Publishing is scheduled and gated, never fire-and-forget.
• Draft-only on blocked platforms. Anything a platform disallows automating stays a draft I post by hand.
• Dry-run + STOP. Automated posting defaults to dry-run and has a kill-switch.
• Voice gate. Copy must pass “would I actually write this?” before it ships.
• Grounded facts. Content is grounded in real source pages, never invented.
• Official APIs for writes. Storefront and video-platform changes go through official APIs and MCP, not screen-scraping.
• One exception at a time. Autonomy is the exception, not the default. A new autonomous action is added only after I have watched the workflow run.

The promise that sits on top of all of it is the academy's standing line: free, no paywall, no signup, no certificate. The guardrails are what let that promise scale without a team.

Source: DDS Cowork operational record (sanitized), 2026-06-29; academy hub.

The Numbers

A receipts class has to show the receipts, including the small ones. These are current as of 2026-06-29:

The honest read: this is a small channel growing steadily, with an unusually large free curriculum behind it. The story is not the subscriber count; it is that one operator ships at this volume because the stack does the finishing. The app valuations elsewhere on the page are framing, not figures in this table — that separation is deliberate.

Source: YouTube Studio and the live academy hub, both read 2026-06-29. Prior figures marked historical with their dates.

Build Your Own

You do not need my channel or my apps to use this. You need one folder, one connector, one scheduled task, and the discipline to grant autonomy slowly. The lifecycle of every standing system here:

1. Connect one folder. Flat, single-purpose. Let structure emerge from real deliverables instead of pre-building a hierarchy.
2. Write a SKILL.md. A description that becomes the prompt, a schedule, and a body of rules — each with a named test the output must pass before it saves.
3. Live-test once. Run it by hand a single time so every tool grant gets pre-approved. This is the step that keeps the unattended run from stalling on a permission prompt.
4. Schedule it. Add the cadence. It now fires while the machine is awake and the app is open — there is no cloud daemon.
5. Iterate the body, keep the schedule. Edit only the description and body; never touch the cron line. Verify the on-disk file against the source after every edit so drift is never silent.
6. Add one autonomous exception. Keep drafts-only as the default. Promote a single action to autonomous only after you have watched the workflow behave.

That is the entire method. The factory is just this loop, repeated, with a guardrail bolted to each step. The playbook below gives you the prompts to run it.

Source: DDS Cowork operational record (sanitized), 2026-06-29; and the sibling class, Claude Cowork Masterclass.

The Playbook

If the systems are the what, these are the how. Each maps to a section on this page. Copy, fill the brackets, and run.

1. Outcome. Turn the class page at [URL] into one markdown file with five blocks: a thumbnail spec, an intro-video prompt, a multi-module script, a slide outline, and the video metadata.
2. Constraints. Ground every fact in the class page; invent nothing. Keep my voice: direct, no hype, no emojis, free-and-no-signup. Title under 60 characters. Exactly the five blocks, labeled.
3. Context. The class page is the only source of truth for facts. My voice rules live in the brand-voice skill; apply it.
4. Test. Every claim traces to a line on the class page; the title passes the character check; all five blocks are present and labeled.
5. Gate. Draft only. Do not generate images or video here, and do not publish anything. Flag any fact you could not find on the page rather than filling the gap.

1. Outcome. Author a scheduled-task SKILL.md for [recurring job] with three parts: a description that becomes the prompt, a cron schedule, and a body of rules.
2. Constraints. The body names a concrete test the output must pass before saving (a word count, a heading count, a forbidden string). Keep the schedule on its own line, untouched by later edits.
3. Context. The task folder is [folder]. The grants it needs are [list connectors/tools]. The cadence is [cron].
4. Test. Re-read the on-disk SKILL.md and diff it against the intended source byte for byte; report any difference.
5. Gate. Tell me to live-test the task once by hand to pre-approve every grant before it runs unattended. Do not schedule it until I confirm the live test passed.

1. Outcome. Write a policy file that lists exactly which actions are autonomous, which are drafts-only, and which are prohibited outright.
2. Constraints. Default every action to drafts-only. Name each autonomous exception explicitly with its scope. Grant no blanket permission.
3. Context. My platforms are [list]. Account creation, financial actions, and permission changes are never allowed.
4. Test. Read the policy back and confirm no action is autonomous unless I named it specifically.
5. Gate. Treat any unlisted action as drafts-only and ask before escalating it, even if it seems harmless.

1. Outcome. Each day, capture the reachable public comments across my channels and draft two on-brand replies per post into one dated file.
2. Constraints. Draft only; post nothing. Where a platform is login-walled or blocks automation, say so plainly. Enforce the brand voice on every reply. Skip anything sensitive or non-English.
3. Context. Loop the channels in a fixed order. Some platforms are blocked here; note them rather than faking results.
4. Test. Every drafted reply passes the brand-voice rules; every blocked platform is listed with its reason.
5. Gate. Write one dated file and stop. Post nothing, anywhere, for any reason.

1. Outcome. Each day, build the next item in the production queue only if the downstream scheduled queue has capacity; otherwise skip and log why.
2. Constraints. If the scheduled queue depth exceeds [N], skip the build. Follow the fixed pack order strictly; never reorder items to fit.
3. Context. Read the production log for the next item and read the platform's scheduled queue for current depth through the connector.
4. Test. Confirm the queue-depth reading before deciding to build or skip; re-read if the value looks malformed.
5. Gate. Append either a build row or a dated skip entry with its reason. Never publish instantly; the build is scheduled, not fired.

1. Outcome. For this shipped artifact, generate a Build Manifest table listing every agent in the chain, its vendor, its role, and its concrete output.
2. Constraints. One row per agent. Describe roles factually with no promotional language. Keep it to four columns.
3. Context. The chain that produced this artifact is in the project notes; some agents authored, others only verified.
4. Test. The manifest accounts for every agent that wrote or verified any part of the artifact, with nothing omitted.
5. Gate. If an agent's exact role is unclear, mark it 'role: unverified' rather than inventing a description.

1. Outcome. Distill my existing posts into an enforceable brand-voice skill that applies automatically to every future draft.
2. Constraints. Capture concrete, testable rules: tone, banned words, hook style, and the verbatim brand line. No vague adjectives without a rule behind them.
3. Context. Read the posts in [folder]. The voice is direct and high-signal: no emojis, no hashtags, no hype.
4. Test. Generate one sample draft and check it against each rule, listing any rule it violates.
5. Gate. Run brand-voice discovery once with me before enforcing; do not infer or invent rules I have not confirmed.

1. Outcome. After another IDE deploys a page, run an autonomous browser QA audit and return a numbered findings list with severity, location, evidence, and a fix.
2. Constraints. Verify internal links resolve, structured-data blocks parse, the FAQ count matches the schema, and interactive elements work in the DOM, not by appearance.
3. Context. The page is at [URL]. Use the browser connector. Some checks are forced-width; flag those for real-device confirmation.
4. Test. Every finding cites a specific element or URL; broken links and schema mismatches are caught, with a count.
5. Gate. Read-only audit. Do not edit the page; produce the findings list and a single pass/fail verdict, and surface any link or schema break at the top.

Sources

• DDS Cowork operational record — sanitized, teaching-grade, 2026-06-29 (standing systems, pipeline, disciplines).
• Live DDS Vibe Academy hub — class counts and the published build manifest, read 2026-06-29.
• YouTube Studio — channel snapshots, read 2026-06-29.
• Companion class: Claude Cowork Masterclass — what Cowork is, its architecture, and the tool-priority ladder.

About the Author