How to make AI work for teams

Used alone, a good AI agent feels unbeatable. It learns how you write, remembers your projects, and gets better every week. Then you bring it into a team, and something strange happens: you add more agents, the results stay flat, and you end up hiring more people, not fewer.

You are not imagining it. MIT's NANDA initiative found in its 2025 report The GenAI Divide that only about 5% of enterprise generative AI pilots were producing rapid revenue gains. The authors did not blame the models. They blamed a learning gap: generic tools that never learn or adapt to how a particular company works.

We have spent two years putting agents to work inside real teams, and rebuilt our approach five times along the way: chatbots with tools, coding agents in a terminal, agents that keep long-term memory on a personal computer, a full "AI company" of agents with job titles, and finally what we run today. This post is what survived. The short version: don't build more agents. Make them stateless, and give the memory to the team.

Why AI that works for one person breaks in a team

Every agent's memory is an island

Agents that remember what you taught them are a real breakthrough for one person on one machine. In a team, that same memory becomes the problem.

Take two people in sales, A and B. Each builds an agent to reply to customer emails. B's gets better every week. A's never catches up. Nothing B's agent learned can reach A's, because each agent's memory lives with the person who set it up. The ideal is obvious: A and B should be using the same agent. The thing keeping them apart is the agent's own memory.

More agents means more places for people to plug in

At a previous company we rolled out an eight-figure ERP. Mapping the business took more than twenty people a full year, and after launch every department had to hire people who could run the system. Outside the license, it cost about as much again. It helped the company grow, but it did not save money. Software is used by people, and people stay the bottleneck: the more complete the system, the stronger the people it needs.

Agents repeat the pattern. Every new agent is one more touchpoint, and every touchpoint needs a person to feed it, check it, and connect it to the rest of the work. This is the old lesson of The Mythical Man-Month: two people share one line of communication, ten share forty-five, fifty share 1,225. Companies talk about talent density for exactly this reason, and agents need the same idea. Call it intelligence density: fewer agents, each one stronger.

Feeling faster is not the same as shipping more

In a 2025 randomized trial by METR, 16 experienced open-source developers worked on 246 real tasks in their own repositories. With AI tools allowed, they took 19% longer. Before the study they expected a 24% speedup, and afterwards they still believed they had been 20% faster. Those were early-2025 tools, and METR has since marked the result as out of date. The lesson still holds: one person feeling faster tells you little about whether the team ships more.

1. Make agents stateless, and let the team own the memory

Agents should arrive with intelligence and nothing else. What the team knows lives in one shared place the team owns. We call it a context database, and it holds four things:

• Knowledge: documents and data.
• Rules: the playbooks and skills for how work gets done.
• Access: who can see what, and who can change what.
• History: who changed what, and when.

There is one copy of this context for the whole team, and every agent reads from it. You manage that one copy instead of chasing what each agent happens to remember.

Three things follow. Switching agents loses nothing, whether you move between Claude Code and Codex today or to whatever ships next year. Colleagues stop being islands: what B teaches, A can use the same afternoon. And when someone leaves, what they taught stays with the team.

Engineers will recognize the shape. Web architecture learned it long ago: services are stateless and state lives in the database, so you can swap or scale services at will. Team AI needs the same split: stateless agents, plus a context database.

If you are weighing where that state should live, we compared the options in Agent Memory vs Knowledge Base vs System of Record.

2. Split agents by access, not by job title

Almost everyone deploying agents copies their org chart: a sales agent, an SEO agent, a project-management agent. We built exactly that, an AI company with job titles. Then we tore it down.

Humans need org charts because no single person can do everything, so we divide the work. AI is different: it can do almost everything, and you can copy it endlessly. Splitting it along an org chart turns a hundred million geniuses into ten average workers. In practice, the more we split agents, the worse the results got and the more people we needed. Every handoff between agents diluted the work a little more.

The only split that holds up is access: what data an agent is allowed to touch. In most teams that means two agents:

• One internal agent with broad access, which everyone on the team uses.
• One external agent that serves customers and partners, with the least access it needs. Your support agent should never be able to read payroll.

