Multi-Agent Collaboration Invisible? Developer Monitors Claude Code with a Pixel Office

Running multiple AI coding agents at once, yet having no idea who's working and who's waiting for you—this is a real predicament many developers face. A Korean indie developer built Refmade for exactly this: a desktop app that reads the local logs of Claude Code and Codex, rendering the agent team as a pixel-art office.

The Problem: Visible Code, Invisible Team

According to the developer's own account, the problem began on September 20, 2026. He had built a personal collaboration system for Codex: 11 sub-agent definitions covering roles like PM, product, business, marketing, design, Figma, engineering, implementation, research, data analysis, and review, with the main conversation acting as team lead. The agent team existed—but he couldn't tell what any of them were doing.

When multiple agents run scattered across different terminals, there's almost no reliable answer to "who's handling what task, and who's waiting on my reply." So he had Codex build an "office" dashboard: each task is a floor, showing each person's current work, next steps, waiting items, meetings, and records. This became the precursor to Refmade.

Multi-agent collaboration typically follows a "master-slave" or "orchestrator-worker" pattern: a main conversation (or supervisor agent) breaks down tasks, assigns roles, and aggregates results, while several sub-agents each take on functions like PM, design, or engineering. This pattern can push many workstreams forward in parallel, but it introduces an observability gap: each sub-agent tends to run in its own session or terminal, with no shared real-time state bus between them. When a task spans multiple agents, it's hard for the human lead to judge overall progress from commits or chat logs—let alone distinguish between three very different kinds of pause: "thinking," "waiting for a tool to return," and "waiting for my input."

Version One: Pixel Art Succeeded, Data Model Failed

Launched on September 21, the v1 office ran locally on Mac at 127.0.0.1:4318, offering a password-protected, read-only remote view via a quick tunnel, refreshing every 5 seconds. The pixel art included floors, shelves, and 12 seated characters, drawn with GPT Image; it passed 25 Python tests and 16 Node auth/deployment tests.

The problem was the data source. V1 required each agent to actively log its own state: a recording script wrote status reports to a file, and the dashboard rendered from that. But an agent in the middle of a long task has no reason to stop and jot down a status note. Skip the report, and the workstation sits empty—and an empty floor looks like an entire team idling. The dashboard couldn't distinguish "no one is working" from "no one reported in."

The lesson the developer drew is blunt: a dashboard that depends on the observed system describing itself will fail precisely at the moment you most need it to be accurate. Anything you can read without the agent's cooperation is more trustworthy than what the agent volunteers.

The "data model" here refers to the abstract structure the dashboard uses to describe agent state: who's working, on what, and waiting on whom. V1 used a "push" model—monitored agents wrote state files themselves, and the dashboard merely rendered them. The flaw is that update frequency depends entirely on agent cooperation, not on the real rhythm of work. A more robust approach is a "pull" or "observation" model: the monitor periodically reads traces that don't depend on the observed party writing anything—logs, processes, file locks, or API call records. The key difference: a push model loses state most easily when the system is busiest, while a pull model only delays—it never vanishes into thin air.

The Pivot: Read Local Logs Directly

On September 25, he concluded the approach itself was wrong. Later versions switched to reading state from the session logs that Claude Code and Codex already write to local disk, rather than waiting on agents to report in.

The current version (0.3.9 on Mac) renders the team from local logs, session by session. Public demo data shows three team cards: a "Community Workshop" area run by Claude is pushing forward homepage booking UI improvements with 2 art members; Codex's "Spring Café" area has two teams, one handling new menu promotion and the other replying to customer inquiries—the latter marked "waiting for your answer." This kind of waiting state is exactly what the original approach struggled to capture.

As terminal-based AI coding agents, Claude Code and Codex typically write full sessions to local disk in structured format (often JSONL), under paths like ~/.claude/projects/ or ~/.codex/sessions/. These logs were originally meant for session recovery and context rebuilding, containing every message, tool call, execution result, and timestamp—so they can be passively parsed to infer whether an agent is currently generating code, waiting for a tool to return, or sitting idle waiting for user input. Compared to having agents self-report, reading such logs has the advantage of zero intrusion: it doesn't change agent behavior, doesn't add burden, and doesn't rely on the agent "remembering" to report. The trade-off, of course, is that log formats may change across versions, parsing logic needs maintenance, and paths differ substantially across platforms.

The Name Came from an Abandoned Project

The name Refmade predates the app itself. Between March and July 2026, Refmade was a web design reference directory product: a Next.js app, roughly 83 references, 131 commits, and payment integration. On August 7, while cleaning up hosting accounts, he cut 29 projects down to 12; the old Refmade survived only because it was bound to a custom domain. On September 21, that domain was pointed at the new office dashboard. Not a single line of the gallery code remains—only the name, and a domain kept by accident.

Status and What's Next

Refmade currently runs on Mac (Apple Silicon) and Windows, free to use, provided Claude Code or Codex is installed and signed in locally. The developer says this series spans 16 articles, one every two days, following real events in order—failures get as much space as launches. Upcoming pieces will cover runaway product plans, shipping a Mac app without notarization, and a long-overdue first Git commit. The app link goes in the final article of the series.

For developers running agents across multiple terminals, a question worth asking yourself: what do you currently rely on to know which agent is stuck waiting for you?

The Apple Silicon mentioned here refers to Apple's in-house ARM-architecture chips (the M series). It differs from traditional Intel Macs in runtime environment, binary compatibility, and some system APIs, so desktop apps usually need to be adapted separately. Shipping without notarization refers to macOS's Gatekeeper mechanism: apps that haven't been notarized by Apple are blocked by the system on first launch, requiring manual bypass. For indie developers, the notarization process involves a developer account, signing, and upload review—not a small hurdle. That's why this series devotes a separate article to "shipping a Mac app without notarization."

One-line Summary

A Korean indie developer built Refmade, which reads local logs to render an AI coding agent team as a pixel office.

Paragraph Summary

Refmade is a desktop app that reads the local session logs of Claude Code and Codex, rendering multiple AI coding agents' work states as a pixel office, so developers can see at a glance who's working and who's waiting for a reply. Its first version required agents to actively report state, which failed frequently on long tasks: when an agent didn't write a status, the workstation went blank—and a blank couldn't distinguish "not working" from "not reported." The developer pivoted to reading local logs directly, avoiding reliance on the observed system's self-description. The app runs free on Mac and Windows, inheriting its name from an abandoned web design directory project that survived deletion thanks to a bound domain.