Context Compaction in Antigravity: The Delicate Balance Between Token Optimization and Determinism in Low-Level Workflows

First off, a huge shout-out to the teams behind Antigravity and Gemini. The ability to handle long, multi-turn pair-programming sessions with autonomous tool-calling has drastically changed how we build complex systems.

However, spending hundreds of hours building deep, mission-critical systems exposes an edge case that is rarely discussed in mainstream tutorials: Context Compaction (sliding-window summarization) and how it affects deterministic, low-level engineering.

There is a fundamental divide in AI-assisted coding:

  1. Permissive / High-Level Coding (Web, UI, Declarative Scripting): A minor semantic drift, an approximate refactoring, or a slightly different utility function is usually forgiven by the runtime or caught visually in seconds.
  2. Deterministic / Mission-Critical Engineering (Embedded, Automotive, Low-Level Protocols, Binary Parsing): Every single byte, bitwise mask, struct alignment, and timing constraint is non-negotiable. An approximation of 1 bit or 1 byte does not result in a minor styling quirk; it locks an ECU, bricks a microcontroller, or drops a CAN bus communication.

In these environments, context compaction can unexpectedly turn from a token-saving feature into an engine of silent regression. Here is an analysis of why it happens, a real-world case study, how we currently mitigate it, and a humble feature proposal for the Antigravity team.

The Mechanics: The “Time-Warp” Effect & The Tool-Calling Urge

When a conversation grows long, the orchestrator naturally compresses earlier turns into a generated summary to stay within optimal context windows. While mathematically sound for token economy, this introduces two systemic behavioral issues:

A. The Chronological Flattening (“Time-Warp”)

Summarization algorithms inevitably compress timeline depth.

  • Turns 1 to 5: You analyze raw hex dumps, discover an obscure edge case, iterate, and finally implement a surgical 4-line patch that passes physical hardware verification.
  • Compaction occurs: The summarizer reduces those 5 turns into: “The user and agent discussed troubleshooting communication issues with module X.”
  • Turn 6: The newly instantiated context reads this summary. Because the temporal resolution was lost, the agent presumes the issue is still open and unresolved. It does not realize that the code currently on disk is the hard-won solution.
B. The Proactive Tool-Calling Urge

Modern coding agents are heavily fine-tuned to be proactive problem-solvers. When faced with the semantic ambiguity of a compacted summary, the agent rarely pauses to ask “Is this already resolved?”.
Instead, its internal bias pushes it to act immediately via replace_file_content or write_to_file. It “fixes” the code back to its broad pre-training statistical prior—effectively reverting hours of fine-tuning to generic, non-working code (“Ghost Reverts”).

By the time the human developer notices the editor tab updating and hits the UI “Stop” button, the file buffer is already mutated, requiring manual diffs or rollbacks.

Real-World Case Study: The UUDT vs. ISO-TP Trap (Automotive Diagnostics)

To illustrate why this matters, here is a concrete scenario from my automotive diagnostics codebase:

  • The Problem: While emulating communication for a vehicle’s Column Integration Module (CIM), the diagnostic tool was timing out during a security key routine.
  • The Investigation: Analyzing raw bus traces revealed that the diagnostic client was not expecting a standard ISO-TP segmented response on CAN ID 0x645 (which carries an ISO-15765-2 PCI length byte like 0x07). Instead, the specification strictly required an unsegmented, raw UUDT (Unacknowledged Unsegmented Data Transfer) frame on CAN ID 0x545 starting directly with the parameter identifier (0x0C 0x01 ...).
  • The Fix: I’m updated the virtual vehicle driver to route this specific diagnostic service to 0x545 as a raw 8-byte frame without ISO-TP framing. Hardware communication was verified.
  • The Compaction Regression: A few iterations later, context compaction triggered. On the very next prompt, I’ve asked the agent to implement a completely separate data parameter. Reading the compressed summary, the agent’s memory of the UUDT constraint was gone. Its general automotive prior kicked in: “Automotive diagnostic = standard ISO-TP on 0x645”. Without prompting, it rewrote the response function, wrapped the payload back into an ISO-TP frame on 0x645, and broke the validated hardware handshake.

Current Survival Strategies on the Ground

To maintain 1:1 fidelity in long projects, I’ve had to build rigid procedural fences outside of the LLM’s working memory:

  1. External Ground Truth (Persistent Journaling):
    I’ve never trust the chat thread to retain state. Every verified milestone, byte layout, and protocol quirk is committed to a local Markdown journal (docs/ia_to_ia.md). The agent is instructed to treat this file, and not its internal conversational memory, as the single source of truth.
  2. Immunizing Rules via System Prompts (AGENTS.md):
    While chat history gets compacted, workspace system rules (user_rules / AGENTS.md) are reinjected in full on every turn. I use this to enforce strict operational constraints:
    • Mandatory File Inspection: Prohibiting any file modification without first performing a physical view_file on the target lines during the current turn.
    • The “1 Screen / 1 Frame = 1 Delta” Rule: Forbidding the agent from anticipating future implementation steps ahead of validated execution logs.
  3. The “Clean Slate” Protocol:
    We train ourselves to treat context compaction not as an invisible background optimization, but as an invalidation event. As soon as a major milestone is reached or compaction is detected, we freeze the state, commit documentation, close the thread, and start a fresh session anchored on the verified docs.

Idea : Enhancing Deterministic Workflows

I love Antigravity and want to see it become the uncontested standard for mission-critical engineering. Here are one non-intrusive ideas that could bridge this gap without compromising token efficiency:

The “Safe-Pause on Compaction” Mode (Opt-in)

Give developers a toggle in workspace settings: Pause on Context Compaction.

  • When compaction occurs, the agent is strictly prohibited from executing file-mutating tools (replace_file_content, write_to_file, terminal writes) on its very first subsequent turn.

  • Instead, it must output a brief technical summary of its perceived state:

    “Context compaction just occurred. Here is my current understanding of the task and active constraints: […]. Shall I proceed?”

  • This gives the developer a zero-cost chance to say “Stop, do not touch module X, that was already validated” before any code is overwritten.

Token efficiency and sliding-window compaction are engineering triumphs, but as agents move from high-level web scaffolding to low-level systems where every byte is a potential point of failure, determinism must take precedence over proactive speed.

How are others handling context drift and compaction regressions when working close to the metal ? And what are your thoughts on a native “Safe-Pause” mechanism ?