A slice gave me a smaller thing to hold on to.

Harshal Dhir, on LinkedIn

Who this book is for

You can think, and you can ship. You span design, product, and engineering, or most of them, and AI is the main tool in your hands. Maybe you work alone. Maybe you work with two to four others who each cover several jobs.

I described this person in The Philosopher Builder. Breadth, reasoning, curiosity, and action live in one body. They can make something real by the end of the week. Often that person is a business owner who became the builder because nobody else was going to.

What you no longer have is the person down the hall who used to ask, "Is this actually done?" This book gives you that question in a form you and your agents can run.

What this book is

A field guide. It picks up where my essay Own the Slice stopped. You do not need to have read the essay first, though it helps.

The essay gave you the unit: a slice, one outcome a person can use, with one owner and a done test that proves it in the real world. This book gives you the discipline that holds a builder and an agent to that unit, day after day. You will plan in slices, delegate with a check the worker cannot fake, ship one slice at a time, keep a record the next session can trust, and learn where the method stops working.

How to read it

Part One, The Unit, takes about twenty minutes. Read it first.

Read Part Two, The Discipline, before you next hand real work to an agent. It is the part you will come back to. It ends with a case study, Jane, Slice by Slice: an open-source app I build with my son Landon, run in slices where anyone can read them.

Part Three, The Builder, is for the harder cases: work that is not code, work that will not slice, and work that runs in a loop.

The tools inside the chapters (a calculator, drills, a plan linter, a quiz) save what you type in your browser only. Nothing you enter leaves your machine. Your Work, at the end of the book, gathers everything you filled in and lets you download it as one file.

A note on the skill

Every rule in this book also exists as an open-source agent skill, so your agents can follow the same discipline you do. Harshal Dhir wrote the first one, slice-discipline, after he took the essay to an enterprise deadline. My version, working-in-slices, builds on his. The Kit, at the back of the book, says what each one adds and where to get it.

Harshal Dhir, the AI engineer behind the open-source slice-discipline skill, had a project that looked built to slip. He described it in a LinkedIn post this October.

An enterprise client project. Huge scope. An aggressive, tight deadline. And all of it in this era of AI expectations, where everyone assumes that because an agent can write code fast, everything should be finished fast.

Harshal Dhir, on LinkedIn

The system itself was "a complicated enterprise multi-agent substrate, the kind of project where you can see ten ways it could spin out of control before you have written a line."

He knew the agents could write the code. The open question was whether anything would be finished by the date.

The two clocks

Then he read my essay Own the Slice. The point he carried away is the one the whole essay rests on:

AI compresses the time it takes to do things. It does not necessarily compress the time it takes to get things done. Those are two different clocks, and most teams only watch the first one.

Kent Langley, Own the Slice

Harshal put it in his own words, and his version is blunt about cost: "Writing code is fast now. Verifying it, integrating it, and deciding if it was worth building still costs what it always cost." On a project that size, he wrote, "that is exactly where I was going to lose my time, and my money."

The first clock measures doing: typing the code, drafting the page, producing the first version of anything. The second measures done: checking that it works, fitting it into everything around it, and deciding it was worth building at all.

Agents moved the first clock a long way. The second one has barely moved.

The arithmetic of a faster doing step

Here is why that matters more than it sounds. Say doing is 30% of a 40-hour piece of work, and an agent makes the doing ten times faster. AI helps with the rest too, so say checking, fitting, and deciding get three times faster. The 12 hours of doing shrink to about 1.2. The other 28 hours shrink to about 9.3. The work now takes about 10.5 hours, so it got about 3.8 times faster.

Doing got 10x faster. The slice got 3.8x faster.

Look at where the hours went. The rest now holds about 89% of them. Push harder on doing and give the agent infinite speed. The 9.3 hours are still there, and the best you can reach is about 4.3 times faster. Engineers know this as Amdahl's law: the part you sped up least sets the limit. These numbers are illustrative, and your split will differ.

Set the three numbers to your own last project. Then move each slider and watch the result. Past a certain point, more speed on doing barely changes the total. The third slider, speed on everything else, moves it the most.

The rest is where the remaining gains are. That third slider is what this book is about.

Why the builder feels it first

In a company of specialists, the second clock had guards. A designer handed off to an engineer, who handed off to someone in QA, who handed back a bug. Every handoff was slow. Every handoff was also a checkpoint where somebody asked, "Is this done?"

The builder this book is for spans those roles. You design it, build it, and ship it, often alone, with AI as the main tool. Spanning removes the waits. It also removes the person who used to ask the question.

An agent will happily report that it finished. Whether the work is done is a separate question, and on a small team there is often nobody else in the room to ask it.

Then there is the pressure Harshal named. Clients assume that fast code means a fast finish. So do builders, on a good day with a fast model. That belief turns a fast first draft into a promised ship date.

Faster chaos

I wrote the operating version of this in Founder Scaled, before agents were writing much of anything. It was about software rollouts at growing companies.

Good process plus technology equals leverage. Bad process plus technology equals faster chaos. No process plus technology equals expensive confusion.

Kent Langley, Founder Scaled

An agent is technology with a very fast first clock. Hand it a pile of loose tasks and you get the pile back, sooner, with more in it. Hand it ten tasks with no outcome attached and you get ten finished tasks, and still no way to tell whether a customer can do anything new.

The process that holds up at that speed is small. One outcome. One owner. One test that says when it is finished. The rest of this book is that process, and the habits that keep it running when nobody is watching.

What Harshal did

Harshal kept the agents at full speed and changed the unit they worked on. He wrote down what that looked like:

One outcome at a time, named in plain language, something a person can actually do when it ships. So I stopped trying to carry the whole scope in my head. One slice at a time. Ship it, run the test, stop.

Harshal Dhir, on LinkedIn

Then he turned the idea into a skill for the agents he works with and open-sourced it. Every rule in it holds the agents to the same loop he held himself to.

He says slices saved him "thousands of dollars on this project." That is his estimate, and the post does not show the math. The comparison he draws is with the fragmented version of the same work, full of reloads, scope creep, and rework. About that version he adds: "And on this deadline, it is also the version that would not have shipped."

Make the doing free and about 9.3 illustrative hours are still on the clock, every one of them spent on done.

In The Philosopher Builder I argued that a business owner's job is to compose the smallest set of builders whose overlaps cover the whole business. Then I added a line I meant literally.

Sometimes, for a good while, that set is you.

Kent Langley, The Philosopher Builder

If the set is you, picture where your project lives on a weeknight. It lives in your head. Every open thread, every half-built idea, every promise to a client, and the three things the model suggested this afternoon. There is no board on the wall, and nobody walks past to read it. You are the board.

This chapter is about getting the board out of your head.

The unit, in three sentences

Own the Slice defines the slice in full, so here is the short version. A slice cuts through every layer the work touches and delivers one thing a customer can use, or a stakeholder can watch in a demo. It keeps the six INVEST qualities of a good user story, from Bill Wake's 2003 checklist, and adds two more: one named owner, and a done test that proves the outcome in the real world.

When the set of builders is you

On a team, the slice spreads the load across people. When you work alone, it shrinks the load to one thing. You hold one outcome until it ships. Everything else gets written down somewhere it can wait.

Agents make this more urgent. A model keeps producing as long as you keep asking, and each request feels small. By Friday you can have twelve partly finished things and no shipped outcome, and the only map of all twelve is your memory. Every one of them costs a reload when you come back to it, and the cost grows faster than the list.

One slice in flight caps what you have to remember at one.

A team of three

Slices are how one person survives carrying everything. When I get to choose, though, I pick three people. So far, on every kind of project I have run, three has been the size that works best for me.

AI adds so much capacity to a small team that there is very little three people cannot build. Three is enough to cover the jobs a real project keeps asking for. Product management, project management, design, engineering, DevOps, client support, troubleshooting, and the escalation path when something goes wrong. Each person carries several of those jobs, and the three of them pass work back and forth as the week changes shape. You can also run several teams of three side by side, each on a different function.

Three gives you one more thing I have come to value. Sometimes a person on the team has to deliver a hard message. With three, one person can have that conversation while another stays focused on delivery, and the work keeps moving.

With one or two people, every role lands on someone who is already busy. That load can be hard to carry, and it can wear you down. In consulting work it can also put friction into the client relationship. The person fixing tonight's outage is the same person who has to explain it, and the same person who has to agree on next month's scope.

The unit stays the same at three. Each slice still has one name on it and a done test that proves it, and each builder holds one at a time. Three builders running slice discipline is the best setup I have found. If the set is you for now, the slice keeps the work moving until there are three.

The new geography

I have said for a while that the new geography is time zones. AI makes that line matter more. When work moves faster, a question that sits unanswered overnight holds up more of it. My rule of thumb is that losing 12 hours to time lag is like losing a full work week.

