Client Handovers Without the Three-Week Knowledge Transfer

Every agency owner knows the ritual. An account manager resigns, gets promoted or finally hands off that one client, and the handover begins. Someone writes a “brain dump” document in a hurry. A walkthrough call covers a tenth of what matters. For three weeks the new person asks “do you know anything about…” in a channel where the answer scrolled away long ago. Meanwhile the client repeats themselves to their fourth contact in two years and starts to wonder whether the relationship they pay for is with your agency or with whoever happens to answer.

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 exists, but it is scattered across chat histories and one person’s head, filed under a person instead of under the client. Handover hurts because you are asking someone to rebuild from memory an archive nobody ever kept in one place.

One engine per client

The fix is to build memory around the client instead of the employee. In Context Engine you do that with 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 fill it. Claude, ChatGPT, Claude Code and Cursor connect to Context Engine over MCP (the standard AI tools use to reach outside services) 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, each client engine supports the work described elsewhere in this academy: pre-meeting preparation before every client call, commitments tracked in both directions, a record of what was decided and why. The account team can also open the engine in the app, browse its Memories and see who saved what. That helps while everyone is still on the account. The bigger payoff comes 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. That depends on habit rather than a hard boundary, so say it 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 mostly reading. 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, but it can now cover judgement and relationships (“the CFO warms up slowly, the marketing lead is your real champion”) instead of facts the engine already holds. The engine carries the facts, and the conversation carries the judgement.

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.

For the client, nothing resets. The new manager’s first call starts with full context, so nobody asks them to explain their setup again and no promise has to be renegotiated because it was forgotten.

The milder emergencies, which are more frequent

Departures are the dramatic case. The everyday versions happen more often and cost more in total: 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 separate engines per client help in 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.

Clients can see the record. 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.

Ending the relationship is simple. 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 is theirs: the engine keeps its own plan, and paying for it moves to them. 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 can also help you win the client in the first place. “You keep the memory when we part” is an offer an agency that relies on lock-in 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

Users are unlimited on every plan, so inviting your team or the client’s costs nothing. Each engine has its own plan, set by how many agents connect to it, so one client’s engine can be on Pro while another stays on Free; see pricing.

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 that was set up and never used has nothing to hand over.

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. The agency engine knows how you work, and 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 what each client’s engine needs.