PROBLEM

What is true now, what must be true, and what bounds the work

GATE OPENS WHEN

You already run one or more agents and keep rebuilding the same steps
Several workflows share jobs like classify, extract, route, or draft
Changing one step currently means retesting the whole agent
You want a failure attributable to a step, not to “the AI”

GATE HOLDS WHEN

You have one workflow and no plan for a second, so build the agent directly
The steps genuinely cannot be separated without losing the outcome
There is no appetite to own a library once it exists

CONSTRAINTS

The workflows you want covered, with their current steps
Without itThere is no way to tell which jobs recur, so the library has no defensible boundary
Examples of correct and incorrect output for each step
Without itA skill cannot be given a typed contract, and a contract is what makes it testable
An owner for the library after handover
Without itAn unowned library drifts back into private copies inside each agent within months

PRESENT STATE

Your existing agents, step by step, with the duplicates marked
EstablishesWhich jobs already recur, and how many times each one has been reimplemented
What you retest today when a single step changes
EstablishesThe current blast radius, which is the number the library exists to shrink
The last few bad outputs, and how long each took to attribute to a step
EstablishesThe baseline failure-attribution time, before any per-step observability exists
How long your most recent agent took to stand up
EstablishesThe baseline that the first workflow built on the library is measured against

TARGET STATE

The bounded jobs that become skills, and the ones that stay bespoke
Agreed whenEvery candidate job is named and justified by more than one calling workflow
The typed contract for each skill: input, output, and failure shape
Agreed whenEach contract is stated precisely enough to write its harness before its body
The composition rules: how skills chain, branch, and fall back
Agreed whenOne real workflow has been drawn end to end over the proposed library on paper
What each skill reports about itself while it runs
Agreed whenLatency, failure, and confidence are agreed as three separate per-step signals

SUCCESS INVARIANTS

What would have to be observable for this to have worked

ID	Criterion	Verified by	Passes when
SC1	A fix to a shared job ships once	Tracing a single change through every workflow that calls the job	A fix to a shared job ships once and every calling workflow picks it up without its own release
SC2	A change is verified where it was made	The blast radius of a change, measured as the set of suites that must run	A change to one skill is verified by that skill's harness alone, with the calling workflow unmodified
SC3	A failure names the step that produced it	Reading the per-step record for a sample of failed runs	A failure names the step that produced it, and that step's latency and confidence are on the record beside it

Done stateAll three criteria hold across every workflow that shares the skill set, not across one of them.

DECONSTRUCT

How the distance was cut, and what each part advances

Cut byWhere a repeated job costs more than it should: building it, changing it, diagnosing it. Ordered so each part removes a dependency the next one would otherwise inherit.

D1The same job is implemented once per agent, so a fix ships three times or not at all
Completes whenLifting each recurring job into one skill behind a typed contract, called by every workflow that needs it
AdvancesSC1
D2Changing one step means retesting a whole agent, because nothing states where that step ends
Completes whenA harness per skill, which makes the blast radius the changed module rather than the calling workflow
AdvancesSC2
D3A bad output is attributed to the AI, because no step reports on itself
Completes whenLatency, failure, and confidence reported per step, so a failure names the step that produced it
AdvancesSC3

PRIORITISE

Which part runs first, and the function that decided it

Ranked by(impact x verifiability x urgency) / max(cost, 1), highest first.

Part	Factors	Score	Why it ranks here
D1	5 x 4 x 5 / 2	50	Nothing else is cheap while the same job exists three times, so the lift comes first.
D2	4 x 5 x 4 / 2	40	A harness is only definable once the module it tests has an edge, which the lift is what creates.
D3	4 x 4 x 3 / 2	24	Reporting is per step, so it is written against steps that already exist and is the last to be affordable.

DESIGN

Want to see which steps should become shared skills, and why?

Describe the steps your agents keep repeating and the AI Automation Audit Agent will design the library that replaces them. It returns a build-ready system design for the workflow you describe, alongside modelled savings, a payback range, ranked opportunities, and a sequenced build plan. The run takes about a minute and costs nothing.

Five inputs. Answer them for the workflow the duplicated steps sit inside, not for the library.