The hardest case I have managed is California to India, a 12.5-hour offset. It works only when one side shifts its hours so the two keep one or two hours of overlap each day. Without that, time itself becomes the problem.

Follow the sun is the exception. Handing work around the globe from shift to shift can work. It takes more people and more management, plus cover for holidays and time off on every shift. Most teams cannot staff that well.

What I suggest these days is simpler. Hire within one or two hours of the time zone where the core human-to-human conversation happens. Build small, talented teams, three where you can, and give each one vertical slices to own. The teams sit close together in time, and their slices run in parallel without waiting on the other side of the world. I wrote about this on X.

There are always exceptions, and you can find those too.

A name you can check from across the room

Naming is the first discipline, and it is harder than it looks.

A good slice name describes a person doing something: "Customers can pay with a card they have used before." Anyone can check that from across the room. Ask a customer. Watch one try. Nobody has to open the code.

Now take "Add payment_methods table." Only someone reading the code can say whether it is done. Even then, they cannot tell you whether any customer can pay. The table can exist while checkout still fails.

The name steers the model, too. An agent handed "add a table" builds a table. An agent handed "customers can pay with a card they have used before" has to reason about the checkout page, the charge, and the card that expired last month. Plain words carry the outcome into the prompt.

Practice it on work you already know. The drill below gives you seven queue items, from a product backlog to a garage, and asks you to rewrite each one as a slice. It flags implementation words as you type and checks for the "who can do what" shape.

Notice which of your answers you could check without opening a file or a spreadsheet. Those are slices. The rest are still tasks with better grammar.

Split by outcome

When a slice is too big for one person to finish in a week, split it. The cut runs along outcomes. "Customers can see the cards they saved" and "customers can pay with a saved card" are two slices, and each one ships something a person can use.

Frontend and backend are layers. Split along layers and you get two halves that prove nothing until both land.

Here is a quick test for any split. Can you write a done test for each piece on its own? If one piece needs the other before anyone can check it, you cut along a layer. Cut again.

The out list

Every slice carries a list of what it leaves out. The essay calls it the most important thing you will write. For a builder working alone, it is also the cheapest protection you have.

It guards against two sources of extra scope. The first is you. At ten at night, with the code working, the next idea always looks small: a default card, a nicer error page, one more way to pay. The second is the model, which will suggest those same things and build them the moment you say yes.

The out list turns each of those into a decision you already made. When the idea shows up, check the list. If it is there, it waits. If it is new and it matters, add it to the list and finish the slice in front of you.

Write the list before you start, while you are calm. Keep it next to the slice name, in the file the agent reads on every turn.

The list does a quiet second job. Read it after the slice ships and you are looking at the candidates for the next one.

When the name says who can do what, anyone you show it to can tell you whether it shipped, and that includes you at the end of a long week.

On September 15, 2026, Omarchy, an Arch-based Linux distribution, shipped version 4.0.4 with its own kernel, linux-omarchy, as the new default. Every task check passed. The package installed. The boot order put the new kernel first. The migration was marked complete.

Machines kept booting the old kernel anyway, along two separate paths. One user ran the wrong kernel for four days, and the only symptom was what uname -r printed. Another user wrote a plugin that finds the intended kernel on every boot and corrects the default. In Own the Slice I called that plugin the missing slice test, built by the community after the fact. The essay walks through both boot paths and the public issues. The lesson fits in three sentences.

Merged, packaged, and marked complete describe the queue. The machine state is the product. The kernel slice was done only when the machine said so.

Kent Langley, Own the Slice

Why done got expensive

In The Expert Costume I put the economics plainly.

Generation got cheap. Verification did not. That asymmetry is the whole story.

Kent Langley, The Expert Costume

An agent can produce a kernel package, a migration script, and release notes in an afternoon. It cannot reboot your users' machines. The check that would have caught Omarchy's problem is one command after a reboot, run once per boot path. Someone has to decide to run it, and to run it against the machine instead of the package.

What a done test does

A done test does three things.

It proves the outcome in the world. "Package installed" describes a step. "After a reboot on each boot path, uname -r shows the new kernel" describes the machine.

Someone else can run it. A teammate, a reviewer, or another agent can run it without asking you what you meant. If only the author can run it, it is a promise.

The worker cannot fake it. A test suite that exercises the changed behavior. A build that exits 0. A live check against the running system. A payment that clears. The worker's own report ("done, tests should pass") is the cheapest thing in the building to produce, and the easiest to get wrong.

Activity checks are tempting because they are all true. Every one of Omarchy's task checks was true. Sort the ten checks below into two piles: the ones that prove the outcome, and the ones that prove somebody was busy.

Look at the activity pile when you finish. Every item in it could be true on a machine still running the old kernel, or for a customer who still cannot pay.

Done tests for fuzzy work

Code makes this easy. There is a command, and it returns a number. Most of what an owner does all week has no command: an essay, a strategy memo, a sales call, a hire. The method still holds. It takes four habits.

Fix the bar before the work. In Progressive Agency I wrote this about agent loops. It applies to every kind of work.

So write the success criteria before you start, and make at least one of them impossible to argue with. The test passes. The file compiles. The number reconciles. Every item on the checklist is there.

Kent Langley, Progressive Agency

A bar written after the draft bends to fit the draft. Written first, it tells you what you are making.

Make one check impossible to argue with. Fuzzy work usually has one hard edge if you look for it. A date. A count. A yes from a named person. Find it and write it down.

Have someone other than the author run it. The author reads what they meant to write. A fresh reader reads what is on the page.

Prefer a decision someone acts on to a document someone reads. A memo earns its done when its owner approves, cuts, or funds something because of it. Until then it is a draft with readers.

Here is what that looks like in practice. These are examples to adapt.

The shape repeats. A named person, an event you can observe, and a place where the evidence lives so the next person can look.

When you cannot verify

Sometimes the done test cannot run. The staging database is unreachable. The check needs a customer who is asleep. The repo has no tests at all. The honest end state is a sentence that says so.

That sentence tells the reader what is proven and what is still a claim. It is an acceptable way to end a turn, and it keeps the claim and the proof apart, where the next person can see both. Add the test you would run, so the gap has an owner.

Every Omarchy task check passed, and only uname -r after a reboot could show which kernel was running.

In Founder Scaled I listed the ways technology projects fail at growing companies. Two of those patterns keep coming back to me now that agents write plans.

Pattern 4 was no clear ownership.

The project had a steering committee. It had executive sponsorship. It had stakeholders from every department. What it did not have was one person who woke up every morning thinking about adoption, one person whose success was measured by whether the system actually worked.

Kent Langley, Founder Scaled

Pattern 5 was success metrics never defined. When I asked how a company knew its rollout had failed, the answer was usually a feeling. People stopped using it. The team went back to the old way. As I wrote then, "Without defined metrics from day one, there is no way to catch problems early enough to fix them."

Those were rollouts with budgets and committees. The same two failures fit inside a one-person plan with an agent. Ask an agent for a plan and it will propose eight tidy steps. Each step is a task. None names who answers for the result, and none says how anyone will know it worked. You approve it because it looks thorough.

A plan is a list of slices

The fix is a format. When a plan comes up for approval, from you or from an agent, every step becomes a slice with four required fields. Here is the first slice from the skill's worked example, as it looks before any work starts:

### Slice 1: Customers can see the cards they saved
- Ships: A signed-in customer sees their saved cards (brand and last four digits) on the checkout page.
- Touches: payments service, checkout page
- Done test: pytest tests/test_saved_cards_list.py
- Owner: self
- Out for now: Paying with a saved card, removing a card
- Status: planned

Ships says what a person can do after this slice that they could not do before. Touches names the layers or files it changes, so you know what to review. Done test is the command or check that proves it. Owner says who builds it.

Pattern 5 lives or dies on the Done test line. Pattern 4 lives or dies on the Owner line.

The last sentence is the useful one. When an agent cannot write a done test for a slice, it has not understood the slice yet. Send it back to read more, before anyone writes code.

self or delegate

The Owner field takes one of two values.

self means the slice gets built in this session, by you or by the agent you are working with right now.

delegate(task=..., verify=...) means a subagent takes it. The task says what it builds. The verify part is the slice's done test. The subagent runs it before reporting done, and you run it again before you accept the work. Chapter 5, Delegate With a Verify Line, covers that handoff in full.

Delegate when the slice is well bounded, its done test is a single command, and you would rather re-run that command than read the diff. Keep it self when the slice needs judgment you have not written down yet.

Either way, the person who approves the plan answers for what ships. The Owner field records who builds. Your name sits on the plan.

An out list for every slice

The out list from Chapter 2, The Slice, goes into the plan once per slice, on the Out for now line.

In a plan it picks up a second job: it shows the order of the work. In the example above, Slice 1 leaves out paying with a saved card and removing one. Those become Slices 2 and 3. Read the out lists top to bottom and you can see the plan's sequence. Anything that never becomes a slice is a deferral you chose on purpose.

