How to Make Your AI Coding Agents More Autonomous and Reliable

Have you ever handed an AI agent a task, gone to grab a coffee ☕ and come back to find… a question? 😅

”I’ve finished step 1. Shall I continue?” 🙈

Yes. Yes, please continue.

That was the whole point of the coffee.

And then, of course, there’s the opposite moment.

The moment where the agent didn’t stop to ask and we’re suddenly staring at a force-pushed branch or a brand new dependency we never agreed to. 🙈

Too timid, or too brave. Rarely just right.

The good news?

Whether we work with Claude, Gemini or GPT, the fix is the same: one small instruction file that tells the agent when to keep going, when to stop and how to report back.

In the next few minutes, we’ll build that file together, section by section, and make sure every major coding agent from different vendores actually reads it.

So let’s get started! 🙌

Giving our AI Agent instructions

Think of an AI coding agent as a brand new team member.

Capable, fast, eager to help.

But without knowledge about how we work, what is allowed and what is not.

So we will build a small instructions file that the agent reads at the start of every session without having to repeat ourselves in every prompt.

The instructions file has 4 sections:

• autonomy: what the agent CAN DO without asking
• boundaries: what the agent CAN NOT DO without asking
• verification: what the agent should do to verify that something works as expected
• report: how the agent should report back to us

Let’s dive into each section in more detail.

Section 1: autonomy, or “please stop asking”

Let’s start by telling the agent what is allowed without asking:

## Autonomy

- When a step doesn't need my input, keep going.
- Put status notes in the same message as your next action.
- Don't end a turn just to report progress.
- Don't stop to offer continuation, to list choices that don't block the
work or to summarise a next step instead of taking it.

It’s important to be specific.

“Be autonomous” is vague and models like to fill vague instructions with their own defaults. Naming the exact behaviours we don’t want gives the model something concrete to steer away from.

Section 2: boundaries, or the “stop-and-ask” list

Autonomy is only safe when the boundaries are crystal clear.

So let’s add a section to tell the agent when to first ask for approval:

## Stop and ask

Stop and ask me first before any of these, every time:

- Deleting data: removing tracked files, dropping tables, deleting branches.
- Rewriting history: `git push --force`, rebasing a shared branch,
 amending pushed commits.
- Anything outside the current repository: global config, `~/.ssh`,
 system settings, files above the project root.
- External writes: opening or merging a PR, pushing to a remote,
 deploying, calling production or paid APIs, sending messages.
- New dependencies: installing packages, editing `package.json` or lockfiles.

Otherwise, keep going.

Every item represents something that is hard to undo or something that is completely forbidden for the agent.

If a mistake would take more than a git checkout to fix, it belongs on the boundaries list.

The line ”Otherwise, keep going” tells the agent that everything else is green light. 🟢

Section 3: verification, or “don’t just tell me it works”

You may have noticed that almost every model from every vendor has the “charming” habit to confidently announce that something works even when it doesn’t 😅

The following section that tells the agent to verify claims first:

## Verification

- Review your own diff before I do.
- List only problems you'd block the merge for.
- For each: file and line, why it's wrong, and how to show it fails.
- Don't claim something works because it should. Run it.
- If you couldn't verify a claim, mark it as unverified and say what you tried.

Asking the agent to mark unverified parts as unverified can turn a scary 600-line diff into a short list of things for us to double-check.

Section 4: a report we can read in ten seconds

Finally, let’s add a section that instructs the agent to give us a short report when the work is done:

## Reporting

End every run with three headings, in this order:

- Blocked on me: decisions left open, approvals needed. Omit if empty.
- Changed: what you actually did.
- Found: anything surprising, including problems you didn't fix.

Plain language. No recap of steps I watched happen.

The “Found” heading asks the agent to tell us about things (e.g. a flaky test or a suspicious config it noticed along the way) it did not fix but that we really want to know about.

Making every agent read the instructions

Models from different vendors look for their instructions in different places:
- OpenAI Codex: AGENTS.md
- Gemini CLI: GEMINI.md (configurable)
- Claude Code: CLAUDE.md

AGENTS.md is becoming the shared standard, and many other tools, including Cursor and GitHub Copilot, now read it too.

So let’s make AGENTS.md our single source of truth and point everything else at it.

For Codex, we’re already done. 🎉

For Claude Code we create a tiny CLAUDE.md that imports it:

<!– CLAUDE.md -->
@AGENTS.md

<!-- Claude-specific notes, if any, go below this line -->

For Gemini CLI, we tell it to look for AGENTS.md in .gemini/settings.json:

{
 "context": {
   "fileName": ["AGENTS.md", "GEMINI.md"]
 }
}

That gives us one file to edit and agents from different vendors reading the same instructions, with no drift between copies. 🙌

AI tools move fast. Before you copy this, check the official docs for your version: the exact file names and settings keys have changed more than once this year.

Summary

Every major coding agent reads an instruction file at the start of a session.

We can use it to instruct the agent when to keep going, when to stop and ask for approval, how to verify claims and how to report back.

By keeping all instructions in one AGENTS.md, importing it from CLAUDE.md, and pointing Gemini at it, we can let every agent follow the same house rules.

Now go create your custom instructions and enjoy your coffee. ☕

Have a great one!

🙏 🙇

PS: As a reference, here is a full instructions file from this article:

## Autonomy

- When a step doesn't need my input, keep going.
- Put status notes in the same message as your next action.
- Don't end a turn just to report progress.
- Don't stop to offer continuation, to list choices that don't block the
work or to summarise a next step instead of taking it.

## Stop and ask

Stop and ask me first before any of these, every time:

- Deleting data: removing tracked files, dropping tables, deleting branches.
- Rewriting history: `git push --force`, rebasing a shared branch,
 amending pushed commits.
- Anything outside the current repository: global config, `~/.ssh`,
 system settings, files above the project root.
- External writes: opening or merging a PR, pushing to a remote,
 deploying, calling production or paid APIs, sending messages.
- New dependencies: installing packages, editing `package.json` or lockfiles.

Otherwise, keep going.

## Verification

- Review your own diff before I do.
- List only problems you'd block the merge for.
- For each: file and line, why it's wrong, and how to show it fails.
- Don't claim something works because it should. Run it.
- If you couldn't verify a claim, mark it as unverified and say what you tried.

## Reporting

End every run with three headings, in this order:

- Blocked on me: decisions left open, approvals needed. Omit if empty.
- Changed: what you actually did.
- Found: anything surprising, including problems you didn't fix.

Plain language. No recap of steps I watched happen.