TriggerWhat starts the workflowFor example: Any of three agents reaches the point where an inbound document has to be classified and routed.ProcessActual step-by-step flow + monthly volume + blended labor cost assumptionsFor example: Each agent separately classifies, extracts fields, then routes. About 900 runs a month, with maintenance at roughly $45/hour.SystemsSystems in scope + real constraintsFor example: Three agent codebases, one shared vector store, and the ticketing API. Two of the three run on a fixed model version.RulesApproval, compliance, and escalation guardrails that actually applyFor example: A low-confidence classification escalates instead of routing, and every routing decision is logged for audit.ResultDesired business outcome + success criteriaFor example: One tested skill behind all three agents, changes shipped once instead of three times, and failures attributable to a named step.

0 of 5 inputs answered.

Run the Audit Agent Open the Audit Agent

How an engagement of this shape is ordered.

TRANSFORMATION PROCESS

How one becomes the other

WHAT IT CHANGES

The skill library: bounded jobs, each with a typed input and output
Per-skill validation harnesses and regression checks
The orchestration layer that chains, branches, and routes them
Per-step observability across latency, failure, and confidence

WHAT IT LEAVES ALONE

Agents that already work and are not changing
Jobs that happen once
Model training, since these are composed capabilities rather than custom models

Skill build
1–2 weeks per batch
Exit criterionEach module meets its contract and passes its own harness in isolation
Composition
1 week
Exit criterionWorkflows run end to end over the library, with policy checks and declared fallbacks
Instrumentation
2–3 days
Exit criterionEvery step reports latency, failure, and confidence separately
Handover
2–3 days
Exit criterionYour team can add or replace a skill without touching its neighbours

Durations are indicative and firm up once the target state is agreed.

SEQUENCING RULES

Why the work runs in this order, and what each rule prevents

Each skill passes its own harness in isolation before anything composes it
PreventsA library whose failures can only be reproduced by running a whole workflow
Contracts are written before bodies, and composition follows contracts
PreventsA contract reverse-engineered from its first caller, which is a private helper wearing a library's name
Instrumentation lands before handover, not after the first incident
PreventsA library owned by a team that cannot see which step failed

BUILD INVARIANTS

What holds in every build, and what is never shipped

HELD IN EVERY BUILD

Every skill states its input, its output, and its failure shape before its body exists
Every skill passes its harness without a calling workflow present
Every step reports latency, failure, and confidence as three separate signals

NEVER SHIPPED

A skill whose contract is inferred from its first caller
A private copy of a shared job living inside one agent
A fallback that substitutes a different outcome without saying so

QUALITY GATE

What is checked before it goes live, and what each check returns

Check	Evidence	Passes when
Contract conformance	Each skill run against its own harness in isolation	Input, output, and failure shape match the declared contract
Composition integrity	One full workflow run end to end over the library	Policy checks fire, and the fallbacks taken are the declared ones
Regression closure	Every harness re-run after every change	No skill's pass rate falls below its last green run
Failure attribution	A deliberately failed step traced from the workflow output	The failing step is named without anyone reading the code

SUCCESS EVALUATION

How you would tell it worked

Measure	Baseline	Success direction
Skills reused across workflows	One, at first use of each module	Up, because reuse is the entire point
Time to stand up a new workflow	Your last agent build, timed	Down as the library grows
Change blast radius	What you retest today for a one-step change	Down to the changed module
Failure attribution time	Time taken to locate the cause of the last bad output	Down
Per-skill pass rate	Each harness at its first green run	Held or up after every change

SOLUTION OUTPUTS

What you have when the engagement finishes

The skill library, each module carrying a typed contract
A validation harness per skill, runnable on demand
The orchestration layer with policy checks and declared fallbacks
Per-step observability across latency, failure, and confidence
A worked example: one full workflow composed from the library
A guide for adding, replacing, or retiring a skill

HANDOVER

How the system stops being ours and becomes yours

Your team adds and replaces a skill without touching its neighbours
TransfersThe right to grow the library, which is the whole reason it exists
The composition layer is walked with a workflow you choose
TransfersUnderstanding of how skills chain, branch, and fall back under policy
The library's owner is named before we leave
TransfersOwnership, without which the library drifts back into private copies inside each agent