If a slice truly leaves nothing out, write nothing. A missing line draws a warning from the linter. An honest nothing passes.

Where the plan lives

A plan that exists only in a chat is lost when the session ends. Save it as plans/<slug>.md in the project, with a lowercase, hyphenated slug, and work from the file. Each slice also gets a short Execute brief under it, which Chapter 8, Execute From the Brief, explains.

When the last slice's done test passes, move the file to plans/archive/. A finished plan left in plans/ reads as open work to the next session. Chapter 7, The Plan Is the Memory, covers what to write into the file as each slice ships.

Check the plan before you approve it

The skill ships with a small linter. Run it from the project root, pointing at the script inside the installed skill folder:

python3 <skill folder>/scripts/check_plan.py plans/<slug>.md

It reads the plan and reports, one finding per line. A missing field is an error. A slice name with a table, a column, an endpoint, or a camelCase word in it draws a warning. A slice marked done with no proof is an error. When every slice is done, it prints the command that archives the plan.

The linter below runs the same rules in your browser. Load the worked example first, then the broken plan, then paste one of your own.

Read the findings in two groups. Errors are missing pieces of the contract: a field left blank, a slice with no brief. Warnings are slice names written in the language of the build.

Four short lines per slice catch both failures that sank those rollouts: nobody owned the result, and nobody said what success was.

The subagent comes back after twenty minutes. Its report is tidy. "Implemented sign-in with a one-time code. Added code generation, two routes, and tests. All tests passing."

You did not watch it work. You do not know which files it opened, what it tried first, or what it gave up on. The diff runs across three files you have not read. (The details are illustrative. You will know the shape.)

Now you have two bad options. You can read everything it touched, which costs close to what doing the work yourself would have cost. Or you can believe the report, which costs nothing until the day it costs a lot.

There is a third option, and it takes a few seconds.

One command between you and the worker

A subagent works in a bounded context. That is the point of it: it reads what it needs, tries things, throws most of them away, and hands you the result. You never see the trail.

So you need an interface that does not depend on seeing the trail. The done test is that interface, and it is the only cheap one you have. It is one command, or one check, that proves the slice works. You write it before the work starts. You put it on the last line of the brief, labeled Verify:. The worker runs it before it reports. Then you run it again before you accept.

Two runs. That is the whole mechanism.

The first run keeps the worker honest with itself. A worker told to run the check before reporting will often find its own mistake and fix it, and you never hear about it. The second run is yours. It turns the report into something you have seen with your own eyes.

The skill spells this out in more detail (see The Kit at the back). The short version fits on a sticky note: no Verify line, no delegation.

The same rule, written for a company

I wrote a version of this before I had the word slice. In Founder Scaled, the chapter on building an AI team argues that agents should be treated like team members with jobs, and it says what a job needs:

Each agent has a defined scope. Clear inputs and outputs. Established handoffs with human team members. This structure creates accountability and prevents the chaos that emerges when AI use is informal and ungoverned.

Kent Langley, Founder Scaled

Read that with a subagent in mind. The defined scope is the slice and its out list. The clear output is what the slice ships. The established handoff is the moment the worker reports and you check. The Verify line is that handoff turned into a command, so the check does not depend on anyone's memory or mood.

There is a second line I lean on here, from Progressive Agency:

You cannot delegate a workflow you have not defined.

Kent Langley, Progressive Agency

The Verify line is the cheapest way I know to find out whether you have defined it. Sit down to write the command. If nothing comes, you are not ready to hand the slice to anyone. You have a topic. Go back and narrow it until a check exists (see Chapter 3, The Done Test, and Chapter 4, Plan in Slices).

That failure is useful. It costs you five minutes at the desk. The same gap found after a subagent has spent an hour building costs the hour, plus the time to unwind what it built.

What goes in a brief

The skill ships a delegation brief you can copy. It has eight parts, in this order:

1. The slice, named for a person doing something.
2. What it ships: what the user can do afterward that they could not do before.
3. The files the worker may touch.
4. The steps, short and imperative, pointing at the design instead of restating it.
5. What is out of scope, including anything nearby the worker might be tempted to fix.
6. Three constraints that never change: do not redesign, touch only the listed files, and stop and report if the brief is wrong.
7. What to return: one line per changed file, anything left out or discovered, and the exact output of the Verify command.
8. The sentence that tells the worker to run the check itself and never report done on a failing one, then the Verify: line, last.

Two of those parts do more work than they look like they do.

The return section asks for the exact output of the check. That gives you something to compare. When your re-run prints the same thing the report printed, you are done. When it prints something else, you have learned something important in seconds.

The out-of-scope list protects the worker from its own helpfulness. A model that notices a messy function next door will clean it up unless you tell it not to. Every unasked change is a change you now have to review.

Try building one for a real slice on your list.

Notice where the Verify line lands: last, after everything else, with the instruction to run it sitting right above it. Leave the field empty and the builder warns you. That warning is this chapter in one line.

Writing a check the worker cannot talk its way past

A weak Verify line lets a worker report success on its own say-so. "Tests pass" is weak. Which tests? Run how? pytest tests/test_auth.py passes is strong, because anyone can type it and get the same answer.

For a deploy, the check is the live service, asked from outside after the deploy finishes: curl -fsS https://app.example.com/health returns 200. A green build tells you the code compiled. The live check tells you customers can reach it.

The same rule works when the worker is a person. A contractor writing a setup guide gets a Verify line too: someone who has never seen the project follows the page on a clean machine, and the app starts. That check belongs to a fresh reader, someone who did not write the page.

One more habit. When the worker writes the tests as well as the code, read the test file. It is usually short, and it is the one file that tells you what "passing" means. A test that checks the wrong thing will pass every time.

When your re-run disagrees

Sooner or later the report will say passed and your run will say failed.

Do not quietly fix it yourself. Send the slice back with the output you got. Often the difference is an environment the worker had and you lack, a fixture it created and never cleaned up, or a service it could reach and you cannot. Each of those is something you needed to know before the slice shipped.

Then write it down. One line in the plan's Notes says what failed and why. The next brief gets a better Verify line because of it (see Chapter 7, The Plan Is the Memory).

One command, re-run by you, is the cheapest proof you will ever get that delegated work is finished.

Slice 1 just passed. The agent ran the tests, wrote the result into the plan, and reported. It is late afternoon and you feel good.

Then it adds a line. "Slices 2 and 3 are straightforward from here. Want me to keep going?"

It is right that they look easy. The files are already open. The agent is fast, it knows the code, and the next step is obvious. Stopping feels like a waste of momentum. So you type "yes, go ahead," and you go make dinner.

In the morning there are three slices in one long turn. The tests pass. Somewhere in the middle, while building Slice 3, the agent changed a helper that Slice 2 depended on, and adjusted Slice 2 to match. You cannot tell anymore which change belongs to which slice, or whether anyone decided that the helper should change at all. (An illustrative scene. Most builders who work with agents have lived some version of it.)

Why unwatched steps add up

I wrote about this in Progressive Agency, and the arithmetic still surprises people. Errors compound across steps that nobody checks. The post has a small table:

Ninety-five percent per step sounds great. Run it across twenty unwatched steps and you get a correct result about a third of the time. Push each step to ninety-nine percent and the same run lands at eighty-two.

The post also gives the caveat, and it matters. That table is the pessimistic case. It assumes errors are independent and that nothing catches them along the way.

That caveat is the opening this chapter walks through. A done test at the end of every slice is a catch. Each time one runs and passes, the count of unwatched steps starts over. Roll three slices into one turn and you remove two of those catches, right when the agent is moving fastest.

State it, run it, record it

The skill's rule for any turn that changes something is short. The turn is not done until its done test has run and passed.

In practice that is three moves.

State the test up front. Before the agent writes a line, it says what will prove the slice. In a plan, the test already sits on the slice's Done test: line. In a turn with no plan, it goes in the first lines of the reply: "Done test: pytest tests/test_checkout.py passes." You can read that sentence and object before any work happens, which is the cheapest time to object.

Run it. In the turn, before reporting. A test that "should pass" has not passed.

Record it. The command and what it printed go into the slice's Proved by: line in the plan. That one line is how the next session knows the slice is finished (more on this in Chapter 7, The Plan Is the Memory).

When the test cannot run, the agent says so in plain words and stops short of calling the work done. Chapter 3, The Done Test, covers that honest end state. It belongs here too, because a turn that ends with "verification wasn't possible because the staging database is down" is a turn you can trust.

The stop after each slice

Here is the rule that would have saved the morning in the opening scene.

The stop gives you a moment to look. One slice, one diff, one test result, one line in the plan. You can review that in a few minutes. Three slices tangled together take an hour, and you will skim most of it.

The gate also keeps a person on the plan. After each slice you decide whether the next one still makes sense. Sometimes Slice 1 teaches you that Slice 2 was the wrong idea. If the agent has already built it, you will be tempted to keep it, because it exists and the tests pass.

