A quick “go ahead” between meetings can change what a customer receives. Before an agent acts, we need a clear record of what that permission covers.
The prompt communicates intent. The process defines authority: what can happen, who approves it, and what evidence remains.
My former colleague John Narus recently made the same case: the system around the AI matters more than how you phrase the request. I agree. This is our version, from a team applying it in production.
At Ruta Cloud, we built RutaCX, our AI customer service platform, with agents writing most of the code. These practices govern that work.
1. Production changes require precise approval
Intent leaves too much undefined. We require a written Change Request, or CR.
Deployments, production settings or data changes, bot replies, messages to real people, and access changes are mutations. Each needs a CR stating the current condition, checked live and dated; the proposed change; rollback; and blast radius—who could be affected.
To revise a bot notification, for example, we record the existing wording, its replacement, which conversations would receive it, and how to restore the original.
Approval uses this literal format: APPROVE CR-YYYY-NNN @ HASH. The hash fingerprints the approved specification; code checks it. A different specification or release target requires fresh approval. A changed system precondition invalidates it too. Approval expires after 24 hours by default.
I am the only human approver. “Do it” means prepare the CR. Silence grants nothing. Agents cannot approve their own proposals.
The script rehearses without writing—a dry-run. Execution requires –apply and revalidation of the conditions. We capture before and after, then read the system again. An HTTP 200 response does not establish that the intended change happened.
2. Human attention follows the risk
Constant permission requests wear down attention. We use a small set of gates with enough context to decide.
- R0: reading within the authorized scope.
- R1: tested branch work, with a record.
- R2/R3: an approved CR is always required.
Agent confidence never authorizes production changes, spending, messages to real customers, or irreversible data operations. Approval requests explain the action, its purpose, what would make it wrong, and how to undo it.
3. Memory connects projects and machines
Shortening a conversation should not erase a decision. Our “brain” is a private repository of Markdown notes, compatible with Obsidian. It connects projects, sessions, decisions, and lessons through links.
Context is RAM; the brain is disk. Saved knowledge survives compaction. A lesson about requesting a useful review remains available to the next project. Git synchronizes that memory across machines.
Projects also keep standing rules in AGENTS.md or CLAUDE.md. We aim for brief instructions that preserve decisions across sessions.
4. Reviewers advise; evidence settles disputes
Reviewers make mistakes too. Our council pairs Fable 5 and Codex, from different model families.
Our rule requires both before production. They inspect the actual diff—the code changes—regenerated from the working tree and checked against its md5 fingerprint. Tests, deployment tooling, and rollback are included. They challenge each other. READY, REVISE, and HOLD are advisory verdicts.
On one diff, Fable found a cost-saving filter that suppressed the notification for a customer requesting a person. No test covered it. Codex found that delivering nothing was the only incident that would not trigger an alarm.
Reviewers have also suggested fixes that would break things. One supposed blocker was an existing defect, not a regression in that release. We check each finding against the code.
Debate stops after two rounds. Factual disagreements go to running code or tests. Judgment calls go to the lead, with dissent recorded. Unresolved material conflicts involving money or data go to the human.
We once deployed while a reviewer was unavailable. Its later verdict found real blockers. “Reviewer unavailable” does not mean “reviewed.” We disclose the gap and the human decides. The agent cannot waive the gate.
5. Tests and history travel with the code
To make decisions traceable, work goes through branches, pull requests, and CI checks for lint, static security analysis, dependencies, secrets, and tests. Nothing goes straight to main. Merging does not deploy: deployment requires its own CR.
The git record identifies the agent, action, risk, evidence, and approval. Operational claims distinguish live evidence, exports, history, inference, and unknowns.
Fixes belong in the correct architectural layer. Behavior changes start in logging-only mode. “Never introduce a new silence” means a change must not leave a customer without a response. Regression tests must fail against the rejected version; passing on both proves no fix.
What is established and what is distinctive
Short project rule files, persistent notes, and review across models are already common practices. Risk tiers and audit trails are established too. In our October 2026 research, approval cryptographically tied to an exact change, with expiry and revalidation, appeared as a proposal rather than documented daily practice. That describes the limits of our search, not proof that nobody else does it. Our emphasis is on requiring that approval every day, checking reviewers’ findings, treating an unavailable reviewer as a missing review, and never letting agent confidence authorize irreversible actions.
What we built this way
We built RutaCX, our AI customer-experience platform for businesses that live on the phone and in chat, with this process. These are the hardest pieces:
- Calls from your phone system: every day it pulls the call log and the recordings of answered calls (today, from HoduPBX / OnePBX systems). Phone audio arrives compressed and noisy, so we measure its quality before trusting it.
- Transcription on your own server: audio is transcribed with a local model, with no per-minute cost and without leaving for third parties. If a recording is unusable, the system says so instead of guessing.
- Call analysis with catalog and rubrics: each call is evaluated against the knowledge base of a configured line of business and with rubrics editable per call type (sales, courier, support). A supervisor, schedulable weekly, rescores a sample and flags what does not add up. The AI that evaluates also needs evaluating.
- A chatbot that does not make things up: it serves WhatsApp, web chat, and other channels using only each line’s knowledge base. When it does not know, it hands the conversation to a person, and once a person steps in, the bot goes quiet.
- Commercial memory per conversation: it records what we know about the customer, what is missing, and what comes next. Code, not the model, derives the funnel stage from the data.
- The follow-up list nobody was making: it finds people who asked for a price or showed interest but have no opportunity or owner, across calls, WhatsApp, and the CRM.
- One history per customer: a native CRM brings calls, chats, and notes together on the contact record.
The controls in this article show up in the product: signed links that expire for sharing estimates, a daily AI spending cap reconciled with the provider, and PDF estimates that only people with access can open. You can see the product at rutacloud.tech.
At Ruta Cloud, we help midsize businesses in South Florida integrate AI into their software with these controls. We can discuss your case in a free call of up to 20 minutes.
These practices did not come from a manual. We built them empirically, as needs arose along the way, drawing on experience with software development processes. Only afterward did we compare them with studies and articles on similar approaches, which support them. We keep improving them as knowledge and AI-assisted development evolve.
Further reading
- Persistent memory and project rules: Obsidian Mind.
- Review across models: Cross-Model Adversarial Review.
- Proportional controls and approval fatigue: Gartner.
- A proposed approval contract: AI Agent Authorization.
Ruben Rivera Founder, Ruta Cloud · Miami