An agent is chat windows split by role, connected
A note that explains an agent as several chat windows with different roles strung together. If you ask for planning, design and development all in one window, context that has nothing to do with the job at hand gets mixed in, so the roles are split; and splitting creates a delivery that carries the earlier result to the later one. The moment you stop copying that delivery by hand and instead have the earlier role leave its result as a file for the later role to read is exactly the agent structure. It also corrects common misunderstandings. Even with four tasks, if only one thing actually does the work it is still one; AGENTS.md and CLAUDE.md are not agents but working guidelines consulted at all times while working; and running 24 hours a day does not mean thinking non-stop, but waiting until a condition arrives — a set time, or new material — then waking, finishing the work, and waiting again.
Key points
- Roles are split so that contexts do not get mixed
- Leave the result as a file for the next role to read and it becomes an agent structure
- Count by how many things actually do the work, not by how many tasks there are
- Even running at all times, it waits until a condition arrives
This is a note: my own write-up after reading several sources. It has no source link; events checked against a source are kept as records.