Skills, actions and triggers
An agent on its own is instructions and a model. Three things extend it, and they are easy to run together because all three are about the agent doing something beyond thinking. They are not the same, and each arrives by a different route.
- A skill is a capability an agent may use.
- An action is a single operation a skill performs.
- A trigger is a condition that starts an agent or a process flow without a person asking.
Skills and actions are about what an agent can do. A trigger is about when it runs. An agent can have skills and no trigger, a trigger and no skills, or both.
Skills
A skill is a capability made available by provisioning a connector. Provisioning is the single
verb for bringing a connector into being, and minting that connector's skills is part of what it
does — one skill per real action the connector offers. Skills do not exist on their own and are not
added to an agent one at a time from nowhere; they arrive with a provisioned connector, and are then
granted to agents by putting their ids in the agent's skills list.
That has a consequence worth stating plainly: there is no tool that creates a skill. The set of
skills an agent can be granted is exactly the set the project's provisioned connectors have minted.
List them with list-skills, which returns them grouped by connector,
each with the real id you put in an agent's skills.
If the skill you want is not in that list, the connector behind it is not provisioned in this
project yet. provision-connector provisions the connectors that
need no credential, and mints their skills as it does. A connector that needs an API key or an OAuth
sign-in still needs a person in the console; no tool can complete that on your behalf.
Actions
An action is a single operation a skill performs. It is the finest-grained unit here: the skill is the capability an agent holds, the action is the individual operation behind it.
The relationship is visible in how skills come into being. Provisioning a connector mints one skill
per real action that connector offers, so the actions a connector supports are what decides the
skills the project ends up with. When you filter list-skills by a connector's category, you are
filtering over exactly that set.
For an agent author the practical shape of it is: you choose skills, not actions. The action is what happens when the agent uses the skill.
Triggers
A trigger starts a run without anyone asking for it. It is configured as part of an agent's definition — a list of triggers on the agent — rather than being a separate object you run.
A trigger names three things.
- What to start. The agent to run, and optionally the agent inside a process flow to start from rather than beginning at the first.
- What to ask for. A
goalin natural language, exactly as a person starting the run by hand would supply. A trigger that fires still starts an ordinary run with an ordinary goal. - When to fire. Either a scheduled time, or a condition and filters describing the event that should set it off.
That second point is the one that surprises people: a triggered run is not a special kind of run. It produces an execution like any other, records the same inputs and outputs, and is governed by the same policy decisions. Nothing is exempt from a rule because a schedule started it rather than a person.
Triggers can also be attached from the other end — configured on a connector, so that an event that connector reports starts a named agent. The shape is the same in both places: an agent to start, a goal to start it with, and the condition that fires it.
How the three fit together
Read them as three separate questions about one agent.
- What can it reach? Its skills — and therefore which connectors the project has provisioned.
- What does one of those reaches actually do? An action.
- What makes it run at all? A person calling
run-agent, or a trigger.
Only the first is something you grant on the agent by id. The second follows from the connector. The third is a separate decision from the other two, and answering it is not a substitute for answering them.
Where to go next
- Agents — what holds the skills.
- Process flows — where an agent's
skillslist appears in the manifest. - Executions and versioning — what a run leaves behind, however it started.