How to build an AI team, not another assistant

A practical guide: define the deliverable, cast the roles, write the quality bar, set the limits. Most teams that underperform got the second and third of these wrong.

Assembling a team is not hard, but it is easy to do in a way that produces mediocre output and then conclude the approach does not work. Four decisions account for most of the difference.

1. Define the deliverable, not the activity

The most common mistake is briefing an activity: "research our competitors", "write some content", "look at our ad spend". Each of those can be satisfied by almost anything, which means you get almost anything.

Brief the artefact instead. "A competitor teardown covering positioning, pricing and feature gaps for our four closest competitors, with sources." Now there is something to check completion against, and the review step has a definition to work with.

2. Cast for the work, not the org chart

Pick roles by what the deliverable requires, not by mirroring how your company is structured. A listing refresh needs keyword research, copy and compliance review — three roles — regardless of whether your company has three departments.

• Under-casting is the common failure: one content role asked to do research, writing and compliance produces adequate work in all three and good work in none.
• Over-casting is less common but real: roles with nothing to contribute add coordination cost and review noise.
• A useful check — for each role, name the specific artefact it owns. If you cannot, it does not belong on this team.

3. Write the quality bar down

This is the highest-leverage sentence in any brief, and the one most often skipped. Without it, output is graded against generic plausibility, which is exactly how you get competent work that does not sound like you.

The bar is usually two or three specifics: the voice, the thing you compete on, and the thing you will not say. "Clinical rather than playful; we compete on ingredient transparency, not price; never imply clinical results we have not published." Thirty words, and it changes every output.

If you would send a draft back to a new hire for a reason, that reason belongs in the brief. Otherwise you will send it back every time.

4. Set limits before the first run

Budget caps, per-role quotas and approval gates are easier to set at the start than after something has gone sideways. Set them tighter than you think you need. A task that stops at its cap is a small annoyance; one that does not is a large one.

Approval gates specifically: leave them on for anything outbound until you have watched the team work for a while. Trust calibrated on observed behaviour is worth more than trust assumed at setup.

A first task worth running

Pick something real, bounded, and that you already know the answer to. Real, because sample tasks produce sample-quality output. Bounded, so the first run finishes fast enough to learn from. Already known, because the fastest way to calibrate is to compare against work you can judge instantly.

Then read the output critically and put whatever was missing into the brief. Two iterations of that is usually the difference between adequate and genuinely useful.