How to Set Up AI Tools for Your Team

When a team starts bringing AI into the work, the first question is usually: do we want one shared agent everybody uses, or a seat for each person?

I got hung up on that for a while, and I think it’s the wrong question.

The agent is the part you’ll probably swap out in six months anyway. The real thing you’re building is shared context and shared tools — what your team’s agents can access, and what everyone can reasonably be expected to know how to do.

What we run

We’re a small team, and we basically keep two piles.

The shared pile is a git repository of tools that any person’s agent can use:

• Pull the logs we care about, with the right app context
• Read production data in read-only mode to diagnose a customer issue
• Create and check tickets in our task system
• Run a first-pass code review — OWASP basics, plus whether the code follows our conventions

The personal pile is my own repository, and nobody else uses it. That’s my coding pipeline, my project-management pipeline, and how I like a task defined before I start. That’s just my process. My teammates have their own versions of that.

Looking up logs used to eat most of an hour. Now it’s a few minutes. Filing a ticket correctly used to be a 25-minute slog. Same story there.

Those are estimates, not measurements. I’ll come back to that.

And when a new person joins, a lot of the team’s know-how is already sitting there, available.

The question that decides it

Is everyone supposed to get the same answer?

If yes, use one shared agent. The sameness is the product. What’s our refund policy? How much PTO do I have? Nobody wants a personalized answer to a policy question.

If no — if the goal is shared but the work is different — then each person runs their own agent, and what you share is the tools and the knowledge base. Sharing the agent itself doesn’t help much if everybody is working on different problems.

As I sorted through my own setup, I noticed every truly shared agent I run is pointed at someone outside the team. My outreach bot has one brain and talks to hundreds of leads, and that works because it’s basically the same conversation every time (how I built that one).

Everything aimed at my actual team looks different. Shared tools, individual agents.

So a lot of the time, “I want to set up an agent for my team” turns into “I need shared context,” because teams don’t all do the same work. The one-brain model shows up when the other side isn’t your team.

What belongs in the shared pile

Shared tools are about access. Personal tools are about process.

If it connects to a system the whole company depends on — logging, tickets, production data, deploy paths — that belongs in the shared pile.

If it captures how I like to work, I keep it personal.

That split isn’t about subject matter. My personal repository is full of work stuff. The real question is whether somebody else needs to do it the same way I do.

What it actually buys you

It’s not about unlocking some new capability.

It’s that being slow stops being an option.

Spending most of an hour digging through logs isn’t just part of the job anymore. At that point, it’s a choice. Same with getting a code review back full of basic issues that could’ve been caught on the first pass.

If I had to explain the value to whoever’s paying for it, that’s how I’d frame it: a standard that depends on discipline decays. “Always check the logs before escalating” is the kind of rule people agree with and then quietly skip when the day gets busy.

A standard built into a tool holds up better, because the right path is also the easy path. You raise the floor without hiring, without writing a process document, and without nagging.

Adoption

I expected I’d have to push this pretty hard. I didn’t.

The first tools removed work nobody wanted to do in the first place — digging through logs for one line, clicking through accounts just to answer a basic question. People were glad to have them, and the bar rose after that.

If I were starting over, I’d do that on purpose. I’d make the first shared tool the one that kills the most miserable job on the team. Adoption is basically free there.

That said, we’re a small team. “Nobody complained” means a lot less when you scale that to 200 people.

What goes wrong

People build tools nobody else actually wants.

More specifically, they take their own process — how they like to plan, how they prefer to work — and push it into the shared pile. Then they wonder why nobody adopted it.

I don’t think that’s a discipline problem. It’s a category error.

Process is personal. Access is communal.

What I’d fix in my own setup

Those time-saved numbers I mentioned earlier are estimates.

We do track this kind of thing. Everyone has KPIs, and we quietly watch time spent by category because it helps more with coaching than scoring. Time researching a bug. Time researching a customer question. Both of those should come down.

I just haven’t pulled the before-and-after yet.

So if I were setting this up and trying to judge whether it worked, I wouldn’t look at how many tools got built. I’d look at time-to-answer on boring, repetitive questions.

Day one, the answers are available. They just have to ask the question.