SIGNAL DESK TERMINAL APP
& 24/7 MULTI-AGENT HARNESS
I'm a designer who builds. Over the last year I built an autonomous multi-agent system that runs my work around the clock — it writes code, triages my inbox, and ships pull requests while I sleep — and then designed the surface I actually use to operate it. Both halves of that sentence turned out to be hard, and the second one surprised me. Building the engine was the kind of hard I expected: architecture, constraints, a year of decisions about how a system should behave when no one is watching. But the moment it worked, a second problem appeared that I hadn't planned for. A mind that never stops is only as useful as your ability to watch it, steer it, and trust it enough to walk away. That's not an engineering problem. It's an interface problem — which means it was mine. So I designed the operator's surface three times before I got it right. Twice I reached for the familiar shapes a designer reaches for, and built them well, and abandoned them anyway. The third one is the one I keep open all day. This is the story of both: the engine, and the three attempts it took to find the right way to hold it.
[YEAR]
2024-2025
[CLIENT]
Owned Product
[TOOLS]
Figma, Claude Design
Codex, Pencil &
Claude Code
1.0
SIGNAL DESK APPLICATION
& MULTI-AGENT HARNESS
I'm a designer who builds. Over the last year I built an autonomous multi-agent system that runs my work around the clock — it writes code, triages my inbox, and ships pull requests while I sleep — and then designed the surface I actually use to operate it. Building the engine was hard in the way I expected. But the moment it worked, a second problem appeared: a mind that never stops is only as useful as your ability to watch it, steer it, and trust it enough to walk away. That's not an engineering problem. It's an interface problem — which means it was mine. I designed the operator's surface three times before I got it right.
[YEAR]
2025-2026
[CLIENT]
Own Product
[TOOLS]
Figma, Claude Design
Codex, Pencil &
Claude Code
I built the engine. Then I built the cockpit to fly it. Two hard problems — and the second one only exists because the first SUCCEEDED. THIS PRODUCT CASE STUDY DEMONSTRATES MY WORK BUILDING A CUSTOM MULTI-AGENT HARNESS AND SIGNAL DESK, A TERAX AI APP FORK I BUILT TO CONTROL IT.
[THE CHALLENGE]
A 24/7 agent system is easy to start and hard to live with. Once you have agents writing code, triaging your inbox, and shipping pull requests while you sleep, the real problem isn't capability — it's control. How do you watch a mind that never stops? How do you step in mid-thought without breaking its flow? How do you trust it enough to walk away, and stay close enough to pull it back with one word? I tried to answer that question three times. Twice as a designer reaching for the familiar shapes — a web dashboard, a desktop app. Once, finally, as a power user who lives in the terminal. The first two were well-built and wrong. The third is the one I keep open all day. This case study is about the engine that made the question urgent, and the interface that finally answered it.
MULTI-AGENT HARNESS
[BRINGING MY DREAM TO LIFE]
I wanted one thing: an executive-level partner that works while I don't. Not a chatbot I prompt and wait on, but a system that wakes up, reads my calendar, clears my inbox, picks up engineering work off a queue, and is still there in the morning with PRs to review — having recovered cleanly from any crash in between. That's the dream. The hard part is that the obvious way to build it is wrong. The industry reflex is to spin up a swarm of agents that talk to each other — a committee of bots negotiating in a shared channel. I built the opposite. Bumba is one mind with very good tools, operated by one person who can see everything it's doing and halt it with a single word. Every architectural decision below is in service of that feel.
[ZONE ARCHITECTURE]
The system is organized as four concentric rings, not a flat list of features. The shape is deliberate: the closer to the center, the more it must never fail.
Zone 1 — Core Identity. Soul, memory, operator understanding, session recovery. This is what the agent wakes up as.
Zone 2 — Personal Assistant. The cron-driven layer that runs my day — briefings, email, calendar, knowledge review.
Zone 3 — Engineering Operations. The heaviest ring, where the agent takes on its "Chief Engineer" modality.
Zone 4 — Ancillary Teams. Specialist departments, called on demand, never always-on.
Cutting across all four are floating territories — a tool registry, a deliberating Board, a cross-model reasoning layer, an autonomous issue-resolver. Rings define what's load-bearing; territories define what's shared. It reads less like an app and more like an operating system for a single agent.
[THE MAIN AGENT IS THE BRAIN, EVERYTHING ELSE IS LEVERAGE]
There is exactly one mind in this system. The main agent — Claude, running with session continuity — is the brain. Everything else is a tool it picks up, uses, and sets down. Specialists never talk to each other. There are no peer-to-peer channels, no group chat of agents reaching consensus. When a specialist needs another department, it raises a typed signal back up to its caller, and the caller decides. The call tree is flat: caller → callee → return. One mind delegating sub-computations and integrating the answers, with zero coordination overhead. This is the design decision that runs against the grain of every popular multi-agent pattern — and it's the one that makes the system feel like a single capable operator instead of a noisy room.
[AN ORG CHART WHOSE BEHAVIORS ARE MACHINE-ENFORCED]
A prompt that says "use your team" is a suggestion. I don't ship suggestions. Every department result passes through eight deterministic verification gates before it returns to the caller: non-empty output, no error or hallucination markers, valid structured output, cost within budget, duration within limit, specialist count inside its bounds. The eighth gate is my favorite — the Delegation Floor: if you built a department, the chief is required to actually use its specialists. You can't claim a team's work and do it solo. Around the gates sits the rest of the enforcement: a wiring manifest of 28 cross-subsystem connections that must report active at every boot (call a subsystem before its wire fires and you get a hard error, not a silent no-op); a single halt policy every autonomous surface honors, so one word stops everything and cancels in-flight work; per-department concurrency limits, MCP tool isolation, and a four-state cost ledger that won't let the system boot if its accounting is broken. The org chart isn't drawn in a diagram. It's enforced in code. The behaviors are mechanical, which means they're real.
[A MAIN AGENT THAT BUILDS, AND 5 DEPARTMENTS IT CALLS]
The main agent does the building. When work maps to a specialty, it calls a department. A chief plus a roster of specialists.
Strategy — product strategy, roadmaps, requirements, positioning
Design — UI/UX, visual design, design systems, accessibility
QA — test planning, automation, security, performance
Operations — infrastructure, CI/CD, deployment, monitoring
Each department is a capability the main agent reaches for, not a layer of management above it. The chief has a constrained toolset — list specialists, delegate, surface a blocker, write an artifact — and nothing else. It delegates, collects, and returns. That's the whole contract. Alongside these five sits the Board of Directors — a separate mechanism, not an on-demand department. When a decision is genuinely strategic, the Board convenes a panel of agents with distinct lenses (contrarian, compounder, systems-thinker, revenue, and more) who deliberate and vote by ranked choice. The departments build. The Board decides. Keeping those two motions separate is what keeps the system from confusing doing the work with choosing the work.
I'd built a mind that never sleeps — and the only way to watch it was to read its logs. The engine was done. The hard design problem was just beginning.
[WHERE DO I GO FROM HERE…]
The engine works. It runs continuously on a Mac mini, recovers from crashes, ships real code, and stops on command. But an engine you can't feel is an engine you don't trust — and for most of this year, the only way to feel it was to read logs. That's the problem the rest of this case study is about. I'm a designer. I couldn't leave the most interesting system I'd ever built behind a wall of text. I needed a surface.
SIGNAL DESK - A TERAX AI FORK
[BUILDING THE AGENT OPERATOR BOARD]
A pilot doesn't watch the engine through a porthole. They have a cockpit — every critical instrument in one glance, every control under their hands, no walking back to the engine room to check a gauge. That's what SignalDesk is: a cockpit for a system of agents. I built it by forking Terax, an open-source, terminal-first AI development workspace (Tauri 2, Rust, React, xterm.js). Terax was already the right substrate — fast, native, terminal-native, the place I actually work. What it didn't have was a way to see across agents. So I added one: the Agent Operator Board, an overlay that sits on top of the terminal and turns a wall of separate processes into a single, legible roster you can watch and drive. The board groups every agent by what it needs from me right now — Attention, Working, Calm, Inactive — so the question "where should I be looking?" answers itself before I ask it. Underneath, an event-streaming architecture (a local hub, a bridge per machine, server-sent events) keeps the picture live without polling. And because not every harness can do every thing, each agent advertises its own capabilities — can it take text input, stream voice, report usage? — and the interface lights up only the controls that agent actually supports. One surface, many kinds of agent, no broken buttons.
[SIGNAL DESK WALKTHROUGH]
[AN INTERFACE FOR MULTI-HARNESS INTERACTION]
I don't run one agent system. I run several — my own Bumba harness, a Hermes web agent, the coding agents Terax detects right inside its own terminal panes. Before SignalDesk, each of those was a different window, a different login, a different mental model. The Operator Board is the one place they all report to. Select any agent and you get the same four-view cockpit, regardless of what's under the hood.
[OVERVIEW]
The glance you take ten times an hour: what is this agent doing right now. Live status, capability meters, and the metadata that orients you.
[CONVERSATION]
Where watching becomes intervening. The full transcript in one lane — and a composer that targets a specific agent, and allows voice mode.
[TELEMTRY]
The honest readout of what a connection can and can't do. It makes capability negotiation visible: instead of guessing why a control is greyed out, you see which signal is missing.
[ACTIVITY FEED]
Recent history as a timeline — status, messages, commands, approvals, errors. How you reconstruct "what just happened" without scrolling the whole conversation.
[TERAX AI AGENT PROFILES]
I also themed Terax itself — the open-source app underneath, and the real star from an application standpoint. This screen is my theme on its profile builder, where you compose the agents that run inside the app.
DESIGN SYSTEM AND EXPERIMENTS
[BUILDING THE DESIGN SYSTEM]
SignalDesk is where I landed. It is not where I started. Before the cockpit, I built two other interfaces to the same engine — and the honest version of this case study is that I built them well and abandoned them anyway, because they were the wrong shape for the person using them. That person is me: a power user who lives in the terminal. Every touchpoint that pulled me out of it was, eventually, a touchpoint I stopped opening. The first attempt was a native desktop app — Bumba Desktop. It looked like what you'd expect a "command center" to look like, and that was exactly the problem. A desktop app frames the agent as something you visit. You leave your work, open the app, observe, and leave again. But operating a 24/7 agent isn't a thing you visit — it's a thing you live inside, alongside your actual work. The app became a window I had to remember to check. I deleted it when I took it out of production. It taught me the first half of the lesson: the right surface can't be a separate destination. The second attempt — Bumba Controller — went deeper and was, by any normal measure, a success. A web dashboard to monitor and drive a fleet of agent machines: a grid of harness cards, live status, inline approvals, aggregated cost, a fully tested backend behind it. It was rigorously architected and it worked. And it was still the wrong shape. A web dashboard assumes passive observation — you glance at cards and click a button. But driving an agent is active and conversational; you live in its stream, not at a distance from it. The form factor forced a modal rhythm — observe all, click one, wait for it to load, now drive — and that context-switch cost killed the flow. Worse, a dashboard is retrospective by nature: it shows you cost after it's spent, status after it changes. A terminal keeps the same information inline with the action, where it can actually change what you do next. I didn't abandon Bumba Controller because it was broken. I abandoned it because no amount of polish fixes a form factor that mismatches how the operator thinks. That was the second half of the lesson — and it's the one that pointed straight at the terminal. Across all three attempts, the visual language stayed coherent because I treated the design system as the constant and the form factor as the variable. Working with Claude as a design partner, I built the system as tokens first — palette, type, spacing, elevation expressed as variables — so a theme could move from a web dashboard to a desktop shell to a terminal overlay without being rebuilt. Restrained, near-monochrome, editorial. Almost no shadow. The discipline that let me throw away two interfaces without throwing away the look is the same discipline that made the third one feel inevitable when it arrived.
[DESKTOP APP - RAPID PROTOTYPE]
I briefly explored this as an electron desktop app. I quickly realized this was the wrong platform for adoption.
Then I explored building a web application, easier to connect to, but ultimately pivoted.
[WEB APP - RAPID PROTOTYPE]
[DESIGN SYSTEM WITH CLAUDE DESIGN]
[DESIGN FOUNDATIONS]
One warm-black elevation stack and a single rationed red carry the whole system. Meaning comes from depth, luminance, and opacity — never from adding a color.
[TYPOGRAPHY]
Two families split by role: Mulish for everything a person reads, iA Writer Mono for everything the machine measures. The split is the system's tone of voice.
[MOTION SYSTEM]
Motion is reserved for life, not decoration — a pulse and a sweep mean "happening now." Nothing moves forever unless something is genuinely alive.
[SURFACES AND NODES]
Six glass recipes, lit from the top, depth carried by shadow — never a lighter fill. The same logic makes every graph node a luminance sphere that earns its rarity.
[COMPONENTS]
Chrome that frames the graph without competing with it: glass over canvas, quiet until it has reason to speak, only the one affirmative action allowed to be solid red.
[STATE MATRIX]
Twelve states, one lever. Red is live or focus, amber needs you, green is done, recession means inert — no state ever invents a new color.
DREAMCATCHER APP CONCEPT
[NODE BASED CHAT INTERFACE]
There's one more interface in this story, and it's the most speculative — a concept I prototyped to answer a different question. Not "how do I operate my agents," but "how do I think with one without losing the thread." Every chat with an AI is linear. You go down a path, it doesn't work, you scroll back, you try again — and the structure of your own thinking collapses into one flat transcript. What you considered, what you rejected, where the strategy turned: all of it flattened. Dreamcatcher restores that structure. The conversation is a graph, not a list — a living map of nodes where every message is a place you can stand, branch from, and return to. Go down a path, and if it dead-ends, the branch dims but never disappears. Nothing is lost. You can always see where you are in the landscape of the thinking, not just what the last message said. I call the underlying idea session decision archaeology — making the shape of a decision visible after the fact, so you can learn from it instead of reconstructing it from memory.
[DREAMCATCHER WALKTHROUGH]
[DESIGNING A DREAMCATCHER]
The canvas is the interface. Nodes settle into place under a force-directed physics simulation — drag one and the graph reorganizes around it, the way thoughts rearrange when you pull on one of them. User messages and AI responses read as distinct shapes; branch points, clips, and inherited nodes each have their own. The visual language is derived from Unit, Anthropic's geometric design vocabulary — precise, near-grayscale, monospace — with color reserved to mean something: gold for selection, blue for navigation, violet for reasoning, dim gray for the paths that died. At low zoom you see only topology; lean in and the full detail resolves. The graph stays readable no matter how large the conversation grows.
[TIMELINE]
The linear reading mode for when you don't want to think in a canvas — it walks the active path root-to-here, and the next thing you type branches from wherever you tap. The bridge between the spatial model and the linear habit everyone already has.
[LONG-PRESS MENU]
Every node carries its actions — branch, inspect, copy, save, regenerate, or reveal every path out of a branch point. One small vocabulary: the same gesture everywhere, doing the obvious thing in context.
[EDUCATION MODE]
The part I'm proudest of. Select any node and Dreamcatcher teaches you from it — explain simply, go deeper, find the flaw — using the full path of context that led there. The graph becomes a tutor sitting on top of the conversation.
[EDUCATION CONTD]
"Find the flaw" earns the feature. Most chat interfaces are built to agree with you; this one hunts your idea for the hidden assumption or the place it could break — turning the transcript into something you interrogate.
[REMEMBER MODE]
Breakthroughs with an AI are usually trapped in the session that made them. Remember Mode lifts them out: save any node, path, or subgraph to a persistent Memory Shelf that survives across sessions.
[SAVING MEMORIES]
Memory here isn't an archive — it's a seed. Clip and spawn: pull a saved node off the shelf and grow a fresh session from it. The thing you figured out Tuesday becomes the start of what you build Friday — a knowledge garden instead of a graveyard of closed tabs.
5. OUTRO
[WHERE DO I GO FROM HERE…]
I set out to build an autonomous partner and discovered, somewhere in the middle, that I was really building two things at once: a system powerful enough to be worth operating, and the operator's surface that makes that power usable by a single human. The engine and the cockpit. You can't design one well without deeply understanding the other — and that, more than any individual screen, is what this project taught me.
The detours mattered. Bumba Desktop and Bumba Controller weren't failures so much as the cost of finding out what shape the answer actually had. A desktop app made the agent a place I visited. A web dashboard made me an observer of work I needed to be inside of. Both were well-built; both were wrong; and killing them is what made SignalDesk obvious. The willingness to throw away good work when it doesn't fit the user is, I think, the most underrated skill in design.
As agents get more capable, intelligence stops being the scarce thing. The scarce thing becomes one person's ability to direct a great deal of it without losing the thread. That's not an engineering problem. It's a design problem — and it's the one I intend to keep solving OVER TIME.
Where it nets out: an engine that runs 24/7 and stops on one word, a cockpit I keep open all day, and a concept — Dreamcatcher — that points at where this goes next. Because the through-line of all of it is the same conviction. As agents get more capable, the scarce thing won't be intelligence. It'll be the ability of one person to direct a great deal of it without losing the thread — to see what it's doing, trust it enough to walk away, and stay close enough to pull it back. That's an interface problem. It's a design problem. And it's the one I intend to keep solving.
I built AN engine. Then I built the cockpit to fly it. Both CHALLENGES taught me that building AN AGENT SYSTEM and operating it are two different problems.
[THE CHALLENGE]
A 24/7 agent system is easy to start and hard to live with. Once agents are shipping PRs while you sleep, the real problem isn't capability — it's control: how do you watch a mind that never stops, and trust it enough to walk away while staying close enough to pull it back with one word? I tried to answer that three times. Twice as a designer reaching for familiar shapes — a web dashboard, a desktop app. Once, finally, as a power user who lives in the terminal. The first two were well-built and wrong. The third is the one I keep open all day.
MULTI-AGENT HARNESS
[BRINGING MY DREAM TO LIFE]
I wanted an executive-level partner that works while I don't — a system that wakes up, reads my calendar, clears my inbox, picks up engineering work off a queue, and is still there in the morning with PRs to review. The obvious way to build it is wrong. The industry reflex is a swarm of agents talking to each other — a committee of bots negotiating in a shared channel. I built the opposite. Bumba is one mind with very good tools: the main agent is the brain, everything else is a tool it picks up and sets down. Specialists never talk to each other; the call tree stays flat, caller → callee → return, with zero coordination overhead. It's the decision that runs against every popular multi-agent pattern, and it's the one that makes the system feel like a single capable operator instead of a noisy room. And the org chart isn't a diagram — it's enforced in code. Every department result passes through deterministic gates before it returns, including a Delegation Floor that won't let a chief claim a team's work and do it solo. A single halt policy means one word stops everything and cancels in-flight work. The behaviors are mechanical, which means they're real. When work maps to a specialty, the main agent calls a department — Strategy, Design, QA, Operations, Job Search — built fresh, run, torn down. A separate Board of Directors convenes only for genuinely strategic calls. The departments build; the Board decides. The engine works. It runs continuously, recovers from crashes, ships real code, and stops on command. But an engine you can't feel is one you don't trust — and for most of this year, the only way to feel it was to read logs.
I'd built a mind that never sleeps — and the only way to watch it was to read its logs. The engine was done. The hard design problem was just beginning.
SIGNAL DESK - A TERAX AI FORK
[BUILDING THE AGENT OPERATOR BOARD]
A pilot doesn't watch the engine through a porthole. They have a cockpit — every instrument in one glance, every control under their hands. That's what SignalDesk is: a cockpit for a system of agents. I built it by forking Terax, an open-source, terminal-first AI workspace — already the right substrate, the place I actually work. What it lacked was a way to see across agents, so I added the Agent Operator Board: an overlay that turns a wall of separate processes into a single legible roster, grouped by what each agent needs from me right now — Attention, Working, Calm, Inactive — so "where should I be looking?" answers itself before I ask. I don't run one agent system, I run several — my Bumba harness, a web agent, the coding agents Terax detects in its own panes. The Operator Board is the one place they all report to: select any agent and get the same cockpit — overview, a conversation lane where watching becomes intervening, telemetry, an activity feed — regardless of what's under the hood.
[SIGNAL DESK WALKTHROUGH]
DESIGN SYSTEM AND EXPERIMENTS
[BUILDING THE DESIGN SYSTEM]
I didn't abandon Bumba Controller because it was broken. I abandoned it because no amount of polish fixes a form factor that mismatches how the operator thinks. That was the second half of the lesson — and it's the one that pointed straight at the terminal. Across all three attempts, the visual language stayed coherent because I treated the design system as the constant and the form factor as the variable. Working with Claude as a design partner, I built the system as tokens first — palette, type, spacing, elevation expressed as variables — so a theme could move from a web dashboard to a desktop shell to a terminal overlay without being rebuilt. Restrained, near-monochrome, editorial. Almost no shadow. The discipline that let me throw away two interfaces without throwing away the look is the same discipline that made the third one feel inevitable when it arrived.
[DESIGN SYSTEM WITH CLAUDE DESIGN]
DREAMCATCHER APP CONCEPT
[NODE BASED CHAT INTERFACE]
One more interface, the most speculative — a concept I prototyped to answer a different question: not "how do I operate my agents," but "how do I think with one without losing the thread." Every chat with an AI is linear. You go down a path, it fails, you scroll back — and the structure of your thinking collapses into one flat transcript. Dreamcatcher makes the conversation a graph, not a list: a living map of nodes where every message is a place you can stand, branch from, and return to. Dead-end a path and the branch dims but never disappears. The part I'm proudest of is Education Mode — select any node and ask it to explain simply, go deeper, or find the flaw. Most chat interfaces are built to agree with you; this one is built to stress-test your thinking. A knowledge garden instead of a graveyard of closed tabs.
[DREAMCATCHER WALKTHROUGH]
5. OUTRO
[WHERE DO I GO FROM HERE…]
I set out to build an autonomous partner and discovered I was building two things at once: a system powerful enough to be worth operating, and the operator's surface that makes that power usable by a single human. The engine and the cockpit. You can't design one well without deeply understanding the other. The detours mattered. Bumba Desktop and Bumba Controller weren't failures so much as the cost of finding out what shape the answer had — both well-built, both wrong, and killing them is what made SignalDesk obvious. The willingness to throw away good work when it doesn't fit the user is the most underrated skill in design.
As agents get more capable, intelligence stops being the scarce thing. The scarce thing becomes one person's ability to direct a great deal of it without losing the thread. That's not an engineering problem. It's a design problem — and it's the one I intend to keep solving.
Where it nets out: an engine that runs 24/7 and stops on one word, a cockpit I keep open all day, and a concept that points at where this goes next.