Compose Skills Without Losing the Thread
Multi-skill workflows work best when state and hand-offs are explicit. I do not want skills communicating through a growing pile of prose that the next model turn has to reinterpret.
- Skill chains and hand-offs
- Shared workflow state
- Structured intermediate outputs
- Parallel versus sequential skills
- Failure propagation
- Idempotency and retry behaviour
The situation
A useful business workflow often needs several capabilities. Prospect research may feed an audit; the audit may feed a redesign brief; the brief may feed outreach; outreach may create a CRM task. That looks like a simple chain until one step fails, produces partial information, is retried, or runs in parallel with another branch.
The naive solution
Let each skill write a prose result into the conversation and rely on the next skill to understand it.
The hidden constraint
Natural-language hand-offs are flexible but weak as system state. Important fields can disappear, a later skill can reinterpret a conclusion, retries can duplicate actions, and nobody can tell which stage actually produced a questionable fact. Once a workflow has business consequences, the chain needs more structure than conversational memory.
The decision
Pass explicit workflow state and structured intermediate outputs between skills. The agent can still reason over those objects, but important facts, statuses, identifiers, approvals, and source references should not depend on reconstructing meaning from prose.
The implementation
I would define intermediate records such as ResearchResult, AuditResult, DraftOutreach, ApprovalDecision, or DeploymentPlan. Each stage records status, inputs, outputs, sources, timestamps, and errors. Parallel skills can write independent branches that a later synthesis skill consumes. Side-effecting operations should have idempotency keys or equivalent controls so a retry cannot accidentally send or charge twice.
The tradeoff
Structured orchestration means more schema design and workflow code. The upside is that failures become recoverable and the business can inspect what happened without replaying an entire model transcript.
The evidence I would look for
I would look for the ability to resume a workflow from a failed stage, rerun one skill without rerunning everything, inspect exactly what information crossed each boundary, and prove that retries do not duplicate irreversible actions.
The reusable lesson
Use language for reasoning and schemas for hand-offs. Agentic does not need to mean stateless or unstructured.
The consultant's questions
- What state is currently passed between skills only as prose?
- Can a failed skill be retried without repeating earlier expensive work?
- Can an irreversible action safely survive a network retry?
- If a final answer is wrong, can you trace which intermediate skill introduced the bad fact?