Most multi-agent setups we see exist because the access differs, not because the jobs do.

3. Fewer skills, and everyone uses the same ones

Once everyone has an agent, everyone writes their own skills. Soon a team has ten different skills for the same job, and none of them pools what the team knows.

A skill is an SOP plus the knowledge and standards behind it. It earns a place of its own because it is a button: the point where a person explicitly asks AI to do a job a particular way. More buttons means more of them sit idle. And when the colleague who wrote a hundred skills leaves, nobody can maintain them.

So the deeper you go, the fewer skills you need. Move the team's knowledge back into the shared context, and keep a skill only if it passes two rules:

1. Someone uses it every week. If nobody touched it this week, it does not need to exist.
2. It needs a person's judgment. If the work is pure execution, automate it fully and stop thinking about it.

What survives the filter is usually small, and it is the core of how your team works. Those few skills need an owner and regular updates. Deciding which of ten versions to keep is a management call and a matter of taste.

4. Keep the judgment with people

Do not try to fully automate a business. Whatever a team produces ends up in front of a customer, and customers keep raising the bar. Noticing that the bar has moved is judgment, and judgment is taste. AI left on its own with no one setting standards drifts toward the generic. A business that can be fully automated is one anybody can copy.

Klarna is the well-known example. In May 2025 its CEO told Bloomberg that its AI-first customer service had been cheaper but lower quality, and that the company was hiring people again so customers could always reach a human.

You also cannot watch every step. Three habits put people in the right place:

• One entry point a day. At the step that matters, give the team a skill they actually open and respond to every day. Hand it to someone with high standards, and improve it at least once a week.
• One report a week. Automation is not finished when the work is delivered. It is finished when it produces a daily or weekly report with recommended actions, and a person approves what should happen and stops what should not. An SEO agent, for example, reports yesterday's traffic, proposes today's keyword, and flags that last month's gains came from searches that have nothing to do with your product.
• A regular "what good looks like" session. The hardest part is not wiring AI into the business. It is agreeing on what good means. Get people in a room, and bring in outside voices, because insiders cannot always say what they think.

People as operators are the bottleneck. People as judges are the moat.

What changed for teams that worked this way

Three teams we work with (we are not naming them):

• A games technology company, one month in, had planned to hire 50 to 100 engineers. It stopped that hiring and plans to move about 20% of its people into new roles.
• A second company, three months in, moved people into new roles and opened more business lines.
• An online retailer dropped a monthly SEO agency retainer. One person now owns the work, and their day is reading the agent's daily report and making the calls.

In each case, people moved from operating to judging.

Three things to do this week

1. List the agents your team has built and ask: if we swapped in Claude Code or Codex tomorrow, would the work carry on? If not, your team's knowledge is locked inside an agent instead of the team.
2. Count your skills. Move the knowledge hard-coded inside them back into shared context. Then apply the two rules, and delete or fully automate whatever fails both.
3. For every workflow, point to the moment a person signs off. If you cannot find it, it is not ready for production.

Where Busabase fits

We built Busabase to be that context database: one place where tables, docs, skills, and apps live together, and where every agent and every person on the team works from the same copy. It is open source under the MIT license. You can run it on your own machine or use Busabase Cloud for a team, and connect the agents you already use.

Each idea above has a concrete shape in it:

• Memory belongs to the team. Every agent reads and writes the same workspace.
• Split by access. API keys come in four levels: read, change request, write, and manage. An agent on a change-request key can propose changes but cannot merge its own.
• Fewer skills. Skills live in the shared workspace, so everyone runs the same version and they stay when their author leaves.
• People judge. A proposed change waits in the Inbox until someone reviews it, and daily and weekly reports land in tables and docs where they can be read and approved.

If you want the longer argument for why this is not just another AI table, start with what Busabase solves. To try it, take one project: put its latest updates and your team's playbook into a workspace, connect the agent you already use, and ask it what changed this week.

Start free on Busabase Cloud, or pick a ready-made workspace from the template center.

Don't build more software for people to operate. Don't build more agents. Give AI the context, and keep the taste for people.