Why Lean?

When something takes three weeks, almost none of those weeks is anyone working on it. In most processes less than a tenth of the elapsed time adds value; the rest is waiting and moving. So making the work itself 50% faster shortens the whole by only about 5% (Fiume, Lean Enterprise Institute).

Toyota's Taiichi Ohno summed up his whole system as watching the timeline from order to cash and shrinking it "by removing the non-value-added wastes" (Ohno, Toyota Production System, 1988, as quoted by Liker and others). Lean is not about working people harder. Toyota's way rests on two pillars, "respect for people and continuous improvement" (The Toyota Way), and Toyota says its system is "based on the premise of making work easier for workers" (Toyota).

Its method is to make problems impossible to miss (any worker can stop the line, and the andon lights up) and then to go and see the real cause before changing anything (genchi genbutsu, LEI).

The factory is an open experiment in applying these Lean methods to agentic software work. It is designed so many teams can adopt it alongside their own engineering lifecycle, without replacing it. So far it has been tested only on the desks and agent hosts that publish to this store, so its findings are evidence about those desks, not proof for every setup. Lean value-stream methods are already applied to software delivery elsewhere (DORA: value stream management); this experiment's chosen focus is end-to-end agent work, its interruptions, its quality and checking whether an improvement actually worked.

Why it matters more with AI agents

AI "amplifies what's already there" (DORA 2025). An agent that writes code in minutes can still leave a task waiting days for review, rework or a human answer. Speed can even be an illusion: in one study, experienced developers took 19% longer with early-2025 AI tools while believing they had been sped up by about 20% (METR). Measuring where the time actually goes, task by task, is how the factory tells real improvement from the feeling of it. The operator's attention is the scarce resource the factory protects.

Four questions, not a required tour

1. Overview. What do we understand about the production process and its evolution?
2. Time & waste. Where did time go, and which supported losses deserve investigation?
3. Improvements. What changed, and did it help, hurt or remain inconclusive?
4. Tasks. What happened in one piece of work and its whole agent team?

The eight wastes, in agent work

Lean names eight kinds of waste: Ohno's original seven, plus non-utilized talent, a later addition (LEI: 7 wastes). The translations into agent work are our own mapping, borrowing the words of Poppendieck's wastes of software where they fit and the definitions the factory's waste evaluator uses. Each waste keeps its color on every chart.

Waiting

Idle time: the lead time less the working time, when no agent of the task was working. It is split by what it waited on: the next prompt, recorded work on other tasks, an API retry, a failed tool call, a long tool call, the queue before the first session, no recorded task session, or a cause not recorded.

Defects

Failures and their rework: a failed command, a broken build, a change undone, a delivery sent back.

Extra processing

More work than the outcome needs: repeating a check that already passed, polishing past the requirement.

Overproduction

Work nobody asked for or used: an unrequested feature, a report no one reads.

Motion

Searching and navigating: rereading the same file, hunting for a path or a command, relearning a codebase.

Transportation

Moving work without changing it: copying context between sessions, handing work from agent to agent.

Inventory

Work started and left: open branches, stale drafts, half-done tasks.

Non-utilized talent

Capability left unused: doing by hand what a tool or skill does, not running in parallel what could.

Glossary

Lead time

The time from a task's card being created to the task being done. Some cards were created after work began; there the lead time is counted from the first session and says so.

Working time

The time any agent on the task was busy: turns, tool calls and subagents. It includes rework and necessary steps, not only value-adding work. The evaluator's labels (value-adding, necessary, each waste other than waiting, agents working but not labeled, and not labeled yet) describe working time only.

Waiting

Idle time: the lead time less the working time, when no agent was working on the task. It is split by what it waited on. Two causes are easy to confuse: recorded work on other tasks means a session of this task was running, but its agent was working on another task; no recorded task session means no session of this task was open at all. Cause not recorded means no agent was working on this task and the store did not record why.

Flow efficiency

Working time divided by lead time, as the Kanban Guide uses it. A low figure is normal: most lead time in any process is waiting.

Value-adding

Work that directly changes the outcome the task exists for: writing the change, running the test that proves it, answering the question asked.

Necessary

Work the outcome needs but that does not change it by itself: reading code to understand it, setting up a workspace, a required review.

