When you run a single AI coding agent, the engineering challenge is making it useful. When you run 300 concurrently, the engineering challenge is making them observable. Control is an illusion at that scale — you can't review 300 diffs, approve 300 PRs, or debug 300 concurrent sessions. What you can do is build a system that tells you what's happening, flags anomalies, and lets you intervene where it matters.
ShareCLI is a Rust runtime for observing and coordinating concurrent AI agents. It provides process-level visibility, FUSE-backed virtual views, thermal pressure monitoring, and structured session recording. It doesn't control the agents — it makes their behavior visible.
The observation problem
AI coding agents are processes. They consume CPU, memory, and GPU resources. They make API calls, write files, run tests, and produce diffs. At 300 concurrent agents, the aggregate behavior is complex enough that individual agent debugging is impractical. You need system-level observability.
ShareCLI's approach is to instrument at the process level. It observes process state (running, sleeping, waiting), resource consumption (CPU, memory, thermal pressure), and output artifacts (files changed, tests run, diffs produced). This data feeds into structured session records that can be queried after the fact.
The key insight is that observation should be passive. The act of observing shouldn't change the agent's behavior. ShareCLI reads process state from the kernel's proc interface, reads file system events from inotify, and reads API traffic from network-level instrumentation. None of this requires injecting code into the agent processes.
FUSE as a design surface
One of ShareCLI's more unusual features is its FUSE-backed virtual views. A FUSE filesystem is a filesystem implemented in userspace — the kernel forwards filesystem operations to your code, and your code responds with data. This lets you present a virtual filesystem that aggregates data from multiple sources.
ShareCLI uses FUSE to present a unified view of all agent sessions. The virtual filesystem exposes session state, diffs, test results, and resource consumption as files. You can navigate this view with standard tools — ls, cat, grep — without learning a new interface. The virtual filesystem is read-only, so it can't accidentally modify agent state.
The design trade-off is complexity. FUSE is a kernel interface with strict correctness requirements. A bug in the FUSE handler can hang the entire filesystem. ShareCLI's handler is deliberately simple — it reads from pre-computed indexes and returns data directly, with no mutable state and no blocking operations.
Thermal awareness
When you run hundreds of concurrent processes on Apple Silicon, thermal pressure becomes a real constraint. The CPU throttles under sustained load, and the throttle behavior is non-obvious: it's not a simple temperature threshold, it's a power-envelope model that considers sustained power draw, instantaneous power, and thermal dissipation.
ShareCLI monitors thermal pressure through the powermetrics interface and adjusts its scheduling recommendations. When thermal pressure is high it suggests deferring non-urgent agents and prioritizing the ones closest to completion. This isn't forced throttling — it's visibility: the human operator decides, with thermal data in hand.
What we built for ourselves
ShareCLI grew out of a practical need: running multi-repo engineering work across multiple harnesses at once. Each harness (Jcode, Codex, ForgeCode) manages its own agents, but nothing gave a unified view across all of them. ShareCLI provides that view.
The structured session recording is the most valuable feature for our workflow. Every agent session produces a record with timestamps, file changes, test results, and resource consumption. When something goes wrong — a test failure, a merge conflict, a resource exhaustion — the session record provides the evidence needed to diagnose the issue without reproducing it.
The durable lesson
The durable lesson from ShareCLI is that observability is the engineering discipline that scales. Control doesn't scale — you can't manually manage 300 agents. Automation doesn't fully scale — you can't anticipate every failure mode. But observation scales because it provides the information needed for both human judgment and automated responses.
Build systems that show you what's happening. The decisions about what to do about it can come from humans, from automation, or from both. But the visibility has to be there first.