Pipeline Strategy Layer: Connecting Advisor Agents to Executor Skills

Defining an advisor agent is not enough to wire it into a pipeline.

When @seo-director was first defined as an agent in Yakumo’s content pipeline, nothing changed. The agent document described its responsibility for keyword design, and it was placed in Claude Code’s agents/ directory. Yet all three pillar articles (reset-timeline / mcluhan-engine / bateson-engine) moved forward without an SEO strategy layer, and the gap only surfaced during the brief review stage for bateson, when the user raised the issue.

The cause was simple: @seo-director had no invocation route in the pipeline JSON. Defining an advisor and wiring it into the pipeline are two different things. This article explains the design pattern for formalizing advisor agents as phase 0 in the pipeline JSON and propagating upstream strategic decisions to downstream executor skills through the brief YAML as a hub.

→ For the full picture of Claude Code agents / skills harness design, see AI Agent Harness Design Principles.

Patterns Where Advisor Agents Go Missing from the Pipeline

Defined but No Invocation Route in the Pipeline JSON

Placing an agent definition in Claude Code’s agents/ directory alone will not cause the pipeline to invoke it.

When reviewing the phase list in blog-ops/config/pipelines/rewrite-tech.json / rewrite-case.json, there was no invocation of @seo-director. The only SEO-related touch point was the /blog-meta skill at the final phase — effectively positioning SEO as a post-writing cleanup step for title and description.

@seo-director existed as an advisor, but from the orchestration perspective it was indistinguishable from a nonexistent agent. Any design that relies on the main thread to proactively remember and invoke an advisor will inevitably fail during busy sessions.

Relying on Main Thread Proactive Invocation Leads to Forgetting

Leaving the advisor invocation up to the main thread’s judgment introduces two problems.

First, timing becomes ambiguous. If the pipeline documentation does not specify whether to invoke @seo-director before brief generation or after writing, the timing will vary every time.

Second, it gets forgotten entirely. Pipeline execution proceeds stage by stage. The realization that SEO design was needed — after phase 1 brief generation is done — typically arrives halfway through phase 2 writing.

The incident that surfaced on 2026-05-18 illustrates this. reset-timeline and mcluhan shipped with only a description retrofit (no changes to title, H2, or body). bateson was caught at the brief stage, so it was addressed before publication. The remediation commit is cc935f4 (2026-05-18 16:28:55), which simultaneously retrofitted the seo section and wired @seo-director into the pipeline JSON (see blog-ops/retros/2026-05-18-seo-missing-from-pipeline.md).

The Pattern: Wiring Advisors as Phase 0 in the Pipeline JSON

Phase 0 = Advisor, Phase 1+ = Executor

The fix is straightforward: formalize the advisor as the first phase in the pipeline JSON.

new-article-pillar.json and new-article-spoke.json were both created in cc935f4 on 2026-05-18. Running git log --follow confirms that the first commit for both files is cc935f4 (2026-05-18 16:28:55).

The revised structure of new-article-pillar.json:

{
  "stages": [
    {
      "phase": 0,
      "step": "seo",
      "runner": "@seo-director",
      "model": "sonnet",
      "trigger": "on pipeline start",
      "description": "Pillar cluster SEO design. Determines primary_keyword / secondary_keywords / longtail_clusters / search_intent"
    },
    {
      "phase": 1,
      "step": "plan",
      "runner": "blog-plan",
      "depends_on": ["seo"],
      ...
    }
  ]
}

The depends_on: ["seo"] field matters. Phase 1 brief generation assumes that phase 0 SEO design is complete. The pipeline execution engine reads this dependency and cannot skip phase 0 and advance to phase 1.

The current new-article-pillar.json and new-article-spoke.json consist of 13 phases from phase 0 (@seo-director) to phase 10 (blog-graph), with @seo-director wired in at phase 0.

Advisor Output Format — Writing to a Specific Section of the Brief YAML

The advisor agent’s output is written to the seo: section of the brief YAML in the following format:

seo:
  primary_keyword: "content cluster persona"
  secondary_keywords:
    - "pillar narrative 設計 audience"
    - "コンテンツ SSOT persona taxonomy"
  longtail_clusters:
    - "cluster と persona の違いとは何か"
  search_intent: "informational"
  serp_title_finalized: "..."
  serp_description_finalized: "..."

@seo-director is designed as an advisor that returns a draft to the main thread. The actual YAML write is performed by the main thread. This design preserves the structure where the main thread holds final judgment without the advisor directly editing files.

Designing Strategy Propagation with Brief YAML as the Hub

The Contract: Each Executor Skill Reads Its Specific Section of the Brief

Writing the advisor’s output to the brief YAML is not enough on its own — it won’t reach downstream skills. Upstream strategy propagates to downstream executors only when each executor skill has an explicit contract to read its specific section of the brief.

