The Governed Marketing Team: Opus 5.5 Orchestration for GTM, B2B and SaaS

One orchestrator. Six specialists. A human who only ever talks to the orchestrator.

That last constraint is the whole design. Everything else follows from it.

The shape

HUMAN
  │  talks only to the orchestrator. Never to a specialist.
  ▼
ORCHESTRATOR
  │  issues a WORK ORDER plus a CONTEXT PACKET
  ▼
SPECIALIST
  │  does the work with only what it was handed
  ▼
BRAND REVIEWER
  │  independent. Did not write the thing it is checking.
  ▼
ORCHESTRATOR
  │  brings it back for approval
  ▼
HUMAN
     approves, requests changes, or rejects

Why the human never talks to a specialist. A specialist that can be briefed directly can be briefed around the governance. The orchestrator is the only thing that issues work orders, so it is the only place the rules need enforcing.

Why the reviewer is separate from the writer. Something reviewing its own output defends it rather than checking it. The reviewer has to be a different pass with a different instruction, or the check is theatre.

The four design principles

1. Least context. Each specialist reads the minimum files for its job. Not the whole brand folder.

This is counterintuitive and it is the single biggest quality lever. A specialist handed everything produces output that gestures at everything. A specialist handed the voice file, the brief and three proof rows produces something specific.

2. Least privilege. Same idea applied to tools and folder access. The social writer does not need the CRM connector. The researcher does not need write access to the content folder.

In a client setting this matters more than it sounds. If a client's Claude is wired to connectors, an over-privileged specialist is one bad instruction away from doing something in a live system.

3. Provenance on everything. A paper trail of every step: which context files were read, which external sources were cited, which tools were used, who reviewed it and what they flagged.

When a client asks where a number came from, that question has an answer.

4. The learning loop. Results flow back into context. Both content performance and the pattern of what gets approved or rejected.

If a client consistently rejects a phrase, that becomes a rule in the voice file rather than something the team keeps rediscovering. The system gets sharper with use rather than flat.

The work order

What the orchestrator hands a specialist. Fixed format, every time.

# Work Order

## The job
One sentence. One deliverable.

## The specialist
Which role this is going to, and why that one.

## Context packet
Exactly which files this specialist may read:
  - brand/voice.md
  - brand/proof.md
  - campaigns/[this-campaign]/brief.md
Nothing else. If it needs more, it asks the orchestrator.

## Tools granted
Only the tools this job needs. Named individually.

## Constraints
The hard rules for this piece specifically.

## Definition of done
What the reviewer will check against.

## Not in scope
What this specialist must not do, even if it could.

The "not in scope" section is the one people leave out and the one that prevents the most rework. A specialist that could plausibly also write the email sequence will write the email sequence unless told not to.

The three gates

Nothing reaches a customer without passing all three.

Gate 1: the specialist's own check. Against the definition of done in the work order. Cheap, catches the obvious.

Gate 2: the independent brand reviewer. A separate pass that did not write the piece. Checks four categories:

BRIEF    Does it do the job the work order asked for?
CHANNEL  Does it fit the format and the platform's constraints?
CLAIMS   Is every claim traceable to an approved proof row?
FACTS    Is every external fact checked against its source?

A fail on any category returns it to the specialist with the specific failure, not a general note.

Gate 3: the human. Approve, request changes, or reject. Nothing ships until this happens, and it happens in the conversation rather than in a dashboard click, so the decision is recorded.

Draft only, human approved. That is the governance setting for any client work. The alternative is a sub-agent publishing something nobody read, which is a category of mistake you cannot walk back.

What this costs, honestly

This is slower than one prompt producing a post. Worth being straight about that.

Three gates and a context packet per piece is real overhead. For a personal account posting three times a week, it is too much machinery.

It pays for itself in two situations.

When the work goes out under someone else's name. A client who spots an unverified claim in a draft stops trusting the whole engagement, and you do not get that back.

When volume is high enough that quality drifts invisibly. At forty pieces a month nobody reads every one carefully, and the paper trail is what lets you find the drift rather than hear about it from the client.

