Your team already knows how to manage agents

There's something that keeps me up at night, and I'm pretty sure I'm not the only one.

This era feels revolutionary. Like when the internet arrived, but faster and weirder. Every week brings a new model, a new technique, a tool that didn't exist two months ago. And the feeling underneath the excitement is the same one any founder must have had in 1996, looking at an HTML page for the first time: if this is what it looks like, what happens if I miss it?

I don't lose sleep building memory systems, analyzing sync patterns between agents, and designing integrations into my team's flows because it's a fun hobby. I do it because the weight of having a once-in-a-generation opportunity in front of me is real, and I'd rather be inside experimenting than outside watching. Also, it's fun.

After several months of doing that, I landed on a conclusion I wish I'd had at the start.

Coordinating agents isn't a new problem. It's the old problem of coordinating people, with a different kind of executor.

And that's good news. Because if your company already knows how to operate as a team, you're already halfway there.

How I got there

Let me walk you through the trajectory, because I'd bet yours will look similar.

Phase 1 — A conversation. The first tasks with an agent are small and self-contained. A script. An analysis. A targeted refactor. Plan mode is enough. You explain what you want, it gives you something back, you review it. The context lives in your head; you act as the human memory. The agent is an extra pair of hands.

It works well. You get excited.

Phase 2 — Sharing the knowledge base. At some point you realize that starting every conversation from scratch is inefficient. You wish it could have access to a slice of your brain, so you don't have to explain everything every time. You're copy-pasting context you already wrote. But the bigger problem isn't the inefficiency.

It's that you become the bottleneck.

You have to go to a doctor's appointment, run an errand, pick up the kids from school — and your whole team grinds to a halt, because all the information they need to move forward is tied to you. The agent starts every session without the context you have in your head. Your human team has to ask you how a thing is done, where a doc lives, what decision was made two months ago about a particular client. You're the database everyone queries.

You've become your team's single point of failure.

You decide to give the agent access to your knowledge base — repos, docs, notes — not as loose attachments but as shared reference. The shift is qualitative, not quantitative. The agent stops being someone you explain everything to every time. It starts being someone who already knows where to look.

And you start getting your freedom — and your pace — back.

Phase 3 — Joint maintenance workflows. After a while, you notice something else. The knowledge base goes stale. There are new decisions, solved problems, accumulating context.

And here's a truth worth putting on the table: if there's one thing humans don't like — and engineers least of all — it's repetitive work. Keeping documentation current, fixing broken links, updating issue status, writing the postmortem you promised two weeks ago. We put it off, do it badly, abandon it. Not out of bad faith, but by construction.

You don't want to be the librarian. Neither does your team.

So you give the agent responsibility for maintaining it. Weekly lint. Cross-reference sync. Auto-ingestion of new sources. The agent stops being a reader and becomes co-responsible for the asset.

Human equivalent: the moment a contributor stops being "the one who executes tasks" and becomes "the one who also looks after the processes." A natural promotion.

Phase 4 — Long-running projects. And this is where it hurts.

When projects grow — weeks instead of hours, chained decisions, problems that show up Tuesday and get solved Friday — what happens with any teammate happens here too. Staying in sync and keeping a history of pending items, decisions, and problems encountered becomes more and more of a necessity.

Not because the agent is clumsy. Because the problem is structural.

The uncomfortable revelation

This is exactly what happens to companies as they grow.

A solo person doesn't need an issue tracker. Two people don't need standups. Five people don't need runbooks. Until one day they do, and the cause is always the same: coordination becomes more expensive than execution.

The software industry has spent decades solving this. Issue trackers so things don't get lost. Runbooks so operational knowledge doesn't live in a single head. Documented decisions so two months from now someone can understand why X was chosen. Standups so the team knows where each person is. Retros to learn from problems instead of repeating them.

Once I understood that agents needed exactly the same thing, I stopped looking for "the right agentic framework" and started applying what I already knew. Much faster.

The equivalence table

