Academy

From worker to specialist: an agent that owns a domain

The difference between an executing worker and a specialist is that the first does one job and steps aside, while the second owns a domain and carries its state over time.

The Felesh team 4 min

When building a multi-agent system, you soon hit an architectural choice: should an agent execute one specific task, or own an entire domain? The difference appears small at first, but it shapes the behaviour of the entire system. Here are the two ends of that spectrum.

The one-step worker

The simplest kind of agent is a one-step worker: it performs an action, returns the result, and steps aside. It reads a record, executes a search, or computes a value. This worker holds no state over time. It requires no context about what preceded it or what follows. It takes an input, returns an output, and halts. This pattern is excellent for independent, stateless tasks.

Two calls to a one-step workerA one-step worker is asked where order D-5520 is and answers: packed, ships Tuesday. Its memory slot reads: kept, nothing. In a second call the customer asks when it arrives, and the worker has no memory of the first call, so it can only ask: which order?two calls to the same one-step workercall 1where is D-5520?workerpacked, ships Tuekept: nothingcall 2when is it due?workerwhich order?no memory of call 1, so it has to ask again
A one-step worker takes an input, returns an output and keeps nothing, so a follow-up reaches it with no trace of the first call.

The domain-owning specialist

Many tasks, however, are not a single action. They are a flow that unfolds across multiple interactions. Here, you need a different kind of agent: one that owns a domain, holds state across interactions, manages transitions, and decides for itself when the flow is complete. This agent is no longer a simple executor; it is a specialist.

One specialist across three messagesThree customer messages about moving a delivery. After the first, the state of D-5520 reads step ask_day and the rule says: no slot, ask for a day. After Thursday afternoon, the slot becomes Thu 14 to 16 and the step confirm. After yes, the step becomes done, and the specialist decides by itself that the flow is complete.customer message, then the specialist’s replyCan I move my delivery?Which day suits you?Thursday afternoon.Thu 14–16, confirm?Yes, book it.Booked. Done.state of D-5520stepslotrule that fired—ask_dayconfirmdone—Thu 14–16no slot: ask for a dayslot set: confirm itconfirmed: close flowit decided by itself that the flow is complete
A specialist carries the order's state from message to message and picks each next move by its own rule, until it sees the flow is done.

Consider the human equivalent: a one-step worker is a lab technician you instruct to run a test and return a result. A specialist is the physician holding the patient’s file: they understand the history, decide the next clinical step, and take responsibility for the entire diagnostic path.

Where the difference shows in practice

The key difference lies in the ownership of state and logic. A one-step worker sees only its immediate task definition, requiring no context about the past or future. A specialist owns the complete lifecycle of a flow: it reads the prior state, determines the next step according to domain rules, updates the state, and knows exactly when its work concludes. No external planner dictates its steps; that routing knowledge lives inside the specialist.

This boundary yields a secondary benefit. Because the specialist is concerned exclusively with its own domain logic, it requires no knowledge of other agents, overall system routing, or global state. The system handles coordination and ordering; the specialist handles its own work. This separation makes the agent simpler and the overall system more stable.

Where the flow’s rules liveLeft, workers only: a coordinator holds the rules no slot ask for a day, slot set ask to confirm, confirmed close the flow, and keeps each order’s state, calling three workers: ask, confirm, close. Right, with a specialist: the coordinator only routes the request to a specialist that holds the state, step and slot, and the rules ask, confirm, close.workers onlycoordinatorno slot: ask for a dayslot set: ask to confirmconfirmed: close the flowkeeps each order’s stateaskconfirmclosecoordinator holds the ruleswith a specialistcoordinatoronly routes the requestspecialiststate: step, slotrules: ask, confirm, closethe rules live with the domain
With workers only, the coordinator carries the flow's rules; with a specialist it only routes, and the rules stay with the domain.

When to use which

The choice between the two depends entirely on the nature of the task. If a task is independent and stateless—one action, one result—the one-step worker is structurally superior. Adding state and a lifecycle here only introduces needless complexity. However, if a task unfolds across several interactions, where each decision depends on the previous outcome, a specialist must own that flow.

Which agent for which taskFour tasks. Read the status of D-5520: one turn, builds on nothing, worker. Price delivery for 12 kg: one turn, worker. Reschedule D-5520: three turns, each builds on the last, specialist. Return D-5520 with label and pickup: four turns, specialist.taskturnsbuilds on lastread the status of D-55201noworkerprice delivery for 12 kg1noworkerreschedule D-55203yesspecialistreturn D-5520, pickup4yesspecialistone action, one result: worker. A flow: specialist.
One action and one result stays a worker; a flow of several turns, each building on the last, gets a specialist.

A common anti-pattern is building an entire multi-agent system from one-step workers, forcing the flow logic into the coordination layer where it does not belong. When a domain requires a multi-step flow, let a specialist own it. This architectural boundary is often the difference between a system that scales gracefully and one that becomes more fragile with every new capability.