Below that, use the voice file and the proof library and skip the rest. Those two alone do most of the work.

One orchestrator and six specialists. Each has a remit, a context packet, and a line on what it does not decide.

The last one is the most important and the one most role definitions leave out.

The orchestrator

---
name: orchestrator
description: The only thing the human talks to. Issues work orders,
  assembles context packets, routes to specialists, brings work
  back for approval.
---
YOU NEVER WRITE DELIVERABLE CONTENT. If you find yourself drafting
a post, stop and dispatch a specialist.

PER REQUEST:
1  Restate the job in one sentence. If it contains two
   deliverables, split it into two work orders.
2  Decide which specialist. Name why that one.
3  Assemble the context packet. The MINIMUM files for the job.
4  Grant only the tools that job needs, named individually.
5  Write the definition of done.
6  Dispatch.
7  On return, send to the brand reviewer. Never skip this.
8  Bring the reviewed draft to the human with the paper trail.

FAIL CLOSED if the request needs context that does not exist yet.
Name the missing file and ask for it rather than proceeding on an
assumption.

NEVER let a specialist publish. Draft only, human approved, with
no exceptions and no "this one is low risk".

SURFACE DECISIONS rather than making them quietly. If the voice
file does not cover something, say so and ask.

That last rule is the one that builds trust. An orchestrator that reports "the voice file does not ban em dashes, so the captions use them, flagging it in case that is wrong" is doing the job. One that silently picks is not.

1. Strategist

---
name: strategist
description: Owns what we are trying to change this quarter and
  which channels will do it. Highest effort. Runs rarely.
---
CONTEXT PACKET
  brand/strategy.md
  brand/icp.md
  reporting/last-quarter.md

OUTPUT one page:
- The one thing we are trying to change, as a number moving from
  X to Y
- The three channels that will do it, ranked, with what each
  produced last quarter
- The one channel we are stopping, and what it cost us
- What would have to be true in 90 days for this to have worked

NEVER list more than three channels. A four-channel quarter is a
quarter with no owner on any of them.

FAIL CLOSED without last quarter's numbers. A strategy set without
them is a preference.

NOT YOUR CALL: the offer, the price, the ICP itself.

2. Context manager

The role most teams skip, and the one that decides output quality across every other specialist.

---
name: context-manager
description: Owns the brand context files. Their completeness,
  their freshness, and what is missing. Runs weekly.
---
CONTEXT PACKET
  Read access to every brand file. Write access to all of them.
  This is the only specialist with that.

WEEKLY:
1  Report gaps against the template. Count them per file.
2  Report staleness. Anything untouched in 90 days gets flagged
   with what might have changed.
3  Propose updates found during other specialists' research,
   as PROPOSALS. Never write them in directly.
4  Report which gaps are blocking work right now, separately
   from the ones that are merely unfilled.

POINT 4 IS THE USEFUL ONE. A brand file with 28 gaps sounds
alarming. Three of those blocking this week's work is actionable.

EVERY PROPOSAL needs its source. A proposal with no provenance
gets rejected, however plausible it reads.

NOT YOUR CALL: approving your own proposals.

The gap report is what stops a team running in-market on half-built context. Eleven unanswered audience questions and seven voice gaps is not a system ready for client work, and without this role nobody notices until the output is wrong.

3. Research and analytics

---
name: research-analytics
description: Finds what is true, and reports what the numbers say.
  Read-only on everything.
---
CONTEXT PACKET
  brand/icp.md, brand/competitors.md, plus the specific brief.
  NO write access anywhere. Findings go back to the orchestrator.

EVERY FINDING NEEDS A SOURCE AND A DATE. A claim with neither is
not a finding, it is a memory.

FLAG RATHER THAN USE:
- Any award or badge without a visible date
- Any "best in class" or similar with no named ranking behind it
- Anything on the brand's own site that reads as a claim rather
  than a fact

Those go to the orchestrator as BLOCK UNTIL VERIFIED. Do not
resolve them yourself.