Waste

Time that adds no value and that the outcome does not need: one of the eight wastes above. Lean's word is muda. Waste is a property of the system, never a person's or an agent's fault.

Agents working, not labeled

Working time when an agent was busy but the evaluator's labels do not say what the work was.

Not labeled yet

Working time the waste evaluator has not classified yet. It is shown as its own part, never as zero.

No recorded task session

Waiting in which no agent session of the task was open at all; the queue before the first session is shown apart.

Recorded work on other tasks

Waiting in which a session of this task was running, but its agent was working on another task. The other task is never named.

Evaluator-labeled pause (inside working time)

A stretch of a session the evaluator labeled as waiting, with what it waited on. It sits inside the working time the evaluator labels, and the session swimlane draws it cross-hatched. It is not the page's waiting, which always means idle time.

The evaluator

An independent agent that labels each stretch of a task's sessions as value-adding, necessary or one of the wastes, once the task is done, citing the evidence and never grading its own work.

Session

One run of an agent harness, such as one Claude Code conversation, from its first record to its last. A session can work on several tasks; a task can have several sessions.

Card

A task's record on the desk: its title, status (drafting, processing, done, signed off) and dates. The site never shows a card's title.

The operator

The person the agents work for: the one who asks for the work and accepts it. Public pages say "the operator", never a name.

Sign-off

The operator's recorded answer to a delivery: accepted, or sent back with a reason, recorded by the agent on the operator's word. "No sign-off" means no answer is recorded.

Finish day (UTC)

The day a task finished, in Coordinated Universal Time (UTC), which can be a day later than the operator's own evening. Every date on this site is a UTC day. "On 7 Oct" is an exact day; "on or before 7 Oct" means the task finished that day or earlier; "on or after 7 Oct" means that day or later; "about 7 Oct (direction not known)" means the record gives a day but cannot say which way the true day lies, and the page gives the reason. A finished task with no day says why.

Operator attention

Desk's estimate of the operator's own reading and answering time on a task: the time to read what the agent wrote and to write the next prompt, estimated from the size of each prompt and of the output read before it (never more than the wait before that prompt), plus a few seconds for each permission decision. It is not the time the task waited for the operator, which is waiting. The Store page averages it over delivered tasks; each task's page shows that task's own estimate.

Handoffs

The table under a task's value stream map with one row per operator prompt: its time on the task's clock, how long the task waited before it, why the agent had stopped, the prompt's size and the size of the output the operator read first. It is the text form of the prompt markers.

Prompt marker

A mark at the time the operator sent a prompt: above the box the prompt starts, on the timeline ladder and in the session's Operator lane. Its color says why the agent had stopped before it. A number on a marker counts prompts that fall together.

Pull request markers

An up-triangle marks when a pull request was opened and a diamond when it merged, on the ladder and in the session's Pull requests lane. A time known only in part is drawn outlined. A pull request with no time on the task's clock is listed under the map instead, never drawn at a guessed time.

Why the agent stopped

The split of "waiting for the next prompt" by why the agent ended its turn: stopped short, asked a question, error or limit, interrupted, a human gate, or not known. Desk decides the mechanical cases by rule from how the turn ended; the evaluator judges the rest from the agent's last message and the operator's next prompt.

Stopped short

The agent ended its turn although its authorization covered the next step and nothing blocked it, for example by asking "want me to continue?" or by waiting on its own background agent without arranging to be woken.

Asked a question

The agent needed information only the operator has: not a decision and not a permission.

Error or limit

The turn ended on an API error, a rate or usage limit, an output cap or a refusal.

Interrupted

The operator interrupted the agent mid-turn, so the wait is the operator's redirect, not the agent's stop.

Human gate

