AI Agent Development and Operations Incident Log

Tomohiro Iida · Published August 21, 2026 · Updated August 21, 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.

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 AI

Design support, implementation, audit, and final integration need different responsibilities, authority, and stop conditions. Using three models does not create independence by itself.

#01 I almost turned AI review into a reassurance ritual

A review budget, scope, rerun condition, and exit condition are required so independent review does not become repeated spending to reduce anxiety.

#02 A repeated human warning is a system defect

Questions such as “Is this the latest SHA?”, “Was it merged?”, and “Did it reach production?” belong in a Controller, Evidence Ledger, and Gate.

Read #02: Controller, Evidence Ledger, and Gate design

Chapter 2: handoffs and state identity

#03 The work item is the same, but the chat names are different

Use the same human-readable chat name across ChatGPT, Claude Code, and Codex, then add a stable work-item ID, predecessor, repository, pull request, and current head SHA.

#04 Stopping the chat does not stop external work

A conversation can stop while an already-dispatched workflow, migration, deployment, or API process continues. Chat stop, process cancel, observation, and rollback are separate operations.

Read #03: a verifiable cross-agent handoff contract

Chapter 3: Git, CI, and evidence

#05 Trust an exact SHA, not a pull request number

The tested SHA, reviewed SHA, owner-authorized SHA, merge target, and production SHA must be distinguished and compared.

#06 CLOSED is not MERGED

A pull request can exist and be closed while its change is absent from main. State, merge commit, ancestry, semantic inclusion, and required behavior are separate evidence layers.

#07 Do not blindly rerun a failed CI job

Preserve the first failure, classify the signature, fix the cause, and use fresh CI. A rerun is justified only after the failure mode is understood.

#08 CI cost reduction almost removed safety checks

Path-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 integration

Worktrees 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 verification

Deployment provenance, production SHA, schema, public routes, authenticated routes, and browser evidence must be verified separately.

#11 Requiring owner approval for everything stopped delivery

LOW, MEDIUM, HIGH, and UNKNOWN changes need different evidence and authorization. Exact-SHA owner authorization belongs to genuinely high-risk mutations.

Read #09: parallel agents, worktrees, and sequential integration

Start with the incident that matches the current bottleneck

• Role confusion between design, implementation, review, and final judgment: #00.
• Broken lineage across ChatGPT, Claude Code, and Codex chats: #03.
• CI results whose subject commit is unclear: #05, #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.