How to read these scenarios (now includes triggers & advanced patterns)
Scenarios 7–9 show off the newer capabilities — webhook triggers, scheduled runs, and sustainable routing — that didn’t exist when the original six were written.
Each example follows the same shape:
- The setup — who’s doing the work and what they need.
- The inputs — what the network takes in.
- The stages — the steps the network runs, with one-line descriptions.
- The final result — what comes out.
- Where it shines — why this scenario fits networks better than agents.
Copy these patterns. Adapt them to your team. Most can be built from existing templates in your workspace library.
1 — Quarterly business review for leadership
The setup
A chief of staff prepares the same shape of quarterly review for the exec team every quarter. Hand-assembled, it takes three days. With a network, ninety minutes.
Inputs
- Quarterly KPI dashboard exports
- Standup notes from each function
- Customer success summary
- The previous quarter’s QBR doc (for shape and tone)
Stages
- Gather and reconcile — pull together the KPIs, surface inconsistencies between sources.
- Draft the function-by-function summary — one section per business function.
- Critique for clarity and length — read like a sharp exec who wants the point in five minutes.
- Polish into the QBR template — apply the company’s standard QBR structure.
Final result
A polished QBR document, ready for the exec meeting, in the format the team already expects.
Where it shines
The work is multi-source, multi-function, and follows a known template. Doing it as four sequential agent runs is doable but tedious — a saved network turns three days into ninety minutes, every quarter.
2 — Vendor evaluation against an RFP
The setup
A procurement lead is comparing three vendors. Each submitted a 40-page RFP response. The team needs a side-by-side recommendation by end of week.
Inputs
- The three vendor RFP responses (attached)
- The company’s evaluation criteria (attached)
- The current incumbent’s profile (for context)
Stages
- Extract per-vendor profile — read each response, summarize against the criteria.
- Build a side-by-side table — compare across all dimensions.
- Flag unsupported claims — call out claims a vendor made that aren’t backed in the doc.
- Draft a one-paragraph recommendation — name the recommended vendor and the reasoning.
- Polish for the exec audience — tighten language, add a one-line risk callout.
Final result
A comparison memo with a side-by-side table, a flagged-claims list, a clear recommendation, and a risk note. Ready for the exec meeting.
Where it shines
Two of these stages — the side-by-side and the unsupported-claims check — are the kind of work that’s tedious to do by hand and easy to miss things. The network does it consistently across vendors.
3 — Customer health writeup before a renewal
The setup
A customer success lead has a renewal meeting in five days. They need a health writeup for an enterprise account — usage trends, recent tickets, sentiment from the last three calls, account team observations.
Inputs
- The customer’s usage data export
- Recent support tickets (linked from the connected helpdesk)
- The last three call transcripts
- The account team’s internal notes (linked from the connected workspace)
Stages
- Pull and reconcile the signals — usage trends, ticket patterns, sentiment from calls, account team notes.
- Identify the top three risks — concrete, with the source signal that flagged them.
- Identify the top three opportunities — features they’re underusing, expansion signals, integrations they’ve asked about.
- Draft the writeup — risks, opportunities, recommended action for the renewal conversation.
- Polish for the CS playbook format — apply the team’s standard structure.
Final result
A 2–3 page customer health writeup with risks, opportunities, and recommended actions. In the team’s playbook format.
Where it shines
The signals come from four different sources. A network handles the multi-source reconciliation cleanly, and the final output is in a format the CS team uses every week.
4 — Multi-step competitive deep dive
The setup
A strategy lead needs a deep dive on a competitor that’s just announced a major product release. The exec team meets in 48 hours.
Inputs
- The competitor’s press release and public materials (linked URLs)
- Three industry analyst takes (pasted)
- The team’s most recent positioning doc (attached)
- A list of our top five customers in that competitor’s target market
Stages
- Synthesize the competitor’s claim — what they announced, what they say it does, who it’s for.
- Map to the analyst takes — what the analysts agree and disagree on.
- Compare against our positioning — where the claim overlaps, where it differs, where we have a sharper story.
- Model the customer impact — for each of the top five customers, the implication of this launch.
- Draft the exec brief — three sections: what they announced, what it means for us, what we should do.
- Polish for the exec audience — tight, decision-oriented.
Final result
A 4–6 page brief that lands on the exec team’s desk the next morning, with a clear recommendation for action.
Where it shines
The customer-impact stage alone would take half a day by hand. The network handles all five customers in parallel and rolls the implications into one cohesive section.
5 — Recurring weekly engineering status
The setup
A VP of Engineering wants a weekly status digest pulled from the team’s standups, sprint board, and shipping log. They want it every Friday for the leadership team.
Inputs
- The week’s standup notes (from the connected workspace)
- Sprint board state at end of week
- The shipping log (from the connected git provider)
Stages
- Reconcile the three sources — what shipped, what slipped, what’s at risk.
- Draft the digest — one paragraph per theme, with named risks at the bottom.
- Polish for tone — confident, no jargon, no buzzwords.
Final result
A two-page weekly status digest in the leadership team’s preferred format. Saved as part of the weekly meeting prep.
Where it shines
Three stages, all from connected sources. The network runs in two minutes and saves the VP’s chief of staff several hours every Friday.
6 — Onboarding brief for a new enterprise customer
The setup
A solutions architect is onboarding a new enterprise customer. They need a brief covering the customer’s environment, the integrations they care about, the success criteria they’ve stated, and a 30/60/90 day plan.
Inputs
- The signed contract and statement of work
- The pre-sales meeting transcripts
- The customer’s environment doc (provided by them)
- The team’s standard 30/60/90 plan template
Stages
- Synthesize the customer context — who they are, what they bought, why.
- Map the integrations to the customer’s stack — what’s already in place, what needs to be built.
- Pull the stated success criteria — direct quotes from the pre-sales transcripts where possible.
- Draft the 30/60/90 plan — fitted to the customer’s success criteria.
- Polish for tone — the brief is shared with the customer, so it should read as ours but feel attuned to theirs.
Final result
A customer-facing onboarding brief, internally reviewed and ready to share at the first formal kickoff.
Where it shines
Onboarding is a stage-heavy task that benefits from being done the same way every time. A shared network means every new customer gets the same quality of welcome.
7 — Webhook-triggered incident triage
The setup
A platform engineering team wants every PagerDuty incident to land in their #incidents Slack channel with a triage summary — not just the alert text. A human still drives the response; they just don’t want to start from a blank page.
Inputs (passed in by the webhook)
- The incident’s title, severity, and affected service
- Recent commits to the affected service’s repository
- Recent deploys to that service
- The team’s incident-response playbook (in connected Confluence)
Stages
- Read the incident context — pull the affected service’s recent deploy and commit history.
- Look for likely causes — match the incident’s symptoms against the playbook.
- Draft a triage summary — the likely cause, the two checks to run first, and the playbook section to follow.
- Deliver to Slack — post the summary to #incidents with links to the supporting artifacts.
Trigger
A webhook trigger from PagerDuty. Fires the moment an incident opens. The summary lands in Slack within a minute.
Where it shines
A network without a trigger is a tool someone has to remember to use. A webhook-triggered network is part of the team’s response by default — the value lands without anyone clicking Run.
8 — Scheduled morning briefing for a leadership team
The setup
A CEO and their chief of staff want a one-page briefing waiting in their inbox at 7 a.m. — covering the previous 24 hours of customer activity, product releases, and any flagged news.
Inputs (pulled by the network)
- Customer-success activity (connected Salesforce + connected helpdesk)
- Product release notes (connected GitHub releases)
- Pre-curated news feed (a custom vector index over the leadership team’s tracked sources)
Stages
- Pull the last 24 hours from each source.
- Surface anything material — high-value customer changes, releases tagged as major, news flagged as relevant.
- Draft the one-pager — three sections, each three to five sentences.
- Deliver via email — to the CEO and chief of staff, by 7 a.m.
Trigger
A scheduled run every weekday at 6:45 a.m.
Where it shines
The briefing arrives whether anyone remembered to start it or not. Over months, that reliability is what makes it feel like a real intelligence product, not a sometimes-useful tool.
9 — Sustainable summarization pipeline
The setup
A research team summarizes hundreds of internal documents a month for an internal knowledge digest. The team has a public commitment to reduce the energy footprint of their AI workloads — and a summarization pipeline running thousands of times a month is a clear lever.
Inputs (per document)
- The document itself
- The team’s preferred summary structure (bullet headline + three-sentence summary)
Stages
- Extract the document’s key claims.
- Draft the summary in the team’s structure.
- Quality-check against the source.
- File the summary in the team’s knowledge digest folder.
Routing mode
Sustainable mode is set at the network level. The router picks energy-efficient models for every step that doesn’t need a heavy model.
Where it shines
The output quality is indistinguishable from what the team had before. The energy estimate per run drops noticeably. The team can show a real reduction in their AI’s environmental footprint without a single workflow change visible to readers.
Patterns across the examples
Look at all of these side by side and you’ll see the same DNA:
- A multi-stage shape that repeats. The task is the same every time; only the inputs change.
- Multiple sources reconciled. Two, three, or four sources combined into one output.
- A clear final deliverable in a known format. Reports, briefs, plans, digests — formats the team already knows.
- A natural audience. The output is for someone specific — exec team, customer, leadership.
When your task has those four traits, it’s network-ready.
Where to go next
- Building workflows — turn a recurring task of your own into a saved network.
- How networks work — the mental model, in depth.
- Triggers and schedules — pick the right way to start a network.
- Smart model routing — Auto, Sustainable, and Regulated modes.
- Getting started — if you haven’t run your first network yet, start there.