Magentic manager

All steps

Normal run

1. Request arrives. The manager will not do the work itself. Its job is to plan, assign, check progress, and notice when the plan has stopped working.
2. Plan. The manager lists what is known, what must be found out, and who can find it: the order record first, then proof of damage.
3. Write the ledger. The plan is stored outside any model's context. Long tasks outlive a context window, and a ledger does not forget step one by step ten.
4. Assign task one. One agent works at a time, on one task from the ledger.
5. Task one done. The order agent finds order 4417, delivered 12 Sep. The manager marks the task complete.
6. Assign task two. Next on the ledger is proof of damage.
7. A dead end. The carrier has no record under the order id. A fixed plan would stall here, or report failure.
8. Replan. After every turn the manager asks whether progress is being made. It is not, so it rewrites the plan to search by tracking number instead.
9. Assign the new task. The same agent, a different approach.
10. Task two done. Under the tracking number the carrier's damage report turns up. The ledger is complete.
11. Respond. Refund approved. It was slower and dearer than a plain orchestrator, and it got past an obstacle that would have stopped one.

Outcome: correct answer, after one replan. The ledger and the progress check are what set this apart from an orchestrator. They pay off on open-ended tasks where the first plan is likely to be wrong.

Failure mode

1. Request arrives. Identical start to the normal run.
2. Plan and ledger. The same plan, written to the ledger.
3. Task one done. The order agent finds order 4417. Nothing has gone wrong yet.
4. A dead end. The carrier's API is down today. The agent reports it the only way it can, as no record found.
5. Replan. No progress, so the manager replans to search by tracking number. So far this is the pattern working as designed.
6. The same dead end. A different query against the same dead API gives the same answer.
7. Replan, and replan again. Plans three and four reword the same search. The ledger records every attempt, but nothing counts them or asks why they all fail alike.
8. Budget exhausted. The large model's planning turns were the expensive part. The run ends with a full ledger of attempts and no answer for the customer.

Failure: replanning without a stall limit. The ability to replan turns into a loop when nothing bounds it. Mitigation: count stalled turns, cap the replans, tell tool failures apart from empty results, and escalate to a person at the limit.