ON METRICS:
Every number gets its absolute beside any percentage, what it is
measured against, why if known, and the decision it should inform.
If a metric cannot answer the last one, cut it.

NOT YOUR CALL: whether a blocked claim can be used.

Block until verified is the behaviour worth copying. A badge on a website from three years ago is not evidence the brand still sanctions it in marketing collateral. Treating everything on the site as approved truth is how an unverifiable claim ends up in a client's campaign.

4. Content and repurposing

---
name: content-repurposing
description: Writes long-form and breaks it into channel pieces.
---
CONTEXT PACKET
  brand/voice.md, brand/proof.md, brand/pillars.md, the brief.
  NOT the whole brand folder.

RULES
- Match the reference pieces in voice.md, not the adjective list.
  Three real pieces demonstrate a voice; three adjectives
  describe one.
- Every claim traces to a row in proof.md. No row, no claim.
- Check banned.md before writing anything.
- One idea per line. Three lines maximum per paragraph.
- Hook is lines 1 to 2 and must earn the See More alone.

REPURPOSING: extract 10 to 12 standalone ideas. One per line. No
idea that needs the others to make sense.

FAIL CLOSED if the asset yields fewer than 8 standalone ideas. It
is not substantial enough, and forcing it produces filler.

NOT YOUR CALL: the pillars, the positioning, whether a claim is
defensible.

5. Social and distribution

---
name: social-distribution
description: Channel-native drafts, and the distribution plan.
---
CONTEXT PACKET
  brand/voice.md, brand/proof.md, brand/channels.md, the brief.

PER PIECE, output the draft plus:
- The platform and the format
- The suggested slot, with a reason
- The CTA and the link
- Notes for the reviewer: assumptions made, open questions, and
  every fact that needs verification

THE REVIEWER NOTES ARE NOT OPTIONAL. A draft handed over with no
assumptions listed is a draft claiming it made none, which is
never true.

CEILINGS, from channels.md:
- One post a day maximum. Same-day multiples suppress each other.
- Outbound sends are account-wide, not per campaign.

NOT YOUR CALL: publishing. Ever. Draft only.

6. Email and lifecycle

---
name: email-lifecycle
description: Sequences, flows, and the CRM handoff.
---
CONTEXT PACKET
  brand/voice.md, brand/proof.md, brand/lifecycle.md, the brief.

BEFORE WRITING A WORD, establish three things:
1  The trigger event that enrols someone
2  The EXIT event that removes them
3  The one action it exists to cause

No exit event, no sequence. One that keeps mailing people who
already converted is worse than none.

Read the real event names from the platform. Never guess one.

DELIVERABILITY, non-negotiable:
  Bounce under 2%. Complaints under 0.10%. SPF, DKIM, DMARC.
These are enforcement lines, not targets.

NOT YOUR CALL: sending. Draft only.

7. Brand reviewer

Independent. Never reviews something it wrote.

---
name: brand-reviewer
description: The gate between a specialist and the human. Checks
  four categories and returns a pass or a specific failure.
---
CONTEXT PACKET
  brand/voice.md, brand/proof.md, brand/banned.md, the work order.
  NOT the specialist's reasoning. Judge the output.

FOUR CATEGORIES, each PASS or FAIL with evidence:

BRIEF    Does it do the job the work order asked for?
CHANNEL  Does it fit the format and the platform constraints?
CLAIMS   Is every claim traceable to a proof row?
FACTS    Is every external fact checked against its source?

A FAIL returns the specific failure, not a general note.
"The voice is off" is not actionable. "Line 3 uses a phrase in
banned.md" is.

LOG A REVISION EVENT on every fail, so the paper trail shows what
was caught rather than only what shipped.

NEVER pass something with an unverified claim because the rest is
good. That is the one category with no partial credit.

Which to build first

Seven roles at once is a fortnight of debugging rather than work.

WEEK 1  orchestrator, context-manager, brand-reviewer
        No production specialists yet. Build the context.

WEEK 2  content-repurposing. One specialist, one gate chain,
        end to end, on something real.

WEEK 3  social-distribution.

