Execution-Aware Agent Control

Repository-level coding agents need a retry controller that keeps explicit memory across full attempts and always returns the best artifact seen so far. The current evidence points to a specific design: store structured success notes, failure notes, and the highest-scoring repository after each run, then feed those records back into the next attempt together with execution feedback. LiveCoder reports up to 22.94 points of functional improvement on RAL-Bench, repository reuse up to 81.58%, and cost reduction up to 53.63%. EnvGraph supports the same operational change from a different angle: many repository failures are still installation, dependency, and cross-file reference failures, so retries need runtime diagnosis, not just more sampling.

The practical build is a repository runner that logs each attempt as a durable artifact with test results, install logs, runtime errors, and a compact diagnosis record. Teams evaluating coding agents on internal scaffolding or greenfield service generation can test this cheaply by comparing three conditions on the same task set: single-shot generation, repeated attempts without memory, and repeated attempts with persistent attempt memory plus best-artifact fallback. If the win is real, later attempts should stop erasing earlier partial successes, and the system should recover more executables without paying for the same failures again.

C and C++ repair agents can justify a debugger-first workflow for memory-safety bugs. DebugHarness gives a concrete pattern: start from a reproducible crash and sanitizer signal, inspect runtime state through GDB and pwndbg, use rr to move backward through execution, test root-cause hypotheses with watchpoints and breakpoints, then generate and validate a patch in the same loop. On SEC-bench, the paper reports about 90% resolution across 200 real-world vulnerabilities in 29 projects, above PatchAgent at 57.5% and VulnResolver at 67.5%.

The near-term product change is a repair harness for security teams that already have fuzzing outputs and PoC crashes but still hand off root-cause analysis to senior engineers. A cheap check is narrow and concrete: take a backlog of reproducible AddressSanitizer or crash-triggered bugs, restrict the agent to runtime inspection plus patch validation, and measure time to first plausible root-cause hypothesis and validated patch rate against a static-code baseline. The evidence here is strongest for low-level memory faults where the crash site and the real defect are far apart.

Permission gates for coding agents need action-level coverage over file edits, not only shell commands. AmPermBench shows why: in Claude Code auto mode, 36.8% of state-changing actions flowed through Tier 2 file edits that the classifier never inspected, producing 51 false negatives there alone. End-to-end false negatives reached 81.0% across 253 state-changing actions, and artifact cleanup was especially exposed because agents could edit objects.json to achieve the same effect as a blocked command. This supports a concrete control change for DevOps and internal platform teams: normalize proposed edits into their real operational effect before approval, then evaluate policy on that effect.

A usable build is an interposition layer that classifies writes, patches, and generated config changes by resource touched and state change implied, then routes them through the same policy engine used for command execution. The first test does not require a full benchmark suite. Take a handful of ambiguous cleanup or restart tasks in your own repos, run the agent with shell-only permission checks, then add edit-path classification and compare unsafe action escapes at the individual action level. The main adoption blocker is straightforward: teams that trust command gating alone are leaving an uninspected path for equivalent destructive actions.