Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstalliTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Reliable AI agents need more than a capable model: they need software-enforced limits, a workflow suited to the job, and a way to detect and recover from mistakes. Ben Lorica’s nine practical rules for agents doing real work offer a useful design checklist—not a consensus standard. The core evaluation question is: what exactly are you testing when you test an agent? The answer should include the model and the system around it.
1. Put hard constraints in software
Use code and policy checks for permissions, calculations, and other requirements that must always hold. Let the model handle ambiguity and judgment, then validate its outputs and important factual claims before acting on them. As Lorica puts it, “A prompt is guidance.” A prompt can express a rule, but it cannot reliably enforce access control or guarantee a calculation is correct.
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
For example, an agent may recommend a refund, but application code should verify eligibility and enforce the permitted amount before issuing it. Keep the boundary clear: the model proposes; software enforces.
2. Give the agent only the autonomy the task needs
More autonomy creates more possible action paths, and therefore more opportunities for errors, cost, and governance work. Start with the authority required for the job rather than granting broad access by default. As a workflow becomes repeatable and reliable, move its predictable steps into ordinary code instead of asking the agent to make the same decisions on every run.
#1 Best Overall
3. Follow the domain’s trusted process
A generic plan-and-act loop is not automatically the right workflow. Where a domain already has checklists, protocols, escalation rules, or approval points, build around them. Those structures encode how the work is expected to proceed and when a person or specialist must take over.
Map the existing process first: identify required checks, decisions the agent may make, and conditions that require escalation. The agent should support that process, not silently replace it.
4. Design for recovery, not just a successful first attempt
Long workflows can fail even when each individual step is usually successful. Lorica illustrates the compounding effect with an author-reported example: if ten independent steps each succeed 95% of the time, the probability of an error-free run is about 60%. This is an illustration from his article, not an independently verified benchmark.
Build recovery into the workflow:
- Checkpoint progress so a run can resume from a known-good state.
- Verify after actions rather than assuming a tool call succeeded as intended.
- Use retries selectively when an operation is safe to repeat.
- Prefer reversible actions where possible, and define how to undo or contain a mistake.
- Measure recovery separately from first-attempt accuracy, so a system that detects and repairs failures is not evaluated as though it never encountered them.
5. Evaluate the model and harness as one system
An agent’s behavior depends on more than its model. Tools, context management, memory, policies, and recovery logic all affect whether it completes a task correctly. Evaluate the assembled system against representative tasks, and rerun the evaluation when either the model or the harness changes.
Lorica reports an 18-percentage-point difference between the best and worst harness configurations for the same open model. His article does not provide the underlying study’s methods or sample, so treat the figure as an author-reported example rather than a general performance guarantee. Its practical implication is that a model evaluation alone may miss important sources of system performance.
6. Keep multi-agent teams small and make criticism consequential
Adding agents is not automatically an improvement. Keep teams small, give each agent a distinct role, and limit each one’s tools, permissions, and information to what that role needs. Overlapping responsibilities can add coordination without providing a meaningful check.
If one agent reviews or challenges another, define the critic’s criteria and give it explicit authority to block an action or escalate the case. A critic that can only offer optional advice is not a reliable safeguard.
Recommended Free Tools
7. Keep the toolbox compact and distinct
Tools with overlapping purposes can make selection harder and multiply the call sequences that need testing. Give each tool a clear job, and log which tools were selected, their inputs and outputs, and any failures. Use those records to decide whether to combine tools, route requests more clearly, or remove redundant options.
Best Value
8. Separate context, memory, and enterprise knowledge
These information sources serve different purposes and should not be treated as one undifferentiated store:
- Context is the information needed for the current run.
- Memory carries useful lessons or information forward between runs.
- Enterprise knowledge is governed material the agent may consult, such as approved policies or reference documents.
Set retention, retrieval, and access rules according to each role. Current task details, persistent lessons, and controlled organizational records need not have the same access or retention policy.
9. Improve knowledge before paying for a larger model
When an agent gives an incorrect answer, check whether its knowledge pipeline is contributing before changing models or fine-tuning. Retrieval can miss relevant information when the user’s wording differs from the source, when content is buried in tables or PDFs, or when documents conflict. Document structure, routing, and governance can therefore matter as much as model capability for knowledge-intensive tasks.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteLorica reports an example in which replacing raw support documents with a diagnostic playbook and routing approach reduced token use by 43% and errors by 48% without changing the model. The article does not identify the underlying study’s methods or sample; these are author-reported results, not a promised outcome for other systems.
Turn the rules into an evaluation checklist
For each workflow, test whether the complete agent system handles the job safely and consistently:
Quick Recap
- Are permissions, calculations, and other critical constraints enforced in software?
- Does the agent have only the autonomy needed for its assigned task?
- Does the workflow preserve domain checklists, approvals, and escalation rules?
- Can the system detect errors, recover from them, and resume from a known-good state?
- Does the evaluation cover tools, context, memory, policies, and recovery—not just the model?
- Are multi-agent roles distinct, and can a critic block or escalate when criteria are met?
- Are tools distinct enough to select reliably, with their inputs, outputs, and failures logged?
- Are current-run context, persistent memory, and governed knowledge handled under appropriate rules?
- Have knowledge structure and retrieval been checked before a model change is treated as the fix?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
