Stop Thinking About AI Features. Start Thinking About What Fires Them. Agents, Skills, Hooks, Tools and Workflows Finally Started Making Sense

Yes. The architecture pattern is portable, but the exact names, file formats, trigger semantics, and maturity differ by platform.

GitHub Copilot is especially close now: its current docs explicitly describe custom agents, automatically selected subagents, automatically selected skills, deterministic lifecycle hooks, MCP servers, and orchestration.

Stop Thinking About AI Features. Start Thinking About What Fires Them.

Agents, Skills, Hooks, Tools and Workflows Finally Started Making Sense

As I prepare for another run at the Claude Certified Architect exam, I keep coming back to one idea.

I don’t just need to know what these components are.

I need to know:

What causes each one to run?

That question changed the way I look at agentic architecture.

We talk constantly about agents, subagents, skills, hooks, MCP servers, tools and agentic workflows. But simply knowing their definitions isn’t enough.

The architecture becomes much clearer when you ask:

Who decides that this thing should run?

That gives us a surprisingly useful mental model.

Agent: The Model Decides

An agent or subagent is a specialized worker.

It might be designed for security analysis, architecture review, testing, research, database analysis or another bounded responsibility.

The fascinating part is that delegation can be semantic.

The system sees the task, considers the descriptions and capabilities available to it, and determines that a specialized worker is appropriate.

Conceptually:

Intent → Context → Model Decision → Agent

That is enormously powerful.

It is also why agents require observability.

If five agents are available, I want to know:

Which ones are actually being selected?

Which ones are never selected?

Which ones are being invoked constantly?

Are two agents overlapping?

Are we paying for specialized reasoning that isn’t improving the outcome?

Autonomy without observability eventually becomes guesswork.

Hook: The Event Decides

Hooks are fundamentally different.

A hook doesn’t need the model to reason:

“Should I run this?”

A configured event occurs, and the hook executes.

Conceptually:

Event → Hook → Deterministic Action

That makes hooks excellent for enforcement.

Security validation.

Logging.

Auditing.

Formatting.

Tool validation.

Policy enforcement.

Telemetry.

Anything that must happen at a known lifecycle boundary is a strong candidate for a hook.

GitHub Copilot, for example, now documents lifecycle hooks for events including session start, prompt submission, pre-tool use, post-tool use, agent completion and subagent completion. (GitHub Docs⁠)

This gives me one of my favorite architecture rules:

Don’t ask an agent to remember something that a hook can guarantee.

Skill: The Capability Is Discovered

A skill is different again.

A skill packages reusable knowledge about how we perform a particular kind of work.

Instead of stuffing every instruction into the main context, we can make specialized capabilities available and load them when they become relevant.

Conceptually:

Intent → Capability Match → Skill → Instructions/Resources

Interestingly, this model is no longer unique to Claude-style environments.

GitHub’s current Copilot documentation describes Agent Skills as folders containing instructions, scripts and resources that Copilot can automatically load when relevant to a task. (GitHub Docs⁠)

That is an important industry signal.

Tool or MCP: The Agent Needs Something Outside Itself

Eventually reasoning has to touch the real world.

Read Jira.

Query a database.

Call an API.

Search documentation.

Update GitHub.

Retrieve enterprise information.

That’s where tools and MCP servers fit.

Conceptually:

Agent/Workflow → Tool → External System → Result

The tool isn’t the brain.

It is a capability exposed to the brain.

That distinction matters.

Agentic Workflow: The Process Decides What Happens Next

Now we reach orchestration.

A workflow coordinates multiple steps toward an outcome.

It might:

Plan → Research → Delegate → Call Tools → Validate → Retry → Implement → Test → Stop

The workflow may invoke agents.

It may use skills.

It may call APIs or MCP tools.

It may encounter hooks along the way.

It may execute steps sequentially or parallelize independent work.

The important distinction is:

An agent owns specialized reasoning. A workflow owns coordination.

That distinction has helped me enormously while studying orchestration.

The Mental Model

I now reduce the architecture to five questions:

