2026 · Design and build · 55.design
A task system for people and agents alike
55 Tareas, built from the ground up for an AI-native studio: the same data and the same permissions whether a person opens the board or an agent asks. Designed and built myself: the first version was in production the day I started, and the team has run its week on it since.
- Problem
- In a four-partner studio, decisions were made in meetings and died without an owner or a date. A five-month experiment that captured action items automatically from every meeting had left 558 open items nobody trusted.
- My role
- I brought it to my partners and ran the session where we defined it, then designed and built it myself: Next.js on Postgres, 216 of 217 commits, the first version in production the same day. The four of us settled product questions in a weekly session, using it in between.
- Outcome
- In use every working day: a median of four people write to it on a weekday, 329 tasks in its first eight weeks, 78% of them closed. A client panel and an agent connector run on the same data. The client panel has been reviewed with the partners, not yet opened by a client.
Context
The studio needed one place where a task set is visible in full to the team, in part to each client, and to the agents we work with every day, all under the same permissions and without copying anything. That rules out most tools: their permissions stop at the table, so internal and client tasks cannot share a schema, and an agent gets either everything or nothing. We had also learned what happens when tasks are kept for a client in a separate workspace: it never quite gets shared. So we built our own, and accepted that we would be maintaining it.
The model is small on purpose. Project, epic, task. A task has an owner and a date, always; both are required fields, not metadata. Two levels, no subtasks. A correction or a round of feedback is a new task in the same epic, not a comment thread on the old one. Sprints belong to the project and give each epic a time frame in two phases, design and development, because the two run in parallel and end at different times.
The first commit is from August 4. On August 5 it was deployed to the whole team, pre-loaded with 164 items, curated with Claude from the old ledger’s 558, so that nobody would open an empty board.
Decisions
01
Delete the import and start empty
Two days after launch a partner opened the app to a board full of tasks he had never written, and said so. Another had stopped opening it for the same reason. The count measured how much of our meetings had been transcribed, not what anyone had committed to. We deleted all of it that day, and each person loaded their own tasks in the daily. Loading a task became an act, not a side effect, and the board became something people recognised. It is the first-run lesson I take everywhere: time to value starts with a screen people recognise as theirs, even if it holds less.
Instead of: Keeping the imported tasks and adding triage on top: bulk-close, filters by source, a “review later” column.
02
The system suggests, a person accepts
Meetings still produce tasks. What changed is where they land: an inbox of suggestions, each one accepted or ignored by a person, one at a time. Nothing writes itself. Eight weeks in, 905 suggestions have arrived and the partners have decided on 702 of them: 136 accepted, 564 dismissed. Most of what looks like a task in a transcript is not one, and that is the point. The decision is the cheap part. The trust in the board comes from having made it.
Instead of: Writing directly above a confidence threshold, or a queue that accepts on its own after a few days.
03
One table, two audiences
A client sees their project and nothing else, and not as a filtered copy of our board. Their home answers what we are on now, this sprint and the next, not the whole plan. They comment but do not edit, and our vocabulary stays ours: the word “sprint” never appears on their side. Underneath, access is enforced in the database, row by row. If the login layer failed, an outsider would see empty screens, not full ones. Every task is internal by default, so the first leak cannot happen by omission.
Instead of: A “client” role over the internal views, or a separate workspace per client kept in sync by hand.
04
The same door for agents
Collaborators connect Claude to the studio’s project context through an MCP connector with OAuth. Each request runs with that person’s token, so an agent sees exactly what the person would and nothing more. The connector logs what was asked and what it could not answer, and the misses decide what gets published next. Collaborators use it more than the partners do.
Instead of: A shared service key with an allowlist of projects.
Results
- Designed and built myself. The first version went to production the day I started; by the fourth week the team was running on it. 216 of 217 commits, 47 database migrations, about 23,500 lines of TypeScript and SQL.
- In use every working day since mid-August. A median of four people write on a weekday, six in a typical week, none on weekends.
- 329 tasks created by the people who own them, 78% closed. 179 comments. 17 projects.
- Views survived on evidence, not argument: three I proposed to switch off stayed because partners were using them.
- The limits, stated: ten people with access, no analytics inside the app, and a client panel that the partners have reviewed but no client has opened yet.
Looking back
Design the reader before the writer
The inbox reproduced the old failure one level up. One partner did not know it existed for two weeks, and suggestions without an owner had no reader at all, because the inbox is read by owner. I had built the place where the system writes before the place where a person reads. Next time the reading side comes first.
Measure inside the product
Every adoption question we argued about on Fridays could have been answered by a handful of events in the app. I read use from meeting notes and the hosting dashboard instead. Analytics were a day of work I kept postponing.
What I would keep: rough, with the users in the room
The partners started using it with the interface admittedly unfinished, on one condition: a weekly session with the board open. That is what turned complaints into a list, and I would do it the same way again. The part that is easy to skip is the meeting, and without it the rest does not work.