DEV Community

Cover image for Stop Spawning a New Agent for Every Recurring Task
Agentic Affairs
Agentic Affairs

Posted on Edited on Originally published at agentic-affairs.com

Stop Spawning a New Agent for Every Recurring Task

Stop Spawning a New Agent for Every Recurring Task

Every agent vendor wants you to believe a recurring task needs a new agent. Amazon Quick's taxonomy says the opposite: a schedule is not an agent, a skill is not a workflow, and treating them as competing names for the same job is how agent systems turn into an unmaintainable mess of lookalike bots.

Quick's team built this vocabulary because their own agents kept reinventing the same concepts under different names — actors, activation signals, packaged procedures, accumulated memory — until nobody could say what a user was actually asking for. Their fix is four questions, and only four: when does work start, what needs doing, who takes responsibility, and how does it get done?

  • A schedule is a trigger, not an agent. A daily Slack digest doesn't need a new persona, a new body of learned context, or a new execution procedure. A schedule can activate an existing agent. Making a new agent the default answer confuses the cadence of work with the identity of the actor doing it — and that confusion is where agent sprawl starts.
  • Triggers carry the task, not just the starting gun. Human messages, agent-to-agent delegation, schedules, and external events are four different origins of activation — and the origin changes the behaviour. Quick's example: a scheduled background task that hits uncertainty should probably do nothing, while a human-initiated one should ask. Timing isn't just timing; it sets the rules of engagement.
  • Tools, skills, and workflows are a confidence contract. Tools are atomic operations with typed schemas. Skills package guidance and leave room for judgment. Workflows prescribe the steps, the branching, and the error handling in code. The difference is how much latitude the agent keeps versus how much you fix in advance — and Quick argues you need all three, because skills preserve institutional expertise while workflows buy you auditability.
  • The agent is the actor that learns — and almost nothing else. Standing instructions, available capabilities, learned context: that's the agent. The underlying model is a swappable parameter, conversation history belongs to the session, triggers belong to the platform. Two agents with identical input behave differently because their instructions, capabilities, and histories differ. That's the whole point of identity.
  • The honest caveat: this is vocabulary, not evidence. Quick describes learned context improving later executions and skills "crystallizing" into workflows — but supplies no benchmark, no success rate, no learning algorithm. The taxonomy tells you where to look for a disagreement; it doesn't prove the system gets smarter. Treat it as a design language, not a performance claim.

Go deeper

The full breakdown — the four trigger types, the skill-versus-workflow split, and where the taxonomy stops short — is on Agentic Affairs: Taxonomy of agentic primitives in Amazon Quick

Originally published on Agentic Affairs (https://agentic-affairs.com)

Top comments (0)