A run is the moment a network earns its keep
A network you’ve built is just a definition until it runs. Each run is where the actual work happens — where the input becomes the output, where time passes, where decisions get made, where the value lands.
This page covers what you see during and after a run, how to dig into what each step actually did, and how to handle the moments when something needs a second pass.
Watching a few runs end-to-end is the fastest way to learn a network. Once you've seen what each step produces in real conditions, the network's structure stops being abstract and starts being a tool you trust.
Watching a run live
Every run gets its own screen. The moment the network starts, the screen begins lighting up.
You see:
- Which step is running right now. Highlighted live as the network moves through its stages.
- What each step has produced so far. Outputs appear as steps finish; you don’t have to wait for the whole network to be done.
- How long each step took. Useful for spotting the slow part of a network.
- Any tools that ran. A Tool step shows which tool it called and what it returned.
- The overall progress. A clear indicator of how far through the network you are.
You can leave the screen and come back later — runs continue independently. You can also stop a run mid-way if you spot something off in an early step.
Reading intermediate outputs
The single most valuable habit when working with networks is reading intermediate outputs.
Each step produces something. You don’t have to wait for the final result to see if the work is on track. Click into any completed step and you see exactly what came out — the draft, the search results, the analysis, the tool’s response.
A pattern that works:
- Glance at the first intermediate output. Does it look right?
- If yes, let the rest run.
- If no, stop and fix. Adjust the input, the step’s instruction, or the upstream block.
Catching a problem two steps in saves twenty minutes of running the rest of the network on bad inputs.
Artifacts — the files a network produces
Networks don’t only produce text. They also produce files — PDFs, spreadsheets, images, charts, mockups. These are called artifacts.
Every artifact a network produces lands in the run’s artifact panel. You can:
- Open it. Preview the file in place.
- Download it. Pull it to your machine.
- Share it. Send the artifact link to a teammate without giving them the whole run.
- Pin it. Keep it visible after the run finishes so it doesn’t get lost in history.
For triggered networks, artifacts often flow on to the next step automatically (an email, an upload to a connected folder). The artifact panel is the durable record of what was produced.
Re-running a single step
When a step’s output isn’t quite right, you don’t have to re-run the whole network. You can:
- Edit the step’s instruction or inputs.
- Re-run from that step.
- Let the rest of the network re-run automatically with the new output flowing in.
This is the single biggest time-saver in working with networks. The cost of a tweak is the cost of one step, not the cost of the whole workflow.
Re-run small. Iterate fast. The teams that get the most out of networks treat each step as independently editable. Change one thing, re-run from there, see the effect. Five small iterations beat one big rebuild.
When a step fails
Networks fail sometimes. When they do, the run screen makes it clear what happened and where.
Three patterns cover most failures.
Missing or wrong input
The most common kind of failure. A step expected something — a file, a value, a previous output — that didn’t arrive in the shape it needed.
The fix: look at the previous step’s output. Usually you’ll see that it didn’t produce what the failing step needed. Adjust upstream, re-run from the step that drifted.
Source unavailable
A connected source was offline, a file was moved, a webpage didn’t load. The network reports the specific source.
The fix: confirm the source is reachable, reauthorize a connection if needed, re-run from the failing step.
A tool couldn’t complete
A tool step tried to run and the tool itself returned an error. The run screen shows the tool’s error message.
The fix: read the error, adjust the inputs or the tool call, re-run. Most tool errors are about a malformed input the tool couldn’t process — and a small fix solves it.
Comparing runs
When you’ve tuned a network and run it twice with different settings, you often want to compare the two runs side-by-side.
The Runs view of a network shows every recent run, with:
- Inputs used. What changed between runs.
- Duration. Which run was faster.
- Step outputs. A side-by-side diff of each step’s result.
- Final result. The deliverable each run produced.
Useful moments to compare:
- After tweaking a step’s instruction. “Is the new draft sharper than the old one?”
- After swapping the underlying model. “Did the cost change? Did the quality?”
- After a source change. “Is the new dataset producing a different answer?”
Run history and audit
Every run is logged. The Runs view lets you filter by:
- Status. Successful, failed, partial.
- User. Who ran this network most often.
- Time range. Last day, last week, last month.
- Trigger. Manual, scheduled, webhook, event.
For shared networks, the history is a useful signal: which networks are being used, by whom, how often. For workspace admins, it’s part of the audit story — see Governance and admin.
A short troubleshooting list
| Symptom | What it usually means | What to try |
|---|---|---|
| A run sits at the same step for several minutes | The step is doing a slow tool call (search, crawl, big generation) | Wait — runs are still live until you see an error |
| The same step fails on every run | The step’s instruction is unclear or its inputs aren’t what it expects | Read the upstream output; tighten the instruction |
| The final result looks wrong even though every step succeeded | The combination of step outputs added up to something off | Read every intermediate output; find where the drift started |
| Artifacts aren’t where I expected | The delivery step didn’t run or the destination changed | Check the end of the run; confirm the delivery step’s configuration |
Habits that compound
Open one run a day, read every intermediate output
For your most important networks, look at one run a day. You’ll learn fast which steps drift, which steps are bulletproof, and where your team’s instructions could be sharper.
Re-run from the smallest possible step
Don’t restart the network when restarting one step would do. The platform is built for incremental re-runs — use them.
Save a few “good runs” as reference
When a run produces a particularly clean result, pin it. Future runs that drift can be compared against the pinned reference.
After a failure, write a one-line lesson in the network description
“This network can fail when the source folder is renamed mid-week. Check connection scope before re-running.” Future you (and future teammates) will save the diagnostic time you just paid for.
Where to go next
- Node types — what the blocks you’re watching actually do.
- Versions and templates — save a working network so the next run uses the right shape.
- Triggers and schedules — start a run the right way for the workflow.
- Building workflows — go from one good run to a repeatable workflow.