Tags
Mental Model, Skills, Ontology
Author
Wout Helsmoortel
Teams are starting to build systems that act with real independence. Yet in most tools, it is still unclear what these systems can actually do. Capabilities live in prompts, scripts, and tool integrations that only a few people understand. You get power without clarity. We need a simple way to show what a system can do, how it is set up, and who is responsible for it. This model starts from one idea: that every capability is a skill.
The mental model in one view
In our mental model, agents are the performers, and skills are the capabilities they use to act. The structure of work defines how those capabilities are applied and connected.
Agent: the performer, human or digital.
Skill: a reusable capability the agent can run.
Task: one run of a skill in a specific context.
Step: a visible action or decision inside a task.
Sequence: several tasks linked to achieve one outcome.
Process: multiple sequences across roles and systems.
You can read this in two simple stacks:
Structure of work: Process → Sequence → Task → Step
Performers and capabilities: Agent → Skill → Task
Together, they answer three questions:
How is work organised?
Who acts at each point?
Which capability is being used?
In a clear system, you can answer these three questions at any moment. The UI should make that obvious wherever you are in the work.
Two complementary stacks: on the left, the structure of work from process to step; on the right, the performers and their capabilities from agent to task.
What is a skill?
A skill is a small, explicit, inspectable unit of capability.
It describes what an agent can do and how it should do it. A good skill is understandable to a teammate, reusable across tasks, and safe to expose to other agents.
A skill usually contains:
Purpose: what it is for and when to use it.
Instructions: how the agent should reason and act.
Resources: data, documents, and tools it may use.
Parameters: inputs that can be tuned, like tone, scope, or detail.
Metadata: owner, version, and review date.
This keeps a skill both human-readable and machine-usable. Product teams can change it safely. Operators can see what it does. Agents can run it without new code.
You can imagine a simple skill view:
Header with name, purpose, owner, and version.
Changelog and version history.
When to use it and a short input/output example.
Linked resources and allowed tools.
The point is not the exact layout. The point is that a skill is a first-class object that people can open, inspect, and improve.
From skills to tasks and steps
When a user or agent runs a skill, it becomes a task.
A task is one execution of the skill in a concrete context, such as:
"Summarise yesterday’s incident report for leadership."
"Check this access request against policy."
The task moves through steps like:
Collect input.
Apply the skill.
Review and adjust.
Finalise and send.
Each step should be visible. You see where the task is, who owns the current step, and what happened so far. That visibility is what turns automation into something people can trust.
A simple task panel might show:
Left: conversation or input area.
Right: task status, current step, agent avatar, and output.
Each step with a short note like "Waiting for review by Marta" or "Step 2 of 4: Drafting".
Every task leaves a trail of inputs, decisions, and outputs. Teams can:
Trace how an outcome was produced.
Repeat successful runs.
Improve the underlying skill when something goes wrong.
From single tasks to sequences and processes
Most real work is not a single task. It is a chain of actions.
Think of:
Collect data.
Summarise findings.
Check against rules.
Share the result with the right people.
These linked tasks form a sequence.
A sequence defines how tasks connect and what moves work forward. A step in a sequence might:
Trigger a skill.
Wait for a human decision.
Branch based on a rule.
A simple sequence builder might give you:
A canvas with steps as blocks.
A library with step types: skill step, human step, decision step.
A panel to set inputs, conditions, and assigned agents.
The goal is to make orchestration explicit, reusable, and inspectable. You should not have to dig through hidden automations to see how work flows.
When work crosses roles and systems, sequences combine into a process.
A process usually contains:
Swimlanes by role or agent.
Sequences as reusable blocks inside those lanes.
Handoffs with clear owners and acceptance criteria.
Milestones to show progress over time.
This gives teams a full picture: who does what, where decisions sit, and how work moves from draft to done.
Governance: making skills part of the product
Once skills, sequences, and processes are shared, they stop being experiments. They become part of how the organisation actually works.
In this model, governance stays simple and close to the work:
Every skill has a clear owner and review cadence.
Higher-risk skills and sequences get a light approval flow before changes go live.
Usage data and time per step show where work slows down or fails.
An audit trail links each sequence step to the tasks that actually ran.
The goal is not bureaucracy. It is to make sure that the capabilities agents use are owned, monitored, and easy to improve. That aligns naturally with existing governance frameworks: you can point to concrete skills, tasks, and sequences as the units you review.
This model is transport-agnostic: whether you use Anthropic skills, a custom orchestration layer, or a protocol like McP, the governed units stay the same – skills, tasks, sequences, and processes.
Closing reflection
Skills make capabilities visible. Tasks and steps make behaviour traceable. Sequences make work repeatable. Processes keep teams aligned.
Together, they form a simple mental model for agentic work.
This model gives teams a shared language for how humans and systems work together. It turns opaque automation into something teams can design, govern, and improve. It also creates a natural path from experimentation to dependable operation, where:
Every skill can evolve.
Every task can be measured.
Every agent can contribute with clear purpose.
References and Acknowledgments
Author: Wout Helsmoortel
Founder, Shaped — specializing in agentic AI systems, explainable architectures, and learning transformation for defense and enterprise environments.
References:
Anthropic. Agent Skills – Modular capabilities for Claude. Anthropic documentation. Anthropic Docs
Anthropic. Model Context Protocol (MCP). Anthropic engineering blog and specification. Anthropic
IBM. AI Factsheets – Documenting AI decision systems. IBM model governance documentation. IBM Docs
