AI Agent Development and Operations Incident Log

Tomohiro Iida · Published August 21, 2026 · Updated August 25, 2026

Adding AI agents increases implementation speed. If handoffs, pull requests, CI, approvals, and production verification do not evolve at the same time, the faster implementation also produces more state inconsistency. This series documents failures Netsujo actually encountered and the controls created from them. All twelve episodes are published.

The conversion model used throughout the series is: Incident → Root Cause → Rule → Guardrail → Evidence.

Chapter 1: roles and quality audit

#00 Separate roles before adding more AIDesign support, implementation, audit, and final integration need different responsibilities, authority, and stop conditions. Using three models does not create independence by itself.

#01 Do not let AI review become a reassurance ritualReview scope, risk classification, a review budget, rerun conditions, and an exit condition, so findings move into tests, CI, and gates instead of repeating.

#02 A repeated human warning is a system defectQuestions such as "Is this the latest SHA?", "Was it merged?", and "Did it reach production?" belong in a Controller, Evidence Ledger, and Gate.

Chapter 2: handoffs and state identity

#03 The work item was the same; the chat name was not the identityWhy Netsujo required identical chat names, why that rule was retired, and how WORK_ITEM_ID became the stable identifier.

#04 Stopping the chat does not stop the workA conversation can stop while a dispatched workflow, migration, deployment, or API process continues. Chat stop, cancel request, cancel confirmation, observation, and rollback are separate operations.

Chapter 3: Git, CI, and evidence

#05 Trust an exact SHA, not a pull request numberThe tested SHA, reviewed SHA, owner-authorized SHA, merged SHA, deployed SHA, and production SHA must be distinguished and compared.

#06 CLOSED is not MERGEDState, merge commit, main ancestry, semantic inclusion, and required behaviour are separate evidence layers for the claim that something is fixed.

#07 Do not blindly rerun a failed CI jobPreserve the first failure, extract the signature, classify it, fix the cause, and run fresh exact-head CI. A rerun is justified only after the failure mode is understood.

#08 Cutting CI cost almost removed the safety checksPath-aware CI must fail closed for unknown paths and CI self-modification. Skipped checks remain NOT_RUN, not PASS.

Chapter 4: parallel integration and production control

#09 Parallelize implementation; serialize integrationWorktrees separate working directories, but lane ownership, a single integration writer, dependency order, and non-force history are still required.

#10 Deployment SUCCESS is not production verificationDeployment provenance, production SHA, schema state, public routes, authenticated routes, browser evidence, and rollback readiness are verified separately.

#11 Requiring owner approval for everything stopped deliveryLOW, MEDIUM, HIGH, and UNKNOWN changes need different evidence and authorization. Exact-SHA owner authorization belongs to genuinely high-risk mutations.

Start with the incident that matches the current bottleneck

• Role confusion between design, implementation, review, and final judgment: #00.
• Review that costs more without reducing risk: #01.
• The same check repeated by a human every time: #02.
• Broken lineage across ChatGPT, Claude Code, and Codex work: #03.
• A process that keeps running after the conversation stopped: #04.
• CI results whose subject commit is unclear: #05, #06, #07, and #08.
• Multiple agents interfering with the same pull request: #09.
• Unclear completion after deployment: #10.
• Owner approval becoming a delivery bottleneck: #11.

This series does not rank models or promise a universal prompt. Required controls depend on team size, repository architecture, authority, regulation, and failure tolerance. Each article states its scope and remaining risk.

How Netsujo runs the company on AI agentsThis series owns incident-by-incident classification, cause, correction, and evidence. The broader operating model is covered in a separate article.