How to build a librarian agent that keeps SOPs current

In 60 seconds: Build a librarian agent that keeps evidence, proposals, and published SOPs distinct. First declare which system is authoritative for each document type and who owns it. Then organize the second brain around processes, rules, exceptions, and owners; store operating rules as team-editable data rather than inside the prompt; and connect change signals such as resolved tickets, system changes, or review dates. The agent finds contradictions and prepares a diff with sources, impact, and confidence. A person approves the exact content before it replaces the current version. Start with one recurring process and measure change coverage, the review queue, unresolved contradictions, and human corrections. The goal is to help the team maintain its operational memory, not make the model the process owner.

In an operations team, someone learns that a particular order exception is no longer handled the way the manual describes. They resolve it, post an update in chat, and return to work. Months later, another person finds the old SOP, follows the published steps, and discovers too late that the system changed.

A distributor may face a similar gap: the procedure says an approval happens by email, while the team now records it in the ERP. Actual practice, approved policy, and published documentation begin telling different stories.

A librarian agent helps close that loop. It does not write company policy or decide which version “sounds better.” It observes authorized sources, relates evidence to the affected SOP, proposes an amendment, and routes that proposal to the right owner. The final outcome remains a human, auditable decision.

This field note continues the “How to build an X agent” series. The order orchestration agent depends on current exception procedures, while the post-sale support agent depends on approved knowledge when answering customers. The librarian works behind both: it keeps instructions reviewable without inheriting their operational authority.

1. Define the job and its stopping point

“Keep documentation current” is too broad to build. The first contract can be written as an observable transition:

change signal
  -> SOP and owner identified
  -> evidence gathered + contradictions exposed
  -> change proposal
  -> human approval or rejection
  -> published version + decision record

The agent may read, compare, classify, and draft. It should not publish silently or turn one conversation into policy. Its work ends in one of these states:

• proposal pending, with a reviewer and date;
• proposal approved and published through the authorized workflow;
• proposal rejected, with a reason;
• insufficient evidence, assigned to the process owner; or
• source conflict requiring a decision.

“The document was updated” is not enough. The record should show what changed, why, which sources were consulted, who approved it, and which version became current.

2. Declare which source governs each fact

The agent cannot resolve contradictions if every folder, chat, and system has equal authority. Build a source register before connecting it.

Content	Authoritative source	Secondary evidence	Rule when they differ
Published SOP	Declared document library or repository	Exported copies, PDFs shared in chat	A copy does not replace the published version
Policy and boundaries	Record approved by the responsible function	Messages, minutes, tickets	Escalate to the owner; do not infer a new rule
Actual system sequence	Current configuration, API, or system manual	Screenshots and recordings	Flag the SOP as potentially stale
Resolved exceptions	Case or ticket system	Internal chat	Propose an exception only with a traceable case and resolution
Owners	Approved directory or operating matrix	Document signature	Request reassignment if the owner is no longer valid
Compliance rule	Applicable legal, security, quality, or regulatory owner	Internal summaries	Block publication until specialist review

For each source, store scope, location, owner, audience, permissions, version or effective date, and retention policy. The published system might be SharePoint, a wiki, a repository, or another library. The contract matters more than the brand.

Chats and meetings are useful sensors. They may indicate that practice changed, but they should not become normative sources by themselves. If someone writes “we do it differently as of today,” the agent opens a proposal and asks for evidence; it does not rewrite the SOP.

3. Structure the second brain to retrieve decisions

A folder full of files is not yet an operational second brain. The agent must retrieve the correct unit without mixing a published procedure with a draft or a local exception.

Use four layers:

1. Processes. Purpose, scope, triggering event, expected outcome, involved systems, and related SOPs.
2. Rules. Explicit conditions governing a decision: who may approve, which fields are required, or which transition is allowed.
3. Exceptions. Conditions outside the standard path, required evidence, owner, and return condition.
4. Owners. Process owner, each SOP owner, delegated reviewers, and the team that performs the work.

Each SOP should carry minimum metadata:

sop_id: OPS-ORDER-014
status: published
owner: operations-order-management
reviewers: [finance, warehouse]
audience: order-operations
systems: [erp, warehouse-management]
effective_from: 2026-09-01
review_by: 2026-12-01
supersedes: OPS-ORDER-014@6
related_rules: [RULE-CREDIT-03, RULE-STOCK-08]

The names are illustrative. Adapt them to the team’s existing vocabulary. What matters is preserving stable IDs and distinguishing draft, pending_review, published, superseded, and retired. The search surface used by people and agents should return the published version applicable to their audience by default without hiding that a proposal is pending.

This resembles the second-brain pattern for case files: separating the archive, index, status, and permissions avoids depending on the model to “remember” where everything lives.

4. Move operating rules out of the prompt

A prompt can explain the agent’s role: compare sources, never publish without approval, show evidence, and stop on conflicts. It should not contain the live list of approvers, deadlines, ERP states, or exception conditions.

Store those rules in a team-editable registry with a schema and version control. For example:

Field	Example	Who edits it
rule_id	RULE-STOCK-08	Operations owner
applies_to	Local orders with confirmed stock	Process owner
condition	ERP returns a valid reservation	Operations and systems
required_evidence	Reservation ID and query time	Operations
approver_role	Warehouse supervisor	Function owner
effective_from / expires_at	Validity window	Rule owner
fallback	Create a stock exception	Process owner

The agent reads the current version on every run and retains the rule ID it used. A rule change goes through its own review path. The team can then correct policy without deploying code or editing hidden instructions, and an audit can reconstruct which rule informed each proposal.

Do not turn free text into a decision engine without controls. Fields that block or enable actions need types, allowed values, and dates. The model may explain a rule or locate the affected section; the deterministic layer decides whether the rule is current and who may approve it.

5. Give it narrow tools and separate permissions

The agent needs limited operations, not a personal credential with access to all company knowledge:

1. Document index. Search only permitted collections and audiences; return the excerpt, ID, version, status, and review date.
2. Rule registry. Read current rules and submit structured amendments. Do not modify the published version directly.
3. Signal reader. Query authorized events from tickets, system changes, releases, or incidents. Each signal must link back to its original source.
4. Review queue. Create a proposal with a diff, evidence, impact, open questions, and reviewer. Return an ID and retain each decision.
5. Controlled publisher. Accept only an approved proposal, verify that the content and base version have not changed, publish a new version, and read back the result.

Separate read, propose, approve, and publish as distinct permissions. A reviewer needs to see the exact diff, not only the agent’s summary. If a sentence, source, attachment, or base version changes, the previous approval no longer applies.

Apply least privilege to reviewers too. A warehouse owner may approve their procedure without gaining access to HR documentation or contracts. Do not index secrets, credentials, unnecessary personal data, or content outside the agent’s audience.

6. Design the proposal before the write

The unit of work is a change proposal, not a fully rewritten document. A reviewable payload may include:

proposal_id
sop_id + base_version
sections_affected
before / after diff
reason_code
source_ids + timestamps
conflicts_found
impact_area
confidence + unknowns
owner + required_reviewers

Use stable reason codes: system change, policy change, repeated exception, overdue review date, invalid owner, or document conflict. Confidence may order the queue; it does not replace approval.

The minimum cycle is:

1. Deduplicate the signal and locate the applicable SOP.
2. Re-read the published version, its rules, and open proposals.
3. Retrieve evidence with permissions and dates.
4. Prepare a small diff; leave explicit questions where information is missing.
5. Route it to the owner and any additional reviewers required by policy.
6. Approve, request changes, or reject the exact payload.
7. Verify that the base version is still current.
8. Publish through the authorized interface and read back the new version.
9. Notify the affected audience and preserve the decision record.

If two people edit the same SOP, version control should block publication built against a stale base. The agent regenerates the diff; it does not silently merge human decisions.

7. Detect staleness with signals, not guesses

A review date is a signal, not automatic proof that content is wrong. Combine several detectors:

Signal	What the agent compares	Safe outcome
Overdue review	review_by against the current date	Task for the owner; no SOP change
Contradiction	Two published instructions applying to the same condition	Block or warning with both sources
System change	Current fields, screens, states, or permissions against the procedure	Proposal targeting the affected steps
Resolved exception	Repeated traceable cases against documented exceptions	Candidate rule or exception; no automatic publication
Invalid link or owner	Inaccessible destination or missing responsible person	Administrative repair for review
Practice-document gap	Authorized operating evidence against the SOP	Question for the owner; frequency does not grant authority

Expiry rules should reflect process risk and rate of change. Do not invent one universal review calendar. A procedure affected by an ERP change may need immediate review; a stable procedure may follow its agreed cycle.

Preserve useful negative results too: “insufficient evidence,” “two authorized sources conflict,” or “owner not found.” Forcing a conclusion turns missing documentation into a false instruction.

8. Keep a person accountable for every SOP

The agent supports four time-consuming jobs: inventory, comparison, change preparation, and review follow-up. Accountability still belongs to named people:

Role	Responsibility
Process owner	Defines policy and resolves business conflicts
SOP owner	Maintains scope, currency, audience, and reviewers
Specialist reviewer	Validates security, legal, finance, quality, or system effects
Operating team	Reports friction and evidence that instructions differ from operations
Agent administrator	Maintains connectors, permissions, evaluations, and incident response

A document without an owner is an open exception. Do not resolve it by assigning the agent. If the team does not know who may approve a rule, that is a governance problem and should remain visible.

The NIST AI RMF Playbook suggests defining human oversight roles and responsibilities for AI systems. Here that means naming who reviews each change type, what evidence they need, and how they stop or reverse a publication.

9. Start with a scope the team can review

Choose one recurring process, one document collection, one rule family, and one owning team. A good first case has observable changes, version history, and enough recent examples to test contradictions and proposals. Avoid starting with legal policy, security-critical procedures, or ownerless processes.

Begin in shadow mode: the agent indexes, detects, and drafts, but no proposal changes the published version. Review whether it chose the correct SOP, whether the sources justify the amendment, whether the diff is minimal, and whether it reached the right person.

You can then enable the approval and controlled-publishing workflow. Keep human review for every change. Initial autonomy belongs in evidence gathering, proposal creation, and routing—not policy decisions.

Measure signals the team can audit:

Signal	Local definition
Change coverage	Eligible signals ending in a proposal, decision, or justified closure / eligible signals reviewed
Proposal quality	Proposals approved unchanged, edited, rejected, or closed for insufficient evidence
Review queue	Open proposals by age, owner, and blocking reason
Document conflict	Open, resolved, and reopened contradictions by process
Currency	SOPs within the agreed review cycle and overdue SOPs with an assigned owner
Control failures	Publications without approval, against a stale version, or outside the permitted audience; operationally, these should not occur

Capture a baseline before the pilot and retain counts and denominators. Do not treat proposals produced as a success metric: an agent that generates unnecessary amendments only creates another inbox.

10. Know when not to build it

Do not build the agent yet if the team cannot identify the current copy, nobody can approve changes, the systems do not preserve versions, or document access ignores audiences. It is also a poor fit when documentation mixes personal data or secrets without classification, or when almost every decision depends on oral context that cannot be verified.

First name owners, consolidate duplicates, define states, and introduce a manual proposal-and-approval path. The agent amplifies that contract; it does not replace it.

Keep the scope focused on team support. The librarian does not evaluate employee performance, turn exceptions into sanctions, or delete historical versions. Its value is giving each operating decision a visible path into the published instruction.

Sources and currency

Official sources reviewed on October 11, 2026. Control CM-3 in NIST SP 800-53 Rev. 5 describes a cycle for proposing, reviewing, approving or rejecting, documenting, implementing, and monitoring controlled changes; we use it as a design reference, not as a general regulatory requirement. Microsoft’s documentation on versioning and content approval confirms that a document library can preserve versions and keep a draft pending until approval; SharePoint is an example capability, not a mandatory recommendation. Each business should validate its applicable rules and obligations with the responsible owners.

Kiia can map the sources, owners, and approval flow for one process before connecting an agent. Bring current SOPs, recent changes, and anonymized exceptions: that is enough to identify a safe first scope and a real baseline.