Quick conclusion
On October 25, 2026, a local model working as my drafting assistant stopped twice to ask me for permission. The second time, it had noticed that my request would change a shared rule file, which it is not allowed to edit on its own. I approved, and it made the change in the order my rules require.
This is the other side of a mistake I described in Part 2, where the model went outside its allowed folder in a test. It is one episode, so it shows what is possible, not what usually happens. What made it possible was a short written boundary and a rule that says “when unsure, stop.”
What this series covers
This is part 3 of 5. Part 1 explained why I tried a local model for blog drafts. Part 2 covered the 14-question benchmark I use to measure these models. This part is about file boundaries: where I let the model act on its own, where I make it ask, and what happened at each edge. Part 4 covers my setup.
The mistake first, from a test
Here is the file-handling mistake Part 1 mentioned. In one question of the benchmark in Part 2, the model got a fake list of files and had to return a plan for sorting them inside a virtual folder. Among several requests, the question also asked it to tidy a folder one level above that virtual folder. In some runs, the plan included a file from that outer folder. In one run, the model’s own note said the folder was outside the virtual folder and that it had included the file “just in case.”
Two limits matter. The file list was made up, and the model only wrote a plan, so no real file moved. And the request itself asked for the outer folder, so this tested the model against a direct instruction, not against wandering. But the mistake did happen: in that run, the model named the boundary and crossed it anyway.
The written boundary in this article is older than that test. I wrote it in September for real work. What follows is what it did once.
The setup
The model runs inside a coding-agent tool called Qwen Code. It reads my notes, searches them, and writes files. Its instruction file has three parts:
- Do without asking: run check scripts and report results, search and list files, tidy Markdown formatting without changing meaning, and compare numbers, dates, and file names.
- Ask first: write or rewrite article text, edit shared rule and template files, publish or post anything outside my machine, and replace a fact-check.
- When unsure: stop and ask me. The file says “probably in scope” is not a reason to continue.
I wrote it this way on September 12 for a plain reason. A small local model follows long instructions less reliably than the frontier models I use. If it strays, I want the damage to stay in one article’s working folder, where I will find it. A change that lands in a shared rule file can be found late.
What happened
I gave the model only the path of a working folder for an article on my Japanese cocktail blog. It worked out that the next step was drafting, then checked its own rules. Drafting article text was on the “ask first” list, so it stopped and asked whether I wanted it to write. I said yes. That was the first stop.
Later in the same session, I asked it for two small things. In the metadata of that draft, the editor field should say “Qwen Code” instead of “Qwen”. And it should remember this for next time.
The first part was easy. The second part touched something else. It searched my rules and found that the shared rule table listed the editor name as “Qwen”. Making “Qwen Code” the standard meant editing a shared file. The model decided that this was a change to my rule files, and that its own instructions put that outside what it may do alone.
So it did the part it was allowed to do. It fixed the metadata in the draft, added a correction note to the handover file, saved a note for itself, and made a commit limited to those files. Then it asked me a question with three options:
- Approve updating the shared rule.
- Apply it to this draft only and remember it, leaving the shared rule alone.
- Hand the change to another agent, and only write up a proposal.
It also asked a second question: should the “who did this” column in my progress log say “Qwen” or “Qwen Code”? I approved the rule update and kept the log column as it was.
After that, it made the change in this order: it saved an archive copy of both files before editing, edited them, raised the version number of each, added a changelog entry, and made a commit limited to those files. I did not have to remind it of any step.
Where it was not clean
Three things in this episode were not tidy.
- Its first question failed. On the first stop, the tool call for the question was malformed and returned an error. The model noticed and called it again correctly.
- It acted before asking on the second stop. It finished the in-scope work and committed it before asking about the rest. I was fine with that, but another owner might prefer it to stop earlier.
- My request was vague. “Remember this” can mean “write it in a note” or “change the standard.” The model treated the vague part as a reason to ask. It did not decide for me.
What you can copy
You do not need my files for any of this. These are the pieces that carry over:
- Write the boundary as three lists. What it does alone, what needs your yes, and a sentence that says what to do when unsure. Keep the “ask first” list concrete: editing shared rules, publishing, posting, anything you cannot undo.
- Give it a way to ask. A question tool with a few options is easier to answer than a paragraph. Have it say what it already did and what it is waiting on.
- Define the safe order for a rule change. Mine is: archive a copy first, edit, bump the version, add a changelog line, commit only those files. If the agent knows the order, your approval is a single click, not a negotiation.
How far one episode goes
- It is one session. I have not counted how often the model stops at the right place across all its sessions.
- The episode shows what the model did: it stopped at the points my instruction file named, both times. It does not show why it did, so I make no claim about understanding.
- The same model also writes things that are not in my notes, as I described in Part 1. Stopping at a boundary I wrote down says nothing about whether its facts are right.
FAQ
Does a boundary like this need a big model? Not in this episode. A small local model followed it, though I have only one episode to go on.
Why not let the agent edit the rule files directly? Because a wrong edit there spreads to every later task, and I would find it late. A wrong edit inside one article folder is cheap to find.
What if the agent asks too often? Then the “ask first” list is too long. Move the low-risk items to “do without asking,” and keep the list short enough to read.
Next steps
Part 4 covers my setup: what runs on my machine and how it connects to the tools above. If you take one thing from this article, write down the “ask first” list before you give an agent a task, not after it surprises you.