Step by step

When multiple agents work together,
how do results move between them?

We split a search feature into three investigations. Which ones are done, and what does the next owner need to know?

See it in action ↓Read the visual overview
“Add a search feature.”
While the test review is still running · Example

Three investigations

UI reviewDone

Search box location · Product list screen

Data reviewDone

Product list · /products response

Test reviewRunning

Reviewing existing tests

Gather results yourself

Open each session to see its findings

Read the two completed findings and pass the relevant details to the implementer.

Next task

Implementer · Waiting for findings

The UI and data findings have yet to arrive.

Two investigations are complete. The test review is still running.

Start with one request

“Add search to the existing app.”

Start with one assigned task. Select each step to see who does what and which results they're waiting for.

Building the search featureIllustrative scenario

Give one agent a goal

1 / 5

The agent inspects the code, makes changes, and runs tests. The user reviews what changed and how it was checked.

UserGoal and constraints

Request search and review the result.

TaskAssign to one session

The request and results stay in one session.

Agent
What the next step needs The request and the codeWhat you see · Session activity

Follow the test result

What happens when a test fails?

Say you've changed the search code and run a test. Choose a result. In this example, you can retry up to twice after the initial test.

Example · Paths based on test results
Test agent Run search tests Orchestrator Check test result and retry count Pass · stop Developer Review code and tests Fail · retries left Coding agent Fix the reported error After the fix Retest Fail · limit reached Stop the run Developer Review the failure record
Choose the initial test result

Choose whether the test on the updated search code passes or fails.

Retries 0 / 2

This example starts with a test that ran and returned a failure. If the command never runs, investigate that separately.

Read about branching and stopping in the visual overview →

Why does coordination matter?

Separate tasks have to come back together

The UI and data reviews can start together. Verification waits until the changed code is ready to test.

Who does the work

Agent

Agents read and change code or run tests within their assignment. They leave findings, code changes, and test records.

What connects the work

Orchestrator

The orchestrator connects tasks to their owners and tracks status. It passes relevant findings to the next task and gathers records for people to review.

When you need an orchestrator

It's useful when work splits into several paths and you need to track which results are pending and where they went. A small change, like editing one line, can fit in a single session.

The person's role

Who coordinates the same goal?

You can assign tasks yourself. Where supported, a lead agent or a defined workflow can take care of assignment and collect the results.

You assign each task

The user opens each research session and checks the results. They hand relevant findings to the implementer and decide when verification can start.

UserResearcherUserImplementer and tester

As work scales up

What should you check first?

Each cell is a task. Change the task count and select a status. These task states are illustrative.

Task status at a glance

Task and agent counts depend on the job.

Which agent should you use?

Sessions and agent types

When assigning several tasks, consider how many sessions will run and which agent types to connect.

Run the same agent more than once

Open separate sessions of the same agent and assign one each to the UI, data, and test reviews.

Connect different agents

Supported agent types and controls for starting, monitoring, sending input, and stopping depend on the orchestrator and its settings.

Explain it yourself

How would you explain it to a teammate?

The UI and data reviews are done. The tester hasn't received the updated code yet. Think about what still needs to happen.

What does the next step need?

Pass the findings to the implementer. Once the code is ready, hand it to the tester, who records the checks and their results.

What does the orchestrator do here?

It can show each task's owner and status and help the next task receive the findings it needs. The user reviews the changes and test records and decides what comes next.