Saggar and functional elegance

I recently put a name to a kind of product design I care about: functional elegance. It means putting care into design where that care materially helps the user, without adding ornament that competes with the job.

Saggar is the clearest example I’ve built.

Saggar is a terminal manager for people working across projects and coding agents. A normal terminal gives you plenty of control, but almost no help managing what happens once several long-running sessions compete for your attention. Saggar has strong opinions about that problem and stays flexible about almost everything else.

That boundary is the product.

The project is the unit

Most terminals organize work as tabs and windows. Saggar organizes it by project, with terminals nested underneath.

That opinion gives the rest of the product something solid to build on. A terminal inherits its working directory, commands, notes, Git state, and history from the project around it. Close the app, come back later, and the same working context is there. A terminal without a project is still allowed, but it is the exception rather than the organizing principle.

The distinction is useful because a project is usually what I’m trying to move forward. The terminals are temporary instruments inside it. Treating them as peers makes the interface technically neutral while leaving me to reconstruct the relationship every time I look at it.

Saggar holds the opinion where it has useful knowledge, then lets me rename the project, choose its icon, change its IDE, configure its commands, or use an ordinary unassigned shell when the model doesn’t fit.

Attention has a shape

Saggar asks one question: which terminal needs me right now?

Each session is classified as Needs you, Working, Idle, Finished, or Failed. Those states roll up to the project, so a folded project can still tell me that one agent is waiting while two are working. Quiet projects fold away, active work stays visible, and ⌘J walks the queue of sessions that need attention.

This is deliberately opinionated. Creation order is easy for software to display, but it has little relationship to what matters now. Saggar chooses urgency and recency instead.

It also knows when to loosen its grip. I can unfold a quiet project and Saggar leaves it alone. I can dismiss an attention claim, change notification behavior, or ignore the queue and pick any terminal directly. The product proposes an order without turning that order into a cage.

Different work deserves different containers

Terminals tend to treat every command alike, even though their lifetimes are completely different. Saggar gives common shapes a home:

• A Quick Run runs a command in a temporary panel, then folds away when it succeeds.
• A monitor stays visible because its output matters over time.
• Run next queues work behind the current terminal, ready to start when it closes.
• A normal terminal remains a normal terminal, with no extra ceremony.

The monitor and Quick Run windows are the most obvious examples. It would be easy to dismiss them as terminals in prettier boxes, a bit of UI flourish around the same old interaction. In practice, they change the interaction completely.

A Quick Run opens over the corner of the workspace, runs in the current terminal’s exact directory, and never takes focus or moves the selection. It lets me run git pull, a test, or some other one-off command without opening a terminal, arranging it, waiting, reading the result, and closing it again. Success appears for long enough to read, then the window folds itself away. Failure stays as a live prompt I can click into and continue using. The interface encodes the likely lifecycle while preserving the full terminal when the guess is wrong.

The monitor window makes the opposite judgment. Some commands matter because they keep running: a development server, a test watcher, a log stream, or a deployment. Putting one in the main terminal gives background work the foreground. Hiding it in another tab makes it too easy to forget. The monitor stays at the edge of the workspace, visible enough to read and separate enough not to interrupt. It can collapse without stopping, retaining its status while giving the space back.

These are new ways of presenting a terminal because they assign meaning to its place and behavior. The window tells me whether this work is passing through, staying for observation, or asking to become the main task. This goes beyond visual polish by removing the repeated management that ordinary terminal windows leave to the user.

The useful opinion is not that Saggar knows what every command means. It only knows enough about how I intend to use the command to present it properly. I choose the command and the container, and Saggar handles the routine behavior after that.

The boundaries remain porous. A Quick Run can become an ordinary terminal. A monitor can collapse without stopping. Either can move into a split or its own window. The default saves work, while the escape hatch keeps an unusual case from becoming a fight.

Small details should do a job

Saggar contains plenty of small design details, but the ones I like most earn their place. Hovering over a file path previews the file, folder, or image without pulling me out of the terminal. Resting on another terminal shows its latest output without switching to it. Holding ⌘ briefly labels the available shortcuts, then the labels disappear when they’re no longer useful.

Even ⌘Q is hold-to-quit. A quick tap does nothing, while holding it shows what is still running before the app closes. That interaction is slightly unusual because the ordinary behavior is dangerous in a terminal managing live work. The opinion is narrow, visible, and easy to understand.

None of these details exists only to make Saggar feel polished. Each removes a context switch, prevents a mistake, or makes hidden state legible. They make the product nicer by making it work better.

Where Saggar gives control back

The terminal itself is still a terminal. Saggar doesn’t invent a new way to run commands, hide the shell, or require work to pass through its own abstractions. Projects can define shared commands, but nothing starts merely because a repository asks it to. The user presses the button.

That is the line I keep returning to. Saggar is strongly opinionated about context, attention, and the presentation of work because those are the problems it exists to solve. It is deliberately flexible about what work you run, how your project is structured, and which tools you use inside it because the user knows more about those things than Saggar ever will.

Functional elegance isn’t a lack of options or a taste for minimal interfaces. It is the harder judgment of deciding which choices the product should make, which belong to the user, and how gracefully control passes between them. Saggar is my attempt to draw that boundary well.