The blog-tech-write skill executes the following in brief-driven mode:

SEO_SECTION=$(python3 -c "
import yaml
d = yaml.safe_load(open('blog-ops/articles/{slug}.yaml'))
seo = d.get('seo', {})
print(f\"primary_keyword: {seo.get('primary_keyword', '')}\")
print(f\"secondary_keywords: {seo.get('secondary_keywords', [])}\")
")

The retrieved SEO data is passed to the LLM prompt, instructing it to naturally incorporate the primary_keyword into H2 headings and place secondary_keywords throughout the body.

Example: The seo Section Inherited by tech-write, review, and meta

The brief’s seo section is inherited by each executor as follows:

This inheritance chain ensures that the advisor’s (@seo-director) output is consistently reflected through writing, review, and meta configuration. Even if the advisor is swapped out (e.g., when @seo-director’s implementation is updated), no executor implementation needs to change — because the brief YAML is functioning as the hub.

Benefits of the Hub Design

The key benefit of advisor and executor communicating through the brief YAML is loose coupling.

@seo-director is solely responsible for writing the seo section of the brief YAML. blog-tech-write is solely responsible for reading it. Both sides only reference the brief’s schema as a shared interface — neither needs to know the other’s implementation.

This is a critical design for maintaining pipeline modularity. If the advisor’s output specification changes, only the brief schema and @seo-director’s implementation need updating — each executor automatically reads and adapts to the schema change.

Detecting Missing Strategy Sections with Gates

blog-gate G11: Failing on Missing seo Section in Pillar Briefs

Formalizing the advisor as phase 0 alone cannot guarantee that the advisor was actually executed. Gates are used as the mechanism to enforce execution.

The G11 extension in scripts/blog-gate.ts (seo section variant) returns fail when any of the four fields — seo.primary_keyword / seo.secondary_keywords / seo.search_intent / seo.serp_title_finalized — are missing from a brief where is_pillar: true.

G11 extension: required seo section check for pillar briefs
  condition: brief.is_pillar === true && any of the four required seo section fields is missing
  result: fail
  reason: pillars carry the cluster's keyword axis. A pillar written without SEO design requires after-the-fact retrofitting

Protecting the seo section with a gate means the pipeline cannot advance if @seo-director was not executed at phase 0. Advisor execution becomes structurally mandatory.

Gating the Strategy Section Enforces Advisor Execution

Leaving the decision to invoke the advisor up to the main thread means it won’t happen on a busy day. Designing the gate as “cannot advance without evidence that the advisor ran (the seo section)” makes advisor execution a structural prerequisite of the pipeline.

This separation of judgment (advisor) from execution (executor) is also a cost separation. According to the “AI Subscription Time Bomb” report, GitHub Copilot is moving to usage-based billing from June 1, 2026, and OpenAI is projected to burn through $115 billion cumulatively by 2029. A pipeline design that runs the advisor once on Opus and delegates executors to Sonnet / Haiku is simultaneously a token strategy for “confining high-cost model usage to the judgment phase.” Once fixed subscriptions stop acting as subsidies, whether this separation exists will directly affect operational costs.

This is implemented as part of G11. checkG11_PillarSeoSection() collectively checks the four fields across the cluster / audience.primary / seo sections. The comment in blog-gate.ts explicitly states “G11: missing cluster / audience.primary / seo section in pillar article brief” (L572-577).

Running git show --stat on cc935f4 shows that the pipeline JSON changes span four files: new-article-pillar.json (new), new-article-spoke.json (new), rewrite-case.json (modified), and rewrite-tech.json (modified). The same commit also includes .claude/agents/seo-director.md, three related skill files, scripts/blog-gate.ts, src/content/config.ts, and others.

Summary — Three Elements for Wiring an Advisor into the Pipeline

An advisor agent works only when it is built into the pipeline. The design requires three elements.

1. Formalize as phase 0 in the pipeline JSON: Declare the advisor’s invocation route as the first phase in the pipeline. Use depends_on so that downstream executors require the upstream advisor’s completion.
2. Strategy propagation via brief YAML as hub: Write the advisor’s output to a specific section of the brief, and make explicit the contract for each executor to read the brief. A loosely coupled design where advisors and executors never communicate directly.
3. Gate-based detection of missing strategy sections: Fail the pipeline if there is no evidence the advisor ran (i.e., the specific section of the brief is absent). Advisor execution becomes structurally enforced.

With all three elements in place, the advisor transforms from “an agent that exists but is never used” into “a strategy layer built into the pipeline design.”

If you’ve built an advisor and found yourself wondering “why isn’t it being used?” — check the pipeline JSON first. Without an invocation route, the advisor won’t run.

→ For details on per-cluster SEO keyword design and keyword map maintenance, see Cluster SEO Implementation — Flowing Pillar Primary Keywords Down to Spoke Secondaries.