What the agent should never touch alone<\/p>\n
Some tasks are reversible. For example, a refactored function can be reverted or a new unit test can be removed. The cost of a mistake is low.<\/p>\n
Recovery cost varies by task. A refactored function takes seconds to revert; you just revert the commit, but a dropped production table might take your entire week, if recovery is even possible. <\/p>\n
The question before you run a task: can this be undone?<\/p>\n
If yes, let the agent move. If no, add a checkpoint before it runs.<\/p>\n
Here\u2019s the permission matrix I work from:<\/p>\n
![\"Table](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/06\/ChatGPT-Image-May-26-2026-05_28_33-PM-1-1024x768.png\")
Table showing recommended agent autonomy levels and human review requirements by task type. Small refactors and unit tests can have high agent autonomy, while API changes, dependencies, migrations, security, infrastructure, and production deployment require increasing levels of human review. Image by Author and ChatGPT.<\/p>\n
The categories that should always require a human<\/p>\n
Some categories require a human checkpoint regardless of how well-specified the task is. <\/p>\n
The risk of a mistake is too high, and the recovery cost too steep, to let an agent decide on its own.<\/p>\n
![\"What](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/06\/ChatGPT-Image-May-27-2026-03_20_21-PM-2-1024x768.png\")
Image by Author and ChatGPT.<\/p>\n
Destructive file operations<\/p>\n
`rm -rf`, `git clean -fd`, `git reset –hard`.<\/p>\n
These delete or discard work that may not be recoverable. <\/p>\n
An agent will run them if the task description implies cleanup. <\/p>\n
I\u2019ve had one run `git clean -fd` in the middle of a refactor because the task said \u201cclean up temporary files.\u201d <\/p>\n
My uncommitted work was gone. There was no malfunction, as the agent did exactly what the words said. The safeguard is an explicit block list with a confirmation step, not trusting the agent to infer where \u201cclean up\u201d ends.<\/p>\n
2. Database writes and migrations<\/p>\n
Any DELETE without a WHERE clause, any DROP or TRUNCATE, any schema migration touching production data.<\/p>\n
A typo in a WHERE clause can wipe a table. A migration that runs out of order can corrupt data that\u2019s impossible to reconstruct. Always review before running.<\/p>\n
3. Cloud infrastructure<\/p>\n
`terraform apply`, `kubectl delete`, `aws iam *`, `gcloud iam *`.<\/p>\n
Infrastructure changes affect live systems and often other teams. Permissions changes are especially dangerous because the damage can be invisible until something fails.<\/p>\n
![\"What](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/06\/ChatGPT-Image-May-27-2026-03_20_21-PM-3-1024x768.png\")
Image by Author and ChatGPT.<\/p>\n
4. Production deployments<\/p>\n
Any deployment to a production environment should go through a human review step, even if the code was agent-generated. <\/p>\n
CI\/CD pipelines can run agent output automatically, and that\u2019s fine. The decision to deploy to production is yours. <\/p>\n
You know what\u2019s in flight, what incidents are open, what maintenance is scheduled. The agent doesn\u2019t have any of that context, and it can\u2019t ask for it mid-pipeline.<\/p>\n
5. Auth and security logic<\/p>\n
Authentication flows, authorization rules, token handling, session management.<\/p>\n
Bugs here don\u2019t show up in unit tests, they show up in incident reports, sometimes months later. <\/p>\n
An agent writing auth logic will produce something that looks correct and passes the happy path. <\/p>\n
The dangerous cases are the edge conditions: a token that doesn\u2019t expire under a specific sequence of API calls, a route that bypasses middleware when a parameter is missing. <\/p>\n
Those are exactly what unit tests miss and what security review catches. Every auth change needs a human who\u2019s specifically looking for those gaps, not one who\u2019s satisfied the happy path is covered.<\/p>\n
6. Secrets, `.env`files, API keys<\/p>\n
An agent reading or writing credentials creates exposure risk. Keep this category off-limits by default and handle it manually.<\/p>\n
git push –force sits in its own category because it rewrites history on the remote. Once pushed, other contributors\u2019 local branches diverge. Recovery is painful and sometimes impossible.<\/p>\n
Humans should be careful with all of these commands too. Agents just make them easier to trigger by accident, buried inside a longer sequence of otherwise safe steps.<\/p>\n
AGENTS.md: write the contract<\/p>\n
Give agents specific structure from the start. An AGENTS.md file at the root of your repo tells the agent what the project is, how to run it, and what it\u2019s not allowed to touch without asking.<\/p>\n
A vague AGENTS.md gets you an agent filling gaps with guesses. I learned this on a codebase that had no AGENTS.md at all. <\/p>\n
The task was \u201corganize the project structure.\u201d The agent moved files across directories based on naming conventions that made sense to it. Everything that referenced those paths broke. <\/p>\n
The task took the agent twenty minutes; the cleanup took me two hours. Three lines of scope constraints would have prevented it entirely.<\/p>\n
Here\u2019s the template I use:<\/p>\n
# AGENTS.md<\/p>\n
## Project<\/p>\n
[Brief description of the project and tech stack]<\/p>\n
## Setup<\/p>\n
\\`\\`\\`bash<\/p>\n
# Install<\/p>\n
npm install \u00a0# or pip install -r requirements.txt<\/p>\n
# Run<\/p>\n
npm run dev<\/p>\n
# Test<\/p>\n
npm test<\/p>\n
# Lint<\/p>\n
npm run lint<\/p>\n
\\`\\`\\`<\/p>\n
## Coding rules<\/p>\n
– Make minimal changes. Don’t refactor unrelated code.<\/p>\n
– If behavior changes, add or update tests.<\/p>\n
– Don’t touch files outside the scope of the task.<\/p>\n
– Keep diffs readable. One concern per commit.<\/p>\n
## Safety rules<\/p>\n
Ask before running any command in blocked_commands.md.<\/p>\n
If you’re unsure whether a command is safe, stop and ask.<\/p>\n
## Definition of done<\/p>\n
– Tests pass<\/p>\n
– Diff is explainable in one sentence<\/p>\n
– Final report provided (see below)<\/p>\n
## Final report format<\/p>\n
After every task, provide:<\/p>\n
1. Summary of changes<\/p>\n
2. Files changed<\/p>\n
3. Tests run and result<\/p>\n
4. Risks or assumptions<\/p>\n
5. Anything not completed<\/p>\n
“`<\/p>\n
The companion file, blocked_commands.md, lists exactly what needs human approval before running:<\/p>\n
# blocked_commands.md<\/p>\n
## Destructive file operations<\/p>\n
– rm -rf<\/p>\n
– git clean -fd<\/p>\n
– git reset –hard<\/p>\n
## Git operations<\/p>\n
– git push –force<\/p>\n
– git push –force-with-lease<\/p>\n
## Database operations<\/p>\n
– DROP TABLE<\/p>\n
– TRUNCATE TABLE<\/p>\n
– DELETE without WHERE clause<\/p>\n
– Any migration that alters a production schema<\/p>\n
## Cloud \/ infrastructure<\/p>\n
– terraform apply<\/p>\n
– kubectl delete<\/p>\n
– aws iam *<\/p>\n
– gcloud iam *<\/p>\n
## Secrets<\/p>\n
– Any command reading or writing .env files<\/p>\n
– Any command touching API keys or credentials<\/p>\n
When the AGENTS.md is vague, the agent guesses. When it\u2019s specific, the agent executes, and so the file is your contract. Write it before you start the task, not after something breaks.<\/p>\n
Check my two latest articles where you can learn how to give your AI unlimited <\/a>context<\/a> and explore six common hard decisions<\/a> AI Engineers need to make in production. <\/p>\n The two-agent loop<\/p>\n For anything medium-complexity or above, don\u2019t use one agent, use two.<\/p>\n Agent 1 implements. Agent 2 reviews. Then Agent 1 applies only the critical feedback.<\/p>\n Implementer prompt:<\/p>\n You are a senior software engineer implementing a specific task.<\/p>\n Task: [describe the task]<\/p>\n Context: [link to AGENTS.md or paste relevant sections]<\/p>\n Rules:<\/p>\n – Make minimal changes.<\/p>\n – Stay in scope.<\/p>\n – Don’t refactor unrelated code.<\/p>\n – Add tests if behavior changes.<\/p>\n – When done, provide a final report: summary, files changed,<\/p>\n \u00a0 tests run, risks, anything incomplete.<\/p>\n Reviewer prompt:<\/p>\n You are a code reviewer with no attachment to the implementation.<\/p>\n Review this diff: [paste diff]<\/p>\n Check for:<\/p>\n – Bugs and edge cases<\/p>\n – Missing tests<\/p>\n – Security issues<\/p>\n – Unintended behavior changes<\/p>\n – Anything outside the stated scope<\/p>\n Output:<\/p>\n – Critical issues (must fix)<\/p>\n – Minor issues (optional)<\/p>\n – Anything you’d flag for a human<\/p>\n Do not rewrite the code. Flag, don’t fix.<\/p>\n The reviewer agent has no ego investment in the code. It looks for bugs, edge cases, test coverage, and security issues without trying to redo the work.<\/p>\n Code review is how you catch what you missed. The two-agent loop is the same process, automated.<\/p>\n The final report<\/p>\n Require a final report for every agent task:<\/p>\n 1. Summary of changes<\/p>\n 2. Files changed<\/p>\n 3. Tests run and result<\/p>\n 4. Risks or assumptions<\/p>\n 5. Anything not completed<\/p>\n This makes the agent accountable. If it can\u2019t summarize what it did in clear terms, that\u2019s a signal the task wasn\u2019t clean.<\/p>\n It also builds up documentation without you writing it manually. The reports stack. When something breaks a week later, you can trace back exactly what changed and why.<\/p>\n The unglamorous work<\/p>\n The hype around AI agents is here to stay, and mostly earned. They do increase your output.<\/p>\n The practitioners getting the most from them are the ones who did the setup work: wrote the AGENTS.md, thought through the permission levels, built the blocked commands list, set up the two-agent loop.<\/p>\n Agents work well when they have clear instructions. That part is on you.<\/p>\n Thanks for reading!<\/p>\n You can find me on LinkedIn<\/a> and Substack<\/a>, where I share more details regarding AI and LLM.<\/p>\n","protected":false},"excerpt":{"rendered":"focuses on what they can do. Autonomy gets framed as the goal: give them tools, give them access,…\n","protected":false},"author":2,"featured_media":61519,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[511,405,25,7537,6590,415,9007],"class_list":["post-61518","post","type-post","status-publish","format-standard","has-post-thumbnail","category-agentic-ai","tag-ai-agent","tag-ai-agents","tag-artificial-intelligence","tag-artificial-intelligence-agents","tag-editors-pick","tag-llm","tag-llm-applications"],"_links":{"self":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/61518","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/comments?post=61518"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/61518\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media\/61519"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media?parent=61518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/categories?post=61518"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/tags?post=61518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"The](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/06\/ChatGPT-Image-May-27-2026-03_20_25-PM-8-1024x768.png\")
Image by Author and ChatGPT.<\/p>\n