Building workflows

When a recurring task is ready to become a network

Not every task should be a network. The right time is when three things are true:

1. The shape of the work is stable. You know the stages, the audience, and the final output shape.
2. It repeats. At least monthly, ideally weekly. Anything you do once a quarter rarely justifies the build.
3. The team would benefit, not just you. Other people produce the same kind of deliverable.

If only one of those is true, keep using agents or chained agent runs. Build the network when you’d run it ten or more times without changing the shape.

A simple build path

Most teams don’t build networks from scratch. They start from a template, run it for real tasks, and customize it where it falls short.

1. Find the closest template.

   Browse the network library. Pick the template that produces an output closest to your goal.

2. Run it on a real task.

   Use a current, real piece of work — not a hypothetical. The gaps you see are the gaps you'll fix.

3. Write down what didn't fit.

   Wrong tone, missing stage, extra stage, wrong source rule. Be specific. "Stage 3's tone was too promotional" beats "the output felt off."

4. Customize one stage at a time.

   Don't rewrite the whole network. Adjust the stage that needed it, rerun, see if the gap closed.

5. Save it for the team.

   When the customized version produces consistent results across three runs, save it. Name it after the deliverable, not the project.

Designing a great network from a clear pattern

Sometimes there isn’t a template that comes close. In that case, design from first principles. Use this loop:

1. Start with the final output

Don’t start with stages. Start with the deliverable.

• What is the final output?
• Who reads it?
• What format is it in (one-pager, multi-section report, table, email)?
• What does “great” look like?

Get this part right and the stages design themselves.

2. Work backwards into stages

Now ask: what would you do, by hand, to produce that output well? Each step you’d take is a candidate stage.

For a competitor brief, the by-hand process might be:

1. Pull public information about the competitor.
2. Cross-check it against internal context (our positioning, our customers).
3. Draft a one-pager.
4. Have a critical reader push back on the strongest claims.
5. Apply the final polish for tone and length.

That’s a five-stage network.

3. Cut what doesn’t pay rent

Every stage adds time. Be ruthless. Ask:

• Could this stage be combined with the next?
• Does this stage produce something a human needs to see, or is it just intermediate detail?
• If I removed this stage, would the final output get noticeably worse?

A good network is the smallest sequence of stages that produces the result reliably. Most great networks have three to six stages, not ten.

4. Define the inputs the network needs every time

Inputs are the contract with the user. Be explicit:

• Required inputs — the network won’t run without them.
• Optional inputs — improve quality but aren’t blockers.
• Source rules — what files, folders, or connected apps each stage expects.

A clearly defined input list means anyone on the team can run the network without asking you what to provide.

5. Test it with three real tasks before saving

Three real runs with real work expose the failure modes. After three, you’ll know:

• Which stage is fragile.
• Which input is often missing.
• Where users will struggle.

Fix those, then save. A network shared too early creates frustration. A network shared after three solid runs spreads adoption.

Splitting work between several networks

Some work is too big for one network. The fix isn’t a longer network — it’s two networks chained together.

Good reasons to split

• The first half and second half need very different inputs. A research network produces a brief; a separate drafting network turns that brief into a customer-facing piece.
• Different audiences own each half. Strategy owns the analysis; marketing owns the campaign.
• The interim output has standalone value. Splitting lets you ship that interim output as its own deliverable.

Bad reasons to split

• “It’s getting long” — length alone isn’t a reason. A six-stage network can run cleanly.
• “I want to see the result faster” — networks already show intermediate outputs.

When you do split, give the two networks distinct names and document how they chain. Make it obvious which one comes first.

Sharing a network with your team

Once the network is solid:

• Name it for the deliverable, not the project. “Quarterly customer health report” ages better than “Q3 customer thing.”
• Write a one-paragraph description. What does it produce, who is it for, what does it need as input.
• Add an example run. A finished run lets new users see what good looks like.
• Tell someone about it. Saved networks discovered through Slack outperform saved networks people stumble onto.

Maintaining networks over time

Networks aren’t set-and-forget. Twice a year, look at the ones your team owns:

• Is anyone still using them? Retire the ones with no runs in 90 days.
• Has the output shape changed? If the audience expects a different format now, update the final stage.
• Have the sources changed? Connected apps move, folders get renamed, permissions shift. Refresh sources.
• Do the stages still all earn their place? You may find one you can collapse into the next.

Networks that get maintained build trust. Networks that drift quietly become liabilities.

A small network is a great first build

If you’ve never built a network, don’t start with the seven-stage masterpiece. Build something three stages long for a task you do every week. Run it for a month. The pattern, once you’ve felt it once, is easy to repeat.

Where to go next

• Use cases — six worked examples covering small and larger networks.
• How networks work — stages, intermediate outputs, and run reviews in detail.
• FAQ — sharing, splitting, and editing tips.