For the person doing the work, the stop is also a finish line. The essay made the case that shipping should mean stopping (Own the Slice, "Conditions for slices to help people"). Pacing is the same idea, applied to an agent's turn.

Where the rule does not apply

The rule covers implementation turns only. If you ask an agent which payment providers support saved cards, it should answer the question. It should not go hunting for a test suite to run. Research, conversation, and read-only turns are exempt.

That scope keeps the rule from turning into ritual. A rule that fires on every question gets ignored on the turns that matter.

Test yourself on seven turns. Some pass, some do not, and one is outside the rule entirely.

Notice how many of the "Not done" turns had passing tests or a confident report. The test passing is half of it. Running it in the turn, on one slice, and having someone outside the worker re-run it is the rest.

The number to grow

Near its end, Progressive Agency names one number to watch:

Then track the one number that matters: steps per touch.

Kent Langley, Progressive Agency

How many actions does the agent take between your interventions? When you drive an assistant turn by turn, the answer is one. The post puts a working workflow agent, one that runs unattended to a bar, somewhere between five and twenty.

One slice per turn puts your gate at the slice boundary. Inside the slice, the agent can take as many steps as the work needs. What grows over time is how much one slice can hold, and how much of its checking a machine can do.

Grow it slowly, and grow it on evidence. The evidence is your re-runs. When the done tests on a kind of slice keep passing for you, week after week, you can make those slices bigger, or hand a whole slice to a loop that runs until its test passes (see Chapter 13, Slices and Loops). When a re-run fails, shrink the slice again.

Trust here is a record. It is the list of Proved by: lines that held up when you checked.

At 95 percent per step, twenty unwatched steps come out right about a third of the time, and a stop after each slice keeps that count short.

Monday morning. You open a fresh session on the saved-cards project and ask the agent where things stand.

It does what a careful newcomer does. It runs git log, reads a week of commit messages, opens a few files, and builds a theory. "Slices 1 and 2 are complete. Customers can see saved cards and pay with them. Ready to start Slice 3."

The theory is wrong. There is a commit called "pay with saved card," and the charge call is written. But the test for a declined card was still failing when you stopped on Friday. You knew that, and nothing in the commit log said so.

So the agent starts Slice 3 on top of a half-finished Slice 2, and you spend the morning untangling it. (The project comes from the worked plan in the skill. The Monday is illustrative.)

On Friday, the one fact that mattered lived only in your head.

One small edit after every slice

The fix is a habit, and it is small. When a slice's done test passes, you, or the agent, edit that slice's entry in the plan file before doing anything else.

In the plan, a finished slice ends up with three short lines:

- Status: done 2026-10-19
- Proved by: `pytest tests/test_saved_cards_list.py` -> 6 passed
- Notes: Shipped as planned. The five-card limit is enforced in Slice 2.

And a slice that is still open says so, in words a stranger can read:

- Status: in progress
- Notes: Charge call is written. The test for a declined card is still failing.

That second block is the one that would have saved Monday. It took one sentence to write.

Keep the edit small. A record that takes twenty minutes to write gets skipped on the busy days, which are the days you most need it. Status, proof, notes. Then move on.

Where the plan lives

The plan is a file in the project, at plans/<slug>.md, with a short lowercase slug like plans/saved-cards-at-checkout.md. A plan that lives only in a chat window disappears when the window closes. If someone pastes you a plan, save it to plans/ first and work from the file.

When the last slice passes, move the plan to plans/archive/. A finished plan left in plans/ looks like open work to the next session, and an agent will happily try to "continue" it. A plan with a deferred slice stays where it is, and its top Status: line names what remains and why.

That gives you a simple map of a project. Open work is in plans/. Finished work, with its proof, is in plans/archive/. Anyone can tell the difference with one ls.

The skill's linter checks the record for you. It flags any slice marked done without a Proved by: line, and when every slice is done it prints the command that archives the plan. The linter command is in The Kit at the back.

Context is judgment, stored

In Wealth Is Context I argued that the asset a company owns now is its context: the facts and decisions it can reach and trust. One line from that essay carries most of this chapter:

Context is judgment, stored.

Kent Langley, Wealth Is Context

And a second one, about how it builds up or leaks away:

Every decision your company makes either deposits context or evaporates it.

Kent Langley, Wealth Is Context

A plan file is that ledger at the scale of one project. Every slice is a decision with a result. The Proved by: line deposits the result. The Notes: line deposits the judgment: the edge case you found, the follow-up you parked, the option you looked at and turned down, with the reason. Skip the edit and all of it evaporates by Monday.

Before any of this, in Founder Scaled, I called the company-wide version of this a knowledge battery:

A knowledge battery is a dynamic repository of institutional intelligence. Think of it like an electrical battery, but for organizational wisdom.

Kent Langley, Founder Scaled

The plan file is a small battery. It charges a little with every slice. It discharges every time a session starts, a teammate picks up the work, or you come back from a week away and need to know what is true.

The handoff at the end of a slice

The essay (Own the Slice) gave the handoff a single line in its list of limits: a builder who works alone becomes the only person who understands the slice. That is the solo builder's real risk: everything known about the work sits in one head.

Here is what the next owner actually needs, and all three already sit in the plan entry if you made the edit.

The entry. What the slice is, what it ships, and what was left out on purpose. The name and the out-for-now list tell the next person where the edges are, so they do not "finish" something you excluded.

The proof. The exact command that passed, and what it printed. The next owner can run it again in seconds and see the same result. If they cannot, they have found the first thing to look at.

The notes. What changed from the plan, what was deferred, what you discovered. This is the part nobody can rebuild from the code.

The test for a good handoff is plain. Could the next person, or the next session, resume from the plan file alone, without reading the git history or the conversation? If yes, the handoff is done. If they would need to ask you a question, the answer to that question belongs in Notes:.

This works the same when the next owner is you. Two weeks from now you will want to know why Slice 2 skipped the retry logic, and the file should say.

A plan with a Proved by: line on every finished slice lets the next session start from the last command that passed.

The agent is on Slice 3 of the saved-cards plan: customers can remove a saved card. It should take an hour.

At the start of every turn it re-reads the whole plan. The Problem section, the Design section, the open questions, all of it. On the third turn it writes: "Before I add the remove button, I want to revisit the five-card limit. A customer with a business account might reasonably want more. Should we reconsider?"

That question was settled two weeks ago. It is marked resolved in the plan, with the answer written next to it. The agent read the old discussion, found it interesting, and reopened it. Now you are debating card limits instead of shipping card removal. (The plan is the worked example from the skill. The detour is illustrative, and common.)

By its own lights, the agent is being helpful. You gave it the whole design to read, so it engaged with the whole design.

What the design sections are for

A plan has two audiences at two different times.

Before the work starts, the plan is for thinking. The Problem section says who is stuck and what it costs them. The Design section says how you will fix it, which options you rejected, and why. The Open questions list what still needs an answer. That is the material for planning and review, and it deserves real argument (Chapter 10, Argue With Your Slice, is about having that argument on purpose).

Once a slice is approved and work begins, the audience changes. The worker needs to know what to do on this slice, how to prove it, and what is already decided. Everything else in the plan is background.

Background has a cost for an agent. Every page it re-reads uses up context it could spend on the code. And every rejected option it reads is an invitation. Models are built to be helpful. Show one an old argument and it will often try to help with the argument.

The execution brief

So each slice in the plan carries a short brief for the worker. In the skill's format it sits right under the slice, and it has three parts: imperative steps that point at the design instead of restating it, the exact done test, and one line that says which decisions are frozen.

Here is the brief for Slice 3, from the skill's worked plan:

#### Execute (Slice 3)
- Add a remove button to each card on the account page.
- Delete the token at the processor first, then the local row, as the Design section says.
- Done test: pytest tests/test_remove_saved_card.py
- Decisions frozen: design sections and resolved open questions apply as written.

Four lines. The second step points at the Design section and does not copy it, so the worker can look up the order of steps if it needs to. The last line says, in plain words, that the five-card limit is settled. So is everything else marked resolved in the plan.

The brief also feeds delegation. When you hand a slice to a subagent, the steps in its brief become the steps in the delegation prompt, and its done test becomes the Verify: line (see Chapter 5, Delegate With a Verify Line). One short block serves both.

When the brief is wrong

Sometimes the brief is wrong. The worker reaches the second step and finds the processor's API has no way to delete that kind of token. The plan said delete at the processor first. That step cannot be done as written.

Two things can happen next.

The worker can improvise. It might mark the card hidden in the local database and leave the token alive at the processor. It writes a test for that, the test passes, and the slice reports done. A real design decision about payment data has just been made inside a slice, by a worker, and nobody reviewed it. The done test cannot catch this, because the worker wrote the test to fit what it built.

Or the worker can stop. "The brief says to delete the token at the processor. The processor's API does not support deleting this token type. I have made no changes. Options I can see: hide the card locally, or ask the processor about a different token type. Your call."

