The funny thing about AI agents is that they feel autonomous until someone asks a basic production question: why did it do that?
Then the team becomes a detective squad. Which prompt ran? Which memory was loaded? Which tool permission was active? Which retrieval result shaped the answer? Which model endpoint responded? Who approved the change? And can we reproduce the same run tomorrow?
Agent behavior is not just code
Traditional software engineering has a strong operating model for code: version control, reviews, CI/CD, environments, artifacts, observability, and rollback. Agent systems often reintroduce the same governance problem in a new form because behavior is assembled at runtime from prompts, tools, memory, retrieval, context, model versions, and policy.
In other words, production is no longer only the repository. Production is code plus state. If that state is not managed like an artifact, every incident becomes CSI: Prompt Engineering. This is part of the same operational gap I see in <a href=”https://runwithran.com/2026/06/07/career-leverage-small-software-companies/”>AI engineering and production workflow design</a>.
The four questions I would ask before production
- Is every prompt versioned? Not just the main prompt, but tool instructions, system policy, and evaluation prompts.
- Are tool permissions reviewable? A model with different tools is a different system, even if the code did not change.
- Can yesterday’s run be replayed? The team needs model, version, input, retrieved context, memory state, tool calls, and outputs.
- Is rollback real? “We will update the prompt and hope” is not a rollback strategy.
What belongs in git
If a team asks what should go into version control, my answer is: more than the code. Prompts, tool manifests, permission boundaries, retrieval configuration, memory schemas, evaluation datasets, release notes, and behavior-change approvals should all be treated as production artifacts.
That does not mean every experiment needs heavyweight process. It means the path from experiment to production must add traceability. The same principle applies to <a href=”https://runwithran.com/2026/06/04/security-architecture-breach-containment/”>software-development process and accountability</a>: speed is valuable only when the team can still explain, review, and recover from what changed.
A practical agent release checklist
- Change diff: what changed in prompt, tools, memory, retrieval, model, or code?
- Expected behavior: what should improve, and what might regress?
- Evaluation evidence: which test cases or replay runs passed before release?
- Human owner: who owns the behavior if the agent causes damage?
- Rollback path: how do we return to the previous known-good behavior quickly?
The operational punchline
The hype talks about agents doing work. Operations needs agents that can be explained, tested, reproduced, and turned off. Without that, autonomy becomes a surprise with permissions.
The first production-grade question for an agentic system is not “how smart is it?” It is: “what changed since yesterday, and can we prove it?”
Context: this article was inspired by a DevOps discussion about AI agents reintroducing governance problems that software engineering already learned to manage, then expanded into a release checklist for production agent systems.
Originally posted on LinkedIn: <a href=”https://www.linkedin.com/feed/update/urn:li:activity:7470712815767658498/”>Hebrew version</a>
