The manager, without a terminal

Work in progress. My manager agent and its overview are moving into the Claude desktop app, for people who never open a terminal: only what needs me, most urgent first, beside the chat. What it looks like so far, what the app taught me, and what is still wrong.

In the last note my manager agent got a pane beside its chat in the terminal: the one thing to do next, which sessions are waiting on me, the approvals only I can give. This one is a work in progress. The same manager, and the same overview, are moving into the Claude desktop app.

Nothing here is released. The pictures come from a virtual machine running a made-up studio, with invented projects, sessions, people and posts.

Why the app

I am used to the terminal. Most people who might want a manager for their agents are not. Many of them will open Claude Code in the desktop app first and never see a terminal at all. If the method only works in a terminal, it is not for them.

So the goal for the next version is easy to say: what the manager does in the terminal, it does in the app as well, and whatever starts in the app stays in the app. No terminal window opens along the way.

What it looks like

The manager’s conversation stays on the left. Beside it, in the app’s right-hand panel, is the overview. Its first tab puts things in order of urgency:

Needs you. What waits for my yes: an approval a session is holding, a post queued to go out. A post opens beside its full text, with Approve and send, Reject, and a Snooze for later.
Next up. The one item the manager would take first, and why. If the session that needs it is not running, a button to start it.
Dates and Coming. What falls due and how far ahead, and the decisions still open. A few quiet rows each.
Sessions. Which are working, which are idle, which are waiting for me, with a Start button beside each one that is not running.

The other tabs hold the long lists: every open decision with its options, the queued messages, the day’s summary and all the dates.

The overview's first tab in the Claude desktop app, dark theme. A highlighted Needs you card with one queued post to a Discord channel. Below it the post's full text with Approve and send, Reject and Snooze buttons; Next up, an approval with a button to start the session that holds it, marked as not running; and a list of dates with how many days away each is. — The overview's first tab, on a made-up studio. "The Steward" is the manager's default name in the kit; nothing in the picture is real.

Above the input box sits a band, always in sight where I type: how many things need me and what the next one is, with Review, Refresh and Details. The band never approves anything. Nothing goes out without my yes, given where it happens.

A band above the app's input box reading: 1 needs you, a post to #announcements, with Review, Refresh and Details buttons. — The band above the input box.

A decision comes to me once, with its options. I pick one or write a note, and Send hands it all to the manager as one message.

The To decide tab, filtered to all projects. Four open items, each with a short explanation and a note field with a Send button. The first asks for a choice between two licences, MIT or Apache 2.0, as two buttons; another has a Mark done button. — To decide, on the same made-up studio.

It uses the app’s own fonts and colours, in light and dark, with colour only where it means something: one accent for what needs me, a warning tone for a session that is blocked or not running. No theme and no charts. It should look like part of the app, not something bolted on.

The whole idea fits in one line: only what needs me, most urgent first.

The first version read like a log

The first build in the app worked. Every section was there, in the right order, and it followed the app’s light and dark themes. My own verdict on 28 October: it read as a native part of the app, and it read as something that annoys you. Another log you learn to ignore.

So I set a bar before anything else was built. Order by urgency. One line per item, details folded away, one clear action. Every item once. Colour as meaning. Space between sections. And a three-second test: at a glance, can I say what needs me and what to press?

I had two layouts drawn against that bar in the virtual machine: an inbox, and a single focus card that steps through the items one at a time. The focus card showed the first item well and hid the second behind a Next button. I picked the inbox.

The app has rules of its own

It starts a session only on my own words. The overview has a Start button for a session that is not running. In the first version the button sent the manager a request, and the manager asked the app to start the session. The app refused (28 October, 17:13): a press in a mod counts as an automated event, and the app starts a new session only when the user asks in their own words. The app was right. Now the button writes the request into my input box, and I press Enter. The words are mine, and at 17:28 the same day the session started inside the app, with no terminal window.

Sessions the manager starts sit under it. In the app’s sidebar, a session my manager started is nested under the manager’s conversation; one I start by hand gets its own group. I like the nesting.

A scheduled check is a session nobody is watching. The app can run a task on a schedule, which suits the manager’s checks: raise a follow-up once its date has passed, list the dates of the coming fortnight. When the manager in the demo was asked for one, the app saved it in Auto mode, because the conversation was in Auto mode. A scheduled run starts a fresh session that no one is looking at. So the manager now says which mode a check will run in before it creates it, recommends Manual, and keeps it paused until I choose.

Where it stands

In the virtual machine since 28 October: the overview, the Start button, a scheduled check and the manager’s instructions for the app, each run on the made-up studio. The pictures above are from the build in progress, taken there on 29 October.
In my own app since the evening of 28 October, on my real records. On 29 October the build running there was the twelfth development build, installed at 19:12.
The overview had 31 tests at the end of 27 October. The twelfth build has 205, and every new rule is broken on purpose once to see a test fail.
The terminal keeps its pane, as before. One codebase draws both.

It goes into the guide’s kit as its next version when it is ready. There is no date yet.

The uncomfortable part

I am not sure it is my way of working. I am used to the terminal. I am using the app version anyway, because that is where most people who might want this will start, and I will not find what is wrong with it until I live in it.
The app knows when a session is waiting. The overview does not. That state never reaches a mod. The overview knows a session waits for me only when the session says so, in the message every session sends when it stops for me. A session that forgets looks idle.
The Start button is one more press. By design it cannot start anything itself. It writes; I send.
Notifications to my phone need Remote Control. A notice from the app reaches my phone only with Remote Control switched on, so a manager that wants to tap me on the shoulder away from the desk needs it.
A new conversation opens in the last folder used, not necessarily the one I meant. The first thing to check in a new conversation is its folder.
A confirmation that never went away. After I approved a post, its “Sent” line stayed on the overview for good. The twelfth build shows it for ten minutes and then lets it go. Real use finds what tests do not.
Still on the list, not built: a focus mode, where I tell the manager what I am working on and every other session pauses and keeps quiet until I am done. It has no design yet.

The method behind the manager is written up as a guide with a working kit, One Manager, Many Agents: on Gumroad, with more about it on its page here.