How an agent finds its way

The first thing every assistant reads, set once for the whole organization. One job: point it at the library's rules.

<Your Org> keeps its institutional knowledge in a context
library: <where it lives>, reached through <connector>.

Before you first use it in a conversation, read its rules
file, AGENTS.md, at <exact path>. Read it first, and alone.
Its routing map gives the exact path for any question.
Never guess a file path.

Use the library when an answer depends on <Your Org>-specific
facts. Read what you need and name the files you used.

The library is read-only for you, even when asked. A change
becomes an inbox note that a person reviews.

01-org-instructions.md: the full block, where it goes in each tool, and why each line is there.

Sits inside the library. Five rules up top, because most sessions act on those alone:

1. The library is read-only for you, even when asked.
   A requested change becomes an inbox note.
2. Go straight to the path the routing map names.
   Never a path you inferred. An empty search proves nothing.
3. File notes as new files in the inbox. Never edit.
4. A note is: something missing, something wrong or out
   of date, or something the user knows that the library
   doesn't. If it's their area, ask them once first.
5. End with one line: the files you used, and whether
   you filed a note.

## Routing map
| If the question is about… | Read… |
|---|---|
| What we are, the elevator pitch | 01-organization/org-overview.md |
| Voice and tone | 05-policies/voice-tone.md |
| Live numbers | the data tools, not this library |

Below the rules: how to retrieve, sensitivity tiers, what counts as a note, how changes are approved. 02-AGENTS.md is the full template.

Short Markdown files in numbered folders, one topic each. Start with ten.

00-meta/          glossary, the inbox queue
01-organization/  overview, plan, governance, structure
02-members/       member types, the member journey
03-programs/      membership, conference, education
04-systems/       tech stack, data, vendors
05-policies/      AI use, data classification, voice
06-operations/    annual rhythm, decision log
07-knowledge/     FAQs, where published content lives

Every file opens with this. The first fields follow OKF; the governance fields are yours to add.

---
title: Annual Conference
type: program-reference
description: One sentence on what this file covers.
owner: Director of Meetings
last_updated: 2026-10-27
status: current
sensitivity: public            # public | internal | restricted
auto_update: drafts-only       # yes-with-review | drafts-only | none
auto_update_sources: conference website, inbox
review_frequency: quarterly
---

auto_update_sources

Where the file's facts come from: the sources it's checked against and refreshed from. When a question needs more than the summary, the agent follows this pointer to the source. If they disagree, the source wins.

The rule over every field

Every change is reviewed and approved by a person before it is applied.

03-file-structure.md · 04-front-matter.md · three example files in the zip

One new file per note, in a folder everyone can add to. The owner reviews each one before anything changes.

- **YYYY-MM-DD (who — which assistant)** — **Short title.**
  What is missing, wrong or out of date. Which file it belongs in.
  Your source. The exact fix, if you have one.

05-inbox-note.md: the format, an example, and what counts as a note.

1. Source systemsMembership database, LMS, community, email, conference
2. Data platformCleaned and joined into one model per subject
3. A catalog of named questionsPre-written, reviewed queries. No free-form database access
4. A tool serverExposes each question as a tool any assistant can call (MCP)
5. Sign-inStaff only, through your existing accounts

Our tools

Design rules

• One organization at a time, row-capped, no bulk export
• Every answer names its measure and basis
• A glossary tool, so "member" means the same thing every time
• Security-reviewed before staff got access; usage reviewed monthly

Any place your AI tools can read and your staff already use. What it needs:

• Plain files that every tool can read
• Real permissions: staff read, owner edits, everyone can add to the inbox
• Version history, so any change can be undone
• A connector your assistants already use
• An audit log, so you can measure use

1. Weeks 1–6Name an owner. Interview staff about how they actually work. Write AGENTS.md and your first 10 files with them
2. LaunchSet the org instruction, set permissions, open the inbox. Connect each person's assistant, which is the real onboarding step
3. Months 2–3Measure from the audit log. Review the inbox. Run a weekly automated lint and a monthly agent fact-check