There is no shortage of AI agents being built today. Give an agent a model, a set of instructions, some context, and access to tools, and it can do impressive things.
The challenge starts when we try to scale that across an enterprise.
Every organization has its own way of getting work done. There are policies to follow, systems to use, approvals to obtain, and years of knowledge spread across documents, applications, workflows, and people. If every new agent has to learn and implement all of that independently, we will eventually end up with hundreds of agents that each carry their own prompts, integrations, permissions, and business logic.
I think there is a better way to approach this: separate the skills from the agents that use them.
Start with business skills
Think about the knowledge work that happens every day: reviewing contracts, researching markets, analyzing customer feedback, interpreting policies, qualifying opportunities, or preparing a business case.
There is usually an established way of doing these things. It may not be documented perfectly, but the knowledge exists.
What if we could package that knowledge as a reusable Business Skill?
A skill could contain the instructions, business knowledge, decision logic, required context, expected output, tools it needs, policies it must follow, and even the criteria for determining whether the work was done well.
This is different from a tool.
A tool gives an agent the ability to do something — search documents, retrieve a record, query a system, or create a document.
A skill describes how to use those capabilities to accomplish something meaningful for the business.
Once we start thinking this way, a Business Skills Marketplace makes sense. It becomes a place where these capabilities can be published, discovered, reused, versioned, tested, and improved.
The important part isn't really the marketplace itself. It's that business knowledge is no longer locked inside a particular agent.
Getting from intent to execution
Having a library of skills is only part of the problem. Something still needs to decide which skill to use, determine whether the prerequisites are available, give the agent the right access, and make sure the outcome is trustworthy.
That's where I see the Agent Harness playing an important role.
Imagine someone asks an agent to perform a business task. Instead of the agent figuring everything out on its own, the harness can help orchestrate the work:
Intent → Identity → Context → Skill → Prerequisites → Agent → Policy → Execution → Evaluation
The skill might say, for example, that it needs access to customer information, document search, and a policy knowledge base.
It shouldn't need to know exactly where those systems live.
The skill declares what capabilities it needs. The harness figures out how those capabilities are provided.
This is also where MCP fits nicely. MCP can provide standardized access to enterprise systems and tools, while the harness determines which of those capabilities the agent should actually receive.
Before anything happens, the harness can answer some basic but important questions:
- Does this skill have everything it needs?
- Does this person have access to the required information?
- Is the agent allowed to use these tools?
- Does a particular action need human approval?
The agent shouldn't be the one deciding what it is allowed to do. That responsibility belongs to the platform around it.
Maybe we don't need an agent for everything
Another thing I've been thinking about is whether every business capability really needs its own permanent agent.
It's easy to imagine where this goes: a research agent, a finance agent, a customer agent, a procurement agent, a policy agent, and dozens more.
Some of those will make sense. But for many tasks, why not assemble the agent when we need it?
If the harness already knows the intent, the skill, the required MCPs, the context, and the policies, it has most of what it needs to build a task-specific agent.
An Agent Plugin could provide the mechanism for doing that:
Agent Template
+
Business Skill
+
Context
+
MCP Capabilities
+
Policies
+
Evaluators
=
Task-Specific Agent
The resulting agent gets what it needs for the job — and not much more.
This changes the conversation from:
"How many agents should we build?"
to:
"How easily can we assemble the right agent for the work?"
I think that becomes a much more scalable question.
Skills should be tested too
There is one more piece that I think is easy to overlook.
If we're going to let agents use business skills, how do we know those skills actually work?
The same harness used to execute a skill can also help validate it.
Basic things like the skill structure, permissions, dependencies, and required MCP capabilities can be checked automatically. Then the harness can create temporary test agents to run realistic scenarios and evaluate the results.
Did the agent follow the skill correctly? Did it use the right information? Did it stay within its permissions? Did it know when to ask for help? Was the final output actually useful?
That gives skills a lifecycle that looks much more like software:
Create → Test → Publish → Observe → Improve
And production usage gives us the feedback to make the next version better.
Where this leads
When these pieces come together, the responsibilities become fairly clear.
The Business Skills Marketplace captures reusable organizational knowledge.
The Agent Harness figures out how to safely apply it.
MCP and enterprise tools provide the capabilities needed to perform the work.
Policy and identity determine what is allowed.
Evaluation and observability tell us whether it actually worked.
The end-to-end model is simple:
Intent → Skill → Agent → Governed Execution → Verified Outcome
For me, that's the interesting part of the skill-driven enterprise.
The goal isn't to see how many agents we can create. It's to make the knowledge an organization already has reusable, give agents a safe way to apply it, and continuously improve those skills based on what we learn.
If we get that right, agents become less like isolated AI applications and more like a new way for people to access and execute the collective capabilities of an organization.
Top comments (0)