AWS has published the vocabulary behind Amazon Quick, its agentic workspace. In a new post on the AWS Machine Learning blog, the Quick team says agentic work breaks down into four plain questions: When, What, Who and How. The answers map to triggers, agents, capabilities and learned context. It is the first post in a series, and it is useful beyond Quick because the same split applies to most agent systems you might build.
TL;DR: the four questions
| Question | Primitive | What it is, per AWS |
|---|---|---|
| When? and What? | Trigger | Starts the work and carries the task: human message, agent-delegated, scheduled, or event-driven |
| Who? | Agent | A persistent, learning actor: instructions, capabilities, learned context |
| How? | Capabilities | Tools, skills and workflows, from fully agentic to fully deterministic |
| Gets better with use | Learned context | Memory that accumulates: queries that work, preferred formats, edge cases |
Why AWS wrote this down
The post opens with a familiar problem. Over the past year, AWS says, Quick's agents went from answering questions to taking actions such as scheduling meetings, running research and generating reports. The same few ideas kept being rebuilt under different names: an actor that does the work, a signal that starts it, a packaged procedure, and a memory that carries lessons forward. That repetition leaked into product design and onto users.
The example is a user who says "monitor my Slack channel and send me a daily digest." Is that a new agent, a scheduled instruction to an existing one, a workflow, or a skill? Without shared vocabulary those distinct questions collapse into one confusing choice.
Triggers: the When and the What
AWS lists four trigger types:
- Human-initiated: a person opens a conversation and asks. Interactive and synchronous.
- Agent-delegated: one agent invokes another mid-task for a sub-problem. Composable and potentially recursive.
- Scheduled: time-based, such as running financial research every Monday at 9am, with the same standing instructions each run.
- Event-driven: a signal from an external system like a new email, a Slack mention, a file change or a webhook.
A trigger is both the activation and the description of the task, which is why AWS merges When and What. The type also conditions behavior: a scheduled background task might stay conservative and do nothing if uncertain, while a human-initiated one would ask rather than stop.
Agents: the Who
AWS defines an agent as a persistent, learning actor and the anchor against which learning accrues. Three things make one up:
- Instructions: standing guidance on persona, role, context files and operating principles. A Finance Agent differs from a general assistant mainly through these.
- Capabilities: tools, skills, workflows and sub-agents, updated dynamically. A charting library can be added in one session and removed the next.
- Learned context: memory that accumulates through use, so the tenth execution beats the first without anyone changing the instructions.
Everything else is extrinsic, per the post. The underlying large language model is a swappable parameter, conversation history is per-session state, and triggers belong to the platform.
The practical consequence AWS draws: a request for an agent that monitors Slack and sends a morning digest is usually a trigger added to an existing agent. That lets Quick merge chat, scheduled and autonomous agents into one actor you can converse with, schedule, and ask to inspect its own past work.
Capabilities: the How
AWS frames capabilities as a spectrum from fully agentic to fully deterministic, and calls the axis a confidence contract: how much latitude the agent keeps versus how much the user fixes in advance.
| Capability | What it is | Who decides the steps |
|---|---|---|
| Tool | Atomic operation with a typed schema, such as send an email or query a database. Can be a local function, an MCP server, or another agent behind a protocol boundary | The caller |
| Skill | Instructions bundled with templates, scripts and examples describing an approach, loaded by progressive disclosure | The agent, with guidance |
| Workflow | Declared steps, control flow, branching and error handling in fixed order | The code |
The tool definition matches how we explain it in our guide to the Model Context Protocol: the caller sees the same name, description, parameters and result, whatever sits behind it. Skills load through progressive disclosure, so the agent sees only names and short descriptions until one becomes relevant. That is the same idea we cover in what agent skills are.
Agent long-term memory notes, illustrating learned context in the Amazon Quick agentic primitives taxonomy
The workflow example in the post is a purchase-approval route: budget check, manager sign-off, then finance, each recorded. The route is fixed, but the judgment inside a step is still the agent's.
Why skills and workflows outlast model gains
AWS anticipates the objection that better models make both unnecessary. It disagrees. Skills are the unit for capturing, versioning and sharing institutional expertise. Workflows deliver auditability, step-wise visibility and deterministic multi-service coordination. Neither is fixed: a well-understood skill can tighten into a workflow (AWS calls this crystallization), and a workflow that keeps hitting edge cases can loosen back into a skill (dissolution). Quick does this through a continuous learning framework that AWS says a future post will describe.
One request, three valid designs
For the Slack digest, AWS lists three ways to meet the request:
- A scheduled task with a one-line instruction, leaving the agent to figure out the rest.
- The same task backed by a skill with explicit formatting rules and channel priorities.
- The same task invoking a workflow with deterministic steps and error handling.
All three produce a daily digest. What differs is the confidence contract. A user who trusts the agent wants the first; one burned by inconsistency wants the second; a compliance-sensitive process wants the third. AWS recommends the simplest option that meets the user's confidence requirement, with a path to graduate through autonomous learning when more is needed.
What builders can take from this
You do not need Amazon Quick to use the model. A few reusable rules follow from the post:
- Separate the actor from the instructions. Treat the agent as the entity that interprets guidance, with its own history, not as a prompt.
- Add triggers, not agents. Before creating a new agent for a recurring job, ask whether a schedule or event trigger on an existing one does the job.
- Choose determinism per step. Use workflows where audit trails matter, skills where judgment matters, and let learning promote or demote between them.
- Keep the model swappable. AWS lists the LLM as a parameter, not part of the agent's identity.
For how Amazon applies related ideas elsewhere, see our coverage of the AWS Agent Registry for runtime tool discovery, the AWS trust-in-depth model for agent autonomy, and the Bedrock managed knowledge base with agentic retrieval.
Questions this framework helps you answer
Should this be a new agent? Ask whether the job needs different instructions, capabilities or history. If the only difference is when it runs or what starts it, add a trigger.
Where does memory live? In the taxonomy, learned context belongs to the agent, not to the session or the model. Conversation history is per-session state and the model is swappable, so swapping the model should not wipe what the agent has learned about your tools and preferences.
How much should I trust the agent? Pick a point on the capability spectrum. A one-line scheduled instruction gives the agent the most latitude. A skill adds guidance. A workflow fixes the order and moves decisions into code. The right pick depends on the cost of an error: a morning digest can tolerate variation, a compliance process cannot.
What happens when uncertain? The trigger type sets the default. AWS says a scheduled background task may stay conservative and do nothing if uncertain, while a human-initiated one can ask a question. Designing that default explicitly is one of the cheapest ways to make background agents safer.
How do I test it? Test each primitive on its own. Check that triggers fire on the right events, that skills load only when relevant, that workflows follow their declared steps, and that learned context improves outcomes over repeated runs rather than drifting.
What the post does not say
The post is a design explanation, not a launch. It gives no benchmarks, pricing or new feature dates, and it says most of the framework stays invisible to end users by design. It also defers the agentic operating system, background learning and proactive feeds to later posts in the series. Treat claims such as the tenth run being markedly better as AWS's description, not a measured result.
Where this fits
Agent platforms are converging on similar nouns. Skills, tools, schedules and memory appear across vendor products. The value of a published taxonomy is shared language: when a teammate asks whether something should be a skill or a workflow, you have a criterion, which is who decides the step order. Our Amazon Bedrock AgentCore Web Answer setup guide shows the tool side of this picture in practice.
Related reading
- What is MCP: Model Context Protocol guide
- What are agent skills: complete guide
- AWS Agent Registry and runtime tool discovery
- AWS trust in depth for agent autonomy
- Bedrock managed knowledge base with agentic retrieval
- Amazon Bedrock AgentCore Web Answer setup guide
- Amazon Quick getting started
Details are accurate as of November 6, 2026 and reflect the AWS post published that day.