Notifications
Clear all
Topic starter
02/08/2026 12:08 pm
TL;DR: AI-assisted development fails less because of the agent itself than because the surrounding process cannot supply context, verification, and control, especially when teams scale fast and tribal knowledge stays undocumented, according to Cogent. The real governance problem is a human plus machine operating model that assumes static review loops can still catch dynamic agent behaviour.
NHIMG editorial — based on content published by Cogent: Your Agent Is Fine. Your Process Isn't
Questions worth separating out
Q: How should teams govern AI agents that can reach APIs, events, and memory?
A: Teams should govern those agents as runtime identities, not as isolated integrations.
Q: Why do AI agents create process risk even when the model is working well?
A: Because the model is only one part of the operating chain.
Q: What breaks when teams rely on undocumented conventions with AI agents?
A: Agents lose the ability to infer the same context that humans carry informally, so they guess.
Practitioner guidance
- Define a mandatory verification loop for every agent session Require test execution, log inspection, and a recorded success criterion before agent output can move to review or merge.
- Document the context an agent is allowed to rely on Move tribal knowledge into searchable specs, task files, and codebase conventions so an agent does not depend on Slack history or one engineer's memory.
- Treat agent bridges as non-human identity control points Constrain sandboxes, network access, and credential scope wherever an agent can touch services, databases, or infrastructure through shared tooling.
What's in the full article
Cogent's full blog covers the operational detail this post intentionally leaves for the source:
- The exact spec-driven workflow used to move from ticket to task file to pull request
- The sandboxing and daemon pattern used to keep agents away from credentials and unrestricted network access
- The CLI and service orchestration design that lets humans and agents use the same operational path
- The context hierarchy pattern that turns repo knowledge into something an agent can actually read
👉 Read Cogent's analysis of how AI agents fail when the surrounding process is weak →
AI agent process gaps: what IAM teams actually need to fix?
Explore further
02/08/2026 1:12 pm
AI agent governance is an identity problem before it is a productivity problem. Once an agent can write code, run tests, query systems, or inspect services, the organisation has created a non-human operator that needs bounded access, accountability, and recoverability. The article shows that workflow design, not model capability, determines whether that operator behaves safely. Practitioners should treat the operating model as part of the control surface.
A few things that frame the scale:
- From our research: 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should own the outcome when an AI agent changes production-facing code?
A: A human owner should always remain accountable for the change, even if the agent authored most of it. Ownership means setting the task, reviewing the evidence, and deciding whether the result meets policy and quality standards. Without a clear owner, recovery and remediation become guesswork.
👉 Read our full editorial: AI agents expose process gaps that IAM teams cannot ignore