Agent — Who should reason about this?

Skill — How do we know how to do this?

Hook — What must happen when this event occurs?

Tool/MCP — What external capability or information do we need?

Workflow — In what order should the work happen, and what happens next?

Put them together:

INTENT

↓

ORCHESTRATOR

↓

SKILLS — reusable knowledge

↓

AGENTS — specialized reasoning

↓

TOOLS / MCP — external capabilities

↓

RESULT

And surrounding that execution:

EVENT → HOOK → ENFORCEMENT / OBSERVABILITY

That’s the object model I want in my head.

But How Do We Know the Agents Are Actually Running?

This may be the more interesting enterprise question.

Automatic agent selection sounds fantastic.

Until somebody asks:

“Which agents actually ran yesterday?”

That should not require guessing.

I believe mature agentic platforms need an Agent Observability capability.

Every invocation should generate telemetry such as:

Agent → Triggering Intent → Reason Selected → Tools Used → Tokens → Duration → Outcome → Errors

Then we can produce a daily Agent Utilization Report showing:

Most-used agents

Never-used agents

Underused agents

Potentially overused agents

Average execution time

Token consumption

Success/failure rate

Tool usage

Delegation patterns

Agent overlap

Now we’re not simply building agents.

We’re managing an agent workforce.

And that is a very different level of architecture.

This Is Bigger Than Claude

The terminology and implementation differ, but the architectural principles increasingly carry across the major AI development environments.

Claude Code may implement the concepts one way.

GitHub Copilot implements them another way.

Cursor and Gemini have their own mechanisms and levels of support.

But the underlying architectural questions remain remarkably stable:

What is context-selected?

What is explicitly invoked?

What is event-triggered?

What is deterministic?

What requires reasoning?

What requires external tools?

What coordinates everything?

That is why I increasingly believe enterprise AI architecture should be designed around patterns rather than vendor features.

The implementation belongs to the platform.

The architecture belongs to us.

The Enterprise Pattern

This also reinforces the Shared Services model I’ve been advocating.

An enterprise shouldn’t need every development team inventing its own agents, skills, hooks and workflows.

Instead, imagine a governed capability layer:

Enterprise Architecture Agent

Security Review Agent

Testing Agent

Deployment Skill

Code Review Skill

Compliance Hooks

Observability Hooks

Jira MCP

GitHub MCP

Standard Agentic Workflows

Then provide platform-specific implementations for Claude Code, GitHub Copilot, Cursor, Gemini or whatever platforms the enterprise approves.

GitHub Copilot’s evolution is already showing how portable some of these concepts are: GitHub documents custom agents, subagents, Agent Skills, hooks and MCP as distinct customization mechanisms. (GitHub Docs⁠)

The files may change.

The syntax may change.

The names may change.

But the architectural intent survives.

The Rule I’m Taking Into the Exam

When presented with an architecture problem, don’t immediately ask:

“Which AI feature should I use?”

Ask:

“What behavior do I need, and what should cause that behavior to execute?”

Then choose the smallest correct mechanism.

Need specialized reasoning? → Agent.

Need reusable knowledge or procedure? → Skill.

Need guaranteed execution on an event? → Hook.

Need an external capability? → Tool/MCP.

Need coordination across multiple steps? → Workflow.

And if you’re deploying all of this into an enterprise:

Observe everything.

Because the future isn’t simply autonomous agents.

It’s governed, observable, intent-driven agentic systems.

Intent-Driven Engineering

The goal isn’t to add more AI components.

The goal is to give every component the minimum sufficient context, responsibility and authority required to accomplish the intent—and no more.

One nuance I’d keep very explicit in the article and for the exam: don’t memorize “all platforms work exactly like Claude.” They don’t. Memorize the architecture abstraction. For example, Copilot currently says custom agents can be manually selected, while subagents and skills can be automatically selected based on the task; hooks are deterministic lifecycle mechanisms.

That actually strengthens your Shared Services idea: standardize the intent and architectural role, then provide Claude/Copilot/Cursor/Gemini adapters for how that role is implemented.