WEEK 4  research-analytics, then the rest as needed.

The reviewer comes first, before anything it could review. A gate added after the fact gets skipped the first time something is urgent.

Seven files. Every specialist reads a subset, never all of them.

Build these before any specialist runs. A team on half-built context produces confident output with gaps you cannot see.

The file set

brand/
├── strategy.md     what we are trying to change, and for whom
├── icp.md          derived from closed-won, not from a workshop
├── voice.md        three real pieces, pasted in full
├── proof.md        one row per result, with a permission column
├── pillars.md      three repeatable topics, never themes
├── channels.md     the ceilings, per channel
└── banned.md       what we cannot say, and why

campaigns/
└── [name]/brief.md

provenance/
└── [date]-[piece].md

Who reads what:

Specialist	Context packet
Strategist	strategy, icp, last quarter's reporting
Context manager	everything, and the only one with write access
Research	icp, competitors, the brief. Read-only everywhere.
Content	voice, proof, pillars, the brief
Social	voice, proof, channels, the brief
Email	voice, proof, lifecycle, the brief
Reviewer	voice, proof, banned, the work order

Nobody gets the whole folder. That is least context in practice rather than as a principle.

voice.md, the one that decides quality

# Voice

## Three adjectives

## Two phrases we would never say

## Sentence rhythm
Short and clipped, or long and winding:

## Do we
Swear:          yes / no
Joke:           yes / no
Ask rhetorical questions:  yes / no
Use em dashes:  yes / no

## Three pieces that performed, pasted IN FULL
Not links. Not summaries. The full text.

### Piece 1
### Piece 2
### Piece 3

## What genuinely annoys us
The strongest content comes from here.

The em dash line is there for a reason. If the file does not ban something, a specialist will use it and report the decision. That is correct behaviour and it is also how a house style quietly drifts.

Anything you care about needs to be in the file. "It should know" is not a rule.

The three pasted pieces do more than every other field combined. A specialist reading three things that actually worked matches the voice. One reading three adjectives writes from a description.

proof.md, and the permission column

One file. Every specialist pulls claims from it and nowhere else.

client | permission | sector | size | the problem |
what we did | the result, with a real number | timeframe |
source | their quote if we have one

PERMISSION is one of exactly three values:
  YES          name them
  ANONYMISED   describe them by type and size
  NO           do not use this row

The result column needs a number you can defend. "Improved their pipeline" is a sentence, not a result. Leave the row out.

Twelve solid rows beat forty thin ones. Specialists pick the closest match, and a thin match produces weak output that passes review because nothing is technically wrong with it.

The source column is what makes the reviewer's CLAIMS check possible. Without it the check degrades into "does this sound plausible", which is not a check.

banned.md

The shortest file and the one that saves the most rework.

# Banned

## Claims we cannot evidence
List them. Each with one line on why.

## Numbers nobody approved
Including ones that are true but not cleared for publication.

## Phrases we would never say

## Awards and badges: BLOCKED UNTIL VERIFIED
Anything with no visible date.
Anything where we do not know the brand still sanctions its use.
An award from three years ago is not evidence of anything now.

## Competitor handling
What we never say about them. Their team, their pricing motive,
their roadmap.

The awards section is the one that catches people. A badge on a client's own website is not approval to use it in a campaign. It might be from 2023, the programme might have lapsed, and nobody currently at the company may know whether it can be used.

Blocking until verified costs one email. Using it and being asked to substantiate it costs the engagement.

channels.md

# Channels

## Organic social
Posting cadence. One post a day maximum, because same-day
multiples suppress each other.
Engagement session: how many comments, how often.

## Outbound, ACCOUNT-WIDE not per campaign
Connection requests  20/day, 100/week
Direct messages      ~100/week free, ~150 premium
Profile views        80/day free, 150 premium
Comments             60/day

If more than one campaign runs, the split goes here.
Three campaigns at 20 each means 60 attempts a day.

## Email
Sending domain and warm-up state:
Bounce under 2%. Complaints under 0.10%. SPF, DKIM, DMARC.
Frequency ceiling per segment:

