Designing a manager–worker system

This lesson exists to shift our focus from individual agents to systems of agents. Once we allow an agent to run autonomously over time, questions of structure, responsibility, and coordination become unavoidable. Designing the system up front helps us avoid tangled behavior and unclear control as autonomy increases.

Defining the overall goals of the autonomous system

An autonomous manager–worker system starts with a clear purpose. The goal should describe what the system is trying to accomplish over time, not how individual agents behave internally.

For example, the goal might be to continuously generate and update a set of static HTML pages about planets and moons as new data appears. This framing gives the system direction without prescribing implementation details.

Identifying manager and worker agent roles

Once the goal is clear, we separate responsibilities into roles. The manager agent is responsible for deciding what work needs to happen and when. Worker agents are responsible for doing specific pieces of that work.

A worker might generate a single planet page, while the manager decides which planets need updates and assigns tasks accordingly. Each role exists to reduce cognitive load and keep reasoning focused.

Determining responsibilities and boundaries for each agent

Clear boundaries prevent agents from stepping on each other’s work. The manager should not generate HTML directly, and workers should not decide overall priorities.

This separation keeps reasoning localized. When behavior needs to change, we know which agent is responsible, and we can modify it without unintended side effects elsewhere.

Designing communication and coordination mechanisms

Agents must communicate, but communication should be simple and structured. Messages often represent task requests, task results, or status updates.

For example, a manager might send a worker a task description containing a planet name and an output path. The worker responds with a result indicating success and the location of the generated file. Coordination emerges from these explicit exchanges rather than shared assumptions.

Planning how state, memory, and tools are shared or isolated

Not all information belongs everywhere. Some state is global, such as a list of known planets, while other state is local, such as a worker’s temporary output buffer.

Tools should follow similar rules. A worker may have access to file-writing tools, while the manager may only read summaries and decide next actions. Planning these boundaries early keeps the system predictable and easier to reason about.

Conclusion

At this point, we are oriented to what it means to design an autonomous manager–worker system. We know how to define goals, assign roles, set boundaries, and plan communication and state sharing. With this structure in place, we are ready to turn the design into a running system.