Consultants: Separate Clients, Separate Credentials, Separate Memory

The consultant nightmare is not a hack. It is pasting a paragraph drafted with client A's numbers into an email to client B. Once your AI agent works across engagements, that risk stops being about your attention span and becomes an architecture question: are your clients' tools, credentials, and context actually separated, or just separated in your head?

MCP for consultants is mostly the same wiring as for anyone else, one standard protocol between an agent and the tools it uses. What changes is the requirement profile. Three things move to the top: separation, revocation, and proof.

Separation: one boundary per engagement

A consultant's agent might touch client A's analytics, client B's CRM, and your own invoicing tool in one afternoon. The lazy setup throws all of it into one agent config, and now nothing but luck prevents cross-contamination.

The clean setup draws a boundary per engagement. Each client's connections live grouped under that client, tools arrive namespaced (clientA__get_report is not clientB__get_report), and the agent works inside one boundary at a time. A gateway makes this natural: connections are grouped where they are managed, not scattered across config files. If you have ever run two clients from two browser profiles to keep the cookies apart, this is the same instinct, applied where it actually holds.

The same boundary has to apply to memory, and this is the part most setups miss. An agent that remembers is an asset; an agent that remembers client A's churn numbers while writing for client B is a liability. Memory needs scoping per engagement, so recall inside one client's work never surfaces another client's facts. When the engagement ends, that memory should be exportable or deletable, not fossilized in some global blob. We wrote more about how gateway-level memory works in [MCP gateway with memory](/blog/mcp-gateway-with-memory).

Revocation: offboarding is the real test

Every engagement ends. The handoff email goes out, the last invoice gets paid, and the access you hold should die the same week. That is where most solo setups quietly fail: the client's API key is still in a config file in some project folder, working, powerful, and forgotten. We covered why that pattern rots in [stop pasting API keys into agent configs](/blog/stop-pasting-api-keys).

The test worth applying to your own setup is brutal and simple: could you revoke everything belonging to one client in under five minutes, and could you list what you revoked? With per-connection OAuth grants in one place, the answer is yes, twice. With keys in files, the honest answer is "probably not, and definitely not provably".

Revocation speed is not paranoia. It is professionalism you can demonstrate: "your access was removed on the 14th, here is the list" is a sentence that wins the next contract.

Proof: the audit trail is part of the deliverable

When your agent updates a client's CRM or edits their tracking setup, you are acting on someone else's production system. If anything looks odd two weeks later, "my agent might have touched that" is a terrible sentence to say to a client.

An audit trail turns it into a good one: every call your agent made, timestamped, with arguments and results, filterable by engagement. That log is not bureaucracy; for a consultant it is billing evidence, dispute insurance, and the fastest debugging tool you own. The full argument is in [audit trails for AI agents](/blog/ai-agent-audit-trail).

The compounding part: stop re-learning your own clients

Separation, revocation, proof: that is the defensive half. The offensive half is what memory does to your margins.

Consulting runs on context. The client's KPI definitions, the stakeholder who must be cc'd, the decision from the March workshop, the way this client wants numbers rounded. A stateless agent makes you re-supply all of it at the start of every working session, which is somewhere between annoying and expensive. Scoped memory means each engagement accumulates its own working knowledge: you explain the KPI definitions once, and in week six the agent still applies them. Per client, never across clients.

The billable-hours math is unromantic and real. If context re-assembly eats fifteen minutes per client session and you run six client sessions a week, that is ninety minutes of unbillable ritual, every week, that memory mostly deletes.

What to check in any tool you adopt

Ours or anyone's. Bring this list.

• Connections groupable per client, tools namespaced, no global pile
• OAuth where possible, scoped grants, secrets in an encrypted vault
• One-screen revocation per client, verifiable afterwards
• An audit trail filterable by engagement
• Memory scoped per engagement, exportable and deletable
• Clear data location (for EU client work, this question comes from the client eventually; see [why EU teams ask where AI infrastructure runs](/blog/eu-hosting-for-ai-infrastructure))

Full disclosure: Tulimoa is our product, and the [gateway](/gateway) is built along exactly these lines (encrypted per-secret vault, per-connection revocation, audit trail, memory tools free on every plan, EU-hosted). It is in early beta and not self-serve yet, and every plan currently connects one agent. If you run a whole agency rather than a solo practice, the shape shifts a bit: we wrote [the agency version](/blog/mcp-gateway-for-agencies) separately.

Whatever you pick, adopt the standard before the tooling: one boundary per client, dead access at handoff, and a log you would be comfortable showing the client. That is the whole discipline.