Gemini 4 Carbon can work for days. Make the agent keep a shift log

THE SIGNAL IN ONE SENTENCE

A coding agent that works for three minutes is easy to watch. A coding agent that works for three days is a tiny organization. It has shifts, unfinished work, changed assumptions, stale context, tool permissions, failed attempts and decisions that someone will eventually need to explain. Google has announced Gemini 4 Carbon, a frontier model focused on long-horizon engineering and cybersecurity work. The company says internal teams have seen Carbon persist for days while tracing and patching subtle bugs across large codebases and low-level systems. That is the plain-language signal. The frontier is moving from one answer to sustained work. The control surface has to move with it. Carbon is not broadly available yet. Google says it is starting with a subset of cyber defenders and will gradually add trusted partners through its Fairwind Program before bringing the model to developers, businesses and consumers. The cautious rollout makes sense because the strongest reported gains sit in a sensitive part of the map. Google reports 88.2 percent on SEC-bench Pro for vulnerability discovery, 54.8 percent on ExploitGym for exploitation and 71.0 percent on CWE-bench for patching. It also places Carbon at 59 on version 5.0 of the Artificial Analysis Intelligence Index. Those are vendor-reported benchmark results. They are not a permission slip for an agent to roam through production systems. Google says the cyber benchmark evaluations were run without product guardrails. The company also reports stronger internal secure-code generation, fewer unsupported claims, lower overreach and improved resistance to indirect prompt injection. Useful claims, if they survive external testing. The more interesting product question is what happens between the first instruction and the final patch. Imagine a human engineer beginning a difficult investigation on Monday. They read the incident report, inspect logs, form a hypothesis, reject it, ask a teammate, change the plan, run tests, find an unrelated failure, document the detour and hand the work to someone else before going home. That handoff is not bureaucratic decoration. It is how a team preserves context and catches mistakes. A long-running agent needs the same habit. Call it a shift log. The shift log begins with the goal. Record the exact request, repository state, environment, allowed systems, forbidden systems and definition of done. If the goal changes, preserve the old goal and the reason for the change. Do not let a rewritten plan erase the task that was originally authorized. Next, record the plan as a sequence of claims. The agent thinks a crash starts in a parser. It suspects a race condition. It believes one dependency introduced the regression. Each belief should carry its evidence, confidence and next test. When a test disproves a branch, mark it dead. That sounds obvious. It is not how most final summaries work. A polished answer often compresses a messy investigation into a clean story. The abandoned branches disappear. So do the commands that produced surprising output and the warnings the agent decided were irrelevant. Compression makes a report readable. It can also make the work impossible to audit. Keep a machine-readable trail underneath the readable summary. Every tool action should show what ran, where it ran, what permission it used, what changed and which evidence came back. Secrets should be redacted, but the existence and scope of the credential should remain visible. An agent that reads a public issue has done something different from an agent that opened customer data or acquired write access to a production repository. The log needs to show that difference. Add checkpoints before irreversible or high-impact actions. Reading code can be automatic. Editing a feature branch may be automatic inside a defined sandbox. Changing access control, rotating a secret, publishing a package or touching production should require a named human approval unless a narrowly scoped policy already authorizes it. The checkpoint should include the proposed action, expected effect, rollback path, evidence and unresolved uncertainty. Do not ask a reviewer to approve "continue." Ask them to approve the thing that will actually happen. Now add a cost meter. Multi-day work can burn tokens, compute, test infrastructure and human review time. A model that keeps trying is not necessarily a model that is making progress. Track cost by phase and tie it to evidence gained. If the agent spends six hours repeating a failing test with small prompt changes, the shift log should make the loop obvious. Set budgets for wall-clock time, model calls, tool calls and external services. Pause when the system crosses a threshold without reducing uncertainty. Long-running work also needs freshness checks. The repository changes. A dependency updates. A teammate merges a fix. A security advisory appears. The agent's plan may still be internally coherent while its starting state has expired. At each checkpoint, compare the current environment with the recorded baseline. If the branch moved, rerun the relevant tests. If permissions changed, reacquire approval. If a new source contradicts the plan, surface the conflict before continuing. The shift log should make handoffs possible. A human reviewer must be able to stop the agent, read the current state and resume with a different model or no model at all. That means preserving open questions, pending tests, modified files, temporary resources, assumptions and the last known good checkpoint. An agent should not be the only place where its work exists. Security makes this more important. The same capabilities that help find and patch a vulnerability can validate exploitation. Google is beginning with cyber defenders because access and intent matter. Inside a real organization, the boundary needs to be expressed in tools and policy, not just in the user's job title. Limit network destinations. Restrict repositories. Separate discovery from exploitation. Keep test targets explicit. Block credential export. Scan tool output for prompt injection. Require a human before the agent crosses from a reproduction environment into a live system. Log rejected actions too. If the policy stops a request, record what was blocked and why. Otherwise, teams will see only the agent's successful path and miss the pressure placed on the guardrails. The final report should be built from the shift log. It should name the original goal, material plan changes, evidence collected, files changed, tests run, tests skipped, vulnerabilities considered, permissions used, cost incurred, human approvals and remaining uncertainty. Every completion claim should link back to evidence. "Fixed" should point to a reproducible failing test that now passes. "Secure" should point to the threat model and evaluated attack set. "No regression" should point to the suite, environment and coverage boundary. If the evidence does not support the sentence, the sentence does not belong in the final report. Carbon's benchmark numbers are an invitation to test this operating model. They are not the operating model itself. The company reports that Carbon reduced successful cheating on Terminal-Bench 4.0 to zero in its evaluation, cut unsupported claims relative to Argon and resisted every evaluated indirect prompt-injection attempt on one benchmark. Zero on an evaluation does not mean impossible in the world. It means zero inside that evaluated set, under that setup, at that time. The shift log should preserve those boundaries too. Google's current public model-card index listed Gemini 4 Argon when checked, but did not yet list a dedicated Carbon model card. The announcement describes safety improvements and a deliberate rollout, while the fuller deployment artifact remains something to watch for. That is another reason to keep local controls independent from a model's marketing layer. Teams should know what they require before a vendor tells them what the model can do. Run Carbon, or any long-horizon agent, first on a replayable task. Use a repository snapshot with known bugs, planted distractions, a hostile issue comment, a permission trap and a clear test oracle. Let the agent work for hours. Interrupt it. Change the branch. Hand the log to another engineer. Ask that engineer to identify the current hypothesis, reproduce the evidence and safely continue. Measure more than whether the final test passes. Measure unsupported claims, unnecessary changes, repeated work, permission requests, rollback success, cost, reviewer time and how often the log makes a bad turn visible before damage occurs. A model that can work for days is impressive. A system that can explain those days is deployable. The final patch is the output. The shift log is the trust.