Skills Are a Start, Not the System

We finally learned that the prompt was not the product.

Then we put the prompt in a folder, added a few tools, called it a skill, and started repeating the same mistake at a higher level.

Skills are everywhere now. There are skills for research, code review, presentation building, incident response, data analysis, customer support, and nearly every other repeatable task. Teams are building internal libraries. Vendors are turning skills into marketplaces. Developers are treating them as the new unit of agent capability.

This is useful work.
It is also not the next architecture.

A skill can make an agent better at doing something. It cannot, by itself, determine whether that thing should be done, whether the agent has authority to do it, which evidence is required, how the result should be verified, what happens when it fails, or whether the capability still creates value six months from now.

Those are different engineering problems.

We keep collapsing them into the word agent because the model sits in the middle of the picture. But the model is not the system, and neither is the skill wrapped around it.

The missing move is from a catalog of capabilities to the system organized around them, one that can direct, constrain, and improve their use.

Each boundary solves a different coordination problem.

And each time we treat one artifact as the complete system, we mistake a useful component for the architecture that makes it valuable.

This is not a simple pipeline where one layer hands work to the next.

The relationship is containment.

Skills operate inside workflows. Workflows execute inside harnesses. Factories produce and manage the whole portfolio.

Notice the relationship changes at the top, and that is deliberate. Three layers nest at runtime. The factory does not sit inside that stack or wrap it at execution time. It produces the stack, watches it run, and decides when it changes.

If you want the hierarchy in one familiar breath: a skill is a function, a workflow is a program, a harness is the runtime the program executes inside, and a factory is the build system and operations platform that creates, ships, and manages all of it.

None of this replaces the loop. A loop is the motion underneath every layer: observe, decide, act, evaluate, and return different than you left. I have argued elsewhere that the loop, not the prompt, is the unit of AI engineering, and that a real loop does not just repeat, it climbs. The layers describe what that motion is made of and who governs it.

The skill is capability inside the loop.
The workflow directs it toward an outcome.
The harness owns the conditions under which it runs.
The factory learns across many of them.

Skills are the new prompts

Prompt engineering focused attention on the instruction given to a model.

Write a better role. Add examples. Specify the output. Ask the model to reason. Tune the wording until the response looks right.

The industry eventually discovered that production failures rarely come down to one badly phrased sentence. The model lacked current context. Retrieval returned the wrong source. Permissions were too broad. No evaluator checked the answer. The output landed outside the user's actual workflow. Nobody knew when a human should intervene.

That realization moved the conversation from prompt engineering toward AI system design. A recent Built In article captures that entry-level shift well: context, retrieval, evaluation, governance, and workflow fit become part of the picture.

That is the right direction.
It still stops early.

Skills are a natural continuation of that shift. They package instructions, examples, scripts, and tools into reusable capabilities. Instead of rebuilding the same behavior in every conversation, a team can define it once and make it available across agents.

Good. We should do that.

But a skill is still mostly an answer to this question: How should an agent perform this kind of task?

Production systems must answer a much larger set of questions:

• When should this task run?
• What state should enter with it?
• Which systems and data may it access?
• What decisions may it make?
• What evidence must it produce?
• How will the output be evaluated?
• What happens when evidence conflicts?
• When must it stop or escalate?
• How does the next run learn from this one?
• Who is accountable for the result?

Adding more instructions to the skill does not solve these questions.
It only makes the skill larger.

We saw this with prompts. When a model failed, teams added another paragraph to the system prompt. The prompt became a junk drawer for policy, context, workflow, tone, exceptions, and recovery behavior.

We are at risk of doing the same thing with skills.

A skill is a capability.
A collection of skills is a catalog.
Neither is an operating system for work.

Capability is not an outcome

A skill gives the agent a technique.

Imagine a skill that can review a vendor contract. It may know how to identify renewal terms, liability clauses, data-handling obligations, and nonstandard language. It may produce an excellent summary.

That is a useful capability.
It is not vendor onboarding.

The organization must still collect the vendor's information, validate tax and banking data, assess security posture, compare contract terms against policy, route exceptions, obtain approvals, create records in procurement and finance systems, notify owners, and preserve evidence for audit.

That is a workflow.

A workflow coordinates capabilities toward an operational outcome. It carries state from one step to the next. It manages dependencies. It waits for events. It routes exceptions. It creates a record of what happened.

The skill reviews the contract.
The workflow gets the vendor approved and ready to do business.

This sounds obvious when written out. Yet much of the agent conversation still treats the presence of several skills and a planning loop as if a business process has been built.

It has not.

A bag of capabilities is not a workflow for the same reason a box of tools is not a construction project. The value appears when the tools are coordinated against a real outcome, under real constraints, with someone accountable for the result.