OVERVIEW

Skills are the building blocks inside an Agent. Each skill handles one bounded job: classify a request, extract entities, route an action, draft a response. Instead of treating these as standalone products, we design them as composable modules that can be reused across multiple agent workflows, validated on their own, and upgraded without rebuilding the agent around them.

ARCHITECTURE

Each skill is a self-contained unit of instructions, tool access, and guardrails that can be validated in isolation. The orchestrator chains or routes these units through linear and branching workflows, delivering reliable execution, controlled retries, and module-level upgrades without rebuilding the entire agent. Because every skill declares a typed input and output, a skill can be swapped for a better implementation without touching its neighbours.

SYSTEM ARCHITECTURE

┌────────────────────────────────────────────────────────────────────────┐
│                         AGENT WORKFLOW REQUEST                         │
└────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│                       SKILL ORCHESTRATION LAYER                        │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│   ┌────────────────────────────────────────────────────────────────┐   │
│   │                             ROUTER                             │   │
│   │      Trigger match · precondition check · skill selection      │   │
│   └────────────────────────────────────────────────────────────────┘   │
│                                   │                                    │
│                                   ▼                                    │
│   ┌────────────────────────────────────────────────────────────────┐   │
│   │               SKILL LIBRARY  (composable units)                │   │
│   │ ┌────────────────────────────┐  ┌────────────────────────────┐ │   │
│   │ │     Classify · Extract     │  │   Route · Draft · Enrich   │ │   │
│   │ │    typed input + output    │  │    typed input + output    │ │   │
│   │ └────────────────────────────┘  └────────────────────────────┘ │   │
│   └────────────────────────────────────────────────────────────────┘   │
│                                   │                                    │
│                                   ▼                                    │
│   ┌────────────────────────────────────────────────────────────────┐   │
│   │                        COMPLETION GATE                         │   │
│   │        Per-skill validation · retry · declared fallback        │   │
│   └────────────────────────────────────────────────────────────────┘   │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│              COMPOSED RESULT  +  PER-SKILL OBSERVABILITY               │
└────────────────────────────────────────────────────────────────────────┘

FUNCTIONALITY

CAPABILITY DESIGN

Bounded capability design with explicit trigger, validation rules, and completion criteria
Typed input and output per skill so a module can be replaced without touching its neighbours

THE LIBRARY

Reusable modules for classification, extraction, enrichment, routing, and response generation
Each module reused across workflows rather than rebuilt per agent

VALIDATION

Per-skill validation harnesses and regression checks before orchestration rollout
Isolated testing so a failure is attributable to one module, not to the whole agent

ORCHESTRATION & OBSERVABILITY

Composable orchestration so skills can be chained, branched, or swapped without rewriting the agent
Observability per skill step to identify bottlenecks, failures, and confidence drops

HOW IT WORKS

We define the skill library first, then map each agent workflow to the minimum set of required skills. Each module is validated in isolation, then integrated into the orchestration layer with policy checks and fallback behaviour. An inbound lead triage chain, for example, can classify request type, extract urgency and intent, route to the right owner, and draft a first response. As requirements evolve, we update or add specific skills instead of reworking the entire agent.

STEP-BY-STEP GUIDE

Define the skill library: the bounded jobs your workflows keep repeating.
Map each agent workflow to the minimum set of skills that completes it.
Specify each skill's trigger, validation rules, and completion criteria as a typed contract.
Validate every module in isolation with its own harness and regression checks.
Compose the validated modules in the orchestration layer with policy checks and fallback behaviour.
Instrument each step, then evolve by updating or adding individual skills rather than rebuilding the agent.

OUTCOMES

Typically faster agent delivery by reusing tested capability modules.
Higher reliability potential through isolated testing and per-skill guardrails.
Improved long-term change agility because modules can evolve independently.
Failures attributable to a single module, which shortens diagnosis and repair.

CONTACT

Got agents that keep rebuilding the same steps?

Describe the steps your agents keep repeating and receive a proposal with next steps within 24 hours.

AI Agent Skills