TL;DR: Self-improving coding agents can build tools, capture learning, and rewrite their own harnesses, but the deeper problem is that they still defer work, miss recurring patterns, and struggle to sustain vigilance across sessions, according to ngrok. The governance lesson is that runtime structure beats raw model introspection when agent behaviour must be controlled.
NHIMG editorial — based on content published by ngrok: bmo and the gap between knowing and doing in self-improving coding agents
Questions worth separating out
Q: How should security teams govern AI coding assistants that can execute commands?
A: Treat them as delegated non-human identities with bounded execution authority.
Q: Why do self-improving agents still miss recurring mistakes?
A: Because introspection is not the same as sustained vigilance.
Q: What breaks when an agent has too many tools and too much choice?
A: Reliability drops because every extra tool increases the decision space, the number of failure paths, and the likelihood of inconsistent use.
Practitioner guidance
- Define hard triggers for agent self-improvement Require explicit conditions for tool creation, reflection, and backlog handling so the agent cannot defer important work into a later session.
- Reduce the agent’s decision space Replace broad shell-style access with safer, task-specific tools that include checks for file existence, command validation, and controlled outputs.
- Separate reflection from execution Run session-end reflection as a scheduled control with fixed questions and persistent logging, then review the results outside the active task loop.
What's in the full article
ngrok's full post covers the operational detail this post intentionally leaves for the source:
- The complete bmo harness design, including the tool model and session loop structure used to drive self-improvement.
- The full reflection template and learning-event-capture logic that shows how the agent was prompted to record lessons.
- The maintenance-pass workflow and backlog mechanics that explain why deferral kept appearing in practice.
- The detailed performance table for tools and skills across sessions, including where the agent improved and where it regressed.
👉 Read ngrok's full analysis of bmo and agentic self-improvement →
Self-improving coding agents: what the gap between knowing and doing means?
Explore further
Runtime self-improvement is a governance pattern, not a capability story. The post makes clear that the real question is not whether an agent can modify itself, but whether those modifications happen under controlled conditions. Without deterministic triggers, self-improvement becomes inconsistent and easy to defer. For agentic AI programmes, that means governance must focus on when the system may change behaviour, not just what the model can do.
A question worth separating out:
Q: How do you know if an agent harness is actually working?
A: You should see repeatable behaviour at the right moments: tool creation when friction appears, reflection at the end of each session, and fewer deferred tasks over time. If the agent keeps punting work into maintenance buckets, the harness is not governing behaviour, only describing it.
👉 Read our full editorial: Self-improving coding agents still fail at sustained vigilance