Cowork Orchestrated Research

Depends on: FTR-28 — Multi-AI Research Synthesis System

What this is

A third research mode alongside Deep (FTR-28) and Cascade (FTR-30) — this one runs on Cowork's own tasking ability instead of manual multi-platform submission. The operator hands Cowork one kickoff instruction covering a whole batch of research items — run in parallel if the items are independent, or run as a chain if one item's output feeds the next — and Cowork works through the batch on its own, returning results as they complete rather than requiring the operator to paste and babysit each item one at a time.

Same RS-track item underneath (FTR-28's ID scheme, same register, same file conventions). What's different is the execution mechanism: no Deep Research mode on any platform, no manual per-item submission — Cowork's browsing/fetch tools running against a single batch instruction, with the operator kicking it off once and collecting once (or a few times, for long batches) instead of round-tripping per item.

Why this exists

Deep (FTR-28) assumes the operator manually submits each prompt to each platform and manually deposits each response. That's correct for triangulation work where a human genuinely needs to run three separate tools. But a lot of research work isn't triangulation — it's high-volume, single-platform, well-scoped fetch-and-compile work where Cowork alone is entirely sufficient, and the bottleneck was never the research quality — it was the operator manually feeding items one at a time when Cowork could have taken the whole batch and worked through it unattended.

This gap showed up directly in production: six research items were prepared as six separate briefs, and the default assumption was that each had to be pasted into Cowork individually, waited on, then the next one started. That's not a limitation of Cowork — it's a limitation of how the items were handed to it. The fix isn't a better brief template; it's a different execution contract: one kickoff, Cowork owns the sequencing (parallel or chained), the operator collects.

The two execution shapes

PARALLEL BATCH — items have no dependencies on each other. All items are handed to Cowork in a single kickoff; Cowork works through them in whatever order it finds efficient and returns results as a set. Use when a batch is a flat list of independent lookups (e.g., a topic backlog where each item stands alone).

CHAINED BATCH — item N's research depends on item N-1's result being available first (a narrower version of what FTR-30 does for Deep, but running inside a single Cowork task rather than across separate manual submissions). Cowork is instructed to complete step 1, use its own output as context for step 2, and so on, reporting at each completed step rather than only at the end.

A batch is one or the other — mixed batches (some parallel, some chained) get decomposed into a chained backbone with parallel sub-groups at each dependency-free stage, same decomposition logic FTR-30 already uses for Deep chains.

Kickoff format — the part that fixes the actual problem

The kickoff is a single instruction, not a set of individual briefs to be pasted one at a time. It:

• States the batch's execution shape (PARALLEL or CHAINED) up front
• Lists every item's scope in one place (not one brief per message)
• For CHAINED batches, states the dependency order explicitly and instructs Cowork to carry each completed step's result into the next as context
• States the Expected Output filename/pattern for every item (same discipline as standard Cowork-mode tracking elsewhere in this catalog), so the operator's register can reconcile against actual output without guessing
• States where completed items should land (a single drop location for the whole batch, not a different location per item)
• Ends with a single completion instruction: report back a status line per item as each one finishes, don't wait to batch-report only at the very end

The operator's job is reduced to: paste once, then periodically check in or wait for the "batch complete" signal — not paste-wait-paste-wait per item.

Alignment with the existing research family (FTR-28 / FTR-30)

All three research types — Deep, Cascade, and this one — use the same underlying RS-track item and the same unified four-stage tracking shape (assigned → running → results back, not yet integrated → done), so a register scan answers "what's open" the same way regardless of which mechanism produced an item. What differs is the mechanism itself:

When to reach for this instead of Deep or Cascade: the research doesn't need multi-platform triangulation, there are multiple items to get through (whether independent or dependent), and Cowork alone can produce adequately-sourced, well-structured output for all of them. If any single item in the batch genuinely needs cross-platform verification, that item should be pulled out and run as a Deep item instead — don't force triangulation-worthy research through a Cowork-only batch just because it's sitting next to items that don't need it.

Prerequisite — CLAUDE.md/AGENT_INSTRUCTIONS.md sync: since Cowork reads its operating context from CLAUDE.md at whatever directory it's pointed at, this feature is only as reliable as that file being current. Before kicking off any batch, confirm CLAUDE.md is a verbatim, up-to-date clone of AGENT_INSTRUCTIONS.md for that directory (per FTR-21's own canonical-source rule — AGENT_INSTRUCTIONS.md is always the source, CLAUDE.md the generated mirror) — a stale seed means Cowork is working from outdated conventions, wrong paths, or a missing Expected Output discipline, and the batch's results won't reconcile cleanly against the register.

