A demo agent and a production agent look similar and behave nothing alike. The demo runs once, in a clean environment, watched by its proud builder. The production agent runs unattended, repeatedly, against messy reality, with consequences when it errs. The practices below are what carry an agent from the first to the second. They are opinionated on purpose, because the generic advice — "test thoroughly," "monitor your systems" — is true but useless, and the specific reasoning is what you can actually act on.
Each practice here comes with why it holds, not just that it does. A practice you understand you can adapt; a rule you merely memorize you will misapply. Read these as a set of disciplines that reinforce each other rather than a checklist to tick. The agents that survive production are the ones whose builders internalized the reasoning behind every one of these.
These pair naturally with the failure modes in Why Most Agent Projects Stall, and the Fixes That Unstick Them; this piece is the constructive counterpart.
Earn Autonomy, Never Grant It
The foundational discipline is treating autonomy as something an agent earns through demonstrated reliability, not something you hand over at launch.
Why and how
- Autonomy is the source of both an agent's value and its risk, so it should scale with trust.
- Start every agent in propose-and-approve mode, where a human confirms each action.
- Widen autonomy only after many correct runs, and keep approval permanently for consequential actions.
This single discipline prevents the most damaging class of failure. It is slower up front and far cheaper over the life of the agent.
Practice Least Privilege Ruthlessly
Give the agent the narrowest set of tools and permissions that lets it do the job, and nothing beyond that.
Why and how
- Every tool the agent can reach is a path a bad decision can take to real damage.
- Provision tools per task, not per project, so each agent's reach matches its need.
- Revisit permissions when the task changes; do not let access accumulate.
Restraint here is not caution for its own sake. It directly shrinks the blast radius of any mistake the agent makes. The sequence for setting this up appears in Standing Up Your First Working Agent Without Drowning in Theory.
Make Everything Observable
Build the ability to see what the agent did and why before you let it act on its own.
Why and how
- An autonomous agent's reasoning is invisible unless you deliberately record it.
- Log every action, the reasoning behind it, the result, and any triggered limit.
- Treat logs as the primary debugging surface, because they will be.
You cannot trust what you cannot inspect. Observability is the precondition for every other practice, which is why it comes before autonomy, not after.
Define Stopping Before Starting
An agent needs to know what done looks like and when to give up, defined before it runs.
Why and how
- Without a success test, an agent cannot tell completion from thrashing.
- Set a step limit, a spend cap, and a timeout so a stuck agent fails safely.
- Decide in advance what the agent does when it cannot reach the goal.
A stop condition is also a definition of success. An agent without one does not truly know what it is trying to accomplish.
Design the Failure Path on Purpose
Plan what happens when the agent cannot finish, with the same care you give the success path.
Why and how
- Real agents fail partway through; an undesigned failure leaves a task in an inconsistent state.
- Define how the agent stops, cleans up after itself, and hands off to a human.
- Test the failure path deliberately, because it is the path that protects you.
A trustworthy agent fails safely. The discipline of designing failure is what separates an agent you can deploy from one that merely impresses in a demo.
Keep Tasks Bounded and Stateable
Reserve agents for work whose goal you can state precisely and whose steps are bounded.
Why and how
- An agent can only pursue a goal it can evaluate, so fuzzy goals produce fuzzy, unverifiable behavior.
- Choose multi-step, bounded, low-stakes tasks where adapting to results adds value.
- When a simple script would be more reliable, use the script.
Discipline in task selection prevents the most expensive failures before any code is written. The fit between agent and task is decided here. The broader rationale lives in Understanding Software That Acts on Its Own Behalf.
Verify Output Before It Acts on the World
For consequential actions, insert a verification step between the agent's decision and its effect.
Why and how
- An agent's confidence is not evidence its decision is correct.
- For high-stakes actions, require a check — human or automated — before the action lands.
- Reserve full autonomy for actions where a wrong move is cheap to undo.
Verification scales with stakes. The higher the cost of a mistake, the more checking belongs between decision and effect. This mirrors the verification discipline that strengthens data tools, discussed in Analytics Software Is Becoming a Conversation, Not a Dashboard.
Test Against Reality, Not the Demo Case
An agent that works once in a clean environment tells you almost nothing about how it behaves unattended against messy inputs. The discipline is testing the conditions you will actually face.
How to test honestly
- Run the agent repeatedly, not once, because intermittent failures only show up across many runs.
- Feed it the messy, malformed, and edge-case inputs it will meet in production, not the tidy demo data.
- Deliberately trigger its failure path to confirm it stops and cleans up the way you designed.
- Watch the logs across runs for actions that were allowed but unwise, and tighten accordingly.
A demo proves the happy path exists. Production reliability comes from proving the agent behaves acceptably across the unhappy paths too, which only repeated, adversarial testing reveals.
Keep a Human Accountable, Always
Even a highly autonomous agent needs a person who owns its outcomes. Autonomy of the software never means absence of human accountability.
Why accountability stays human
- Someone must be responsible for what the agent does, regardless of how independently it acts.
- That owner watches the logs, decides when to widen or narrow autonomy, and answers for mistakes.
- Diffuse ownership, where no one is clearly accountable, is how an agent's failures go unaddressed.
The agent acts; the human answers for it. Keeping that accountability clear is what makes autonomy responsible rather than reckless, and it is the discipline that ties all the others together.
Frequently Asked Questions
What is the most important practice if I can only adopt one?
Earn autonomy gradually rather than granting it at launch. It prevents the most damaging failures because those failures happen unsupervised. Starting in propose-and-approve mode and widening slowly is the highest-leverage discipline by a wide margin.
How is least privilege different for agents than for regular software?
The stakes are higher because an agent decides its own actions. A permission a human would never misuse can become a path to damage when an agent makes a flawed decision. Restricting tools to the task's exact needs directly limits how much a mistake can cost.
Do these practices slow down development?
Up front, somewhat. Over the life of the agent, they save far more than they cost by preventing the failures that derail projects. The teams that skip them move faster to a demo and slower to anything dependable.
When can an agent act without verification?
When a wrong action is cheap and easy to undo. Low-stakes, reversible actions can run autonomously. Anything consequential or hard to reverse warrants a verification step between decision and effect, sometimes permanently.
Are these practices specific to any tooling?
No. They are tooling-agnostic disciplines about autonomy, permissions, observability, stopping, failure, task selection, and verification. The specific platform changes how you implement them, not whether they apply. They hold across every agent worth deploying.
Key Takeaways
- Treat autonomy as earned through demonstrated reliability, never granted at launch.
- Practice least privilege so every mistake has the smallest possible blast radius.
- Make every action observable before allowing any autonomy.
- Define success, stop conditions, and the failure path before the agent runs.
- Keep tasks bounded and stateable, and verify consequential actions before they affect the world.
For the failures these practices prevent, read Why Most Agent Projects Stall, and the Fixes That Unstick Them.