I build agents that act in the real world: a WhatsApp bot with dozens of commands, and an app with server-verified missions. The interesting part is not the model. It is everything around it that keeps the agent from doing damage when it is wrong.
These are the rules I actually work by, learned the hard way.
1. Never submit blind
An agent must never send, commit, push, or publish something I have not seen, unless I explicitly ordered that exact action. Drafts go to a staging area first. Live code is only touched after a check passes in a throwaway copy.
This rule exists because of a real incident: a bot command once committed and pushed a change without my approval. The change stayed, but the rule changed with it. No agent query touches live code or a live repo on its own.
2. Verify the decisive claim yourself
A researcher's report that a site is broken, a listing is dead, or a price is real is not evidence. I check it directly before it reaches a client or a user. A clean build or a 200 response is not verification either. The check has to reproduce the real conditions: the real phone, the real viewport, the real account state.
A screenshot alone is never enough for a diagnosis. Check the live session, the account, and the platform state before asserting what succeeded or failed.
3. The phone is the final gate
I build on a desktop, but most of my users are on phones. Every visual or interactive deliverable is judged on a real phone, not on a clean build log. When my rig cannot reproduce those conditions, I say so before delivery, and the first real run becomes the test.
When a fix fails on a phone, the next attempt starts by reproducing that exact phone scenario in a test, never by deploying and hoping.
4. Every failure must produce a permanent adaptation
A bug that is fixed and forgotten will return. A failure class that is understood gets a standing check that makes that class impossible, or at least caught early.
Examples from my own work: verification must reproduce touch with jitter and a phone viewport. A watchdog must check a service by its port and status endpoint, not by a process name that changed months ago. A commit must be authored by the account that owns the deployment target, or the deploy will be blocked.
5. Log silently, speak only when it matters
A watcher that reports every routine event becomes noise, and noise gets ignored. Losses, enters, and reassignments log silently. The watcher speaks only when a ticket is won, when a human hand is needed, or when the watcher itself breaks.
The same applies to an agent's output. One complete report at the end beats a stream of partial updates.
6. Keep secrets out of the work
Keys, tokens, and passwords live in a vault or a designated env file, never in memory, ordinary files, chat, or a repo. A credential delivered in chat is treated as exposed and rotated at the next login.
This is not paranoia. It is the only way a system with many moving parts stays trustworthy.
The short version
Build the agent, then build the guardrails around it: staging before live, verification before claims, a phone check before delivery, a permanent adaptation after every failure, silent logging, and secrets kept out of the work entirely.
The model is the easy part. Surviving contact with real users is the job.
I am Ashar, a full-stack developer and AI integration engineer. More of my work is at https://asharxyz.vercel.app.
Top comments (0)