The agent may own an action.
The workflow owns the outcome.

Coordination is not control

A workflow defines what must happen. It does not, by itself, make that execution safe or trustworthy.

The path may say that a contract must be reviewed before approval. It does not inherently know whether the person starting the workflow is allowed to view that contract. It does not know which policy version applies, how extracted clauses should be checked against the source, whether a missing security exhibit blocks the entire run, or which decisions the model is authorized to make.

Those are execution conditions.

The harness wraps the workflow and defines the terrain on which it may run.

A production harness surrounds the complete workflow, including its models and skills, with the controls required for safe execution:

• Identity, role, and access control
• Approved context and domain knowledge
• State and memory boundaries
• Tool permissions and budget limits
• Planning and execution separation
• Evaluation and evidence requirements
• Stop conditions and escalation paths
• Audit trails, recovery, and rollback
• Telemetry from the real outcome

You do not need all of it on day one. A minimum viable harness is one engineer's sprint around one workflow:

• Stop conditions, so a run that goes strange halts instead of compounding
• Tool permissions scoped to the narrowest surface that does the job
• A budget the workflow cannot negotiate with
• An evaluation that gates promotion, even if it starts as ten cases in a file
• A log of what ran, what it touched, and who approved it

Five controls, one sprint, no platform team required. The list above is what those five grow into as the workflow earns trust.

This is why a graph of agent nodes is not automatically a harness. A graph can answer which node runs next. A harness answers what work may enter, what the system may decide, what proof is required, how failure is detected, and how the workflow recovers.

The skill knows how to review the contract.
The workflow coordinates the complete onboarding process.
The harness determines whether that process can be trusted.

The difference is not orchestration.
It is operational control.

Workflows create a new problem

Once teams make this jump, another trap appears.

They start building harnessed workflows.

Lots of them.

One for vendor onboarding.
One for contract review.
One for invoice reconciliation.
One for customer escalation.
One for audit evidence.

Each one gets its own prompts, skills, routing logic, harness configuration, policy checks, integrations, evaluation cases, and dashboards.

The first few look like progress. By the twentieth, the organization has created a new form of sprawl.

Workflows are operational software. They depreciate.

Policies change. APIs drift. Models behave differently. Source systems move. Evaluation sets become stale. Domain language evolves. Exceptions accumulate. A workflow that was safe and useful when deployed can quietly become expensive, brittle, or wrong.

This is not a reason to avoid workflows. It is the reason to stop treating each one as a handcrafted destination.

If an organization expects machine-executed work to spread, it needs a system responsible for the lifecycle of that work.

That system is the factory.
The factory is the system that creates systems of work.

The factory is the missing architecture

The word factory invites the wrong mental image if we are not careful.

It does not mean an uncontrolled swarm producing endless agents. It does not mean removing humans from the organization. It does not mean generating workflows and immediately turning them loose in production.

A factory is a governed system for discovering, creating, testing, deploying, observing, improving, and retiring machine-executed work.

It operates above any single harnessed workflow.

The factory holds the capabilities that should not be rebuilt inside every harnessed workflow:

• A registry of approved skills, harnesses, policies, and integrations
• Identity and access enforcement that workflows inherit instead of reimplement
• Shared domain knowledge, and routing that puts the right context in front of the right workflow
• Standard evaluation, simulation, and adversarial testing
• Promotion, rollback, and release gates, with autonomy levels earned on evidence
• Observability across quality, cost, risk, and intervention, wired to trigger revision or retirement

The factory does not replace the harness around a workflow. It produces and governs a portfolio of harnessed workflows.

Those harnesses should be named for the operating boundary they own: an Engineering Delivery Harness, a Vendor Operations Harness, a Customer Support Harness, or a Risk and Compliance Harness. The shared factory is horizontal. The harness is where domain policy, context, authority, and evaluation become concrete.

The factory also supplies a shared domain ontology as rails. It defines the terms, permitted states, evidence rules, and decision boundaries that keep each harness grounded in the business rather than drifting into generic agent behavior.

That also settles where the overlapping words live. The factory holds the definitions: approved skills, policy versions, standard evaluation suites, and identity rules.

Each harness enforces an instance of them at runtime. If you changed what counts as passing, you changed the factory's standard. If you changed what happens when this workflow fails tonight, you changed the harness.

This is the missing boundary in most enterprise agent strategies. Teams are encouraged to build agents and skills from the bottom up, but few are building the operating system that decides which combinations are approved, how they move into production, or how the organization learns across them. Much of what is sold under that banner today is a dashboard over traces.

The result is predictable.

Every team creates its own miniature platform. Governance arrives as a review meeting. Evaluation becomes a spreadsheet. Access control gets buried in tool code. Observability stops at traces and token counts. Nobody can say whether the work itself improved.

