Building Kalendar, Part 3: An Org Chart of Agents

The mental model most people have for building with AI is a single assistant you ask to do a thing. That is not how Kalendar gets built. I did not prompt an assistant. I staffed a team.

Every agent in the process is a team member I hired for a specific role. It has a job description, a lane it stays in, and a set of concerns that are its and no one else’s. And the single most important thing I have learned building this way is almost embarrassingly ordinary: defining each role’s job clearly, and being just as clear about what is not its job, is most of what makes the team work. A hire with a fuzzy job description underperforms. So does an agent.

This is Part 3 of a series on building Kalendar, a real product, mostly with an AI coding agent. Part 1 was the discipline. Part 2 was the contract the work is held to. This one is about who does the work.

The team

Here is the roster. Each of these is a real, versioned role in the repository, a prompt that reads more like a job description than an instruction:

• Product Owner. Takes an intake issue and drafts a spec, the behavioral contract from Part 2. Translates intent into observable behavior. Does not design the system.
• Tech Lead. Takes a ratified epic and drafts the solution design, the architecture that frames the detailed designs, and commissions the cross-cutting decision records. Sets direction; does not do the per-spec detail.
• SDD Author. Takes one ratified spec and drafts the design for it: components, sequences, data, error handling, test strategy. Describes how; never changes the what.
• Task Generator. Takes an approved design and produces the work order, the ordered list of tasks an implementing agent executes and then throws away.
• Completeness Reviewer. Reads an artifact and judges whether it is substantively complete and faithful to the layer above it: the questions a linter cannot answer.
• PR Reviewer. Reads a finished change and judges whether it actually realizes the spec, within the design, before it merges.

Six roles, each with one job. Not one generalist doing all six. That roster is the org chart, and notice what kind: not boxes stacked in a hierarchy, but a division of labor with a clear owner for every artifact.

The assembly line

They work as a line, and every handoff is an artifact, not a conversation. An issue becomes a draft spec. A ratified spec becomes a solution design. A design becomes tasks. Tasks become code. Code becomes a reviewed pull request. Each role picks up what the last one produced, in version control, and hands off the next thing. Nothing important lives in a chat window where it scrolls away.

And every handoff stops at a gate that a human owns.

The rule that makes it a team and not a mob

Here is the rule at the center of the whole thing, and it is the reason this works at all: no agent approves its own work.

The repository states it in one line: the agent drafts and reviews; the human ratifies. Every role enforces its half of that. The Product Owner drafts a spec but cannot ratify it. The SDD Author drafts a design but cannot approve it. The Task Generator writes the work order but does not execute it. The reviewers review but cannot merge. Read enough of the prompts and you notice the same sentence in all of them, in different words: you do not approve your own work.

This is not an AI idea. It is the oldest rule in a functioning engineering organization. You do not let the person who wrote the code be the only one who reviews it, and you do not let the reviewer be the one who merges it. We separate those duties because people are fallible and incentives are real. Agents are fallible in their own way, confidently and fluently, so the separation matters more, not less. The whole value of a reviewer is that they did not write the thing and have no stake in it being right.

Why the job descriptions are so strict

The other thing you notice in the prompts is how much they say about what a role must not do. The SDD Author must not change the contract. The Task Generator must not invent design; if the design is missing a detail a task needs, it records a blocker instead of filling the gap itself. Every role is told, in some form, do not invent answers.

That strictness is the point. A bounded role is a guardrail against the failure mode from an earlier post: the confident answer that is not true. An agent asked to “build the feature” has room to quietly make a decision that was never its to make. An agent whose single job is to turn an approved design into tasks does not. It cannot hallucinate its way into an architecture decision, because architecture is not in its lane, and when it reaches the edge of its lane it is told to stop and flag rather than guess. Narrow roles do not just divide labor. They contain error.

Here is a real one. These are the non-negotiables handed to the Task Generator, the role whose whole job is to turn an approved design into a work order:

Non-negotiables:
- Derived from the SDD, never authored independently. Introduce no behavior or design beyond it.
- Every task ends with a Verify line citing a test class and AC ID(s) from the SDD.
- Blockers halt; deviations do not.
- You generate the work order; you do not execute it.

Read the last line again: you generate the work order; you do not execute it. That is separation of duties written into the job description itself, in the role’s own words. And “never authored independently, introduce no behavior beyond it” is the fenced-off lane made explicit. The role is not trusted to be disciplined. It is told, in writing, exactly where its authority ends.

Two kinds of review

Two of the six roles are reviewers, and they are deliberately not the same kind of check as the tests. The mechanical tier, the linters and the type checker and the test suite, has already run by the time a reviewer looks at anything. Those catch what a script can catch. The Completeness Reviewer and the PR Reviewer are the judgment tier: is this statement actually observable from outside the system, does this change really satisfy the acceptance criteria, does the design honor the constraints. That is the work you cannot automate, so I hired two roles to do it, and I kept the final call for myself.

What stays human

I am the hiring manager, and I am every gate. I write the job descriptions. I ratify the specs, approve the designs, and merge the code. The agents draft and review; I decide. That is deliberate, and it is also the honest cost I named in Part 1: putting a human at every gate is how you keep control, and it is exactly where the process leans too hard on one person.

I chose that on purpose. I wanted a human in the middle, someone accountable for what shipped rather than a process that ran itself. What I did not expect is what happened as I sharpened the agents’ job descriptions: the better their lanes got, the more my own role at each gate thinned into something mechanical. I was still a human in the loop, but increasingly a meat proxy, a set of hands advancing the line more than a mind weighing it. The control was real, and so was the bottleneck, and they turned out to be the same thing.

The fix is not to remove the human by going hands-off. I have no interest in prompt-and-forget, in walking away and hoping the output stays faithful to the intent. The fix is to see governance itself as a role that can be staffed. A well-defined governance agent could advance the gates and hold the work to the project’s high-level outcomes, the same way every other role holds the work to its layer. That keeps a human for the judgment that genuinely needs one, and stops spending a person on the part that was only ever a rubber stamp.

But the division of labor itself, I would not change. Defining each agent’s job, its concerns, and the line it does not cross is the highest-leverage work in the whole system. It is the same work that makes a human team good. The tools are new. Building a team you can trust is not.

Next in the series: the guardrails and the verification that let a team like this move fast without breaking what people depend on.