Implementing the capstone system

This lesson exists to close the gap between design and execution. Up to this point, we have talked about roles, boundaries, communication, and control in abstract terms. Now we bring those ideas together into a working system that actually runs, makes decisions, and produces observable behavior over time.

The goal is not polish or completeness. The goal is to see how multiple agents, tools, memory, and workflows fit together in real Python code without losing sight of the original design intent.

Assembling manager and worker agents

Implementation begins by turning conceptual roles into concrete agent instances. Each agent exists as its own unit, with its own state, tools, and responsibilities.

A manager agent is typically responsible for coordination and decision-making. Worker agents are responsible for execution. The important point is that these roles are reflected in code structure, not just comments or naming.

At this stage, agents are created explicitly and held in memory by the running program. The system knows which agent is the manager and which are workers, and that relationship is encoded directly.

Wiring tools, memory, workflows, and reasoning

Once agents exist, they need capabilities. Tools are attached so agents can act. Memory is configured so agents can remember what matters. Workflows are defined so multi-step behavior is possible.

This wiring is where earlier abstractions meet reality. Tools must accept the inputs the agent can provide. Memory must store state the agent will actually read later. Workflows must align with how decisions are made.

Nothing here is automatic. Each connection is deliberate, and mismatches are usually obvious once the system runs.

Running the system as a long-lived process

With agents assembled and wired, the system is started as a long-running process. A main loop keeps the system alive, allowing agents to receive input, delegate work, and respond over time.

This loop does not need to be complex. Its job is to keep control flowing and prevent the system from exiting after a single action. In practice, it often waits, wakes up, checks state, and lets agents do their work.

Running the system continuously is what reveals whether the design holds up beyond a single interaction.

Observing and validating system behavior

Once running, the system should make its behavior visible. Output, logs, or generated artifacts act as signals that agents are doing what they are supposed to do.

Observation is not about debugging individual lines of code. It is about validating that responsibilities are respected, coordination happens where expected, and no agent quietly takes on unintended roles.

If behavior feels surprising, that usually points to a design mismatch rather than a small implementation bug.

Iterating while preserving design intent

Iteration is expected at this stage. Tools change shape, workflows get adjusted, and memory structures evolve. What matters is that these changes do not collapse the original separation of concerns.

Good iteration improves clarity without re-centralizing everything into one agent or one function. When the design intent remains visible in the code, iteration strengthens the system instead of eroding it.

This discipline is what keeps a capstone system from turning into an unstructured script.

Conclusion

At this point, the capstone system exists as a real, running multi-agent program. Manager and worker agents are assembled, connected to tools and memory, and kept alive by a long-running loop. The system’s behavior can be observed, validated, and refined.

The goal of this lesson has been achieved if the system feels coherent rather than accidental. We are no longer talking about autonomous agent systems in theory. We are running one.