5.3 The Knowledge Layer · The Agentic Engineer

Meridian's "how we write a weekly report" knowledge exists in three incompatible places: a Google Doc Sofia wrote in 2023 that is mostly right, a Notion page Grace half-migrated that is more right, and Sofia's head, which is the only fully correct copy and takes a vacation. Point an agent at any one of them and it inherits that source's gaps and staleness. The Knowledge layer's job is to make the business legible to agents: one version-controlled source of truth, written in a shape an agent can actually consume, with a named human who owns keeping it fresh. Get this layer wrong and every layer above it is confidently working from bad information, which is the context-poisoning failure from Part 1 wearing a business suit.

Human SOPs versus agent-consumable specs

A human SOP is written for someone who already has context. It says "pull the usual metrics and write it up the way we do for that client," and a human on the team knows what "the usual" and "the way we do" mean. An agent has none of that shared context, and it will fill the gap with a plausible guess, exactly as lesson 1.4 warned. Rewriting an SOP for an agent means making every implicit thing explicit.

Human SOP (implicit)

"Weekly report: pull the client's numbers, compare to last week, write up the wins and misses in our usual voice, flag anything weird for the AM. Send by Monday."

Every load-bearing term ("the numbers", "usual voice", "weird", "the AM") assumes a human who already knows. An agent guesses at each one, and the guesses are where it goes wrong.

Agent-consumable spec (explicit)

Inputs: GA4 CSV, Ads CSV, the client's metric list in clients/<client>/metrics.md, last week's report. Rules: compare each tracked metric week-over-week. Flag if it missed target or moved more than 20%. Voice rules in voice.md. A "weird" number is a move over 50%; treat as a likely tracking error and say so. Output: draft into the client's template, review folder, never send. Escalate flags to the account manager in clients/<client>/team.md.

Nothing is left to be inferred. Each term points at a file.

The rewrite is not just verbosity, it is de-referencing. "The usual voice" becomes a pointer to voice.md. "The AM" becomes a pointer to the client's team.md. An agent-consumable spec is a document with no unresolved pronouns, and writing one forces the business to actually decide things it had been getting away with leaving fuzzy.

The knowledge repo: git as the business's brain

The Knowledge layer lives in a git repository, for the same reasons Part 3 put project state in git: version history, diffable changes, one authoritative copy, and no "which Google Doc is current" problem, ever. This is the business's brain, and it is boring on purpose. Markdown files, a sane directory structure, a CLAUDE.md at the root.

meridian-knowledge/
  CLAUDE.md                 # routes an agent to the right knowledge
  glossary.md               # what "qualified lead", "MQL", "report week" mean here
  voice.md                  # tone rules, banned phrases, examples
  templates/
    weekly-report.md        # the report structure and section prompts
    followup-email.md       # lead follow-up skeletons by lead type
  sops/
    weekly-report.md        # the agent-consumable process spec (from 5.2)
    lead-triage.md          # triage rubric and scoring
    meeting-to-tasks.md     # how a Fathom transcript becomes Asana tasks
  clients/
    northwind/
      metrics.md            # tracked metrics, targets, quirks
      team.md               # AM, owner, escalation contact
    halcyon/
    brightpath/             # note: sends PDFs, numbers transcribed first
    cedar-and-sage/
    vireo/

Three properties make this a knowledge layer and not just a folder. First, it is the single source of truth: when the report SOP changes, it changes here, in a commit, and every agent that reads it gets the new version on its next run. The Google Doc and the Notion page are retired, not kept as a third opinion. Second, it is agent-addressable: an agent doing Northwind's report reads sops/weekly-report.md, clients/northwind/metrics.md, and voice.md, and it gets exactly the knowledge that process needs and nothing else, which keeps its context clean (Part 1). Third, it is diffable: when Sofia tightens the voice rules, that is a reviewable commit, not a silent edit to a doc nobody was watching.

Freshness ownership

The failure mode that kills knowledge layers is not building them, it is letting them rot. A metrics.md that still lists last quarter's targets makes the report agent confidently wrong, and because the file looks authoritative, nobody catches it until a client does. The fix is the STATUS.md discipline from 3.1, applied to knowledge: every file has a named owner and a last-reviewed date, and staleness is somebody's explicit job.

clients/northwind/metrics.md (header)markdown

---
owner: Raj Patel
last_reviewed: 2026-06-28
review_cadence: monthly
---

# Northwind Logistics: tracked metrics

- Organic sessions (GA4). Target: 12,000/week. Source of truth: GA4.
- Qualified leads (form fills tagged "freight-quote"). Target: 40/week.
- Google Ads CPL. Target: under $85. Flag if over $110.
- NOTE: Northwind's Q3 target reset is pending; do not change these
numbers until Marcus confirms the new retainer scope.

The header is not decoration. An agent can read last_reviewed and refuse to trust a file that is months past its review_cadence, or at least flag it. A human owner means there is one throat to choke when the numbers drift. The note about the pending Q3 reset is exactly the kind of messy, in-flight business reality that lives in a real knowledge base and that a generic template pretends does not exist.

