On a Monday in May, an AI tool called Kimi was given a new job and a short leash.
Kimi could start small helpers inside itself. The helpers that looked around and made plans were meant, by default, mostly to read. The helper that wrote code was different. It could be used only on a turn when the Operator had clearly said yes to writing.
A turn is one round of a conversation. He sends a message, and the AI answers and acts. When the turn ended, the yes ran out. The next turn started over at no.
Here is the odd part. Just the day before, a rule had been added to the same company’s files that seemed to point the other way. Its message to every AI agent was, in short: look it up before you ask him.
So which was it? Were the agents supposed to ask the Operator less, or more?
This is a true story, told as a fable. Most of it happened in three days.
Who’s who
- The Operator The founder, and the only human here. The company’s chart called his role Orchestrator.
- The Team Lead An AI assistant that turns his plain words into written work orders.
- The Developer An AI tool that does the work inside the company’s files.
- The Auditor Kimi, an AI tool that started out on the list of Developers.
Saturday: who does what
Once upon a time, which is to say on a Saturday, three changes were saved to the company’s files within seven seconds.
Every change to those files is saved with a time and a short note. These three were saved under the Operator’s account. Who typed them is not recorded.
One rewrote the front page, which now said, “Day-to-day work uses a three-role pattern …” One added a plan file: a list of planned work and where each piece stood. The third added a chart of who does what. About that chart, the plan file said: “Drafted in chat.” It does not say which chat, or with whom.
The chart began with a claim: “Software development with AI in 2026 is not a single conversation with a single model.” Then it set out three roles, like jobs in a small workshop.
First came the Orchestrator, the Operator himself. He “Makes the architectural decisions. Owns quality.” And, firmly: “Cannot be replaced by AI; should not delegate this role.”
Next came the Team Lead. Its job was to turn the Operator’s plain talk into written work orders. It did not run code itself. The chart was clear: “This role does not execute code or run shell commands directly.”
Last came the Developer, the AI that worked inside the files. Its description began: “Executes. Reads files. Writes files. Runs commands. …”
Work moved one way. The Team Lead wrote the orders, and the Developer carried them out. The chart said, “The AI developer never decides what to build …” One more line put the Operator in the middle: “The orchestrator reviews the meta-prompt before it goes to the AI developer.” A meta-prompt is a work order that one AI writes for another. Every order would cross his desk first.
Why go to such trouble? The chart named the mess it meant to stop. A common mistake, it said, was using one AI for all three jobs. You pour your loose thoughts into it. It tries to guess what you mean and do it, both at once. The work goes off the rails, and the “… orchestrator can’t tell where it broke.”
Three roles were the cure: “Three checkpoints, three sets of eyes (one human, one team lead, one developer). …”
There is just one catch with a desk that every order crosses. It can also become the first stop for every question.
Sunday: look before you knock
On Sunday, a new rule was saved. It was called the Search-First Discipline. The note saved with it gave the goal: “… so future agent sessions stop halting on facts already on disk.”
In plain English: agents should stop pausing their work to ask the Operator about things already written down in the files. Call that pause a knock on his door.
The rule said what it was for. It turned “… the operator’s recurring complaint …” into a written rule. As the rule told it, the complaint was about an agent that had stopped to ask about something already in the plan file. Written down, the rule said, “… every future session inherits the rule instead of being re-trained turn by turn.” That way, the idea went, no new AI session would need the lesson taught again.
The rule itself was simple. Before any agent asks the Operator a question, or stops for “missing context,” it has to look first. The search has limits, but it must happen, and it must “… prove the gap is real.”
The first bad habit on its list was a question you can almost hear: “What sprint are we on?” A sprint is a short stretch of planned work, and the plan file was where that answer lived. The habit was asking before opening it.
And when an agent could go ahead without asking, but was working from a guess? Then it had to say so in one line, like this: “Proceeding under assumption X (verified via Y).” If the Operator disagreed, “… one short turn corrects the path …”
Not every knock was banned. The real stops stayed: secrets; anything that destroys, costs money or touches live systems; merging work into the main copy; and a choice between several equally safe paths. The rule even guarded itself against growing: “This policy reduces unnecessary halts; it does not become a vehicle for adding new ones.”
One line summed it up: “Halt is not a failure; halt-without-evidence is.”
Stopping to ask was fine. Stopping to ask without looking was not.
That seemed settled. Then, on Monday, a new character got its job, and its rules held a different kind of asking.
Monday: the second opinion
On Monday, another document was saved. It gave each AI tool one fixed role.
On Saturday, Kimi had been listed as one of the Developers. Now it was given a job of its own. The records do not say why. It became the Auditor. In the document’s words: “Treated as a separate opinion that runs in parallel with Claude Code, not as a Claude Code substitute.” Claude Code was another of the Developers.
Think of a second doctor. A second doctor who only repeats the first one is no help. The document said nearly that: “… if Kimi just paraphrases what Claude Code already said, the lane has failed its purpose.” So the Auditor was asked to say where it disagreed, when it could, before it saw the main worker’s final answer.
It also got a rule that sounded like Sunday’s: “A Kimi finding without evidence is a defect.” Two days, two rules, one idea: show your evidence.
And it got the leash from the start of this story. Its writing helper was only for a turn when the Operator “… has explicitly authorized writes for this turn.” The document said it again, another way: “Authorization is granted for one turn at a time and lapses at turn boundary.”
A permission slip, good for one turn.
About an hour later, something new showed up in the record. Another change was saved, this one about how the plan file should be run. Its note said: “Kimi audit applied before commit …” It was the first saved note in the record to report a Kimi audit changing work before that work was saved.
The changes from that first recorded audit were small. Three fixes were applied. One trimmed 39 characters from a wordy description, to give it room again. One made a line clearer: did it mean the middle of a stretch of work, or the end? And one took out the “34 others” count, which had been written in as a fixed number.
What Kimi actually said is not recorded. Only the three fixes are.
So, less or more?
Set the two rules side by side, and they turn out to be about two kinds of asking.
Sunday’s rule was about questions of fact, like “What sprint are we on?” Those go to the files first. Monday’s leash was about permission: may this AI write right now? That question went to the Operator, one turn at a time.
One kind of asking was sent away from his door. The other kind stayed there and, for one tool, started over every turn.
September: before and after
Four months later, a line was added to the company’s main rules file. (Authorization means permission.) It reads: “There are no authorization levels, no per-turn … authorization, and no authorization phrases.” The next sentence: “Do not ask again … because a turn ended.”
By that line, a yes no longer runs out when a turn does. No record links it to Monday’s leash. The two are only a before and an after.
Sunday’s rule is still there. The main rules file still sends agents to it before they stop to say “I can’t find it”. And that one line has not changed a word: “Halt is not a failure; halt-without-evidence is.”
The moral: Look before you knock. Save the knock for what only the boss can decide.
What any founder can take from this
- Write each job down, including what it does not do. The chart said of the Team Lead: “This role does
not execute code or run shell commands directly.” A clear “not my job” line keeps three roles from melting into one.
- When you answer the same question twice, write the rule. Ask for a look first, and for any guess to be
stated along with how it was checked. A reminder reaches one person; a written rule reaches every newcomer.
- Make your second opinion truly second. Ask for it before it hears the first answer, and treat a finding
without evidence as a defect.
- Decide how long a yes lasts. A yes that runs out every turn has to be given again every turn.
How this article was made: This story is based on the company’s shared files and their saved change history from May 2 to May 4, 2026, and on its main rules file as it stood on October 14, 2026. Quoted words from those files are exact. Cuts in a quote are marked with ellipses, and the bold type in the September quote is the original’s. Telling it as a fable, with the roles as characters, is our choice. So are the everyday pictures: the desk, the knock on the door, the second doctor and the permission slip.