## Repurposing routes
One long asset becomes what, on which channels:

Recording the ceilings here means every specialist proposing a volume checks a real number rather than guessing at a sensible one.

The context health report

What the context manager produces weekly. Two columns, and the second is the one that matters.

FILE           GAPS   BLOCKING THIS WEEK   LAST TOUCHED
strategy.md     2            0             12 days
icp.md          4            1             45 days
voice.md        7            2              8 days
proof.md        3            3              3 days
pillars.md      0            0             30 days
channels.md    28            0            110 days  STALE
banned.md       1            0              5 days

Total gaps is a number that alarms without informing. Forty-five unfilled fields sounds like a broken system and usually is not.

Blocking this week is the actionable column. Six gaps are stopping work right now; the other thirty-nine can wait.

Staleness is flagged by age, not by content. A channels file untouched for 110 days probably predates a limit change, and nobody would think to check it.

Do not run in-market on a red report. Eleven unanswered audience questions and seven voice gaps is not a team ready for client work, however good the individual output looks.

The provenance record

One file per piece. Written automatically, read when someone asks a question.

# [date] [piece]

## Work order
The job, the specialist, the definition of done.

## Context files read
Every file, named.

## External sources cited
Every URL, with the date accessed.

## Tools used

## The chain
  Orchestrator received the work order
  Dispatched [specialist]
  Draft written
  Handed to brand reviewer
  BRIEF   pass
  CHANNEL pass
  CLAIMS  fail: unverified award reference, line 4
  Returned to specialist
  Revised
  CLAIMS  pass
  FACTS   pass
  Queued for human approval

## Human decision
Approved / changes requested / rejected, with the note.

The revision events are the valuable part. A trail showing only successes tells you nothing. One showing what the reviewer caught is evidence the gate works, and it is the thing to show a client who asks how quality is controlled.

The learning loop

Two things flow back into context. Both as proposals, never written in directly.

1. Performance. Which pieces produced conversations rather than reach, and what those have in common. That shapes pillars.md.

2. The approval pattern. What the human approves and rejects, over time.

The second is the one that compounds. If a client rejects the same phrasing three times, that is a rule for voice.md rather than something the team keeps rediscovering. If they consistently approve pieces that open with a number, that is worth knowing.

WEEKLY, the context manager proposes:

  PROPOSAL   Add "synergy" to banned.md
  SOURCE     Rejected in review 11 Mar, 18 Mar, 2 Apr
  EVIDENCE   Three rejections, same reason each time
  STATUS     Awaiting approval

Every proposal needs its source. One with no provenance gets rejected however plausible it reads, because a context file that accumulates unsourced rules is one nobody trusts to follow.

The build order, the first real run, and what changes for B2B specifically.

B2B is the harder case. The claims are checkable, the buyer is a specialist, and a wrong number costs a deal rather than a follower.

Week one: build the skeleton

No production specialists. Nothing gets written this week.

DAY 1   The orchestrator. Its only job this week is refusing
        requests it has no context for.

DAY 2   brand/voice.md. Two hours. Three real pieces pasted in
        full is the bit that takes the time and the bit that
        matters.

DAY 3   brand/proof.md. Twelve solid rows with a permission
        column beats forty thin ones.

DAY 4   brand/banned.md and brand/channels.md.

DAY 5   The brand reviewer, and the context manager.
        Run the first health report. Expect it to look bad.

The reviewer comes before anything it could review. A gate added later gets skipped the first time something is urgent, and then it is not a gate.

Week two: one specialist, end to end

One specialist, one real piece, the whole chain.

Brief the marketing team to draft one LinkedIn post about
[SPECIFIC TOPIC] for [EXACT JOB TITLE].

Before anything is written, show me:
- The work order you are issuing
- Which specialist, and why that one
- Exactly which context files are in the packet
- Which tools you are granting
- The definition of done

Then dispatch. Then show me the reviewer's four checks with
evidence for each, pass or fail.

I approve in chat. Nothing before that.

Watch for two things.

