Introduction to agentic primitives
Amazon Quick’s taxonomy of agentic primitives separates an AI system into four questions: when work starts, what needs doing, who takes responsibility, and how the task gets done. Its central distinction is that a recurring task does not necessarily require a new agent. A schedule can activate an existing agent, which then uses the capabilities appropriate to the request.
In its account of the taxonomy, the Quick team describes the problem that prompted this framework. As its agents expanded from answering questions into scheduling meetings, conducting research, and generating reports, the same concepts repeatedly appeared under different names. Actors, activation signals, packaged procedures, and accumulated memory needed clearer boundaries.
The team uses a request to monitor a Slack channel and send a daily digest to expose the ambiguity. Does that request define an agent, a scheduled instruction, a workflow, or a skill? In Quick’s framing, those labels address different parts of the work. Treating them as competing names for the entire request obscures the design decisions underneath.
The practical value is a way to separate those decisions. Builders can identify the activation mechanism, assign the work to an actor, and choose how tightly to prescribe execution. This is the Quick team’s architectural vocabulary, rather than evidence that every agent system follows the same definitions. Its usefulness rests on whether those distinctions make a particular system easier to design and explain.
Importance of shared definitions
The Quick team says the absence of shared definitions became a recurring problem as its system evolved. Rebuilding similar concepts under different names affected both product design and the choices presented to users. The issue was therefore more than terminology: unclear internal boundaries made it harder to express what a user was actually asking for.
Consider the daily digest request. Its recurring timing does not, by itself, specify a different persona, a new body of learned context, or a particular execution procedure. Those are separate choices in this taxonomy. Making a new agent the default answer would conflate the cadence of work with the identity of the actor performing it.
A shared vocabulary allows the request to be decomposed without requiring the user to perform that decomposition. The schedule answers when. The digest instruction answers what. The existing agent can answer who. A loosely specified approach, a skill, or a workflow can answer how. The same visible outcome can therefore arise from different combinations of primitives.
The editorial implication is that the taxonomy helps locate disagreements. A team discussing whether a task needs a workflow may actually be debating how much execution order must be fixed. A discussion about creating an agent may instead concern whether separate instructions, capabilities, and learning are needed. These are interpretations of the framework’s distinctions, rather than measured outcomes reported in the source.
Quick’s stated aim is to keep most of this machinery invisible to end users. The builders need precise concepts so that the product can translate an ordinary request into the appropriate arrangement. A shared vocabulary earns its place when it reduces the conceptual burden of making that translation.
Overview of the taxonomy
The framework connects triggers, agents, and capabilities. Triggers combine activation with task instructions; agents interpret and undertake the work; capabilities provide the means of execution. Learning feeds back into the actor across uses, according to the team’s description.
| Question | Primitive or responsibility | Meaning in Quick’s taxonomy |
|---|---|---|
| When? | Trigger | The human action, delegation, schedule, or external event that starts work |
| What? | Task carried by the trigger | The instruction describing the work to perform |
| Who? | Agent | The persistent actor that interprets the instruction and accumulates learning |
| How? | Capabilities | The tools, skills, workflows, and sub-agents available for execution |
The final question contains an important distinction. Quick describes capabilities as spanning a spectrum of discretion and determinism. The authors call this a confidence contract: how much latitude the agent retains and how much the user fixes in advance.
Tools are atomic operations with typed schemas. The source gives sending an email, querying a database, and reading a file as examples. Whether an operation is a local function, a Model Context Protocol (MCP) server, or another agent behind a protocol boundary, the caller sees a name, description, parameters, and result. This definition concerns the interface exposed to the caller.
Skills package guidance and resources, including templates, scripts, and examples, while leaving room for judgment. They describe an approach rather than imposing a rigid sequence. Quick describes progressive disclosure: the agent initially sees names and short descriptions, then reads the full instructions when a skill becomes relevant. Detailed guidance can thus remain available without being loaded in full at every moment.
Workflows prescribe coordination through declared steps, control flow, branching, and error handling. Code determines the step order and decision logic governing that coordination. The source illustrates this with a purchase-approval route moving through a budget check, manager sign-off, and finance. An agent can still exercise judgment within a step; the route itself remains prescribed.
These distinctions explain why skills and workflows are separate. The Quick team argues that skills preserve institutional expertise, while workflows provide auditability, visibility into individual steps, and deterministic coordination across services. That is the authors’ rationale for retaining both even as models improve, rather than an independently demonstrated forecast about their future use.
Role of triggers in agentic work
A trigger does more than announce that execution should begin. It also carries the task. A human message combines the moment of activation with a description of what the agent should do. A scheduled trigger combines a recurring activation time with standing instructions. In both cases, when and what belong together without becoming the agent’s identity.
The source identifies four trigger types. Human-initiated work begins when someone opens a conversation and makes a request; the interaction is conversational and synchronous. Agent-delegated work begins when one agent invokes another during a task to handle a subproblem, enabling composable and potentially recursive execution.
Scheduled work uses time-based activation. Quick’s example is financial research every Monday at 9am, with the same standing instructions applied across runs. Event-driven work begins with an external signal, such as a new email, Slack mention, file change, or webhook. These categories distinguish the origin of activation without requiring a separate kind of actor for each origin.
Trigger type also affects the execution context. The authors suggest that a scheduled background task might act conservatively and do nothing when uncertain, whereas a human-initiated task might ask a question. These are examples of suitable behavior, not a documented universal rule or a complete account of Quick’s safeguards. They show why an activation mechanism can matter beyond timing.
The daily digest example makes the connection to capabilities concrete. The Quick team describes three valid arrangements: a scheduled task with a short instruction, the same task supported by a skill containing formatting rules and channel priorities, or the task invoking a workflow with deterministic steps and error handling. All aim at a digest delivered on a schedule. What changes is how much of the procedure has been specified.
The design implication is to evaluate timing and procedural control separately. A recurring request can remain open-ended in execution, while a recurring request with stricter consistency needs can use more explicit guidance or coordination. Scheduling alone does not settle that choice. The source recommends the simplest arrangement that meets the user’s confidence requirement.
Characteristics of agents
Quick defines an agent as a persistent actor that learns. It answers who performs the work and provides the identity against which learning accumulates. Two agents can receive identical input yet behave differently because their instructions, available capabilities, and histories differ.
The definition has three constituent parts. First, standing instructions establish persona, role, context files, and operating principles. The source attributes the difference between a Finance Agent and a general assistant primarily to that guidance. Instructions shape interpretation, but the agent is the entity interpreting them.
Second, the agent has capabilities: tools, skills, workflows, and sub-agents available for use. These can change dynamically. The authors give the example of a charting library being available in one session and removed in the next. Under this definition, continuity of the actor does not require an unchanging set of capabilities.
Third, learned context accumulates through use. The source describes effective tool queries, preferred formatting, and relevant edge cases as examples. The team argues that this accumulated context can improve later executions without someone manually rewriting the standing instructions. The distinction is between guidance supplied to the actor and lessons retained through experience.
The authors place several other components outside the agent’s defining identity. The underlying large language model is a swappable parameter, conversation history belongs to the session, and triggers belong to the platform. These boundaries are specific to the proposed taxonomy. They explain how the same actor can participate in chat, scheduled work, and more autonomous execution without becoming a separate agent each time.
That separation also clarifies the team’s claims about learning. The source describes later executions as improving through accumulated experience, but provides no benchmark, measured success rate, or detailed learning algorithm. It says further discussion of background learning and the continuous learning framework will follow. The account supports the intended role of memory in this architecture; it does not establish a quantified improvement or explain how learned context is validated.
The same qualification applies to the proposed movement between skills and workflows. Quick describes a well-understood skill becoming a workflow as crystallization, and a workflow encountering persistent edge cases loosening into a skill as dissolution. The authors associate this with continuous learning, without supplying the implementation details in this article. Conceptually, the distinction allows the degree of procedural control to change while the actor remains persistent.
Conclusion on the value of the taxonomy
The strongest contribution of Quick’s taxonomy is the separation of choices that an ordinary request bundles together. A daily digest needs an activation pattern, an instruction, an actor, and an execution approach. It does not follow that each request needs a new agent, or that every recurring task needs a workflow.
For builders, the useful question is which part of that arrangement must change. Different timing points to a trigger decision. Different standing guidance or accumulated learning raises an actor decision. A stronger requirement for prescribed steps raises a capability decision. This is an analytical use of the framework, grounded in the boundaries the Quick team describes.
The supplied account presents a vocabulary and architectural rationale, with examples of how the primitives compose. It leaves the mechanics and measured effects of continuous learning unresolved. Within that scope, the framework offers a concrete way to discuss agentic work while preserving the user’s ability to ask for an outcome in ordinary language. Its value depends on whether those internal distinctions help the system assemble an appropriate response to that request.
