The AI Stack I Would Set Up for a Five Person Team
A friend asked what I would actually set up if I joined a five person team tomorrow. Not the conference-talk answer. The real answer, in order, with the boring parts included.
Some context for why my answer looks the way it does. I spend a good part of my working life building AI systems: custom agents, integrations that connect assistants to real business tools, prompt systems, publishing pipelines that push brand-consistent content across email, social, and community platforms. I have shipped working web apps on AI-assisted platforms, with auth and data models and forms, not just demos. So when I say most of that is not what a five person team needs first, it is not skepticism talking. It is the scar tissue of having built the fancy version and watched what actually got used.
The honest pattern is this: the teams that get real value from AI got the plumbing right in the first month. The teams that flailed bought tools in week one and never built the foundation those tools sit on. So here is the thirty-day plan, week by week.
Week one: shared foundations, not accounts
Everyone already has a chat window. What teams lack is shared context. Before any automation, I build the document layer: a voice file describing how the organization sounds, a facts file with names, terminology, and the details models get wrong, and templates for the five most repeated writing tasks. These live in shared storage the whole team can reach. This is unglamorous and it is 60 percent of the value.
Let me make those three documents concrete, because "voice file" sounds fancier than it is.
The voice file is one to two pages: how formal are we, what words do we use and refuse to use, three real examples of writing that sounds like us and one example that does not, with a sentence on why. When anyone on the team asks an assistant to draft something, this file rides along with the request, and suddenly five people's drafts stop sounding like five different companies.
The facts file is the unglamorous hero. Every organization has a private encyclopedia that models cannot know: how the founder's name is spelled, what the product tiers are actually called, which client is sensitive about what, the difference between what the website says and what is currently true. Write it down once and every hallucinated detail it prevents pays for the hour it took. I have watched a single wrong program name in an AI draft cost a team a week of cleanup emails. The facts file is how that never happens twice.
The templates are simply your five most repeated writing tasks, captured as fill-in prompts: the client update, the meeting recap, the social post, the support reply, the proposal section. Not clever prompt engineering. Just the shape of the task, written down, so the sixth time someone does it they start from the team's best version instead of a blank box.
Week two: connect the tools you already pay for
Modern assistants connect to real systems through standard connectors now. Email, calendar, project board, file storage, the usual suspects. I connect them read-only first and teach the team two habits: ask the assistant to summarize before meetings, and ask it to draft before writing. Draft, not send. That distinction is policy from day one.
The read-only start matters more than it sounds. Nothing kills a team's trust in AI faster than an early mistake with consequences: a message sent to the wrong person, a calendar event mangled, a task board reorganized by surprise. So for the first stretch, the assistant can see everything and touch nothing. It summarizes the inbox, preps you for the 2:00 call, pulls the status of every open project into one view. Value shows up immediately, and the worst possible outcome is a bad summary, which costs nothing.
Draft-not-send is the second guardrail, and I state it as policy rather than preference so nobody has to relitigate it. Anything that leaves the building passes through human hands on the way out. In practice this costs each person a few seconds per message and buys the one thing a small team cannot afford to lose, which is the confidence of the people they serve. Later, once the review step has been boring for months, a team can decide to loosen it for low-stakes categories. Deciding that in month one is how teams end up apologizing.
By the end of week two, something quiet has usually happened: the team stops thinking of the assistant as a toy on the side and starts thinking of it as a colleague who read everything. That shift, not any single feature, is what week two is for.
Week three: automate two chores completely
Pick the two most hated recurring chores. Usually it is meeting notes into action items, and the weekly update nobody wants to compile. Wire those end to end, with the output landing as a draft for a human to approve. Two visible wins beat ten half-configured experiments, and the team's trust after those wins is what makes everything later possible.
Notice the word completely. A chore automated 80 percent of the way is still a chore, because someone still has to remember it, check it, and finish it. The goal is that the meeting ends and the action items appear where tasks live, assigned and dated, waiting only for a yes. The Friday update compiles itself from the project board and the week's activity, lands as a draft, and the person who used to lose ninety minutes to it now loses four.
How do you pick the right two chores? I use three filters. It happens every week without fail. It follows the same shape every time. And nobody would miss doing it. Meeting notes and the weekly update pass all three for almost every team I have met, which is why they are usually the answer. What fails the filters: anything involving judgment calls about people, anything customer-facing with emotional stakes, anything that changes shape every time. Those stay human, and that is not a limitation to apologize for. That is the design.
There is also a reason it is two chores and not five. Every automation needs a debugging period where its outputs get watched closely, and a five person team has attention for about two of those at once. Finish two, let them become invisible, then take the next one from the list. The queue is a feature.
Week four: the review rhythm
One short meeting: what did the tools get wrong this month, which template needs fixing, what chore is next in line. AI infrastructure drifts like any other system. A team that inspects it monthly keeps compounding. A team that sets and forgets is back to individual chat windows by spring.
I keep this meeting to thirty minutes with a standing agenda of three questions. What did the AI get wrong, and was it a model problem or a stale facts file? Nine times out of ten it is the facts file, which means the fix takes two minutes. Which template drifted from how we actually work now? Templates are living documents; a template nobody updates becomes a template nobody uses. And what is the next chore in the queue, now that the last two have gone boring?
The meeting has a second function nobody puts on the agenda: it keeps ownership distributed. If one enthusiast on the team quietly maintains all of this alone, you have rebuilt the single point of failure that infrastructure was supposed to remove. Rotate who runs the review. The tooling should belong to the team the way the shared drive does, unremarkably.
What I would skip
Custom-built agents, fine-tuning, and anything that requires a demo to justify. A five person team does not need impressive. It needs reliable, reviewed, and slightly dull. Dull infrastructure is what interesting work stands on.
I want to be precise here, because I build custom agents and I am not against them. They are the right tool when a workflow is high-volume, well-understood, and stable, which is exactly what a team in its first month of AI adoption does not have yet. Building an agent for a process you have not standardized is paving a road before you know where people walk. Run the manual-with-help version for a quarter, learn where the real path is, then automate the path.
Fine-tuning gets the same answer for a different reason: everything a small team wants from it, sounding like themselves and knowing their facts, is delivered by the week one documents at a thousandth of the cost and with instant updates. And the demo test is my filter for everything else. If a tool needs a staged demonstration to look valuable, it will not survive contact with a Tuesday afternoon. The stack above never demos well. It just quietly returns hours to five people every week, which is the entire point.
The math that makes this worth doing
Run the numbers on a team of five. If this stack saves each person even four hours a week, a conservative figure once meeting notes, weekly updates, drafting, and pre-meeting prep are handled, that is twenty hours weekly, or roughly half a full-time role, recovered for the cost of existing subscriptions and one month of setup attention. No new headcount, no platform migration, no consultants living in your office.
But the hours are the smaller half of the win. The larger half is what the hours get spent on. The drafting help means the writing that goes out is the team's best version more often. The summaries mean fewer meetings starting cold. The facts file means fewer small public errors, which compound in reputation the same way the savings compound in time.
Thirty days, four moves: build the shared context, connect what you already pay for, automate two chores completely, and put a monthly review on the calendar. None of it is impressive at a conference. All of it will still be working in a year, and by then, so will the more interesting things it made room for.