AI agents can do very different kinds of work. Some handle a single, well-defined task. Others decide what to do next as a process unfolds. Still others develop a plan before carrying it out. These approaches are often grouped together under the term “agentic workflows,” but they work differently. Understanding where and when an AI model makes decisions helps explain the trade-offs in flexibility, consistency, speed, and cost. Three common patterns illustrate the differences.
Type 1: The Atomic Agent (AI-Native Task Automation)
The Technology
An atomic agent is a single-purpose AI agent that receives a bounded task with a defined input and output, completes it, and returns the result. For example, a telecom operator may use an atomic agent to check and standardize incoming service-order details. It can interpret inconsistent address formats, identify missing information, and return a validated record for the next step in the order process. It does not decide how the entire order should be fulfilled; it performs one piece of the work.
The Business View
Because an atomic agent handles one bounded task, its behavior is generally easier to test and review than that of an agent managing an entire process. Its model usage is also relatively contained. But it still makes AI-driven decisions, so the output may vary, and a defined task does not automatically guarantee a fixed cost or result.
The main limitation is scope: an atomic agent does one task, not an entire process. Several agents can be connected in sequence, but someone or something still has to decide what happens next, pass information between them, and handle exceptions. In other words, the agents may be the workers, but a multi-step process still needs a way to coordinate the work.
Type 2: The Supervisor-Orchestrated Agentic Workflow
The Technology
Here a supervisor agent manages a process by repeatedly asking an AI model what to do next. It selects an action or specialist agent, receives the result, and uses what it learns to choose the next step. Consider a bank investigating a failed trade settlement. The supervisor might examine transaction records, ask a specialist agent to compare counterparty details, retrieve an exception report, and decide which discrepancy to investigate next. The path changes with the evidence. A human can review and authorize any consequential correction before it is made.
The Business View
The advantage is flexibility. A supervisor can adjust course when the path is not known in advance, which makes this approach useful for exploration and work that calls for frequent judgment. The trade-off is that repeated model calls can add time and cost. Because the model can choose a different next step on each run, outcomes can also be harder to predict or reproduce. That is not necessarily a flaw; it is a characteristic to understand when deciding how the work should operate.
Type 3: The Plan & Execute Agentic Workflow
The Technology
In a Plan & Execute workflow, an AI model develops a plan before the steps are carried out. Instead of asking a supervisor to decide every next move, an executor follows that plan. Some implementations create a fresh plan for each request; others allow plans to be reviewed, stored, and reused. The distinction is not whether AI can design the work, but whether its design is recreated for each transaction or becomes an approved way of operating.
Example: processing incoming invoices at a bank or telecom operator. The model can determine a sequence for extracting invoice details, matching them to purchase orders, checking approvals, and routing discrepancies. In one version of Plan & Execute, it creates a new plan for each invoice. In another, similar invoices follow an approved plan until a condition arises that the plan does not cover. Both plan before execution, but differ substantially in the amount of repeated reasoning and variability they introduce.
The Business View
Separating planning from execution can reduce the need for a model decision at every step. The practical questions are what information the model uses to create the plan, whether that plan is reviewed and reused, and what happens when the work no longer fits it. Planning anew offers adaptability; reusing an approved plan offers consistency for recurring work. Neither characteristic, by itself, makes one architecture the answer to every kind of operational problem.
How Kaya Approaches Repeatable Work
Kaya supports all three patterns: Atomic, Supervisor, and Plan & Execute. Its approach to repeatable work starts before execution. AI can absorb the materials that describe how an operation runs today, including standard operating procedures, playbooks, existing automation files, screenshots, and context from internal chat applications and other systems. It uses those materials to design a new way to perform the process: the steps, decision points, handoffs, and paths for handling exceptions. A human reviews and approves the proposed redesign before it becomes an executable plan. The basic sequence is:
01 AI designs the process; people approve it. AI synthesizes the operational materials and creates a redesigned process, rather than simply transcribing existing instructions. The proposed plan is reviewed by the relevant experts, approved, versioned, and stored in the plan library.
02 Run the approved design consistently. Transactions that meet the plan’s conditions follow its approved steps without asking the model to redesign the process each time. Kaya preserves what happened during execution, including the decisions, outcomes, and any human interventions.
03 Record and resolve exceptions. When a case falls outside the approved path, it is handled through an exception process, which may involve additional AI reasoning and human judgment. The circumstances, actions taken, and resolution become part of the execution history.
04 Turn recurring exceptions into approved improvements. When enough similar exceptions reveal a repeatable need, AI develops a proposed new step or pathway from their documented resolutions. A human approves the change before it joins the versioned plan library and is used for future matching cases.
Consider a telecom service-order process. AI could examine the operator’s provisioning playbooks, process documentation, existing scripts, screenshots, and records of how teams coordinate work. It then designs a proposed order-handling process for approval. Once approved, matching orders follow that process consistently. If a particular kind of order repeatedly requires manual intervention, the documented exceptions provide the basis for AI to develop a new step or pathway. That proposed change is reviewed and approved before it is added to the plan library. The process can therefore become more capable over time without silently changing the rules while work is underway.
The Three Types at a Glance
| Type | How it works | Key trade-off | Typical use |
|---|---|---|---|
| Atomic agent | One agent handles a bounded task | Limited scope; output may vary | Individual tasks |
| Supervisor-led | A model repeatedly decides the next step | Flexible, but repeated reasoning adds cost | Exploration and adaptive work |
| Plan & Execute | A model plans; an executor follows the plan | Consistency depends on when plans are reused | Work that can be planned |
Understanding the Differences
These three types are not stages of maturity, and one does not replace the others. An atomic agent performs a bounded task. A supervisor-led workflow decides what to do next as information emerges. Plan & Execute designs a plan before carrying out the work. Organizations may use all three, even within the same operation. The key distinctions are when AI reasons, how often it reasons, what the reasoning produces, and whether that result can be reused.
Those distinctions affect flexibility, consistency, cost, and the ability to explain what happened. A further distinction matters for repeatable operations: whether the process design itself can evolve through approved changes informed by the documented history of exceptions and human decisions. Understanding these differences gives business and technology leaders a clearer language for how agentic workflows operate, without implying that a single architecture is right for every situation.
