I Didn't Give My AI Team Its Epics. I Gave It a Definition of One.

"If you build the overview at the very end and find out it doesn't hold together, are you going to redo every admin screen? Is that how people normally work?"

I wrote that to my AI team at 10:36 on November 14. The day before, I had rewritten what the studio means by an epic, twice.

The team is two directors, executors, a reviewer and an orchestrator, coordinating on a board of markdown files. Most of the agent teams I read about this year go under the name software factory: agents carry a spec through code, tests and review to a shipped change, starting from intent and scope that people set (Factory, StrongDM). The studio is aimed somewhere else. I want a team that works out the why and the what for itself, tries things, and carries them through without me handing it either. That is why it writes its own requirements and design, and a large part of why its recent goals have gone badly. A factory would mostly be assembly for me: I've already built workflows that take a change from requirements through design and review, and what's left is fitting a team's own review, merge and task conventions. What I haven't built is a team that decides what to make. Mine has to decide where an epic ends.

One epic for everything

At 11:49 on November 13 I gave the team its next product goal, with a list of seven things it would need. At 15:02 it still hadn't shown me an epic or a goal, and it was already running experiments and changing the experiment code. "Why are you working without showing me an epic or a goal?" Three minutes later: "Stop everything. Work done without a goal isn't worth a thing."

At 19:04 I asked how many epics it expected in total. The answer was one. The whole product goal was one epic, and its first goal alone held every major system on my list.

The rules allowed it. An epic was "a medium or large outcome that cannot be done as one piece of work", which is a floor with no ceiling. The directors had considered splitting along my list and turned it down, because building one item at a time would mean building parts. With nothing saying how large an epic may be, one good reason not to split was enough. In the last post the team set its own bar too high. This time nothing set a size at all.

What I asked for

I told the Claude session I use for studio changes that this was far too big. As a unit of value, it would take dozens of goals to finish. Think in MVPs. For this product goal I'd cut it roughly into four: lay out the whole space, fill it with the unfinished assets, wire the core into it, then tune the experience. "At a granularity where you can confirm the value through the whole sequence."

Each of those stages ends with something I can go through from start to end. After the first, the whole space. After the second, the same course with everything in it. After the third, the same course, and now it runs. A goal inside a stage achieves one purpose.

Then one more request: "It would be bad if it got the MVP wrong, so add something like a unit where one user journey can be judged. It means the same as confirming value end to end, but phrase it so an LLM understands it."

Twelve epics

Claude wrote it into the rules. The first version read:

An epic is one of the parts the product goal is made of: the smallest outcome after which the human can go through one user journey in what is built and judge it, a journey being a stretch of use the user recognises from its start to its end, such as crossing from one place to another, or using one device and seeing what it changes. When a journey holds shorter journeys the human could judge on their own, each of those is an epic.

The team read it and came back with twelve epics, one for each thing a user does: repair something worn and see what changes, go from one place to another and back, buy something and install it, change a price and read the effect, save and load, and so on, ending with a full run through everything. The first two were the two examples in the definition. They were even in the wrong order, with the repair placed before the trip that gets you to the thing being repaired.

"Smallest" pushed toward the smallest unit, and the rule about shorter journeys finished the job. Claude's draft had also carried a larger example, a full cycle of use, which it dropped because it might let the whole product goal through as one epic. Only the small examples were left, and they became epics.

I asked Claude: "Do you understand what I meant by user journey? Did you look it up?"

It hadn't. It had treated each action as a journey, when I meant the course through the product goal as a whole. The second version is the one in the rules now:

An epic is one of the parts the product goal is made of: a stage after which the human can go through the product goal's user journey [...] from end to end in what is built, and judge it. Each epic leaves that journey whole from end to end and richer than the epic before: the journey's steps are deepened across epics, not built one per epic.

The examples are gone. A goal got one line: it achieves one purpose its epic needs, and another purpose is another goal.

The part I kept out of the rules

Under the second version the team proposed three epics. The first keeps the whole course and shrinks everything else into one thin vertical slice through every part, connected end to end. The second widens it. The third adds the optional parts. The first goal has a single purpose. At 20:44: "A bit big, I thought, but it feels like the best so far." I agreed to it four minutes later.

Claude preferred the team's cut to mine, saying a stage with only the space built couldn't carry the journey through to its purpose. I didn't follow that. You can go through the whole space in that stage and understand all of it. The difference is where the value shows up: the core starts running in the third stage of my cut and in the first stage of the team's.

Then, at 20:52, what I think was missing. What matters is how fast I can judge, and by that measure the team's cut is heavier. If this were going out to users, everything should be connected. It's a phase only we see, so the first stage should be whatever scope I can go through end to end soonest.

That is a branch on the phase, and I didn't put it in the rules. Either cut would be a small mistake at worst, and the if-statement would cost something in every decision from then on. I didn't want to pay for that forever.

Back to parts

The next morning I was reviewing the team's designs for the admin screens. It had drawn the one screen this goal touches and opened straight onto it, with no start screen, no menu, and the overview left for a later stage.

At 10:32: "Fine to build it later, but do you understand what I said? The menu is needed, because it's part of the UI. The screens it leads to aren't, because they come next." Four minutes later: "If you say you won't build it because it's out of scope, why did we split the epics by MVP? When can the whole experience be checked?" Then the line at the top.

Twenty minutes after that I went back to the goal itself. "You keep saying admin screen, admin screen, but that's one element of this goal. You're taking this long on it. Can you really build the rest and connect it all? Is anything else being worked on?"

The team's answer: "Putting off the screens that shape the whole, then finding at the end that they don't hold and rebuilding, is not the right way to work. We'll put the overview and the entry to purchasing into the current design."

The epics are cut by stages now. Inside a goal, "out of scope" still drifted to mean "not built", when the cut needs it to mean "built at this stage's depth". In a factory, people cut the scope before the agents start. Here the team cuts it, and for now I'm the one who notices when a goal slides back into parts.