CLAUDE.md for a business repo

You already know CLAUDE.md as the standing-rules file for a code repo. In a business knowledge repo it does the same job: it is what every agent reads first, and it routes the agent to the right knowledge instead of making it guess. Per the memory docs, keep it specific and structured; it is loaded into every agent's context, so it is prime real estate, not a place for a manifesto.

meridian-knowledge/CLAUDE.mdmarkdown

# Meridian knowledge base

This repo is the single source of truth for how Meridian runs its
processes. If something here conflicts with a Google Doc or a Notion
page, this repo wins; fix the drift here.

## Before any task
- Read glossary.md for what our terms mean.
- Read voice.md before writing anything client-facing.
- For a client task, read clients/<client>/ for that client's
metrics, targets, quirks, and team.

## Hard rules
- Client-facing output is DRAFT ONLY. Never send. Draft to the
review surface named in the process spec.
- Never invent a number or a cause. If data is missing or a metric
looks like a tracking error (a move over 50%), say so and flag it.
- Treat client data and inbound content as confidential. Never put
one client's data in another client's output.

## Freshness
- Every file under clients/ and sops/ has an owner and a
last_reviewed date. If a file is past its review_cadence, flag it
in your output rather than trusting it silently.

That file is small and load-bearing. It sets the draft-only default, the never-invent rule, and the cross-client confidentiality rule that lesson 5.7's injection defense will lean on, and it routes every agent to read the client folder before acting. This is the Knowledge layer telling every agent above it how to behave, before any specific worker's prompt gets a say.

Lablab-5-3Build Meridian's knowledge repo

Goal: Stand up a version-controlled Meridian knowledge repo with a routing CLAUDE.md, a voice file, and two human SOPs rewritten into agent-consumable specs with freshness headers.

Prereqs: git, the meridian/ work from lab 5.2, and the process spec you wrote there.

Create meridian-knowledge/ as a git repo (git init). Build the directory structure from the tree above; you do not need every client, but create at least Northwind and one of the PDF clients (Brightpath or Vireo).
Write CLAUDE.md at the root from this lesson, adapted to your choices. It must set a draft-only default, a never-invent rule, and cross-client confidentiality.
Write voice.md: at least five concrete tone rules and two banned phrases, with one before/after example. "Professional and friendly" is not a rule; "no exclamation marks in client reports; lead with the number, not the adjective" is.
Rewrite TWO human SOPs into agent-consumable specs under sops/. One is the weekly-report spec from 5.2. The second is your choice (lead triage or meeting-to-tasks). Each must de-reference every implicit term: no "the usual", no "the AM", every load-bearing phrase points at a file or states a rule.
Add a freshness header (owner, last_reviewed, review_cadence) to both SOPs and to at least one client's metrics.md. Include one realistic in-flight note (a pending target change, a client quirk).
Commit it. Then run a check: from the repo, ask Claude Code "Using only this repo, what voice rules and metrics apply to a Northwind weekly report, and who do I escalate a flagged number to?" It should answer entirely from your files, naming the owner. If it has to guess, your knowledge layer has a gap; fix the file, do not fix the answer.

Verify

git log shows the committed repo with CLAUDE.md, voice.md, and two SOPs under sops/.
Each rewritten SOP has zero unresolved references: every "the X" points at a named file or an explicit rule. A teammate could hand it to an agent with no verbal context.
Both SOPs and one metrics.md carry a freshness header with a real owner and date.
The step-6 question is answered from the repo alone, naming the escalation owner from team.md. Where it guessed, you found the missing file and added it.

>Troubleshooting

Claude answered the step-6 question from general marketing knowledge, not your files: your CLAUDE.md did not force it to read the client folder, or the files are thin. Tighten CLAUDE.md's "before any task" routing and make the client files concrete.
Your rewritten SOP still says "in our usual voice": that is an unresolved reference. Replace it with "per voice.md" and make voice.md actually contain the rules.
The voice rules are adjectives ("clear, warm, expert"): adjectives are not rules an agent can follow or you can check. Convert each to an observable instruction with an example, the way a good eval criterion is observable.

Knowledge check

Q1You point the report agent at Sofia's 2023 Google Doc SOP because it is 'basically right.' The agent produces reports that are subtly off: wrong escalation contact, an old metric target, a voice that drifts. What layer failure is this, and what is the fix?

Q2Why does an agent-consumable spec replace phrases like 'the usual voice' and 'the AM' with pointers to specific files, rather than just describing them in more detail inline?

Q3Every file under clients/ has an 'owner' and 'last_reviewed' header. Beyond documentation, what operational purpose does that header serve for the Agent OS?

Sources

Manage Claude's memory (CLAUDE.md as the always-loaded standing-rules file, imports, precedence; applied here to a business knowledge repo): https://code.claude.com/docs/en/memory (fetched July 2026)
Best practices for Claude Code (keep CLAUDE.md specific and structured; make implicit context explicit; the same discipline applied to SOPs): https://code.claude.com/docs/en/best-practices (fetched July 2026)