Subsystem

Part 2 of 6 Working through your agent

Filing work, and what can be started

By the end of this chapter the website rebuild has real work in it, one task is waiting on another because it genuinely is, and your agent can answer what can I actually start with something better than a list of everything.

You will not type a single command in this chapter. You are describing work; your agent is filing it.

The work so far

The commands of Install it, and tell your agent and Watch it happen: Subroutine installed, a project, an account for the agent, and two tasks filed by asking.

$ uv tool install subroutine
Resolved … packages in …
Prepared … packages in …
Installed … packages in …
…
Installed 2 executables: subr, subroutine
$ subroutine init
Ready. Try: subroutine add "something to do"
$ subroutine project create web "Website rebuild"
Created web … Website rebuild
  Tip: subroutine add "something to do +web"
$ subroutine agent create claude --profile worker --project web --store
Created service account claude, with the contributor role.

  sr_…
…
$ subroutine add "Write the copy for the home page +web"
Added: Write the copy for the home page  (read +web)
  Tip: subroutine agenda
$ subroutine add "Choose a typeface for the headings by Tuesday +web"
Added: Choose a typeface for the headings  (due Tue 6 Oct)  (read +web)
  Tip: subroutine agenda
{
  "mcpServers": {
    "subroutine": {
      "command": "subroutine",
      "args": ["mcp"]
    }
  }
}

Describe the work, not the ticket

Tell your agent what the week holds. It writes each one as a line Subroutine reads:

subroutine_add(text="Agree the new navigation +web")
…
subroutine_add(text="Build the new navigation +web ~1d")
…
subroutine_add(text="Audit the third-party scripts +web !3/2")
…

Four things are happening in those lines, and none of them is a field you filled in.

+web files it in the project. A project has to exist before work can go in it, which makes it the one part of the line that can be refused: a tag is a label and invents itself, a project is structure.

~1d is an estimate and !3/2 is importance and then urgency. Those last two are asked separately on purpose. Importance is about the work and urgency is about the clock, and a list that mixes them cannot tell a thing that matters and can wait from a thing that is trivial and due tomorrow. You will do both this week; you should not do them in the same order.

Neither is a deadline. A deadline is a date and it goes in the sentence, as by Tuesday did in the last chapter.

One thing waits on another

Building the navigation before anybody has agreed what it is would be a week thrown away. Your agent can say so:

subroutine_link(ref=3, type="blocks", other=4)
…

That is a fact about the work, not a preference, which is what makes it worth writing down. A priority says what you would rather do. A blocker says what is not possible yet, and only one of those is an opinion.

What can be started

Now the question that a list of tasks cannot answer:

subroutine_list(ready=true)
…

Building the navigation is not in that answer, because it cannot be started. That is the difference between what can I pick up now and what is on my plate, and it is exactly the work somebody would otherwise start and then abandon.

The other half is free: a list that knows what is blocked also knows what is blocking. Agreeing the navigation is not the most important task by any measure you set, and it is the one to do first, because something else is waiting on it.

subroutine_show(ref=4)
…

The count of blockers done is what you want when three things are holding something up and two of them have landed.

A claim, before it starts

Ask your agent to pick something up, and it takes the work before it touches anything:

subroutine_claim(ref=3)
…

A claim and a status are two different facts and both are worth saying. The claim says somebody has this right now, so ready stops offering it to anybody else. The status says work has begun, which is not the same thing: an agent may claim an item in order to read it and decide it is not for them.

subroutine_update(ref=3, status="in_progress")
…

A claim is a lease rather than a lock. Every write to something an agent holds pushes it out, so an agent that is working never has to think about it, and an agent that stopped stops renewing. Nothing is stranded when a session ends, which it will: the claim expires and the next one can take it.

Finishing hands it back with the work, so there is no separate step at the end:

subroutine_done(ref=3)
…

And the thing that was waiting is now the thing you can do:

subroutine_list(ready=true)
…

Nobody moved it. The blocker finished, so the work behind it became startable, and the next agent to ask what can I start is told.

That is the whole of it: you described a week's work in ordinary sentences, and what came back was an ordered answer to a question you would otherwise have had to hold in your head. The next chapter is about the other half of what stays beside the work: not what to do, but what you decided and why.