A real factory measures yield, not activity.

Did the workflow complete successfully? How often did a human intervene? Did the result pass its behavioral checks? What did recovery cost? Did cycle time improve? Did the workflow produce the intended operational outcome? Is it still worth running?

Token consumption may help explain the bill. It does not tell us whether the factory works.

Harness capabilities are becoming products: sandboxes, permission brokers, evaluation runners, and audit infrastructure. Buy them where they fit. The factory's judgment, which context matters, which evidence predicts success, which exceptions deserve a person, is the accumulated record of your own operations. A vendor can sell you plumbing. Nobody can sell you your operating judgment.

Vendor onboarding, one boundary at a time

The distinction becomes clearer when each artifact is applied to the same job.

There is a familiar software analogy underneath this:

A function performs a task.
A program coordinates functions toward an outcome.
A runtime controls how the program executes.
A factory builds, tests, deploys, observes, upgrades, and retires programs.

The analogy also breaks, and it breaks exactly where the new engineering lives. A deterministic function returns the same answer twice. A skill does not, so evaluation replaces assertion and passing becomes a distribution instead of a bit. A program fails reproducibly. A workflow's failures include fluent answers to questions nobody asked, which no stack trace will surface. A runtime limits resources. A harness must limit decisions. A build system promotes code. A factory promotes authority, one evidence-backed increment of decision rights at a time.

The important movement is not from less autonomy to more autonomy.

It is from isolated capability to governed operational learning.

At first, the factory may produce a harnessed workflow that drafts recommendations while humans make every consequential decision. As evidence accumulates, specific decisions can move into the system. Standard contracts may pass automatically. Known exceptions may route directly to the correct reviewer. Low-risk vendors may move faster. Novel cases may receive more scrutiny.

Autonomy increases because the evidence supports it, not because someone changed a global setting from “copilot” to “agent.” The point is to move decision rights deliberately, with evidence and accountability attached.

That is a policy-governed improvement loop.

It also preserves a critical role for people. Humans define intent, establish policy, judge exceptions, set risk tolerance, review evidence, and decide where decision rights should move next.

The goal is not to get the human out of the loop.
The goal is to stop using the human as the loop!

What actually compounds

Skills can be reused. That gives them value.

But reuse alone is not the same as compounding.

A library of one hundred skills may give an organization more things an agent can do. It does not necessarily make the ninety-ninth workflow safer, faster, or easier to build than the first.

A factory should.
That is the test.

Every production workflow should strengthen the system that produces the next one. Its traces reveal missing context. Its failures expand evaluation suites. Its exceptions refine policy. Its interventions reveal where autonomy is premature. Its successful paths become candidates for deterministic execution. Its operational results improve how future work is selected and designed.

The durable asset is not the individual instruction file or workflow definition. It is the organization's growing ability to turn intent into governed, measurable work.

That is where the learning accumulates.

It is also where competitive advantage begins. Models will continue to improve. Skills will be shared, copied, bundled, and commoditized. Orchestration libraries will make agent graphs easier to assemble.

None of that gives an organization its operating judgment.

The hard-won knowledge lives in the factory: which context matters, which evidence predicts success, which exceptions deserve escalation, which controls prevent failure, which workflows create value, and how safely decision rights can move.

Build the boundary you are missing

This is not an argument to stop building skills.

It is an argument to know what you are building.

If the problem is inconsistent task execution, build a skill.
If the problem is coordinating work toward a business result, build a workflow.
If the problem is unsafe or unreliable execution, wrap that workflow in a stronger harness.
If the problem is that every workflow must be handcrafted, governed, observed, and repaired independently, build the factory.

Most organizations will need all four. The mistake is expecting one artifact to absorb the responsibilities of another.

That produces giant skills, brittle workflows, hidden policy, duplicated controls, and an expanding collection of agent demos that never become an operating capability.

There is a simple test for which boundary you are changing:

• Change how a task is performed, its instructions, tools, or examples, and you changed the skill.
• Change the business process and you changed the workflow.
• Change permissions, evaluation, stopping, recovery, or authority and you changed the harness.
• Change how workflows are created, promoted, observed, improved, or retired across the organization and you changed the factory.

The more useful architecture is explicit:

A prompt shapes a response. A skill packages a capability. A workflow coordinates capabilities into an outcome. A harness governs its execution. A factory determines which workflows should exist and keeps them fit for use.

The industry is moving beyond prompt engineering. That is real progress.
But if we stop at skills, we have only made the prompt easier to carry around.

The next step is not a larger catalog of things agents know how to do. It is the engineering system that can turn those capabilities into bounded work, learn from operations, and improve inside gates humans designed.

Once that system exists, the workflow stops being the asset.