Your AI playbook needs one current version

The procedure in Drive says to use the new template. The agent’s instructions still contain the old one. A teammate has a third copy saved from last month’s conversation.

Everyone is following the playbook. They are following different playbooks.

A reusable instruction needs a current version that people and agents can identify. Saving the instruction once only solves the first part of the problem.

A shared format can remove one source of copying

Google’s October 5 update for Drive and Docs introduced viewing, editing, and collaboration on Markdown files in Docs without converting their file type, plus rendered previews in Drive. The announcement describes a gradual rollout.

Markdown is relevant because many agent instructions already live in that text format. Allowing colleagues to review the same file can reduce the temptation to maintain a separate readable copy.

It does not establish which file your agent actually loads. That connection still needs to be explicit.

Name the authority, not just the filename

Consider a hypothetical team preparing a weekly customer-service recap. Its playbook defines the reporting window, what counts as unresolved, and which details stay internal.

The owner edits the document. The agent keeps using a copied instruction from a repository. The output remains polished, so nobody notices the reporting rule changed.

Choose one authoritative editing location for this procedure. Give the procedure an owner and a stable identifier. Record the approved revision and when it becomes effective.

If a runtime needs a separate installed copy, treat that copy as a published artifact with a known source revision. The important thing is that the relationship is inspectable. A team can use a document editor and a repository without pretending they are automatically synchronized.

Item	What it should establish
Authoritative source	Where an approved change begins
Approved revision	Which instructions are ready to use
Installed revision	Which instructions the agent actually loads
Run record	Which revision governed this particular output

Avoid using the word “latest” as the only identifier. It describes a relationship that can change while you are investigating an old result.

Publishing a procedure is a small release

Separate a proposed edit from an accepted operating rule. For a low-impact wording improvement, the review may be brief. A change to who receives a report or which records are included deserves a more deliberate check.

Use a sanitized example with a known expected result. Run the revised procedure against it and compare the behavior that the edit was supposed to change. Check one case that should remain the same.

Then install the approved revision and verify the active copy. Asking the agent which version it thinks it uses can help surface confusion, but inspect the configured file or published artifact as well. A confident answer is not a deployment receipt.

Keep the previous approved revision available for recovery. If the new procedure fails, restore a known version and record the reason instead of editing history until the output looks acceptable.

Try the two-reader test

Ask a teammate and an agent, separately, to locate the current rule for the same recurring job. Do not hand either one your preferred document link first.

Compare the source identifiers and revisions they use. If they differ, fix the discovery path or installation process before rewriting the procedure again.

The test succeeds when both can find the approved rule, the installed copy matches it, and a run leaves enough information to explain which version was used. It does not require a complicated document-management platform.

Reduce the copies that can give orders

Old examples can stay useful as history. Label them as history and remove their authority to direct current work. Link them to the current source where practical.

For when to create a reusable procedure in the first place, read Stop Re-Explaining Yourself to Your AI. Once that procedure exists, the next job is making sure the whole team is using the same approved version.

Source and scope

Google Workspace: native Markdown collaboration in Drive and Docs, October 5, 2026. Native editing is a vendor-described capability, not automatic synchronization with agent runtimes. The recap workflow and revision checks are illustrative recommendations.