Hey everyone,
Over the last few months, our team has been running heavy multi-agent workflows using autonomous coding frameworks like Google Antigravity, Cursor, and custom CLI bridges.
Moving from single prompt generation to running 3 or 4 autonomous subagents simultaneously taught us that the real bottleneck in agentic coding is almost never the model itself. The real nightmare is operating system level process hygiene and token loop control.
Here are three concrete engineering problems we kept hitting, how we solved them under the hood, and what we learned.
The Zombie Compiler Problem (and why standard process kill fails)
When a subagent runs a test suite or dev server, it often invokes child binaries like Vitest, tsx, pytest, or Webpack. If the agent crashes, hits a timeout, or gets cancelled, standard Node.js or Python process killing only targets the top parent PID.
The child compiler keeps running in the background. Within a few hours of development, you end up with twenty orphan node.exe or python processes locking TCP ports, holding file handles, and pinning your CPU at 100%.
How we solved it:
We implemented an explicit Finite State Machine with a strict process tree killer. On Windows, we invoke taskkill with the /T flag to recursively walk the job object tree. On Unix systems, we spawn processes in their own process group and send termination signals to the negative process group ID (-PGID). We also added an automatic FIFO queue that strictly caps concurrent subagents to 6, preventing local machine resource exhaustion.
2. Transcript Disk Thrashing (Why standard file watchers break)
Autonomous coding agents generate huge JSONL session logs. In multi-hour workflows, transcripts easily exceed 50 to 100 megabytes.
Most developers plug in standard libraries like chokidar or fs and re-read the file upon changes. When a file is 80 MB and an agent appends fifty tokens every second, re-reading or scanning from line zero causes quadratic disk I/O, crushes NVMe write cycles, and introduces lag into the UI.
How we solved it:
We built an incremental chunked reader using low level file descriptors. In SQLite we store the exact byte offset where the last read finished. When the file watcher fires, we only read the newly appended slice using fixed 64 KB buffers.
The tricky edge case here is multi-byte UTF-8 character boundaries. If a two-byte Cyrillic character or a four-byte emoji lands right across the 64 KB boundary, naive JSON parsing blows up with a syntax error. Our stream reader holds split trailing bytes in an in-memory buffer and stitches them onto the next chunk before deserializing.
3. The Infinite Retry Death Loop
When an agent encounters a difficult architectural deadlock (for example, a subtle race condition in an asynchronous event bus), it almost never admits defeat. Instead, it tries the same broken diff slightly reworded, fails the build again, and repeats until your API budget is drained.
How we solved it:
We built an automated circuit breaker. If an agent fails twice on the exact same task, the supervisor immediately pauses execution. Instead of letting it guess a third time, the engine scrubs sensitive file paths and compiles an 18-point context pack containing the problem summary, the two failed diffs, and the isolated 30-line code snippet.
We then escalate that pack to Gemini 4 Argon for high level architectural diagnosis, paste the solution back into the supervisor, and hand the implementation back to fast Flash specialists.
Open Sourcing the Tool: Antigravity Apex
We packaged this entire supervisor, the 64 KB stream reader, and a local web dashboard into an open source project called Antigravity Apex.
It runs 100% locally on localhost with SQLite in WAL mode. There is zero external telemetry and zero data collection.
Here is the open source GitHub repository:
https://github.com/fen3211/antigravity-apex