That second report is worth more than a passing test. It puts the decision back with the person who owns the plan, while the decision is still cheap. You read it, choose, update the Design section and the brief, and the next turn picks up from there.

The rule cuts both ways. It frees the worker from re-deciding settled questions, and it forbids the worker from settling new ones on its own.

The same failure, in a person

People do this too, and builders who think well are the most exposed.

In The Philosopher Builder I described the person this book is for, and I put a warning inside the name:

You do not want someone so philosophical that reasoning becomes the deliverable.

Kent Langley, The Philosopher Builder

A few lines later, the essay says it more bluntly:

The research is not the work. The thinking is not the shipping. Hold both truths.

Kent Langley, The Philosopher Builder

You know the version of this in your own week. You open the strategy doc on Tuesday to check one number, and an hour later you are rewriting the pricing section you agreed with yourself last month. You read the old reasoning again, found it interesting again, and started over with no new facts in hand.

The execution brief works on you the same way it works on an agent. While you are building, read the brief. If something has truly changed, such as a customer saying no, a cost turning out higher, or an API missing a call, then stop, write down what changed, and reopen the decision on purpose at the next plan review. That is a decision you made. Drifting back into the design doc because it is more fun than the slice is a different activity, and the plan gives you a way to tell the two apart.

A four-line brief with a frozen-decisions line keeps the agent, and you, working on the one slice in front of you.

On October 19, 2026, I closed issue #18 in the Jane repo with one comment:

All 17 slices shipped (v0.4.0 + v0.4.1). Plan archived at plans/archive/learning-loop-v0.4.md.

Kent Langley, Jane issue #18

Issue #18 tracked a plan called "Learning loop v0.4: shorter quests, review gates, honest medals." Above my comment sat seventeen ticked boxes, one per slice, each linked to its own closed issue. This page walks through that plan: the method in this book, running in public.

What Jane is

Jane is "an adaptive learning app for primary school kids based on the Marble Skill Taxonomy." I build it with my son Landon. The README says it plainly: "Jane was designed by Kent Langley and Landon, and developed with Grok Bot, an AI assistant." Grok Bot writes and revises the code from our feedback.

So Jane is a small set of builders with an agent doing the mechanical work. That is the setup this book is written for.

From six problems to seventeen slices

The plan lives in the repo, at plans/archive/learning-loop-v0.4.md. It starts with six problems, stated in plain words: "Quests are too long." "Medals are too easy, and the trophy list has duplicates." "Finished quests can change." It answers them with six design sections and three open questions for me. Then it cuts the work into slices. The commit that added the plan ends "in 16 slices."

Each slice is named for what changes for a learner or a parent:

• Slice 1: Quests fit in about eight minutes
• Slice 4: Asked for a percent? Write a percent
• Slice 6: Mastery takes real answers, not a thumbs-up
• Slice 17: Parent report shows coverage by area

A parent could read any of those and tell you whether it shipped. None of them uses the skill's literal <who> can <do what> shape, and every one passes the check behind it: no table, no endpoint, no column in the name.

The plan grew a slice before any code landed. My answer to the first open question, about medals earned under the old rules, was "Update all with new rules." That answer became Slice 9: Existing medals re-earned under the new rules. The commit that recorded my decisions ends "renumber later slices." Slice numbers follow the order of the work. Issue numbers follow the order the issues were opened, which is why Slice 9 is issue #19.

A done test with named cases

Every slice issue carries the fields from Chapter 4, Plan in Slices: Ships, Touches, Done test, Owner. Jane's done tests add one habit I now use everywhere. Each one lists the cases the test must hold.

Slice 4's done test runs a new test file, test/answer-form.test.mjs, then the full npm test suite, "with these new cases." The first case asks "What is 27/100 as a percent?" An answer of 0.27 gets a gentle nudge, with tries still 0. Then 27% counts as "correct on the first try (full points)."

Anyone can run that command and read what the slice promised. When the slice closed, its record said: "6/6 new cases pass, 27/27 in npm test."

The issue also shows where the work moved from the plan. The planned nudge used the real answer as its example. The shipped nudge says "like 50%," and the notes give the reason: "The nudge examples are generic (like 50%) so the first nudge never gives the answer away." One sentence, written at the moment it became true.

Briefs that keep decisions settled

Each slice issue also holds the short Execute brief from Chapter 8, Execute From the Brief.

Every brief in the plan ends with the skill's own line: "Decisions frozen: design sections and resolved open questions apply as written." My three answers sit in the plan, marked frozen. No slice argued with them again.

Closed issues are the record

Each slice issue ends with a Progress section under three headings: Shipped, Done test, and Deferred / discovered. The skill calls the same three facts Status, Proved by, and Notes. Then, on every slice but Slice 9, a closing comment repeats the proof, starting "Done test passed:".

The notes stay honest about small things. Three issues say "Owner was delegate; executed directly in this run." Slice 1 records a gap it found and chose to leave: "Already-published packs are not re-validated by the app (grandfathered): the engine plays whatever is in KV."

This is Chapter 7, The Plan Is the Memory, at the scale of a public repo. When the last slice passed, the plan moved to plans/archive/ and the tracking issue closed. A new session on Jane next month reads issue #18 and the archived plan. It needs neither the old conversation nor me.

What the stamps show

GitHub stamps every step in UTC, and all of these carry the same date, October 19. The plan was committed at 18:58. The commit recording my three decisions landed at 20:55. The commit "Slice 1: quests fit in about eight minutes (closes #2)" is stamped 21:02. The Slice 17 commit is stamped 21:28. The plan moved to the archive at 21:54.