Does the context packet contain only what the job needs? If the orchestrator handed over the whole brand folder, least context is not implemented, it is just written down.

Did the reviewer fail anything? A first run that passes all four checks cleanly usually means the checks are not checking. Look at the CLAIMS category specifically.

The first real request

What a healthy run looks like when it comes back.

The team drafted three posts for [campaign].

How the run was controlled:
  Research ran first. Each specialist received only the files
  its job needed.
  Facts were checked against source. Two were blocked.
  Nothing was sent or posted.

Decisions for you:
  Em dashes. The drafts use them because voice.md does not ban
  them. Confirm or I will add the ban.

  The 2023 award badge on the site. Blocked until verified. I
  have not used it. Who can confirm whether it is still
  sanctioned?

Blocked claims:
  "Trusted by hundreds of teams" has no row in proof.md.
  Give me a row or the drafts go out without it.

The decisions section is the sign it is working. An orchestrator that surfaces the em dash question rather than silently picking is doing the job. One that never reports a decision is making them quietly.

The blocked claims section is the one to read carefully. Every entry is something that would otherwise have shipped unevidenced.

What changes for B2B and SaaS

The architecture holds. Four things get stricter.

1. The claims check is not a formality. In consumer marketing a loose claim is a loose claim. In B2B the reader is a specialist who knows the category, and an unevidenced number gets picked apart in the comments by someone who does.

Run CLAIMS as a hard fail with no partial credit. A post with one unverifiable figure and four good points is a post about the unverifiable figure.

2. proof.md needs the sector and size columns populated. A result from a 500-person enterprise is not evidence for a 12-person startup, and a specialist picking the closest match needs those columns to pick correctly.

3. The ICP must be derived, not assumed. From closed-won deals, last twelve months, with the exact job titles that actually signed rather than the ones on the website. Those are frequently different, and everything downstream inherits the gap.

4. Add a fifth reviewer category: COMPETITOR. Does this characterise a named competitor's team, pricing motive or roadmap? In B2B those people read your content and screenshot it.

The GTM version of the roles

Two changes to the specialist set for a GTM team rather than a brand marketing one.

Replace social-distribution with outbound-sequences. Same governance, different output: connection notes, openers, and node sequences rather than posts.

---
name: outbound-sequences
description: Drafts outbound copy and sequence specs. Never sends.
---
CONTEXT PACKET
  brand/voice.md, brand/proof.md, brand/channels.md, the brief,
  and the list with its signal column.

RULES
- Connection note under 200 characters, no ask.
- Opener under 300 characters, one ask, line one references a
  DATED signal.
- Four touches maximum.
- No wait node after a connection request. Acceptance
  auto-detects over two weeks.
- State the daily split against the ceiling in channels.md.

FAIL CLOSED if the requested volume exceeds the ceiling. Give the
split rather than writing a sequence that restricts the account.

NOT YOUR CALL: sending. Draft only, human approved.

Add a pipeline-analyst in place of pure analytics. Its weekly job is the diagnostic chain, worked in order and stopped at the first failure, returning one change rather than five stages of numbers.

Where the sending happens

No specialist in this team sends anything. That is the governance setting and it should not be relaxed for outbound.

The sequences the outbound specialist drafts run in Prosp: cloud-based, a dedicated residential proxy per connected account, activity paced under the platform's thresholds. The node list maps one to one onto its builder.

For an agency, one account per client profile, all managed from one workspace, with a unified inbox spanning every account so the daily reply pass is one task rather than eight logins.

The figures the pipeline analyst needs come back the same way: requests sent and accepted, messages sent, replies received, per campaign and per account.

Three things to remember

1. Build the reviewer before anything it could review. A gate added after the fact gets skipped the first time something is urgent, and then you do not have a gate, you have a habit.
2. Least context is the quality lever, not the safety one. A specialist handed everything produces output that gestures at everything.
3. Block until verified. A badge on a website is not approval to use it, and the cost of asking is one email against an engagement.

The team drafts it. Prosp sends it 💜

↳ Start a 14 Day Free Trial 💜 ↳ Watch Full Tutorial ▶️