A stop only the operator can clear: a decision (a choice outside the agent's authorization), an approval (permission for an action the agent may not take alone) or an acceptance (finished work the operator must accept). Its length is mostly the operator's response time, which this split does not judge.

Why not known

Waiting for the next prompt whose stop has no class yet, always shown with its reason: not labeled yet (the evaluator has not run), could not tell, no stop recorded, or outside the task's share of a session.

Capture coverage

The share of the sessions still on the contributing machines that reached the store as facts. When it falls below 80%, or drops by 15 points or more, the status line raises an alarm: the store may be missing work.

Improvement loop

Desk's own loop that turns problems the factory finds into improvement items, fixes them and closes them only when the data confirms the fix. The status line raises an alarm when the loop reports a problem with itself, such as an item open for a week or a step that stopped succeeding.

Job-hours

How Rank causes counts time: each task's hours on a cause, added up over tasks. A moment two tasks share counts once for each task.

Value stream map

Lean's picture of one item's journey: each step as a box, the waits between steps as triangles, and a timeline underneath (LEI). On this site a step is a burst of agent work.

Work burst

A stretch of a session in which an agent of the task kept working. Desk starts a new burst after 15 minutes idle or when an operator prompt arrives. On the value stream map, which may fold shorter waits to fit the screen (the note under the map gives the threshold), each box holds one or more bursts, and its data box says how many.

Rework

Work done again because the first try was wrong: the stretches the evaluator labeled as defects. The map marks them with a loop arrow on the box that holds them, with how many there were and how long they took.

Timeline ladder

The square wave under a value stream map: one level for waiting, one for working, each step labeled with its duration, so it is plain how much of the lead time was waiting. A step labeled with a plus sign, such as "+5m", is the short waits folded inside the box before it. Each step opens its evidence.

Inventory triangle

On a value stream map, the triangle between two steps marks work waiting between them. On this map it marks waiting, idle time, with what it waited on; its time is waiting, not the inventory waste.

Yamazumi (stack-up)

A stacked bar per item. The classic yamazumi stacks each operator's work against takt time to balance a production line (LEI); the yamazumi-style chart here stacks each task's time by where it went, so every task's waste is comparable at a glance.

Pareto chart

Causes as bars in descending order of the time they cost, with a running total, so the vital few stand out (Pareto chart).

A3

One page that tells a problem's story from evidence to countermeasure to check, named for the sheet of paper it fits on (Shook, Managing to Learn).

Kaizen

Continuous improvement: many small changes, each checked against the evidence. Here, an improvement issue with its countermeasure.

Andon

The signal that stops the line when something is abnormal (LEI). Here, an issue raised when a release makes a quality measure clearly worse.

About the factory

Desk is a plugin that gives coding agents (Claude Code, Copilot CLI, Codex) a durable desk of tracks and tasks. The factory measures that work. The question it exists to answer: how much human attention does an accepted outcome cost, and where does the rest go? The value it cares about is an outcome a human accepted; agent time, tokens and tool calls matter only because they help explain that cost.

Designed for many desks; proven on one so far.

How this data gets here

1. A session ends. The host publishes an anonymous facts file: tool calls, failures, retries, models, tokens, subagents, time intervals, and which task it touched.
2. CI validates and merges it. Every field is checked against the published schema. No transcript text, prompt, file content or identity is ever accepted.
3. CI builds the reports. Each task's timeline is rebuilt and its report published: what happened, what mattered, what was waste, and what could not be seen.
4. An evaluator labels the waste. When a task is done, an independent agent classifies each stretch of its sessions as value-adding, necessary, or one of the eight Lean wastes, citing evidence and never grading itself.
5. Kaizen closes the loop. Evidence becomes an improvement issue naming the measure, the countermeasure and, once it ships, whether the data confirms it helped.

No who, no content, just how

• No who. No contributor, operator, account, machine, host name, desk path or branch appears in any facts file. A task is identified only by a one-way key.
• Dates and times are stated, and how precise. Facts carry durations and offsets from the session start and the task card's creation. The one calendar fact is the UTC day a task finished, never a time of day. Times inside a task sit on the task's own clock, an offset from its card's creation; pull request times come from GitHub, which already shows them. A finish day taken from a later record (the card's last update, or the day the task's labels landed) is marked "on or before". Anyone can therefore read which days the work was done. That cost was accepted on 2026-10-08: accuracy and precision outrank privacy here.
• No content. No transcript text, prompt, response, tool argument, file content, file path or task card title ever leaves the contributor's machine.
• Public references only. References to private repositories are dropped and only counted. Public pull requests and commits are, like any GitHub contribution, already public.
• Public work is named publicly. A task's name is the title of the earliest-opened of its public pull requests, by the time GitHub records it was opened, plus how many more it has. If some of its pull requests could not be read, the name comes from those that could, and the task page says so. A task with no public pull request is shown as "Private task" with a short key.
• Operator prompts are on the task's clock. Each prompt is drawn at its time on the task's clock, with how long the agent had been stopped and the size class of the prompt and of the output the operator read; never its text.
• Pull requests are on the task's clock. Each pull request that first appeared in the task's sessions is drawn at GitHub's opening time and, once merged, when it merged, from the session's own record or from GitHub's times placed through the task's clock anchor, to within seconds. A time known only in part is drawn outlined and its evidence says which way the true time lies; a pull request with no placed time is listed as "opened, time not recorded", with why, and is not drawn. A time outside the task's lead time is listed in a margin before or after the map, with how far outside it lies. Each pull request's drawer says whether the task's session opened it or only mentioned it, as Desk records; a few older records do not say, and their drawers say that.

Finish order

Tasks are ordered by the UTC day they finished, earliest first. The day comes from the first source that has one. First, Desk's record of the day the task's card moved to done or cancelled (measured), or of the card's last update (the task finished on or before it). Second, the task's clock tied to GitHub through its pull requests: measured when a pull request the session opened sets it, or when a strict majority of at least two pull requests agree within 2 minutes and none is later; when nothing confirms the pull requests it rests on, the task finished on or after the day shown; when pull requests the session opened disagree, the direction is not known. When the task's lead time ends at its last recorded work, the day is that of the last work, so the task finished on or before it. Third, the day the task's first waste labels landed in the store (the task finished on or before that day); if the pull requests put the finish after that day and the two cannot both hold, the labels' day is shown with the conflict and no direction. A task with no day is shown without one, with the reason. Tasks finished on the same day keep the order in which each task's first label file landed in the store. Tasks whose labels landed together are ordered by lead time, so the longest of them takes the latest position. Finished tasks with no day follow the dated ones, by the same rule. Open tasks come last, with the tasks whose status could not be read, in the order their first session was published. "Follow a task" opens on the latest-finished task that has something to teach and waste labels, named or private: of the finished tasks (done or cancelled) with a finish day, those with a lead time of at least an hour, at least 5 minutes of known working time, at least one work burst on its map, at least one recorded operator prompt and evaluator waste labels (so the value-adding and waste split shows), the one with the latest day. The store knows no order within a day, so tasks finished on the same day are a tie, and a tie goes to the larger lead time. If no task has all five, the label condition is dropped; if no task has the other four, it opens on the latest-finished task whose lead time is at least an hour. A note above the task says which rule chose it and why the finished tasks after it in finish order were skipped.

How to read the numbers

• A plain figure was measured. A figure marked at least 12partial was only partly measured; "at least" or "at most" says which way the true figure lies. The reason is on hover, in text for screen readers, and in the note under each table.
• "No data" is never zero. A figure shown as no data was not measured, and its reason is given beside it or once under its table. A zero appears only when zero was measured.
• Every total says what it rests on, for example "12 of 31 jobs", and a sentence beside a headline says whether its sample is thin or partial.
• "Declared" means taken from the task card, such as a task's start date written on its card, rather than measured from a session record. A task's "Every measure" table says which figures are declared.
• Two kinds of waiting. "Deliveries waiting for an answer" counts finished work the operator has not yet accepted or sent back. "Gaps between the operator's prompts" is idle time inside sessions. An evaluator-labeled pause (inside working time) is a stretch the evaluator labeled as waiting, on CI, tools or the operator; it is not the page's waiting, which is idle time.
• Accepted means the operator's word, recorded by the agent through Desk's sign-off tool.
• Bars start at zero on a stated scale. A share runs from 0 to 100%; any other bar list states its scale in its title.
• The status line under the steps has three states. Abnormal names each alarm and who is on it, or says no one is. Normal names what was checked. Not monitored says what is not recorded, so missing data never reads as normal.

For agents

Every view has a machine-readable twin. llms.txt lists every data file with its size, in the order of the walk, and marks which are small enough to read whole.

The rubric

Contribution is opt-in, asked once per machine. The measurement rubric is public and open to review: RFC section 4 and the evaluator's rubric.