Human practice	How it maps to the agent
Onboarding doc	The agent's system prompt — its internal version of onboarding
Internal wiki	The agent reads it (and maintains it) like any team member
Operational runbook	A document humans and agent consult for the same procedure
Issue tracker	The agent picks up issues, works them, closes them — via the Linear/Jira/whatever MCP
Daily standup	The agent posts status in the same channel where the team posts
Code review	The agent opens PRs, humans approve — identical flow
Documented decisions	Decision records the agent reads on startup and updates on close
Sprint with bounded scope	Goal definition + a session with a limited remit
Post-incident retro	A post-mortem of what failed and how to avoid it

Notice it's not "the agent replaces the issue tracker." It's "the agent uses the same issue tracker as you." That difference matters.

The right question

When you hire someone new, you don't build them a parallel Slack, or a parallel Linear, or a parallel Notion. You give them credentials for the ones your team already uses.

That decision is obvious for humans. It has to be just as obvious for agents.

It's not about picking the new tool that comes with AI built in. Or building a parallel RAG system. Or tearing down the processes that already work to replace them with something more "intelligent." It's about amplifying them.

MCPs (Model Context Protocol) are exactly that: the way an agent gets credentials to participate in the tools your organization already has. There are MCPs for Linear, Slack, Notion, GitHub, Google Drive, Jira, and they grow every week. The agent doesn't replace the stack — it uses it.

So the practical question isn't "what tools does an agent need?". It's "which of the ones your team already uses do you connect it to?".

That shifts the conversation from buying new SaaS categories — "a memory store," "an agent platform," "an orchestration layer" — to giving the agent access to the operational stack you already have battle-tested.

The step that multiplies everything

For me, this happened concretely with infrastructure.

I started with Docker on my laptop. Moved to Docker Swarm with Dokploy when I needed reproducibility. Then migrated to Kubernetes for better Terraform support. Added the LGTM stack for observability and alerting (Loki, Grafana, Tempo, Mimir). Each step was real work — weeks each.

When I managed, safely, to let my agent query metrics, read logs, see cluster state, and operate on it — through MCPs specific to each one — something changed qualitatively.

Suddenly my capacity multiplied. It's like having an SRE living with me.

Not because the agent suddenly got smarter. Because it stopped being an assistant where I manually translated cluster state for it, and became a collaborator that saw what I saw. Just like any teammate with access to production.

That's the real multiplier effect of MCPs: they don't add new capabilities, they remove the coordination seams between you and the agent. The difference between a remote collaborator who can only ask you questions and one who has access to the wiki, monitoring, the issue tracker, and Slack.

Why we're a good team (and why that matters)

There's a detail that's easy to miss, and that I think is the crux of it.

Agents aren't humans. They're a different kind of executor, with different strengths and weaknesses.

An agent, more and more, is deterministic at repetitive processes. It keeps a knowledge base current without complaining. It closes issues on time. It detects inconsistencies by cross-referencing across twenty documents. It does the boring work well, every day, with no emotional context.

A human has better judgment about the goal, the real priorities, the paths worth taking. They read the political subtext of a decision. They know when the playbook doesn't apply. They identify that the problem the customer is describing isn't the problem they have.

That's why we make a good team. Not by being similar. By being complementary.

That reorders how you distribute the work. Deterministic, repetitive, verifiable work — to the agent. Work that requires judgment, prioritization, and reading human context — you, or your team. The line isn't always obvious, but that's the design exercise.

What really matters

If your company already knows how to operate as a team — how to onboard new people, how to document decisions, how to run retros, how not to lose pending work — that asset just became a lot more valuable. Because those same processes now hold up both your human team and your agents.

The reverse is also true and worth saying: companies with sloppy processes are going to suffer twice. Not only because their human team doesn't operate well, but because now they have to add agents that depend on the same processes that don't work.

If you find yourself thinking "first I need to document how we work better before bringing in agents" — that's not procrastination. That's the right investment. Your team's coordination practice is the foundation everything else is built on.

Closing

The good news: most of the problems you'll find when bringing agents into your operation are already solved. Not by the AI industry — by the software industry, decades ago.

Onboarding. Knowledge bases. Runbooks. Issue trackers. Standups. Retros. Documented decisions. They're all tools your team probably already uses, and they all apply the same way when one of the team members isn't human.

The revolution isn't only in the models. It's that your operational discipline now pays off twice over.