Each stamp marks when a commit landed, so together they give the order of the work. (They cannot time the agent's work between commits.) The plan and my answers came first. Then came one commit per slice, each named for its slice. It is a small picture of Chapter 1, Two Clocks: about two hours passed between the plan and my answers, and every slice commit came after them.

One step waited for a person. Slice 9 rewrites medals already stored, so its brief says "The live Cloudflare run needs Kent's explicit go-ahead at execution time." I approved it with one change, to keep legendary medals already awarded. That change shipped as version 0.4.1.

The habit outlived the plan. About two hours after #18 closed, issue #23, "Trophy Case: tap a medal type to filter," opened as a "Small follow-up to the v0.4 learning loop." It had the same fields, one done test, and a Progress section. It closed with "83/83 in npm test."

What you can copy

• One plan file in plans/, with design sections and numbered open questions you answer before the first slice starts.
• One tracking issue per plan, with a box per slice.
• One issue per slice, labeled, named for what changes for a person, with a done test that lists its cases.
• A Progress section with Shipped, Done test, and Deferred / discovered, filled in before the issue closes.
• One commit per slice that names the slice and closes its issue.
• A move to plans/archive/ when the last box is ticked.

Each of Jane's seventeen closed slice issues ends with the command that proved it, so anyone can check our work.

In The Philosopher Builder I drew a picture of where the work went:

AI collapsed software engineering, product, and design into one circle. The person you want to hire sits dead center.

Kent Langley, The Philosopher Builder

Picture that person on a Tuesday. One screen holds a design they sketched that morning. Another holds three agent sessions, each working on something different. There is a customer email open about a bug, a half-written pricing page, and a note to call the accountant. They are the designer, the product manager, and the engineer, and on a small team they are often the owner too.

They hold the tools of three roles in one pair of hands. They also have nobody across the table asking, "Is this done?"

That question used to come for free. The designer asked it of the engineer. The product manager asked it of both. The handoff between roles forced a check. When the roles collapse into one person, the handoffs go away, and so do the checks they carried.

A lever needs someone pushing on it

The same essay has a screen for the trait that matters most once AI is in the room. I called it the discipline to use AI without going soft:

The builder still applies their own judgment, still follows a process, still owns the outcome. AI is a lever. A lever with nobody pushing on it moves nothing.

Kent Langley, The Philosopher Builder

A lever also needs a direction. Point a strong lever at a vague goal and it moves a lot of things a little. Three agents, each busy, each producing plausible work, and at the end of the week nothing a customer can use.

The slice gives the push a direction. One outcome, named for a person doing something. One test that proves it. One list of what stays out. The lever does the heavy work inside those lines, and you can see whether it moved the thing you aimed it at.

The finisher at the table

The Philosopher Builder borrowed a lens from Kolbe, which measures how people instinctively take action. It contrasts the Fact Finder, who gathers, with the Quick Start, who initiates. The essay names the failure on one end of that range:

Very high knowledge-seeking with very low Quick Start produces someone who researches beautifully and forever, and never ships.

Kent Langley, The Philosopher Builder

Its answer for a team was to mix people so that "the gatherer and the starter and the finisher sit at the same table." On my own projects, three people at that table have worked best so far (Chapter 2, The Slice, explains why).

A solo builder has one chair at that table. And AI has made two of the three roles nearly free. An agent will gather all day: research, summaries, comparisons, options. An agent will start anything you ask, and start ten more things while it waits. The role AI does not fill on its own is the finisher, the one who says "this is the outcome, this proves it, and now we stop."

The slice supplies that role. The done test says what finished means before the work starts. The out list says what finished leaves alone. One slice per turn (Chapter 6, One Slice per Turn) forces a stop. The plan file (Chapter 7, The Plan Is the Memory) records that the stop happened. A builder with no finisher on the team can still work with one, as long as the finisher is written into how the work is cut.

Five things, mapped to a slice

In Experience Repriced I tried to say what "skilled" means now for a generalist who works with AI. I landed on five things. Context assembly. Decomposition. Delegation in writing. Output judgment. Accountability.

Two of the definitions are short enough to quote:

Decomposition. Cutting ambiguous work into pieces something else can execute.

Kent Langley, Experience Repriced

Accountability. Owning the result.

Kent Langley, Experience Repriced

Lay those five next to the work of cutting and owning a slice and they line up almost one for one.

That table is why I call slice discipline a skill. The five judgments inside it take practice, and the slices themselves are the practice.

The person holds the outcome

The essay (Own the Slice) said where agents fit, and it gave them credit. They can propose scope, flag edge cases, and draft the out list, and they will keep getting better at all of it. Then:

Agents write the code. A person answers for it.

Kent Langley, Own the Slice

Harshal Dhir, who took the essay to an enterprise deadline and built the original skill (slice-discipline), describes himself on LinkedIn as a Human Centaur. I like the word. It names the builder and the machine as one working unit, and it puts the person on top. The machine brings speed and volume. The person decides what ships, holds the outcome, and takes the call when something breaks.

That is the job at the center of the circle, and it belongs to a person.

A track record you can open

The Philosopher Builder also gave a way to test a builder with real projects, on a rising arc:

• 7 days: first proof
• 30 days: real ownership
• 90 days: keep or pass

The essay turned that arc into a slice ladder, and I will not repeat it here. What I want to add is where the evidence lives, especially for someone who works alone and has no manager to grade them.

It lives in your plan files, and as each plan finishes, in plans/archive/. Every finished plan sits there, and every slice in it carries a Proved by: line: the command that ran and what it printed. At seven days, the first proof is one slice whose test someone else can re-run. At thirty days, real ownership is a run of slices, each with an out list you held. At ninety days, keep or pass is a decision you make by opening the folder and reading.

If you are the owner deciding whether to keep a builder, ask for that folder before you ask for a demo. If you are the builder, the folder is how you show your work without having to talk about it.

The builder who finishes is the one whose archive holds a passing command for every slice they claimed.

The slice shipped on a Thursday. Customers could pay with a card they had used before. The done test was clean: a sandbox customer paid with a saved card and got a receipt. The owner ran it, a teammate ran it, and both saw the receipt.

On Monday, support heard the same complaint it had heard every day for a year. People still had to type their card again.

This is an illustrative version of the coffee client from the essay, and the reason is ordinary. The new code saved a card at the moment of payment. Every card used before launch had never been saved. Customers reorder every three or four weeks, so for the first month the feature worked for nobody who had complained. The test customer had a saved card because the test created one.

Where the claim broke

Run that slice through Toulmin's parts and the failure has an address. The claim: returning customers can pay with a saved card. The grounds: the chooser works, and the sandbox payment clears. The warrant, the assumption that joins the two: every returning customer already has a saved card on file. Everybody believed it, and nobody had written it down.

Own the Slice ran a real case through the same parts, the Omarchy kernel, and summed it up in one line: "The warrant is where both real bugs hid." Chapter 3, The Done Test, tells that story. The lesson to carry here is narrower. A done test checks the claim under the conditions you imagined. The warrant is where you write those conditions down, so someone can attack them.

The full sequence and a prompt to paste are in the essay, and the table is in the skill's reference on cutting slices. This chapter covers when to argue, where the answers go, and how hard to push.

Argue at plan review

The cheapest moment to lose an argument is before anything is built. At plan review, a rebuttal costs a sentence. You read it, decide, and edit one line of the plan. After launch, the same rebuttal arrives as a support ticket. By then the slice is marked done, the owner has moved on, and the fix competes with the next slice for the same week.

So the argument belongs in the plan, after the done test is written and before the Execute brief is frozen. Chapter 8, Execute From the Brief, freezes decisions for good reason: an agent that re-argues the design mid-slice burns context and drifts. The freeze only works if the arguing already happened, once, on purpose.

Every rebuttal lands in writing

A model will hand you three rebuttals in under a minute. Each one has to go somewhere you can see it.

There are two places. Into scope, if the fix fits the size check. Or into the out list, with a line that says so. For the coffee slice, the warrant rebuttal has two clear homes. The slice can reach the cards customers used before launch, through whatever records the payment processor already keeps. Or the out list says "Cards from orders before launch," and the slice name gets a qualifier: from a customer's second order after launch.

Either answer is fine. The silent answer is the one that hurts. A rebuttal you read, nod at, and leave in the chat is a decision nobody can see. The next session cannot find it, and the person who complained never learns it was considered.

Match the depth to the stakes

Some slices need a debate, and most need a few minutes. In The Expert Costume I put the rule in five words: "Match review depth to stakes." Here is how that sorts out for slices.

• Low stakes, easy to undo. A copy change, an internal report, a page behind a flag. The done test is enough. Skip the argument.
• Normal stakes. Most product and business slices. Run the prompt once, read the three rebuttals, and spend ten minutes deciding where each one goes.
• Money, customer data, or anything you cannot take back. Run the full sequence. Ask the model for the case you would be most embarrassed to have missed. Then have a second person read the rebuttals and your answers before the brief is frozen.

The skill draws the same line. It asks for the argument "before a slice with real risk ships," and leaves the rest to the done test.

The bar

The Expert Costume also set one bar for everything that ships: "can you defend this without the model in the room?"

Use it as the last step of the argument. Close the chat. Explain the slice out loud to someone who was not there: the claim, the warrant, what you brought into scope, and what you left out and why. If you can do that in two minutes, you made the decisions. If you keep reaching for the transcript, the model made them and you agreed.

The tool below writes the prompt from your slice. If you have already used the slice builder in Chapter 11, Slices Beyond Code, its outcome and done test carry over. Add your grounds and your warrant if you know them.

Paste the prompt into a capable model and read the warrant it states before you read the rebuttals. If the warrant surprises you, that is the sentence to fix. The worked example shows the Omarchy table, the cleanest real case of a warrant nobody checked.

Who decides

A model is good at this job. It reads fast, it has seen many ways a payment flow can fail, and it has no stake in your plan being right. It is also generous. Ask whether to bring a rebuttal into scope and it will often say yes to all three, because it carries none of the week.

That is scope creep in a new coat, and you are the one holding the size check. The model argues. The owner decides what ships, writes the answer into the plan, and answers for it when a customer calls.

In the coffee slice, the warrant took one sentence to write and one sentence to rebut, and skipping both cost a month of the same complaint.

On the fifth business day of every month, the bookkeeper closes the books. Every account reconciles. The task in the project tool turns green. It has turned green every month for three years.

On the sixth business day, the owner sends a text: "How much runway do we have?" The bookkeeper stops what she is doing, opens three spreadsheets, and answers an hour later. Next month, the same text arrives.

This owner is illustrative, and you probably know him. The reconciliation is done, by every measure the task ever had. His question is still open, because nobody ever turned it into an outcome. So the work sits on his desk and comes back every month like a bill.

The same drill, on the rest of the business

In Chapter 2, The Slice, you rewrote seven queue items as slices. Four of them came from the business side: Update CRM fields, Reconcile accounts, Post the job description, Tag billing tickets. The rewrites worked the same way they did for the payment table. Each one names a person who can do something once the work is finished.

Reconcile accounts becomes "The owner sees cash runway every Monday without asking." The reconciliation is still in there. It is now a step inside an outcome, and the outcome has a reader.

Business work hides activity better than code does. Code at least has a test suite to embarrass it. A green task, a posted job, a tagged ticket: each looks finished, and each can sit beside a problem that has not moved in a year.

Who owns the process

I wrote about this before I had the word slice. Founder Scaled has a chapter called Process Before Technology, and its process audit asks a plain question.

Who owns this process end-to-end? If the answer is "multiple people" or "nobody," that's a problem.

Kent Langley, Founder Scaled

A slice answers that question for one outcome at a time. That is a much smaller job than redesigning your finance function. Decide who owns the Monday runway number, from the bank feed to the owner's inbox, and what proves it arrived.

The order matters too. The same book puts it this way: "Technology must follow process and process must follow people." AI makes the technology part nearly free. Point it at a process nobody owns and you get the same unowned work, sooner and in larger amounts.

Done tests for business work

A done test for business work is still one observable check that someone else can run. The skill's reference on done tests says the check "is usually a date, a record, or an absence." Then name where the evidence lives, so the next person can look without asking you.

Some of these take longer than a week to observe. That is fine. The building fits in a week, and the proof arrives when the next request does. Write the date you expect it on the plan, so the check has a day on someone's calendar.

Two kinds of done test fail here more than anywhere else. The first checks activity: the template exists, the CRM has a quote field. The second can only be judged by its owner: the process feels smoother. Chapter 3, The Done Test, has the sorter for both.

One name, in public

Business slices drift toward shared ownership. "Finance" owns the runway number. "The team" owns pricing. Or the owner puts his own name on everything, because it feels faster than explaining.

Put one name on the slice, where the people involved can see it: the team channel, the top of the plan, the weekly notes. Help is welcome. The bookkeeper may need the sales lead's pipeline numbers. The name tells everyone whose week the outcome lives in.

Watch for your own name. The slices in this chapter exist to move an outcome off your desk. If your name sits on the runway slice, you have built yourself a new chore.

One at a time

Founder Scaled lists a signal that an owner needs a way to decide what comes first: "you worry about starting too many initiatives and finishing none." An owner who has just found slices may want to cut eight on the first afternoon. The CRM, the books, the hiring pipeline, the support inbox, all at once.

Cut one. Start with the complaint you hear most, or the question you keep asking. Finish it, run the test, and tell the person who complained. Then cut the next. Each slice that ships takes a recurring question off your desk for good, and the second one goes faster because the first one showed your team what done looks like.

The builder below walks the nine steps for one slice. Load the example to see a finished card, then clear it and cut your own, starting from the complaint.

Notice what the name check flags. If it catches a word like ticket or table, your outcome still describes the work. Keep rewriting until it names a person who can do something. "Copy as plan entry" gives you a block to drop into plans/<slug>.md.

The test for this whole chapter fits on one line: next Monday, the runway number arrives and nobody had to ask.

A client needs to move twelve years of billing records from an old system to a new one. Every customer, every invoice, every payment plan. The cutover has a date, because the old vendor's contract ends that month. Nobody can ship half of it to a customer and watch them use it.

That client is illustrative, and so is every example in this chapter. The problem is real. Own the Slice names it in its limits section.

Some work does not slice cleanly. A database migration, a compliance audit, or a platform rebuild may need coordinated specialists and a longer runway.

Kent Langley, Own the Slice

Two more limits follow it. "Some slices are too big for one person even with agents. Cut them smaller rather than staffing them larger." And: "A builder who works alone becomes the only person who understands the slice, so every slice needs a short, deliberate handoff at the end."

The essay names the problem and stops there. What follows is how I work when I hit it. It is my working method, from my own projects. Nobody has studied it, so take what holds up in your work and leave the rest.

Find the smallest provable outcome

A big job usually has a small proof inside it. My first move is to look for the smallest thing that can be shown working, for real, with the same kind of check the whole job will need at the end.

Six shapes cover most of what I find:

• One account. Move one real customer, end to end, and bill them from the new system.
• One region. Run the change where the fewest users live.
• One record type. Invoices before payment plans. Active customers before archived ones.
• A dry run. Run the whole job against last night's copy of the data, and compare.
• A shadow run. Let the new system work beside the old one for a cycle, with the old one still in charge, and compare every result.
• A rehearsal with a rollback. Cut over the smallest piece, undo it, and time both.

For the billing move, those shapes turn one frightening date into a run of slices, each with an owner and a done test.

Each slice proves a piece of the job in the real system, and each one can fail cheaply. By cutover day, the frightening part has already happened four times at small scale.

One small tell helps here. The plan linter flags the word migration in a slice name. That is a useful nudge on this kind of work. Name the slice for the person who can do something once it passes.

The learning slice

Sometimes you cannot cut a slice because you do not know enough yet. Take a compliance audit. Before you can plan the work, you need to know which systems hold customer personal data, and nobody is sure.

That gets its own slice, and its done test is a question answered in writing. The owner can name every system that holds customer personal data, and who can reach each one. It is done when a one-page answer exists, and the person who will sit across from the auditor has read it and found nothing missing.

Learning slices carry the risk you met in Chapter 8, Execute From the Brief: the research quietly becomes the work. So I hold two limits on them. A learning slice gets a day or two at most. And its answer has to change a decision. If the page would leave the plan exactly as it was, skip the slice and start building.

Specialists in sequence, one owner over the whole

A platform rebuild needs people the builder cannot replace. A database specialist. A security reviewer. Someone who knows how the payment processor behaves.

Give each of them a slice of their own, with an owner and a done test. The security reviewer's slice is done when the review is signed. The database specialist's is done when a restore drill runs clean on a copy. Chapter 5, Delegate With a Verify Line, gives you the brief, and it carries across people as well as agents.

Then put one person over the whole sequence. That person owns three things: the order the slices land in, the handoff between each pair, and the done test for the whole job, the one that proves what the rebuild promised. Choose someone who will pay attention to the whole, and write the name where everyone can see it.

Too big for one person

When a slice feels too big, the reflex is to add a second person to it. I resist that reflex. Two people on one slice means a handoff inside the slice and an owner who is really two owners. The essay's rule holds, so cut it smaller.

The cut usually sits along an outcome boundary you have not named yet. One record type. One customer group. One step of the job a person can watch work. If you can say what someone can do after the smaller piece ships, you have found the cut.

When to stop slicing

Some work really does refuse. A filing that is accepted or rejected as one piece. A contract that is signed or unsigned. A cutover where the old system goes dark at midnight and there is no way to run both. I know I am there when every split I try produces layers, and the only done test I can write is the whole job.

Then I stop and say so, in writing, at the top of the plan.

This work does not slice.
Owner: <one name>
Runway: <start date> to <end date>
Specialists: <names, and what each one signs>
Checkpoints: <dates, each with something someone can inspect>
Done when: <the one check for the whole job>

Saying so plainly is a result. It tells the people around you to expect a longer runway. It also keeps anyone from forcing fake slices onto the work, and a fake slice does real harm, because it passes a test that proves nothing.

The handoff at the end

Big work has many owners, and each one becomes the only person who understands their piece. So every slice ends the same way, even when it is one of twenty: the plan entry, the proof, and the notes. Chapter 7, The Plan Is the Memory, shows what goes in each.

On a long job, that habit lets the coordinator see where the whole stands by reading one file.

By cutover day, the billing move in this chapter has run four times at small scale, and each run left a done test someone else can repeat.

Picture an agent at two in the morning, on its eleventh pass at a slice. It has rewritten the same function four ways, and each time it reported progress. At 2:40 it writes "All done" and goes quiet.

Whether that sentence means anything depends on one question: who decided it was done?

In Progressive Agency I described the loop as one of five dials you install around a model, and I said what it needs.

It is also worthless without a judge. A loop that cannot honestly score itself does not converge. It drifts, and then it declares victory.

Kent Langley, Progressive Agency

A slice gives the loop that judge, and much more.

A loop runs one slice

The loop dial in that essay has three settings: "One turn, then a set number of turns, then running until it clears a bar." The slice supplies the bar.

A loop is plan, do, verify, decide, over and over. Plan the next attempt. Make it. Run the check. Decide whether to stop, try again, or give up. The slice gives each part its edges. The outcome says what to aim at. The out list says where the loop may not wander. The done test is the check.

And because a loop runs one slice, it ends when that slice is proved. Then the person who gates the next slice gets a turn, the same pacing Chapter 6, One Slice per Turn, set for a single agent.

I built a powerful tool for exactly this work. It is called running-loops, and it is part of fOS (getfos.ai). It runs a slice to done, and it delegates each piece of the work to the model and the reasoning effort that piece needs.

The judge sits outside the worker

The done test is the loop's judge. Chapter 3, The Done Test, asked for one check impossible to argue with, written before the work starts. A loop is where that check earns its keep, because the loop will run it dozens of times while you sleep.

The worker should run the check on every pass. It should never be the one to accept the result. A test suite that exits 0, a build, a live /health, a row count: those answer for themselves. A worker's own summary of how it did is the cheapest thing in the loop to produce and the easiest to get wrong.

So acceptance happens outside the worker. The orchestrator re-runs the Verify: line, or continuous integration runs it on its own. Chapter 5, Delegate With a Verify Line, set that rule for a single handoff. A loop is many handoffs in a row, so the rule matters more.

A loop also needs a way to end without a pass. Set a limit before it starts: a number of turns, a dollar figure, a clock time. When it hits the limit, it stops and reports what it tried, along with the exact output of the failing check. A loop that runs out of budget and reports success has declared victory, and the judge is there to catch exactly that.

What stays behind a person

Some steps never go inside the loop. Progressive Agency put the list in one line: "Sending. Publishing. Deleting. Spending. Those stay behind a person."

That gives a slice a shape for loops. The loop runs up to the gate and stops. Take the sales slice from Chapter 11, Slices Beyond Code: a prospect who asks for pricing gets a quote the same day. A loop can read the request, pull the rate card, draft the quote, and check the arithmetic against the rate card until it matches. A person reads it and presses send. The done test still runs on the outcome: the CRM shows the quote went out the day the request came in.

Write the gate into the plan. The Execute brief says where the loop stops, and the Notes line says who holds the button.

Count the outcome

A loop makes activity cheap to produce and easy to count: turns, tokens, files touched. None of those numbers says whether the loop paid.

In Self-Liquidating Token Spend I asked for one signal: "Emit an accepted-outcome event from every material AI workflow." For a slice, that event already exists. It is the moment the done test passes and something outside the worker accepts it. Write it on the plan's Proved by line and you have your count.

Then divide. "Cost per outcome is the true denominator," as that essay puts it. For loops, the outcome is a passed slice. The cost is everything it took to get there: every attempt, every retry, the tokens, and your own review time.

Here is an illustrative month. Loops cost $300 in tokens. You spent eight hours reviewing, at $150 an hour. Twenty slices passed their done tests. That is $1,500 for 20 slices, or $75 a slice. Watch the trend more than the number. If next month the token bill falls and the cost per slice rises, a cheaper setup is costing you more.

Watch the throwaways too. The same essay put it plainly: "If a loop hands you ten results and you throw six away, you are doing the review work the tool was supposed to save." It drew the line at roughly a 50% accept rate. That framing is Anatoli Kopadze's, and the 50% line is my own working threshold, an estimate from practice. A loop whose slices fail review more often than they pass is a loop to fix before you scale it.

Your token bill and your plan file already hold the one loop number that counts retries and your time: cost per passed slice.

It is Monday morning. The list is long, the agent is fast, and everything on the list looks like it could be finished by Wednesday.

Here is the week I would run. One slice, from the pile to the proof, by Friday.

Monday: cut one slice

Find the pile: the place where work waits, the question that keeps coming back, the thing your team keeps apologizing for. Pick the complaint underneath it, from a real person. Name the outcome in their words, as "[who] can [do what]." Write the done test before anything else, and note where its evidence will live.

Draw the out list. If the slice carries real risk, argue with it once (Chapter 10, Argue With Your Slice), and write every rebuttal into scope or out.

Tuesday: one name, in public

Put one name on the slice where the people involved will see it. If the name is yours, say so. Save the plan to plans/<slug>.md and run the linter on it.

Wednesday and Thursday: build

Let AI do the mechanical work. Keep pointing at the out list. The agent takes one slice per turn. Every piece you hand off ends with a Verify: line, and you re-run it before you accept the work.

Friday: prove it, stop, tell them

Run the done test. If it passes, stop. Leave the next slice for Monday. Tell the person who complained, in their words, that they can now do the thing. Then record the slice in the plan: the status, the command and what it returned, and anything you deferred.

If the test fails, say so in the plan and in the message. A failing done test on Friday is useful news. A slice that slides into next week marked "almost done" is the queue coming back.

Small enough to finish

Obie Fernandez wrote about an evening with a longtime friend. The friend was a staff engineer with half a dozen terminals open and an agent in each, and he said he could not make progress on anything. In Own the Slice I read Obie's advice to his friend as, in effect, a slice: "pick something this week small enough to finish and consequential enough that another person will notice." That sentence is the whole week above.

Harshal Dhir worked this way against an enterprise deadline, then turned the method into the open-source slice-discipline skill. His post on LinkedIn ends his loop with the instruction for the following Monday: "Then shape the next one."

Count one number

Count slices shipped and proved this week. Proved means the done test ran, it passed, and the result sits on the plan's Proved by line. Leave tickets closed, hours worked, and tokens spent off the count. Those measure the first clock.

For most builders, the first honest count is zero or one. That is your baseline. One proved slice a week comes to about fifty a year, and each one is a thing a person can do that they could not do before.

The self-check below turns the skill's checklist into ten statements about your own work. Answer them honestly.

Start with the first No, even if a later one bothers you more. The list runs in the order the work does, so an early fix makes the later ones easier.

On Friday, if the test passes, one person can do something they could not do on Monday, and you can show anyone the check that proves it.

The skill

The rules in this book exist as agent skills you can install and run today.

• slice-discipline, by Harshal Dhir (github.com/unixguru2k/slice-discipline, MIT). The original. Harshal took the essay to an enterprise deadline and turned it into five disciplines for agents: plan in slices, delegate with a Verify: line, verify before done, record progress, and execute from briefs.
• working-in-slices, by Kent Langley (github.com/kentlangley/working-in-slices-standalone, MIT). It follows Harshal's five disciplines rule for rule. It adds slicing for work beyond code, arguing with a slice before it ships, the slice card and delegation brief templates, and a plan linter.
• working-in-slices in Founder OS, for Founder OS members (getfos.ai). The same skill, connected to the other Founder OS skills. A slice can hand off to loops, client delivery, and the team's knowledge battery without leaving the system.

The linter checks a plan file against the format. With the skill installed in Claude Code, run it from your project root:

python3 ~/.claude/skills/working-in-slices-standalone/scripts/check_plan.py plans/<slug>.md

It checks every field, flags slice names written in implementation language, and tells you when a plan is ready to move to plans/archive/. Exit 0 means the plan is clean.

Templates

• The plan (templates/slice-plan.md): the skeleton you save as plans/<slug>.md, with Problem, Design, Open questions, and one entry per slice.
• The slice card (templates/slice-card.md): one slice on one page, nine fields, for any kind of work.
• The delegation brief (templates/delegation-brief.md): the prompt you hand a subagent, ending with the Verify: line.

Your work

Everything you typed into this book's tools sits below, saved in this browser only and ready to download.

Glossary

• Slice. One outcome a person can use or watch, cut through every layer it touches, with one owner and a done test.
• Done test. One observable check, runnable by someone other than the worker, that proves the outcome in the world.
• Owner. The one named person who answers for a slice from start to ship.
• Verify line. The last line of a delegation brief: the exact command that proves the work, run by the worker and re-run by you.
• Plan file. The running record of a piece of work, saved at plans/<slug>.md.
• Archive. The plans/archive/ folder, where a plan moves once every slice has passed its done test.
• Execution brief. The short block of steps, done test, and frozen decisions that a worker reads while building one slice.
• Out for now. The written list of what a slice leaves for later.
• Pile. The place where work waits. The constraint sits just downstream of it.
• Warrant. The assumption that joins a slice's evidence to its claim, and the first place to look for bugs.
• Judge. The check that decides whether a loop's work passed, kept outside the worker.
• Steps per touch. How many actions a system takes between human interventions.

Work with Kent

If you want slice discipline running in your own work, ask me. Help usually takes one of three shapes. I can help you install the working-in-slices skill, so your agents plan, delegate, and verify the way this book describes. I can work with your team to cut its first slices on a live project, done tests and out lists included, so you have a proved slice to show within two weeks. Or you can join fOS Builder's Lab, where we teach it, and work your own slices alongside other builders. Start at getfos.ai, or reach me at kentlangley.com.

Sources

Kent Langley's open-source project

• Jane, an adaptive learning app for primary school kids based on the Marble Skill Taxonomy, which I build with my son Landon. Its README, closed issues, and commit history are the source for the case study Jane, Slice by Slice.

Kent Langley's essays and book

• Own the Slice (September 21, 2026). Its own source list carries full citations for every case it covers.
• The Philosopher Builder (July 25, 2026).
• Progressive Agency (August 15, 2026).
• Wealth Is Context (June 12, 2026).
• The Expert Costume (June 10, 2026).
• Experience Repriced (June 12, 2026).
• Self-Liquidating Token Spend (June 29, 2026).
• Founder Scaled, read online. Its stories are composites, with names changed.

Others

• Harshal Dhir, post on LinkedIn (October 2026), and the slice-discipline skill (MIT).
• Bill Wake, "INVEST in Good Stories, and SMART Tasks" (XP123, 2003).
• Stephen Toulmin, The Uses of Argument (Cambridge University Press, 1958); see Toulmin model.
• Omarchy: GitHub issues #12664 and #12145, plugin-marketplace #7862; omarchy-kernel-guard; Linuxiac (September 2026), as cited in Own the Slice.
• Obie Fernandez, essay on X (September 2026).
• Anatoli Kopadze, post on X (2026), the cost-per-accepted-change framing cited in Self-Liquidating Token Spend.
• Gene Amdahl, "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities" (AFIPS Spring Joint Computer Conference, 1967), the origin of Amdahl's law.
• Kolbe Corp, the Kolbe A Index, as described in The Philosopher Builder.

Thanks

To Harshal Dhir, for taking the essay to an enterprise deadline and open-sourcing the result.

About the author

Kent Langley writes at kentlangley.com and wrote Founder Scaled. He builds Founder OS (getfos.ai).