diff --git a/skills/internal-meeting-brief/SKILL.md b/skills/internal-meeting-brief/SKILL.md
index a836bbb..416ab5e 100644
--- a/skills/internal-meeting-brief/SKILL.md
+++ b/skills/internal-meeting-brief/SKILL.md
@@ -178,6 +178,31 @@ fixed list per brief type:
   here, or flag it `open` if the registry doesn't resolve it (e.g. a variant with no
   assigned code yet). This registry is a genuine dependency, not this skill's own
   content to maintain — see Dependencies.
+- **End agency / client organization — identify and enrich it, not just the people.**
+  When a topic has a real end client (a transit agency, most commonly), resolve its
+  full identity, not just whatever name got said in the meeting:
+  1. Check the MPM Technical Reference System first — `60-proof/agency-roster.md`
+     (is this agency already a known MPM deployment? gives HQ city/state) and
+     `60-proof/clients-and-partners.md`. Cheap, already-vetted, check before the web.
+  2. If not found or incomplete, search the public web for the agency's official
+     site. Resolve **both** names, distinctly — most transit agencies have a legal/
+     governmental name and a separate public transit brand, and both matter for
+     different reasons (contracts use the legal name; everything rider-facing uses
+     the brand). The precise, correct pattern — confirmed against MPM's own FTA
+     filings for Oshkosh — is **"[Legal Entity], dba: [Transit Brand]"** (e.g. "City
+     of Oshkosh, Wisconsin, dba: GO Transit"). Don't collapse these into one name or
+     guess which is which.
+  3. Pull the agency's logo and re-host it as a data URI embedded in the brief — do
+     not hotlink to an external image URL. This is the same "own content at
+     creation" principle already applied to fonts/tokens elsewhere in Brief: the
+     brief must survive as a standalone file even if the agency's website changes.
+  4. Capture the agency's general contact info (main line, address) alongside — not
+     a replacement for a named individual contact (see attendee resolution above),
+     supporting information for anyone reading the brief who needs to look the
+     agency up independently.
+  Present this as its own clearly-labeled card/section (see
+  `references/section-structure.md`), separate from the internal attendee list —
+  this is organizational identity, not a meeting participant.
 
 Helpdesk ticket review is still a deliberate, manual exception (see below) — not
 pulled automatically regardless of topic type.
@@ -268,6 +293,20 @@ person needs to actually see and review it, not just trust it happened.
   correct; a brief with invented content to fill them is not.
 - **Bounded queries only.** Gmail/Chat scans are scoped by project keyword + date
   window from the manifest. Never an open-ended search.
+- **Channel/pricing confidentiality by audience.** internal-meeting-brief is internal
+  by definition, so this doesn't block anything it currently does — but it's the rule
+  that must govern any future external-facing brief type (vendor-partner-brief,
+  kickoff-brief's external-client variant), so it's recorded here where the pattern
+  first came up. Grounded in MPM's own Technical Reference System
+  (`60-proof/reseller-channel.md`): on a reseller-sold account, **MPM's contract of
+  record is with the reseller, not the end agency** — the agency is not privy to
+  what MPM charged the reseller, only to whatever the reseller separately agreed
+  with them. A brief ever shown to the end agency must exclude MPM's own SO/PO
+  pricing entirely on a channel account, not just redact the total — line-item
+  pricing implies the same thing. This is not "hide pricing from external
+  audiences" generically: a *direct* account (no reseller) showing an agency its own
+  figures is normal. The dividing line is whether there's a reseller between MPM and
+  the reader, not whether the reader is external to MPM.
 - **No live publishing yet.** This skill produces a local file only. Hosting/publishing
   (a shareable link, external access control) is CW-029 (Brief Server) — deliberately
   separate, deliberately not built yet. Don't attempt to stand up delivery
diff --git a/skills/internal-meeting-brief/references/section-structure.md b/skills/internal-meeting-brief/references/section-structure.md
index 8023c2c..717e0d7 100644
--- a/skills/internal-meeting-brief/references/section-structure.md
+++ b/skills/internal-meeting-brief/references/section-structure.md
@@ -18,6 +18,11 @@ structure per meeting. This is the contract — read it before generating a brie
    When external counterparts are named in discussion but weren't present, give them
    their own card group ("Named in discussion, not present") with resolved contact
    info (see SKILL.md step 4) rather than omitting them or burying them in prose.
+   **If the topic has a real end-client organization** (an agency, most commonly),
+   give it a distinct "End Agency" card of its own — separate from individual
+   people — showing the legal-name/brand-name pair (e.g. "City of Oshkosh, dba: GO
+   Transit"), a re-hosted logo, website, and general contact info. See SKILL.md
+   step 5.
 3. **Topics Covered** — a `cards` grid, one card per distinct subject actually
    discussed. Card count and grid density (c2/c3/c4) follow the number of real topics —
    don't pad to hit a round number, don't force unrelated topics into one card to save