Skills, Agents, and Tools: The Architecture Developers Need to Understand
- Mark Kendall
- 3 hours ago
- 9 min read
Skills, Agents, and Tools: The Architecture Developers Need to Understand
From knowing how to do the work, to deciding what work to do, to actually doing it.
I am currently in what I call Learn → Teach → Master mode.
I haven’t reached Master yet.
In fact, one of the reasons I’m digging so deeply into agentic engineering right now is simple: I recently discovered some very specific gaps in my own understanding. Rather than memorize enough terminology to get through a certification exam, I want to understand the architecture well enough that I can explain it to another developer and actually build it.
And one distinction has become particularly important:
Skills, agents, and tools are not competing approaches. They are different layers of the same system.
The simplest way I’ve found to remember the relationship is:
Skills provide knowledge.
Agents provide reasoning.
Tools provide action.
Or:
Know → Think → Do.
That simple model explains a surprising amount of modern agentic software engineering.
1. Start With Intent
Before skills, agents, or tools, there should be a reason for the system to do anything.
That’s the intent.
Suppose we’re building an enterprise integration adapter.
The intent might say:
Create a TMF632 adapter that consumes an approved
organization-account request and creates the appropriate
Salesforce account hierarchy.
Preserve existing repository architecture and Salesforce
integration conventions.
Reuse existing capabilities wherever possible.
Make the smallest safe implementation change.
Notice what we haven’t told the system.
We haven’t said:
Open file X.
Change line 73.
Run command Y.
Call API Z.
We’ve defined the desired outcome and constraints.
That distinction becomes important once agents enter the picture.
The architecture starts here:
INTENT
"What do we want?"
│
▼
ORCHESTRATOR
│
"How do we achieve it?"
Now the agent needs capabilities.
That’s where skills, subagents, and tools enter.
2. Skills: How Our Organization Does Something
A skill represents reusable knowledge about how a particular kind of work should be performed.
For example, imagine that our company builds dozens of integration adapters.
We don’t want every developer—or every AI coding agent—to rediscover the architecture every time.
We might create an:
enterprise-adapter-scaffolding skill
That skill could teach the agent:
How to identify the correct reference adapter
How to inspect its architecture
How to preserve authentication patterns
How to preserve Kafka conventions
How to preserve logging
How to preserve error handling
How to preserve deployment configuration
How to identify the requested delta
How to generate the smallest safe scaffold
How to validate the result
The important thing is that the skill represents organizational knowledge.
Think:
“This is how we do this here.”
A skill should not automatically become an enormous application.
It is guidance that helps an agent perform a reusable task consistently.
3. Agents: Reason About the Problem
Now we need something capable of making decisions.
That’s the agent.
Suppose our orchestrator receives:
Build the TMF632 Salesforce adapter.
Instead of loading the entire repository, architecture, security model, Salesforce implementation, test suite, and deployment infrastructure into one giant context, the orchestrator can delegate focused investigations.
ORCHESTRATOR
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Architecture Salesforce Testing
Agent Agent Agent
│ │ │
repo patterns SF patterns test patterns
Each subagent has a narrow job.
The architecture agent might answer:
{
"referenceAdapter": "existing-tmf-adapter",
"architecture": "kafka-outbound-adapter",
"newArchitectureRequired": false
}
The Salesforce agent might return:
{
"pattern": "pre-existence-query",
"reference": "resolveOpportunity",
"reuse": [
"escapeSoqlLiteral"
],
"recommendation": "implement resolveParentAccount"
}
The testing agent might return:
{
"requiredTests": [
"create new parent",
"reuse existing parent",
"create billing account",
"omit optional website",
"do not resend create-only defaults"
]
}
Now something interesting has happened.
The orchestrator knows substantially more about the problem without carrying every file each investigator inspected.
That’s one of the major benefits of subagents:
context isolation.
4. Tools: Now Go Touch Reality
Eventually reasoning isn’t enough.
An agent needs information it doesn’t possess.
Or it needs something in the outside world to change.
That’s where tools come in.
The MCP specification describes tools as executable functions that allow models to retrieve information or perform actions. Tools can query databases, call APIs, perform computations, write files, and interact with other systems. (Model Context Protocol)
For example:
Salesforce Agent
"I need to determine whether
Parent Account 12345 exists."
│
▼
querySalesforceAccount
│
▼
Salesforce API
│
▼
{
"exists": true,
"salesforceId": "001..."
}
That is fundamentally different from a skill.
The skill told us:
Query Salesforce for an existing parent before creating another one.
The agent decided:
I need to perform that lookup now.
The tool did it:
Parent exists. Salesforce ID = 001…
That gives us:
SKILL
"Here's how we do it."
↓
AGENT
"Here's what I need to do."
↓
TOOL
"I'll actually do it."
↓
RESULT
"Here's what happened."
5. The Tool Result Goes Back to the Agent
This part is critical.
Calling a tool isn’t necessarily the end of the workflow.
The result goes back into the reasoning loop.
Conceptually:
MODEL
│
▼
REASON
│
▼
TOOL REQUEST
│
▼
APPLICATION EXECUTES TOOL
│
▼
TOOL RESULT
│
▼
MODEL
│
▼
REASON AGAIN
The new information may cause the agent to call another tool.
Reason
↓
Tool #1
↓
Result
↓
Reason
↓
Tool #2
↓
Result
↓
Reason
↓
Tool #3
↓
Result
↓
DONE
This is the heart of an agentic loop.
6. Tools Can Be Sequential or Parallel
Here’s another distinction developers need to understand.
Imagine our agent needs:
JIRA requirement
Confluence architecture
Repository implementation
Those pieces of information may be independent.
So instead of:
JIRA
↓
wait
↓
Confluence
↓
wait
↓
Repository
the agent may be able to request them concurrently:
ORCHESTRATOR
│
┌───────────┼───────────┐
▼ ▼ ▼
JIRA Confluence Repo
Tool Tool Tool
│ │ │
└───────────┼───────────┘
▼
combine results
│
▼
reason
That’s parallel tool use.
getJiraStory()
↓
returns externalAccountId
↓
querySalesforce(externalAccountId)
Those operations are dependent.
Therefore:
Tool #1
↓
result
↓
Tool #2
That’s sequential tool use.
A good orchestrator needs to understand the difference.
7. Not Every Agent Should Get Every Tool
This may be one of the most important enterprise lessons.
Suppose I create a security-analysis agent.
Its job is:
Inspect the implementation
Identify security violations
Return findings
Why should that agent be capable of deploying production?
It shouldn’t.
Give it:
READ
SEARCH
Don’t give it:
WRITE
DELETE
DEPLOY
Now consider an implementation agent.
It may legitimately need:
READ
SEARCH
WRITE
EDIT
TEST
And a deployment agent may need:
BUILD
DEPLOY
READ DEPLOYMENT STATUS
So the architecture becomes:
Architecture Agent
------------------
READ
SEARCH
Security Agent
--------------
READ
SEARCH
Implementation Agent
--------------------
READ
SEARCH
WRITE
EDIT
TEST
Deployment Agent
----------------
BUILD
DEPLOY
STATUS
This is least-privilege agent design.
Do not ask:
“What tools does our AI system have?”
Ask:
“What tools does this particular agent need to accomplish this particular responsibility?”
That is a much better architecture.
MCP’s specification reinforces the importance of authorization, user control, data privacy, and caution around tools because tools can create real data-access and code-execution paths. (Model Context Protocol)
8. So Where Does MCP Fit?
MCP is another concept developers sometimes collapse into “tools.”
They’re related, but they’re not identical concepts.
MCP provides a standardized protocol through which applications can expose capabilities and context to models. MCP servers can expose resources, prompts, and tools. (Model Context Protocol)
Think of it this way:
AGENT
│
tool request
│
▼
┌──────────┐
│ MCP │
│ Server │
└────┬─────┘
│
┌─────────────┼──────────────┐
▼ ▼ ▼
JIRA API Salesforce API Database
The MCP server might expose:
getJiraStory()
searchConfluence()
querySalesforce()
queryDatabase()
createPullRequest()
getDeploymentStatus()
MCP gives us a standardized mechanism for making those capabilities available.
The MCP documentation itself makes the control distinction useful for developers: resources provide context, prompts provide templated interaction, and tools expose functions that models can invoke. (Model Context Protocol)
That makes MCP particularly interesting in enterprise environments because it provides a natural place to centralize and govern integrations instead of every development team inventing another Salesforce, JIRA, database, or ServiceNow connector.
9. Add Hooks and the Architecture Gets Even Better
There’s another capability we need.
Some rules shouldn’t depend upon agent judgment.
Suppose our enterprise rule says:
NEVER commit a secret.
I don’t want the agent thinking:
“Given the circumstances, perhaps committing this API key is acceptable.”
No.
That’s deterministic policy.
This is where hooks and other deterministic controls belong.
So our mental model expands:
INTENT
"What outcome do we want?"
SKILL
"How do we do this?"
AGENT
"What should happen next?"
TOOL
"Interact with the world."
MCP
"Expose governed external capabilities."
HOOK / POLICY
"What must always or never happen?"
SUCCESS CRITERIA
"How do we know we're done?"
That’s a remarkably complete architecture.
10. Put It Together: An Enterprise Development Workflow
Now imagine the developer supplies:
Implement TMF632 Salesforce account creation.
The system starts:
FEATURE INTENT
│
▼
ORCHESTRATOR
│
▼
Adapter Scaffold Skill
│
"How do we build adapters?"
│
▼
DECOMPOSE WORK
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Architecture Salesforce Testing
Agent Agent Agent
│ │ │
TOOLS TOOLS TOOLS
│ │ │
└─────────────────┼─────────────────┘
▼
STRUCTURED RESULTS
│
▼
ORCHESTRATOR
│
▼
IMPLEMENTATION AGENT
│
filesystem tools
│
▼
TESTS
│
▼
VALIDATION
│
▼
SUCCESS CRITERIA
And deterministic controls surround the process:
┌───────────────────────────┐
│ │
│ GOVERNANCE │
│ │
│ secrets │
│ permissions │
│ allowed tools │
│ deployment policy │
│ validation │
│ │
└───────────────────────────┘
Now we’re no longer talking about “AI writing code.”
We’re talking about an engineering execution architecture.
11. What Developers Should Learn
I think developers entering this world need to stop focusing exclusively on prompting.
Prompting matters.
But the larger skill is architecting the execution environment around the model.
A developer should be able to look at a requirement and classify the capabilities it needs:
Question
Architecture
What outcome are we trying to achieve?
Intent
Is this reusable organizational knowledge?
Skill
Does something need focused reasoning?
Agent/Subagent
Are several workers being coordinated?
Orchestrator
Does the system need external information or action?
Tool
Do we need standardized external capability exposure?
MCP
Must a rule be enforced deterministically?
Hook/Policy
How do components communicate reliably?
Structured I/O
How do we know the job is finished?
Success Criteria
That classification exercise alone eliminates a lot of bad architecture.
12. Don’t Turn Everything Into an Agent
This deserves special emphasis.
If something can be:
function calculateTax() { ... }
it probably doesn’t need to become:
TaxCalculationAgent
If something is deterministic, keep it deterministic.
Likewise, don’t create a subagent just because subagents sound sophisticated.
Use one when independent reasoning, context isolation, specialized instructions, different tools, or parallel investigation provide meaningful value.
The architecture should be:
Simple where deterministic.
Agentic where reasoning is valuable.
Not:
Agents everywhere.
13. Don’t Turn Every Procedure Into a Tool Either
Suppose we tell Claude:
When creating an enterprise adapter:
1. Find the closest reference implementation.
2. Identify architecture.
3. Identify delta.
4. Preserve security.
5. Preserve operational behavior.
6. Generate scaffold.
7. Validate against reference.
That’s reusable procedural knowledge.
Skill.
But:
getJiraStory("ZSP-632")
That’s an action.
Tool.
And:
Determine whether the requested adapter requires
a new architecture or can reuse an existing pattern.
That’s reasoning.
Agent.
This distinction sounds obvious once stated.
It isn’t obvious when you’re building the system.
14. The Bigger Enterprise Pattern
Eventually organizations are going to accumulate these capabilities.
That creates another architectural problem.
Imagine 500 developers each creating:
their own Salesforce tool
their own Jira tool
their own security agent
their own adapter skill
their own deployment agent
their own hooks
That’s not an AI platform.
That’s chaos.
Reusable agentic infrastructure should increasingly become shared engineering infrastructure.
ENTERPRISE AGENTIC PLATFORM
┌─────────────────────────────┐
│ Approved Skills │
│ Approved Agents │
│ Approved MCP Servers │
│ Approved Tools │
│ Approved Hooks │
│ Shared Schemas │
│ Observability │
│ Security / Governance │
└──────────────┬──────────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
Team A Team B Team C
Developers consume approved capabilities by default.
When a team discovers something genuinely reusable, it gets promoted into shared infrastructure rather than copied into another repository.
That is how agentic development starts becoming an enterprise engineering discipline.
15. The Mental Model I’m Keeping
After digging through all of this, this is the model I’m carrying forward:
INTENT
"What do I want?"
│
▼
SKILL
"How do WE do it?"
│
▼
ORCHESTRATOR
"What needs to happen?"
│
┌───────────┼───────────┐
▼ ▼ ▼
AGENT AGENT AGENT
"think" "think" "think"
│ │ │
▼ ▼ ▼
TOOLS TOOLS TOOLS
"do" "do" "do"
│ │ │
└───────────┼───────────┘
▼
RESULTS
│
▼
REASON
│
Need more?
/ \
YES NO
│ │
TOOLS ▼
│ VALIDATE
└──────► │
▼
SUCCESS CRITERIA
│
▼
DONE
And surrounding all of it:
SECURITY • GOVERNANCE • HOOKS • OBSERVABILITY • HUMAN CONTROL
That’s the architecture.
Learn → Teach → Master
The interesting thing about learning this material isn’t getting every terminology question correct.
It’s reaching the point where you can look at a real engineering problem and say:
That’s knowledge. Make it a skill.
That’s reasoning. Give it to an agent.
That’s coordination. Give it to the orchestrator.
That’s an external operation. Give the agent a tool.
That’s an enterprise integration. Consider exposing it through MCP.
That’s a non-negotiable rule. Enforce it deterministically.
Those investigations are independent. Run them concurrently.
That second operation requires the first one’s result. Run them sequentially.
That agent doesn’t need production access. Don’t give it the tool.
That is a very different level of understanding from simply knowing what the words skill, agent, tool, and MCP mean.
And that’s why I’m spending the time on it.
I’m still learning.
Then I’m teaching what I’ve learned.
Master comes later.
But increasingly, I think the path to Master is exactly this: stop memorizing the components and start understanding how they compose into a system.
References
The architecture in this article is my synthesis, but the MCP portions are grounded in the official Model Context Protocol specification, particularly its distinction between resources, prompts, and model-controlled tools and its security guidance around tool invocation. (Model Context Protocol)
Comments