Teamtown

The problem

AI agents are sold as colleagues, but they're used like a search box. The people who could benefit most — a farm shop, a tax office, a family planning a move — get stuck before the first step: which agents do I need, what should each of them do, and how do I write instructions for them? Agent tools assume you already know the answers.

So the question I worked on was: how does someone who has never set up an agent get from an idea to a working team?

From one prompt to a team

Teamtown starts where people already are — with a sentence. "Our farm shop wants a weekly newsletter and Instagram posts about seasonal products, but nobody has time for it." Teamtown asks a few follow-up questions that fit the plan (a trip gets different questions than a newsletter) and then proposes a complete team.

The proposal isn't a list of generic bots. Every agent gets a name, a role, a clear responsibility and ready-made working instructions; a team lead distributes the work, a reviewer checks every result before it reaches you. The proposal ends with a concrete first task, so nobody stares at an empty screen. Don't like it? Ask for another proposal, rename or remove agents — or skip the prompt and pick one of twelve ready-made teams.

Designing for trust

A team is only useful if you dare to give it real work. So nothing counts until a human approves it: plans, results, questions and tasks only a person can do land in one inbox. Every plan shows its expected cost up front, projects have a budget, and confidential projects only run on local models. Teamtown also checks every number in a result against your documents — without AI — and marks what's backed and what isn't.

The team then works in a pixel office, where you can see who is busy and who is waiting for you. That visual idea isn't mine: it was inspired by the open-source projects Pixel Agents by Pablo De Lucca and Agent Pixels. Teamtown is an independent implementation — no code or artwork was taken, all graphics are drawn in its own code. My contribution is everything before and around it: getting non-technical people to a fitting team, and making its work safe to approve.

How I worked

I was the product owner, not the programmer. I wrote the product rules into a short brief for the coding agents — plain language in the UI, every external effect behind an approval, model output never rendered as HTML — and steered every iteration: what to build next, what to cut, what felt wrong in use. Most iterations went into the onboarding: test runs showed that people needed examples to start, that private plans need different questions than work, and that an empty team without a first task leads nowhere.

What I'd do next

Learn from real users before adding anything: how often people accept the first proposal, what they change, and which of the twelve ready-made teams nobody picks. The roadmap should follow that data, not my enthusiasm.