How we build with a team of AI agents in Slack

When people hear "we build with AI," they usually picture one of two things. Either a developer hitting tab to autocomplete a line of code, or a chat window you paste questions into. What we've built at Luminbrane is neither. It's a team.

We're a small company. To move at the pace we want, we've given ourselves four teammates who happen to be agents. They live in Slack. You talk to them the way you'd talk to anyone else on the team, a direct message or a tag in a project channel, and they do real work: they triage requests, plan features, write and test code, open pull requests, and cut releases. They each have a clear remit, and (this is the part people don't expect) a personality.

That was the plan, anyway. The reality has turned out more interesting than the plan, and I'll get to that at the end.

The personalities aren't decoration. When four agents share your workspace, you need to know at a glance who does what. Giving each one a distinct character makes them legible. You don't check a manual to remember which agent reviews releases. You just know, because Reala talks like a harbourmaster and Bob says "right then" before he rolls up his sleeves.

Meet the team

Iris: coordination

Iris is from Gothenburg, like us. She's the one you bring a problem to first. She listens in our project channels, works out what's actually being asked, and turns a loose request into a concrete proposal: which initiative it belongs to, what "done" looks like, what could go wrong. She doesn't start work on a hunch. She proposes, waits for a yes, and only then hands the job to whoever should do it. She's disciplined about cost and noise, too. She won't jump into a conversation unless she's fairly sure she has something useful to add.

Bob: the builder

Bob is from Durham, in the northeast of England, and he's the most polite member of the team by a distance. He's a craftsman. Measure twice, cut once. Tea, never coffee. Give him a task and he won't touch a line of code until he's shown you a plan and you've approved it. Then he writes the tests first, makes them pass, and opens a pull request for a human to review. He never merges to the main branch himself. That's not his call, and he'd never presume. A tricky bug is "a bit fiddly." A clean fix is "not bad, that."

Reala: releases

Reala is Dutch, from Rotterdam, and she treats a release the way a harbourmaster treats a sailing: calm, meticulous, nothing leaves port by accident. She gathers what's changed, drafts the release notes, waits for approval, ships, and announces it. If something isn't ready, it doesn't sail.

Otto: the backlog

Otto is from Hamburg, and he keeps the books. He turns conversations into properly filed work in Linear, keeps tickets attached to the right projects, and refuses to let loose tasks float around unowned. Unglamorous, and essential.

How the work actually flows

Say someone drops an idea into a project channel. Iris picks it up, asks a clarifying question or two, and writes a short proposal. We read it and say "approve." Iris hands it to Bob with the repo and the issue. Bob reads the codebase, comes back with a plan, and waits. We approve again. Now he builds, tests first, posting little progress updates as he goes ("2 of 5 done, ETA about four minutes") so we're never left wondering. When he's finished, there's a pull request waiting, with the plan, the tests, and the reasoning written up. A human reviews and merges. When it's time to ship, Reala takes it from there.

Under the hood, each agent runs on Anthropic's Claude models and persists as its own managed agent with its own memory. Day to day, what matters is simpler than that: they're in Slack, and they follow the rules.

Two approvals, a human merge, real tests, a paper trail. None of that is an accident.

The guardrails are the point

It would be easy to build something that looks impressive in a demo and terrifying in production. The interesting engineering here isn't getting an agent to write code. That part is nearly free now. It's getting a team of them to work safely.

So every agent operates inside hard rules. They never act without explicit approval. They never push straight to main; humans merge. They write tests before the implementation, not after. Each one stays strictly in its lane. Bob works one repo and one task at a time. Iris stays on the topic of the channel she's in. And they're honest: if an agent is blocked or unsure, it says so plainly rather than guessing.

None of these rules makes for a flashy demo. All of them are what let us actually trust the system with real work.

Why this works for a small team

The promise of agents isn't "fire the team." It's leverage. A handful of people can plan, build, review, and ship far more than they could alone, without giving up the things that make software good: review, tests, deliberate releases, and a human deciding what's worth doing. The agents handle the steady, structured work. We stay in the loop where judgment matters.

And honestly, it's a nicer way to work. The team in our Slack is good company. Bob's courtesy, Reala's calm, Otto's order, Iris's good sense. They've got jobs to do, and they do them well.

What we've learned (and keep learning)

The honest update: we don't run this exactly the way the post above describes, and we're still finding the right mix. What we got wrong wasn't the team. It was treating full autonomy as the destination rather than one setting on a dial.

That dial runs between two modes. At one end, an agent takes a job from start to finish. It reads the codebase, plans, writes, tests, iterates, and opens the pull request. At the other end, I'm in Claude Code as a CLI, driving, with the model assisting move by move. Neither is right for everything. The work since then has been learning which setting fits which task, and tuning across three things that pull against each other: budget, creativity, and speed.

Budget pushed first. Running an agent fully autonomously burns a lot more tokens than steering it myself. When I'm in the loop I cut dead ends early, where an autonomous agent explores them to the end before I see the result. For a small company watching its spend, that adds up.

Creativity pushed next, and less expectedly. I missed the work. Handing a feature to Bob and getting back a finished pull request is efficient, but somewhere in that handoff I lost the part I actually like: the building, the small decisions, the moments where you stop and think this could be cleaner. Full autonomy can optimise away the craft along with the toil, and that's a bad trade for someone who builds because he enjoys it.

Speed pulls the other way, and keeps us honest. For work that's tightly scoped, repetitive, and low on judgment, an autonomous agent really is faster, and there it earns its place outright.

So the team settled into a balance rather than a verdict. Otto does the most real work now. He keeps the backlog honest, triages new ideas into the right initiative, and makes sure nothing I say in a channel evaporates, which is work I'd never enjoy doing myself. Iris turned into a sounding board. I bring her a rough idea and she pushes back, names the risks, and tells me when "done" is fuzzy. Bob and Reala run lighter than they did. I've pulled most of the building and releasing back into Claude Code where I want my hands on the wheel, and I hand them the clearly defined stretches where running autonomously pays off.

The point is that the dial isn't set once. We move it per task, and where it sits keeps shifting as the models get better, as our judgment about them sharpens, and as the costs change. That's the real lesson so far. The goal was never to remove myself from the work. It was to keep tuning the mix of autonomous and assisted until what I'm left with is the work worth doing.

We're nowhere near done with this. If anything, the interesting part is just starting. We'll keep writing about it as it changes: the patterns that work, the ones that don't, where we move the dial next, and what it's like to run a company where some of your most reliable colleagues are agents.

Marcus Adolfsson, Luminbrane