Control planes, diagnostics, and review gates now define agent reliability work

The Agent Operating System (AOS) paper gives the period’s most explicit systems proposal. It defines a control layer for long-running agents where identity, goals, task graphs, capabilities, memory, policy checks, and audit records are managed objects. The key design rule is deterministic approval before side-effecting actions run, with policy outcomes written to append-only logs.

DevArch shows the same pressure in a product form for Claude Code. It uses hooks, directives, architecture decision records, session summaries, domain boundaries, and test gates to keep agent work inside project rules. The evidence is descriptive, with no benchmark or defect-rate measurement, so the practical claim is about workflow shape rather than measured quality gains.

Monitoring work is becoming more operational. The audit-agent study argues that early systems need checks for integration gaps, stage behavior, and variance across runs before task-level error detection is reliable. In its synthetic audit testbed, within-run monitors found deterministic stage defects with CV = 0.02, cross-run monitors found variable failures with CV = 1.25, and a structural monitor found an integration gap with CV = 0.00.

The triage result is concrete. The method routed 10,210 L3 findings to automated monitoring and 243 L2 findings to human investigation, reported as a 43x reduction in analyst review volume. That makes monitoring scope and severity routing part of the reliability design, not just an alerting layer.

The type-error study gives a measured example of tooling tuned for agents. The authors modified Shplait to expose several diagnostic modes and ran 2,400 qwen2.5-coder:14b repair trials across 60 broken programs, four feedback modes, and ten runs. Richer type-error diagnostics improved repair behavior, and 97.9% of repairs that removed the type error also passed semantic tests.

Mark Brooker’s essay states the broader engineering rule in plainer terms: coding agents do better when they can run fast checks such as compiler errors, tests, benchmarks, formal specifications, and simulators. The stronger evidence here is the Shplait experiment; the essay is useful because it connects that result to everyday software workflows.

Two studies focus on what happens after agents produce artifacts. The code-review study with JetBrains treats review of LLM-generated multi-file changes as a trust-calibration problem. Its proposed IDE workflow moves through a change overview, risk-ranked files, and code-snippet inspection with constructs such as risk-per-line, risk-per-file, judge, walk-through, and security cage. In validation, 63% of respondents expected lower overall review effort, though the study did not measure defect detection or task time.

The requirements-engineering study shows a similar constraint in product work. At XITASO, product owners used AI across 15 requirements use cases, with backlog refinement reported by 6 of 8 participants. The main practical limiter was tool connection: Jira, Confluence, source code, tender sources, and meeting data determined whether AI outputs fit the team’s process or created manual handoffs.