Guide · Agency operations

# One client code, one search boundary

The objection you beat last month is buried in a chat, and a note from one client can leak into another client's copy. Give every client a code, file notes against it with evidence, and scope every search to one code.

By Mitchell KellerNov. 10, 20266 min read

A shared command chamber with a glowing map table.

[Download the blank worksheet](https://www.joinlegion.io/downloads/one-client-code-one-search-boundary-registry.md)[View Markdown](one-client-code-one-search-boundary.md)

## Key answer

- Give every client a short, unique code. No code may be the start of another code.
- Every note carries its client code, where it came from, how much you trust it and when to review it.
- Every search is scoped to one client code. Test that it cannot return another client's notes.
- Shared methods get their own code and contain no client names or data.

On this page

## What you learn disappears, or leaks

Each client teaches you something: the objection that keeps coming up, the line that books meetings, who actually signs. Most of it ends up in a chat thread nobody searches again. The other failure is worse. A note from one client turns up in another client's work, and now you have a confidentiality problem.

A small knowledge base with one rule fixes both: every note belongs to exactly one client code, and every search names one client code.

How a scoped note moves

The work happens in a client's folder, which names its client code. A note filed from that work is tagged with the code, its evidence and a trust level. A search from that folder is limited to that code, so another client's notes never come back. A person reviews the answer before it goes into anything a client or prospect sees.

- Client folder and codewhere the work happens
- Notecode, evidence, trust
- Scoped searchone code only
- Reviewed answera person checks it

## The note card

Keep the model small enough that people actually fill it in.

Fields on one note

| Field | What to put

| Client code | One registered code, for example ACME

| Type | Objection, winning line, reply, voice, decision or research

| Note | One finding in a sentence or two

| Evidence | Where it came from: a reply, a call, a campaign result

| Trust | New (unchecked), checked by a person, or proven by results

| Recorded and review date | When it was written and when to look at it again

## Six steps on one page

- Assign codes. Short and unique. Check that no code starts with another: if you have NOVA and NOVAX, a name starting NOVAX matches both.
- Register them. Keep one registry of codes. A note with an unregistered code gets rejected, not filed somewhere loose.
- File one note. Pick a real finding from last week, write it on the card with its evidence and a review date.
- Scope every search. Searches take a client code and only return that client's notes. No code, no search.
- Test the wall. Search client A for a word that only appears in client B's notes. The right answer is zero results.
- Keep a shared lane. Methods that work across clients go under a shared code, rewritten so they hold no client names, numbers or quotes.

## Let the folder pick the scope

People forget to set a filter. Agents do too. The safer setup is to put a small marker file in each client's working folder that names its code, and have your search tool read it. An agent opened in that folder can then only search that client, and cannot widen the search on its own. That is how I run mine.

Trust levels matter as much as the wall. A new note is a guess until someone checks it. Do not let an unchecked note drive copy that goes to a prospect.

### When this is the wrong tool

With one client, a single notes document is enough. This also does not replace your CRM. It holds what you learned, not who you talked to.

## Get the blank registry

Client code registry and note card (blank, Markdown)

An empty client code registry with the prefix check, a blank note card with the six fields above, and the wall test to run before you trust the setup. It contains no client data.

[Download the .md](https://www.joinlegion.io/downloads/one-client-code-one-search-boundary-registry.md)

## Source notes

This guide describes the model I use for client knowledge across my own agency work. Every client code and note shown here is invented. The Legion course covers the setup we run in more depth for members; nothing here depends on it.

## Run your agency on agents you can check

Get one useful GTM email a week. Then join the community on Skool.

[Get the newsletter](https://waitlist.joinlegion.io/g/legion-waitlist)

## Start here: the agency path

- [Give every campaign a spend ceiling](/resources/give-every-campaign-a-ceiling): budget control.
- [Keys by person, project and client](/resources/access-by-person-project-and-client): access control.
- [One client code, one search boundary](/resources/one-client-code-one-search-boundary): client knowledge. (this guide)
- [Code Mode MCP: one tool surface for many tools](/resources/code-mode-mcp-one-tool-surface): code mode mcp.

[Back to resources](/resources)

## Bring the GTM job you need done. Build the run you can check.

Get one useful GTM email a week. Then join the community on Skool.

Get one useful GTM email a week. Then join the community on Skool.

[Get the newsletter](https://waitlist.joinlegion.io/g/legion-waitlist) [Join the community on Skool](https://www.skool.com/legion/about)
