Client Handovers Without the Three-Week Knowledge Transfer

Every agency owner knows the ritual. An account manager resigns, or gets promoted, or finally gets that one client taken off their plate, and the handover begins: a “brain dump” document written in a hurry, a walkthrough call that covers a tenth of what matters, three weeks of the new person asking “do you know anything about…” into a channel where the answer already scrolled away. Meanwhile the client repeats themselves to their fourth contact in two years and quietly starts wondering whether the relationship they are paying for is with your agency or with whoever happens to answer.

The uncomfortable accounting: most of what the departing person knows about that client was once said out loud or typed into an AI chat. It was worked through in Claude, drafted in ChatGPT, built in Cursor, decided on a call. The knowledge is not missing; it is scattered across chat histories and one person’s head, keyed to a person instead of to the client. Handover is painful because you are asking a human to reconstruct, from memory, an archive nobody ever kept in one place.

One engine per client

The structural fix is to make the client, not the employee, the unit of memory. In Context Engine that unit is an engine: one memory with a purpose, a few sentences in your words saying what it is for, what belongs in it and what does not. Give each client its own. “Everything about our work for Harbor Foods: their brand, the people on their side, what we agreed and why. Not our internal pricing or other clients.”

Your team’s AI tools then do the filling. Claude, ChatGPT, Claude Code and Cursor connect to Context Engine over MCP and save memories as they work: the decision made on Tuesday’s call, the commitment given, the person on the client side who signs off on copy. Every save names its engine, and the tool reads each engine’s purpose to decide which one. Briefs, contracts and call transcripts go into Files: drop a file, a whole folder or a .zip, and text and PDFs become searchable.

Day to day, this powers the work this academy documents, scoped per client: pre-meeting preparation before every client call, commitments tracked in both directions, a record of what was decided and why. The account runs better while everyone is present. But the deepest payoff appears the day someone moves.

Keeping clients apart in the tools themselves

Separate engines are only half of the boundary. The other half is which engines each AI tool can reach, and that is set on the connection: one signed-in app or one key, reaching the engines you tick, each at Can read or Can read and save.

In Claude Code, give each client repository its own project-scoped connection, run inside that repository:

claude mcp add --scope project --transport http ce-harbor https://app.contextengine.com/mcp/c/<id>

Then run /mcp in Claude Code, choose ce-harbor and authenticate. Work in the Harbor repository reaches Harbor’s engine and nothing else.

Claude Desktop and claude.ai switch every connector on in every chat. There, separating clients means switching on only that client’s connector in each chat, from the tools menu. It is a habit, not a wall, and worth saying out loud to the team.

The handover, replayed

Run the ritual again with the engine in place. You invite the new account manager to Harbor’s engine from People, as a member. They connect their own AI tool to it, and the first time that tool opens a session it gets the brief: what the engine is for, what happened recently, and what changed since it was last there. Their onboarding is a reading assignment, not an excavation. On day one they open Ask in the console and start with the obvious question. An illustrative answer, with invented names:

You: What should I know before my first call with Harbor?

Harbor has been a client since January 2025, on a monthly
retainer for brand and site work.

People: Dana Whitfield (marketing lead) approves copy. Omar
Reyes (CFO) joined the last two calls about scope.

Open: the spring campaign landing page, due 14 October,
assigned to you. Harbor owes us product photography.

Decided: the rebrand was postponed to next year, twice. The
second time because their packaging supplier changed.

Not on record: anything about the new CFO's preferences.

Sources: "Rebrand postponed to 2027" (decision), "Spring
landing page" (task), "Dana Whitfield" (person), "Call with
Harbor, 2 Sept" (meeting)

Every answer names the memories it came from, so the new manager can open “Rebrand postponed to 2027” and read the rationale, and its History shows who saved it, with which tool, and what it said before. Ask answers only from the engine that is open and does not browse the web, so “not on record” means exactly that.

The departing person’s walkthrough call still happens, and becomes what it always should have been: judgement and relationships (“the CFO warms up slowly, the marketing lead is your real champion”), not a recitation of facts the engine already holds. Facts transfer through the engine; judgement transfers through the conversation. Splitting those two is the entire trick.

When they leave, you remove them from the engine. Their AI tools lose it at the same moment. What they saved stays, with their name on it, as “Name (former member)”, so the record of who decided what survives the person.

