We are asked to move an AWS infrastructure: one Application Load Balancer serves around 50 virtual hosts, and we want to improve performance. First, though, we need to agree which measures to use and which constraints to respect.
If we ask a model for a complete plan straight away, we may get a polished answer that fills any gaps with assumptions and risks exhausting the context window. In these cases, it helps to take a project management approach: break the work into tasks a single agent can handle, then orchestrate them through a separate project-manager agent. First we map the current state, then define the comparison criteria, and finally prepare the migration phases.
This example illustrates a method; it is not a project ready to execute. The architecture, configurations and sizing in the examples are purely illustrative.
What does “faster” mean?
We may want to reduce response times, handle traffic peaks better or simplify maintenance. These are different goals and can lead to different choices. Before comparing platforms, we need to decide what to measure and how to establish the baseline.
The AI project manager starts with a clear brief: objective, confirmed information, gaps and expected outputs. We explicitly ask it to create three specialist agents, assign one to each task and coordinate the handoffs. We also want a detailed report for every task, so we can follow each agent’s work and understand what supports its findings. For example:
<task role="migration-project-manager">
<objective>
Organise the assessment and planning for moving an AWS service
to a new infrastructure.
</objective>
<context>
One Application Load Balancer serves around 50 virtual hosts.
We want to improve performance, but have not chosen a target
architecture or defined how success will be measured.
</context>
<work>
Create three specialist agents and assign a distinct task to each.
For every task, define its objective, scope, inputs, expected output,
dependencies and completion criteria.
<agent id="1" name="current-state">
Build an inventory of the 50 or so virtual hosts and the services
they depend on. Include the source and date for each data point;
separate confirmed facts from assumptions and flag missing details.
Output: inventory, dependencies and checks still required.
</agent>
<agent id="2" name="requirements-and-options">
Clarify which measures could describe the expected improvement.
Compare architecture options only against confirmed requirements
and the available inventory. If performance criteria have not been
approved, list the questions to resolve and do not claim that one
option is faster.
Output: criteria, options, trade-offs and missing information.
</agent>
<agent id="3" name="migration-plan">
Prepare migration phases using the verified current state and any
approved direction. For each phase, list prerequisites, dependencies,
checks and conditions for stopping or rolling back. If a choice or
approval is missing, provide a conditional plan and state where work
must wait.
Output: phased plan, checks and decisions required.
</agent>
Start each task when its required inputs are available. If a dependency
is unmet, report the blocker and do not invent information. Coordinate
handoffs between agents and collect conflicts and gaps.
</work>
<constraints>
Separate facts from assumptions and flag missing information.
Do not propose executable changes or invent requirements.
</constraints>
<task_reports>
Ask each agent for a detailed report on its assigned task, both during
the work and at handoff. Each report must include: task and responsible
agent; objective and scope; inputs received; work completed; findings
and sources; assumptions and gaps; status, dependencies and blockers;
output delivered and next handoff. If a task has not started or is
blocked, state why and what is needed to proceed.
</task_reports>
<result>
Return all three detailed reports and an overall summary. Highlight
conflicts between findings, open dependencies and decisions that need
our approval.
</result>
</task>
The prompt does not choose the solution, but helps the AI project manager create the agents, assign the tasks and surface open questions. The reports let us review each agent’s contribution and blockers as well as the overall result.
Three tasks, three outputs
Rather than asking every agent the same question, we give each one a defined task and an output the next person can use.
| Task | What it needs to clarify | Output |
|---|---|---|
| Current state | Which virtual hosts are there, what services do they depend on, and what information is missing? | Inventory with sources, owners and open checks |
| Requirements and options | Which measures define improvement? Which options are worth comparing? | Criteria, options and trade-offs to discuss |
| Migration plan | Which phases, checks and stop conditions are needed? | Conditional plan with dependencies and decisions required |
Each agent produces an output that the next can review and use.
The outputs need to use compatible references. If the inventory names a service one way and the plan uses another, the project manager asks for the data to be reconciled before moving on. A polished summary can clarify the findings, but it cannot resolve a discrepancy.
When the outputs do not line up
Imagine the agent mapping the current state cannot find reliable response-time measurements. The one comparing options cannot then claim that a platform is “faster”: it can list the alternatives, but it has to leave the comparison open.
The project manager records the gap and asks us to choose a metric and a source. Meanwhile, the agent preparing the migration can outline the phases, but leaves the target choice and acceptance criteria unresolved.
This is where orchestration matters: the project manager connects the outputs, but does not make up missing data to make the plan look complete. When information is insufficient, it returns a specific question and identifies the decision that is still needed.
Who makes the decisions?
The AI project manager compares sources, identifies contradictions and flags tasks without prerequisites, but it does not know every dependency in the environment or take responsibility for operational risk. We review the evidence, approve the choices and authorise changes.
If the agents do not share a state or work repository, the project manager has to pass information to them manually: prompts define the tasks, but do not create the system that connects them.
A phase does not begin just because the previous task is complete: first, we check that its output contains the required evidence and that we have made the necessary decisions. If a prerequisite is missing, the project manager pauses the workflow and asks us to clarify it.
Checking the result
After the migration, we compare the agreed measures with the baseline and record interruptions, anomalies and differences from the plan. If the result is not what we expected, we ask the agents to explain the gap, but not to bend the analysis towards the conclusion we want.
We can reuse the structure for other projects, but we need to redefine the tasks, sources and criteria each time. Before adding an agent, I would ask: what does it need to receive, and what should it hand over to the next agent? If the inputs, outputs and checkpoints are unclear, another agent adds steps but does not improve coordination.
Conclusions
To get the expected benefits (more manageable tasks, verifiable handoffs and visible gaps), we need to define the assignments, inputs, outputs and approval points. We should set our expected result in advance; it gives us a baseline for comparison. Setting up the first multi-agent structure takes effort, which we can refine as we use it. Reusing it on later projects avoids repeating the implementation cost and lets us focus on the benefits of the method.