Worked example

Operator has 6 independent research items ready (a KB/FAQ topic backlog, no dependencies between them).

Old way (what actually happened before this feature existed): operator pastes brief 1 into Cowork, waits, collects, pastes brief 2, waits, collects — six manual round-trips.

With this feature: all 6 items are assigned RS-track IDs and logged QUEUED in the register as one PARALLEL batch. One kickoff message is built covering all 6 — scope, Expected Output filename per item, single drop location, and the instruction to report each item's completion as it happens rather than waiting for all 6. Operator pastes once. Register moves the whole batch to RUNNING. As results land, each item individually moves to RESULTS IN; operator evaluates and closes each independently — no requirement that all 6 finish before any of them can be checked off.

A CHAINED example: item 2 needs item 1's finding as context (e.g., "first identify which vendors serve this market," then "for each vendor identified, compile their pricing structure"). The kickoff states this order explicitly and instructs Cowork to carry step 1's actual findings into step 2 rather than treating step 2 as independently scoped. Register reflects this as a chain (parent ID + step suffixes, same numbering convention as FTR-30) even though the whole thing runs inside one Cowork task rather than across separate manual submissions.

Assess first

Before proposing this feature to a project: check whether Cowork is actually available and whether the project already has FTR-28 installed (this feature assumes FTR-28's RS-track and register exist — it's an additional execution mode on the same track, not a separate tracking system). Check whether the project has multiple pending research items sitting unbatched — that's the strongest signal this feature would help immediately rather than being installed speculatively.

Ask, only if needed

If the project has FTR-30 (Cascade) but no clear use of Cowork yet, confirm the operator actually uses Cowork as part of their workflow before installing — this feature is dead weight in a project where research is always triangulation-only.

Write

◆ COWORK ORCHESTRATED RESEARCH (FTR-32)

Depends on FTR-28 (shares the RS-track ID scheme and Research Register). A third
execution mode alongside Deep (manual multi-platform triangulation) and Cascade
(dependency-sequenced Deep) — this one runs on Cowork's own tasking ability: one
kickoff instruction covering a whole batch, run in parallel or as a chain, instead
of the operator manually pasting and collecting each item one at a time.

EXECUTION SHAPES
  PARALLEL BATCH — independent items, single kickoff, Cowork self-sequences,
    reports each item's completion as it finishes (not only at batch-end).
  CHAINED BATCH — item N depends on item N-1's result; kickoff states the order
    explicitly and instructs Cowork to carry each completed step's actual findings
    into the next step as context. Same decomposition logic as FTR-30 for mixed
    dependency graphs (chained backbone, parallel sub-groups at each stage).

KICKOFF FORMAT (the fix for "I thought I had to run these one at a time"):
  One instruction, not one brief per message. States: execution shape (PARALLEL/
  CHAINED) up front; every item's scope in one place; for CHAINED, the explicit
  dependency order; Expected Output filename/pattern per item (same discipline as
  client-level Cowork tracking); a single drop location for the whole batch; and
  an explicit instruction to report per-item completion as it happens.

REGISTER STATES (same shape as Deep/Cascade — see FTR-28):
  QUEUED -> RUNNING -> RESULTS IN -> CLOSED
  RESULTS IN is real and distinct from CLOSED — a batch item landing in the drop
  location has not yet been evaluated. Never mark CLOSED on arrival alone.

WHEN TO USE THIS VS. DEEP/CASCADE: no item in the batch needs multi-platform
  triangulation, and there are multiple items to get through (independent or
  dependent). If one item in an otherwise-Cowork-suitable batch genuinely needs
  cross-platform verification, pull it out and run it as a standalone Deep item
  instead of forcing triangulation through a Cowork-only batch.

PREREQUISITE: confirm CLAUDE.md is a current, verbatim clone of AGENT_INSTRUCTIONS.md
  for whatever directory Cowork is pointed at before kicking off any batch — Cowork
  reads its operating context from CLAUDE.md, and a stale seed means wrong paths,
  outdated conventions, or missing Expected Output discipline, none of which will
  reconcile cleanly against the register afterward.

Full spec: https://claude.sotekzone.com/data/items/cowork-orchestrated-research.md

Confirm

After installing, confirm with the operator: is there a pending batch of research items right now that this should be applied to immediately? If yes, build the first kickoff as part of this same session rather than leaving the feature installed but unused.