Choose work that can actually run in parallel
A good starting point is a feature with separate research, implementation and testing questions. Give each session a clear responsibility rather than asking several agents to solve the same vague problem.
For example, a welcome-flow change can have one session investigate the existing experience, another propose the implementation and another identify failure cases. This is an illustrative workflow, not a report of a measured speed improvement.
- Research: explain the current behavior and the constraints.
- Build: implement an agreed change in the relevant project.
- Test: check the acceptance criteria and report reproducible failures.
Write one brief that all sessions can use
Describe the outcome, the scope and how a person will decide the work is complete. Attach the relevant project and documents. State what is deliberately out of scope so an agent does not turn a small change into a larger redesign.
In TM8, tasks, documents and sessions can stay connected to the same work. A focused session can carry its own conversation while still referring back to the shared intent. Shared context helps alignment; it does not remove the need to inspect the result.
Make dependencies explicit
Parallel work still has an order. An implementation may depend on a design decision, and a review may depend on a working build. Identify those handoffs before starting every session at once.
Ask each session to return the result, the checks it performed and any unresolved question. When work touches the same files or decisions, choose a clear integration owner and reconcile changes before the final review. More concurrent sessions are not automatically faster or cheaper.
Review the result as one change
A collection of successful session reports is not proof that the combined outcome works. Check the integrated behavior against the original brief, run the relevant tests and inspect the parts that a user will see.
The TM8 product tour shows parallel sessions and returned assessments. The interactive workspace on this site uses sample data; it does not execute agents or measure production concurrency. Actual capacity depends on the infrastructure and model-provider limits.
- Does the integrated result meet the acceptance criteria?
- Are the tests relevant to the changed behavior?
- Are open questions and remaining risks visible to the person deciding whether to ship?
Common questions
Does running more agents guarantee a faster result?
No. Dependencies, overlapping changes, model latency and review overhead affect the outcome. Start with a small, separable scope and measure it.
Where can I see this in TM8?
The recorded product tour shows parallel sessions and returned work. The Product page also includes a local interactive example with invented sample data.
TM8 workflow guide · Reviewed 25 October 2026
Watch the recorded product tour →Read our website-build story →