Team, skill, or just a session?

Every piece of work starts at the same fork. Open a chat and work it through yourself. Package it as a skill, so next time it runs without you describing it again. Or hand it to a team of specialists working in parallel.

The case study gives you the four questions for that choice — complexity, value, viability, cost of error. Good questions, hard to use cold: at the fork you don't yet know how the work will go. So here are three real decisions instead, lightest rung first — the order you should actually reach for them in.

1

Most work · most of the time

Just open a session

The first rung is just the chat window. You, the assistant, and however long the job takes. Nothing set up in advance.

The most useful thing I've built started in a session like that: a knowledge base that pins down what we decided about a feature area and why, so the plan of record and the open risks stay accurate.

The document isn't the interesting part — the assistant sitting over it is. Documentation dies of friction: you have to stop, find the right section, and rewrite it, so you don't. Here I say what changed in a sentence and it does that part. And because it has read the whole thing, it comes back with what's already recorded, what this contradicts, and what's now out of date. That's the part I'd miss on my own.

I keep it open while I work. I never turned it into a skill and never put it on a schedule. And it's still the thing I use most — worth saying, because once you can build skills, schedules and agent teams, the pull is to build one. Most work doesn't need one.

The tell

It has no cadence, and it doesn't split.

This rung is the default. You only leave it when one of the other two tells fires: the work picks up a cadence, or it splits across experts who can all work at once. The knowledge base never did either.

2

Sometimes · once it repeats

Make it a skill

Take the 5am brief. It sweeps the job tracker, pulls what's due and overdue, checks the day's calendar, and picks out three things worth actually doing. Same shape every morning — which is exactly why it's a skill and not a conversation.

You don't have to prove a routine by repeating it. Usually you can see it on the first run: this has a fixed shape and I'm going to want it again on Monday. That recognition is the trigger, not a repetition count. And you don't write the skill yourself — you say "turn what we just did into a skill" while you're still doing it the slow way, and it writes itself down.

But routines come in two kinds, and only one of them earns a skill. High frequency has a clock on it: daily, weekly, monthly. Low frequency is still a real routine — you genuinely will do it again — just months apart.

That's the one I get wrong. I built a requirements-doc generator and a project scaffolder. Both were fine, and both were real routines. They were low-frequency ones, and I treated them like high-frequency ones. I used each about twice.

Getting that wrong isn't free. A skill you rarely run atrophies: it drifts out of step with how you actually work now, so the next time you reach for it you spend longer repairing it than the job would have taken. It's harder to find, too, in a folder full of ones you never run.

The ones that stuck, by rhythm

Daily: daily-momentum-brief correios-tracking-check
Every other day: trip-cost-update
Weekly: sunday-week-review brazil-ai-events-scan
Fortnightly: biweekly-cv-draft
Monthly: monthly-job-trend-review
On demand: apply-cv-improvements

The tell

It has a cadence.

Not "is this any good?" — the generator was good, and it was a real routine. The question is how often: a clock you can name, or a trigger specific enough to say out loud. Low-frequency work is better left on rung one, where it costs you nothing to keep.

3

Rarely · and on purpose

Spin up a team

This site, and the case study you came here from, were built by an orchestrated team. Two agents coordinating; six doing the work. One scaffolding the repo, one on the design system, one writing every word of copy, one assembling pages, one on the integration, one on the final quality pass.

One lead agent splits the work, sends out the pieces that don't depend on each other, and puts the answers back together. Each subagent runs in its own context window, so they can't see each other while they work — which is what makes running them at the same time safe.

So the question was never whether the job was big, but whether the parts were independent. The architect and the design-system agent went first, together, needing nothing from each other. The copywriter couldn't start until there was a design system to write into, so it waited. That's the wave structure, and it's the honest shape: some of it parallelised, some of it queued.

The tell

It splits across experts who can all work at once.

Because each subagent has its own context window, they can't share state mid-run. If the parts have to hand work back and forth, that isn't a parallel workload — it's a sequential one carrying orchestration overhead.

Mine is a fixed roster, defined up front rather than sized by the orchestrator at run time — because asking for parallelism doesn't reliably get you parallelism. Writing the split down in advance is how you stop that being a coin toss.

Cutting across all three

Where you stay in the loop

None of the three tells you how much should run without you. That's a separate question, and it's about what happens if something goes wrong while nobody's looking.

My job search runs daily and unattended. It scans the sources, scores the roles, drops the duplicates, publishes a shortlist. The research on a particular role, and the decision to apply, stay manual. That handover point — where it stops and waits for me — is the gate.

That split has nothing to do with difficulty — the research would parallelise fine. A wrong row on a shortlist costs me a scroll. A wrong application costs me a role.

I didn't reason that line into place. Two things taught it to me. A posting API served me a role whose live page had already gone 404 — the feed was a cache, not the truth. And the dedupe kept resetting, surfacing the same roles every morning, until I worked out that its memory was being written into a sandbox that got thrown away between runs.

Both were cheap, because a human was reading the output. Neither would have been cheap in something that publishes unattended.

Automate the funnel, keep the gate. And confirm at the source of truth before anything expensive or irreversible.

The short version

Three tells

Open a session when it has no cadence and doesn't split.
Write a skill when it has a cadence — a clock, or a trigger you can name.
Spin up a team when it splits across experts who can all work at once.

And underneath all three: the gate goes wherever being wrong is expensive and nobody's watching. Pick the lightest rung that still clears it.

Scoped to one pipeline on purpose — this is what these choices looked like in one assistant, not a general account of how anyone should build one.