Step 1 of 4
Analyze the workload for separability
The architecture question is really a workload question.
Analyze my agent workload before choosing an architecture. Answer in writing: (1) Can the work be split into subtasks that do NOT need to share intermediate state? (2) Do subtasks need different tool sets or different permission levels? (3) Is there a natural review/producer split where one context should not contaminate the other? (4) What are my latency and cost budgets per task? (5) What is the blast radius if two workers act on stale views of shared state? Produce a one-page workload profile with these answers and concrete examples from my actual use case: [DESCRIBE YOUR USE CASE].
Expected after this step
A one-page workload profile answering the five separability questions.
Should not happen
- ✕Choosing multi-agent because the demo looked impressive
- ✕Underestimating coordination cost: message passing, state sync, partial failures
- ✕Role-play theater: five agents doing what one prompt would do better
- ✕No plan for what happens when one agent in a chain returns garbage
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Choosing multi-agent because the demo looked impressive
- !Underestimating coordination cost: message passing, state sync, partial failures
- !Role-play theater: five agents doing what one prompt would do better
- !No plan for what happens when one agent in a chain returns garbage
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The analysis is generic. Redo it against three real example tasks from my domain, tracing exactly what state each subtask reads and writes.