The question I get most from owners with small teams: "What do I get for my people? What plan should we be on?"
The honest answer starts a step earlier, because the plan is the easy part. The hard part is that when your team gets agents, your business goes from one actor changing things to many, and most small businesses have no structure for that. OpenAI's plans really appeal to enterprise, and enterprises have IT departments to absorb the chaos. You have you.
The Two Collisions Coming for Your Team
The Drive collision. Your agent goes into the shared Google Drive and organizes everything: structure, naming, the works. Your co-owner has the same idea the same week. Their agent goes in and reorganizes it according to its own logic, rewriting what your agent built. Neither of you finds out until things stop being findable. And because the two agents ran in separate accounts with no shared record, there is no log of whose agent did what, and no agent can see the other's work to fix it.
The website collision. The one from the top of this page. An agent scaffolds your custom website and it looks beautiful. A marketing team member's agent goes in to publish a single blog post and takes the site down, or quietly rewrites things it was never supposed to touch. "Revert it to what it was" only works when there is a record of what it was, and across two disconnected agent accounts, there is none.
Both stories have the same root. Every human on your team suddenly has hands that work at machine speed, and nobody agreed whose hands touch what.
The Rollout Order That Works
First: the owner-operator, alone, on a $100 plan. Before any team member gets an agent, you establish the foundation with yours: how files are named, where things live, what the agent may touch, what needs your approval. My setup tutorial covers the personal side; the point here is sequence. The structure has to exist before the team arrives, because agents inherit whatever environment they land in, including a lawless one.
Second: heavy operators, on their own $100 plans. Skip the $25 per seat Business tier for anyone who will actually operate agents; $25 of monthly usage disappears in days for a real operator, as the pricing guide lays out. Onboard operators one at a time, into the rules you already proved with your own agent.
Third, and only after the rules hold: consider pooling. Once operations are figured out, a pooled team spend, say a thousand dollars a month, can be simpler than a stack of individual plans. Know the failure mode before you choose it: tokens in a pool bill differently, and one employee's project going rogue can drain the spend for the entire team. Pools reward teams that already have discipline and punish teams acquiring it.
Write the HASOP Before You Need It
You have SOPs, standard operating procedures written for humans. Agents need the next version, and I call them HASOPs: Human-Agent Standard Operating Procedures. What is going to happen, and how are we going to work together, when some of the "we" are agents?
A starter HASOP for a five-person team fits on one page:
| Rule | What it prevents |
|---|---|
| One agent owns each shared system (Drive, website, CRM). Other agents request, never write. | The Drive collision. Two organizers with equal authority guarantee a rewrite war. |
| Every agent action on shared systems gets logged where the whole team can see it. | The "whose agent did this?" dead end. A revert is only possible when the record exists. |
| Naming and filing standards are written down where agents can read them. | Each new agent inventing its own organizational logic on arrival. |
| Customer-facing sends, publishes, and payments require a named human approval. | The website collision, and every version of it involving invoices and inboxes. |
| Contractors working under your domain follow your recording and context protocols. | Half your client conversations being invisible to the agents that need them. |
Hand the drafting to your own agent once your structure exists:
Paste into Work mode
I am onboarding two team members and their agents next week. Based on the folder structure and naming standards we have established, draft a one-page Human-Agent SOP for them: which agent owns which shared system, what their agents may read but not write, where every agent action gets logged, and what requires my approval before it happens. Then test it: spawn sub-agents playing the role of a new team member's agent and see whether the rules actually stop them from rewriting what we built.
The Ownership Rule That Saves You Later
One more, learned from watching it go wrong. If your team uses agents, you pay for the subscriptions, and every seat is tied to an email on the workspace domain you own.
I have seen people log into the agent with the wrong email and build something custom for one business inside another email's account. Retrieving that work later is very hard, and technically you do not really own it. The infrastructure your agents build, the sites, the tools, the automations, should accumulate under accounts that belong to the business, including the GitHub and Cloudflare accounts it builds with. Your business's agent layer is an asset. Hold the title.
Common Questions
What plan for a team of five? Do not buy five seats of anything yet. Start with you and your one or two heaviest operators each on your own individual $100 per month plans, because the cheap per-seat team tier comes with a usage allowance too small for anyone doing real agent work. Once your rules are proven and the team knows how to work with agents, you can consider a shared pool of credits for everyone else. Just know the trade: in a pool, one person's runaway project can use up the whole team's allowance.
Can my whole team just start at once? Technically yes, and that is exactly how the disasters in this article happen. When five people get agents the same week with no shared rules, you get two agents reorganizing the same Google Drive with different logic, and nobody able to tell whose agent changed what. Go in order: the owner sets up first and works out the rules, then the structure gets written down, then team members join one at a time under it.
What is a HASOP again? It stands for Human-Agent Standard Operating Procedure. You already know SOPs: the written playbooks that tell your people how a process runs. A HASOP is the next version, written for a team where some of the workers are AI agents. It spells out which agent is allowed to touch which system, what always requires a human sign-off, and where every agent action gets recorded so anything can be traced and undone. The full framework is here.
Do contractors need to follow this too? If they work under your business's accounts and email addresses, yes, the same rules apply, including your rules about recording client conversations. Here is why it matters: your agents can only learn from what gets captured. A contractor who keeps their calls and notes outside your systems creates a blind spot, a slice of your business your agents cannot see, cannot learn from, and cannot help with.
What if collisions already happened? Stop the bleeding first: pause adding any new agents. Then give each shared system, like the Drive or the website, exactly one agent that owns it, so no two agents can rewrite each other's work. Have that one agent rebuild the structure with a log of every change turned on. Once the foundation is stable and traceable, bring the other team members and their agents back in, one at a time.
Bottom Line
Agents multiply whatever operational discipline your team already has. Build the rules with one agent before you hand out five.