Is there a better way to orchestrate multi-step agent workflows than chaining Skills?

Discussions
, ,
1

I’m using a parent Skill to orchestrate a multi-step workflow (parse input → generate code → run long jobs → report results). Each step has strict input/output contracts, quality gates, and sometimes hour-long background jobs.

Current pattern

Parent Skill

→ Step 1: transform raw input into structured prompt

→ Step 2: generate + validate code

→ Step 3: run computation (often background)

→ Step 4: run evaluation / reporting

  • Parent Skill defines IO contracts, hard-stop rules, and resume via run_id
  • State persisted via a small CLI (context.json, per-step logs)
  • Child Skills use disable-model-invocation: true (explicit invoke only)

What works

  • Skills carry domain knowledge well
  • Explicit invocation avoids accidental triggers
  • File-based state enables resume across long runs

Pain points

  • Parent SKILL.md is very long (~500 lines) — high token cost, hard to maintain
  • Orchestration correctness depends on the agent following instructions reliably
  • Shell allowlist requires literal commands (no variable expansion)
  • Pipeline variants share most logic but duplicate SKILL.md
  • No clear best practice for long-running background steps

Questions

  1. Is Skills-as-pipeline the recommended pattern, or is something else better (Automations, subagents, SDK)?
  2. How do others handle long-running steps without polling or losing context?
  3. Any pattern to reduce SKILL.md size while keeping strict step contracts?
6

You seem to be the expert here … Thanks for the info - all i do is try to keep the entire scope of changes and new dev into managable blocks → research and define scope → create prompt → use prompt to create plan ( i have a detailed planning rule ) → execute plan

I dont use skills to orchestrate anything, in fact i dont use skills at all - but i create and execute lots of plans

7

Thanks for the reply! The reason I rely on skills for orchestration is that my daily work involves fixed workflows. If I were to use a single monolithic skill or plan, I’d run into issues with context length limits and difficulty managing mid-process adjustments. With my current setup, I get the best of both worlds: I can leverage the full skill pipeline while still being able to call upon individual sub-skills as needed.