And the client feels continuity instead of reset. The new manager’s first call opens with full context: no “could you walk me through your setup again,” no promises renegotiated because nobody remembered them.

The milder emergencies, which are more frequent

Departures are the dramatic case, but the same mechanism absorbs the everyday versions, which collectively cost more: vacations, parental leave, someone covering an account for a week, a senior person dropping into an escalation at 6 p.m. Invite them, or tick the engine on a connection they already have, and they are briefed in minutes. Remove the access when the cover ends. Coverage stops depending on the one person who knows things.

Why per-client, not one big pot

A single agency-wide engine would work, but the per-client boundary earns its keep three ways.

Confidentiality is physical. Every engine has its own database, its own search index and its own Worker, so client A’s memories are not rows in the same table as client B’s. Across engines, a memory’s title and its engine’s name are shown only to someone who can reach that engine. What still needs discipline is the tools: a connection that reaches two clients’ engines can read both, which is why one connection per client matters.

Transparency becomes a deliverable. You can invite people from the client’s side as viewers. A viewer can read and search everything in that engine and change nothing, and a viewer’s connections only read. “Here is the living memory of what we know and have decided together” is a stronger renewal argument than a slide, because it can be checked.

The endgame is clean. When a relationship ends, you can hand the engine to the client. The person who will own it must already be a member; you offer it with Transfer ownership, nothing changes until they accept, and then it moves onto their plan. They choose whether you stay, as a member, as a viewer or not at all, and the engine’s history records the transfer. Before you offer it, the transfer dialog looks for memories you wrote that fit another engine of yours better, such as a note about your own pricing, and offers to move them out first. If you would rather keep a copy, export the engine: one ZIP of Markdown and JSON that opens without us.

That last point is also a reason to be chosen. “You keep the memory when we part” is an offer a lock-in-shaped competitor cannot make.

Moving what landed in the wrong place

Some memories will be saved to the wrong engine: a method note in a client’s engine, a Harbor decision in your own. Open it and choose Move to another engine. It travels with its whole history and who saved each version. The engine it left keeps only a placeholder saying that something was there, who wrote it and that it moved, and none of what it said. It no longer appears in search there, and Summaries that cited it are rewritten without it.

Tuning it

Knob	Default	Alternatives
Engine scope	one per client	one per brand for holding groups
Rollout	your two or three largest accounts	all accounts at once
Account team roles	members	admins for account leads who manage access
Client visibility	none	client people invited as viewers
Connections	one per client, per person	one read-only connection for a director who reviews every account
Offboarding	hand the engine to the client	export, then delete

How many engines you can own depends on your plan; see pricing. Engines you were invited to do not count against yours, and an engine handed to a client moves onto their plan.

Failure modes, and the fixes

The engine is thin when the handover comes. It only pays out if it was filling up before it was needed, which is why the daily habits matter: tools connected with Can read and save, decisions saved with their reasons, call notes and documents dropped in. An engine set up and unused is an insurance policy nobody paid premiums on.

Cross-client work gets awkward. Some knowledge legitimately spans clients: your methods, your templates, your staffing. That belongs in your agency’s own engine, not in any client’s. Two layers, clean boundary: the agency engine knows how you work; each client engine knows that relationship. Write both purposes so a tool can tell them apart.

Everything is switched on in Claude Desktop. Someone drafts a Harbor email with every client connector live and the tool pulls in another client’s note. Make “only this client’s connector in this chat” a team rule, and prefer Claude Code’s project-scoped connections where the work happens in a repository.

Access sprawl. People and tools accumulate access they no longer need. On each engine’s People page, owners and admins see everyone, their role, and every AI tool of theirs that reaches the engine, at which access and when it was last used, and can remove a tool from that engine alone. Tie engine access to account assignment, granted and removed together, and look at the list when accounts change hands.

Build this yourself

• An engine per client, each with a purpose that says what belongs there and what does not.
• Your own agency engine for the knowledge that is yours, not any client’s.
• One connection per client, per person: project-scoped in Claude Code, one connector at a time in Claude Desktop and claude.ai.
• People with roles: the account team as members, an account lead as admin, client contacts as viewers if you offer it.
• A handover routine: invite, connect, read the brief, ask the first question, then remove the person leaving.

Start with one client on the free plan at app.contextengine.com, or see pricing for the number of engines an agency needs.