Case Study 05
AI Workflow Supervisor
A custom internal tool for managing concurrent Claude Code sessions, built without writing a line of code
The Problem
Running Claude Code at any real scale means running multiple sessions at once. Different projects, different tasks, different states of completion. It's the natural working pattern for anyone using AI across more than one engagement at a time. The moment you have five or six sessions open, a problem emerges that general-purpose terminal tools weren't designed to solve.
Each Claude Code session is isolated. You open a terminal, start a session, give it a task, and wait. While it works, the terminal is occupied. Running another session means opening another window. Checking on the first one means clicking back to it. With six sessions running across six projects, that's constant tab-switching with no visual shorthand for what's happening where. There's no indicator of which sessions are working and which have finished, short of clicking into each one.
When Claude finishes, there's no notification. The terminal returns to a prompt, silently. If you've moved on to something else, you might not notice for minutes. Multiply that across several sessions and the overhead becomes real. Sessions go unchecked, projects fall behind, and the workflow starts requiring more active management than the work itself.
Session state adds another layer. Quit Terminal.app or iTerm2 and everything is gone. No record of what was running, what project it belonged to, or what the session was named. The next launch starts blank. Standard terminals solve the window proliferation problem adequately for most command-line work. They don't solve it for AI-assisted workflows where sessions need to be tracked by project, need to survive restarts as at least partial context, and need some visual indicator of status that doesn't require clicking through each window to find out.
The System
MTS is a native macOS desktop application built on Electron, xterm.js, and node-pty. Every session runs a real /bin/zsh pseudo-terminal with full shell support, scrollback, and correct cursor handling. All sessions run simultaneously in the background. The interface has three panes: a collapsible file browser on the left, the active terminal in the centre, and a right column split between the session list above and the project navigator below.
Component 01
Session Management
Create as many sessions as needed. Each runs independently in the background, regardless of which one is visible. Click a session name to bring it forward; the others keep running. Double-click a name to rename it. When you quit, MTS counts the open sessions and asks before closing.
Component 02
Status Indicators
When Claude Code finishes in a background session, a solid orange dot appears next to that session's name. No blinking, no timers. The dot clears two seconds after switching to the session. A glance at the session list shows exactly which sessions have finished and are waiting for input. This feature doesn't exist in any other terminal tool.
Component 03
Session Persistence
When you quit MTS, each session's metadata writes to ~/.mts/sessions.json. On relaunch, the full session list comes back: names, project directories, and positions. Sessions whose processes ended on quit appear as disconnected. Click one and MTS spawns a fresh shell in the saved project directory.
Component 04
Project Navigator
The bottom of the right column scans the projects root directory and lists everything it finds. Four sort modes: A-Z, Z-A, Most Recent, Oldest. The root is pinned at the top. Right-click any project to open a new session in that directory immediately. Cmd+Up and Cmd+Down move through the list from the keyboard.
Component 05
Session Grouping
Sessions are organised under their project with collapsible headers for each group. Sessions can be reordered within their group by drag-and-drop. When you change directory in a terminal, MTS reads the new working directory and moves the session to the correct project group in real time, visible the moment the cd completes.
Component 06
File Browser + Drag-and-Drop
The left pane shows the directory tree for the active session's project. Clicking a file opens it in read-only view. The browser switches automatically when you switch sessions. Cmd+B toggles it. Drop any file or folder onto the terminal and the path is shell-escaped and inserted at the cursor, with no formatting issues.
Component 07
Keyboard Navigation + Layout Persistence
Cmd+N opens a new session in the selected project. Cmd+W closes the current session. Cmd+Left and Cmd+Right move between sessions with wraparound. Cmd+1 through Cmd+9 jump directly to a session by index. All pane dimensions save to ~/.mts/settings.json on every resize and restore on launch.
Many AI implementation roles describe this intake process explicitly: interview the team, map their workflow, find where things break down, and build or direct the solution. The solution might be a prompt system, an automation, or a custom internal tool that doesn't exist off the shelf. This case study is that same process, applied to a real workflow: observed directly, diagnosed precisely, specced, and shipped. The tool is in active daily use. The intake pattern transfers directly to any team.
Key Architectural Decisions
Two decisions defined how the system actually works. Neither came from upfront design. Both emerged from a specific failure caught during use, diagnosed precisely, and fixed with a minimal targeted solution.
Done detection
The first design used a regex to match the shell prompt character ($, %, >). It failed immediately. Claude Code uses a TUI interface with ANSI cursor-move sequences, not newlines, and the residual escape codes corrupted every pattern match. The prompt couldn't be distinguished from noise.
The replacement was a three-second silence window. After output started, the session would stay "working" until three consecutive seconds passed with no new output. This worked in testing but wasn't stable across response timing variations. The Enter-key detection that gated the timeout introduced its own edge cases, and getting the dot behaviour consistent across session switches required several rounds of fixes.
The final design doesn't use timers at all. Every Claude Code response ends with a timing string: the verb changes session to session (sauteed, cooked, etc.) but the pattern is constant: "for Xs" or "for Xm Xs". Matching that pattern in stripped PTY output detects completion reliably. No timers, no Enter-key tracking, none of the side effects. A solid orange dot appears on completion in background sessions and clears two seconds after the user switches.
Live CWD tracking
The original architecture ruled out CWD tracking. Sessions open in a project directory; that directory was meant to be fixed at creation. The reasoning was correct for the intended use pattern and wrong for actual use.
In practice, users change directories in the shell before launching Claude Code. A session created in career_ai/ after a cd into a subdirectory appeared under the wrong project group, with no way to move it. The fix added a get-session-cwd IPC handler that uses lsof to read the PTY shell's actual working directory from the OS. When the detected project differs from the session's current group, the session moves in the sidebar immediately. The re-grouping is live and visible the moment the cd completes.
The So What
The process that produced MTS is what most AI implementation roles describe when they ask candidates to identify friction in a team's workflow. Observe how people actually work. Find the specific points where things slow down, break down, or require more active management than they should. Research what's available off the shelf. Define what's missing. Spec it. Direct the build. The output here is a native desktop application. In another engagement, it's a different solution type. The intake and delivery pattern doesn't change.
The other case studies in this portfolio document AI systems built for specific domains: content production, job evaluation, curriculum planning, knowledge management. MTS extends the same methodology to a different class of output. A native desktop application with real session management, system-level process tracking, and hardware-level dependencies sits closer to the operating system than a web app and is less forgiving when something fails. The methodology that produced it is identical to what produced everything else here.
Every architectural problem in this build was found during actual use, not anticipated upfront. Each one was diagnosed precisely, fixed minimally, and the build moved forward. That pattern — failure, diagnosis, minimum targeted solution — ran consistently across every component. It's the same pattern that runs across every case study in this portfolio, and it's what separates a delivered system from an abandoned prototype.
Without a background in software development and without writing a line of code, he observed a workflow problem, defined it precisely, and directed a complete build from specification through architecture, testing, failure-driven revision, and packaging. The result is approximately 2,300 lines of custom code across 11 modules, a feature set that doesn't exist in any terminal application currently shipping, and a tool in active daily use. The same intake process is available for your team.