Per-project terminal identity for multi-client developers

A consultant's terminal looks different from a single-product developer's terminal. Five clients, five codebases, five sets of conventions, five sets of "do not say X in front of customer Y" rules. The same person, the same shell, doing five very different jobs.

When the terminal-based AI agent treats all of those jobs as one shared memory, things go wrong fast. The agent remembers a fact from client A and surfaces it in client B's session. It uses the naming convention from one project in another. It runs the deploy command that was right for one codebase in a codebase where that command would do harm.

This isn't a fringe failure mode for consultants — it's the central failure mode. A shared CLI memory is worse than no memory at all, because it generates false confidence. The agent acts like it knows what it's doing; it just knows the wrong project.

The fix is per-project terminal identity. Each project gets its own scope: its own memory, its own conventions, its own tools, its own session continuity. The same terminal, the same agent, different identities.

Why "one shared CLI memory" fails for consultants

The single-memory model works fine for a developer with one codebase. The shell remembers the last fifty commands. The AI agent remembers the recent decisions. There's only one project, so memory leakage is impossible.

For multi-client developers, the same pattern is hazardous.

Naming collisions. Client A's deploy script does something different from client B's deploy script. The agent that remembers "running deploy on this project means X" is wrong for the other project.

Convention bleed. Client A uses tabs; client B uses spaces. The agent that recently saw tabs assumes tabs are global, then writes a PR for client B with the wrong convention.

Confidentiality leakage. Client A's information shouldn't surface in client B's terminal. "Last week we discussed the Acme project" appearing in a session for Beta Inc is a serious problem, not a small one.

Stale decisions. A decision made for client A is no longer relevant when the user is in client B. The shared memory keeps surfacing it.

These aren't theoretical. They show up in every multi-client developer's first month of using AI terminal tools. The fix has to be structural; no amount of "please be careful" prompts solves it.

What per-project identity looks like

Per-project identity means the agent treats each project as its own world.

Memory is scoped. Memories about client A are tagged to client A and don't surface in other contexts. When the user cds into client A's repo, the agent's available memory is client A's.

Conventions are project-local. The agent inherits client A's style guide when in client A's repo, client B's when in client B's. No leakage.

Tools are project-aware. When the agent calls a deploy tool, it calls the one defined in this project's context. The same word — "deploy" — resolves to different actions in different repos.

Continuity is per-project. "Where did we leave off" returns the right answer for the project you're currently in, not the most recent project across all clients.

Credentials are project-bound. The agent reaches for the API keys tied to the active project, not a global keychain that could leak the wrong key into the wrong context.

The shared substrate underneath is fine — it's the exposure that has to be scoped. The agent has one memory layer, but at any moment only the project's scope is visible to the current session.

What this looks like in practice

A consultant working with three clients, with per-project identity in place:

cd ~/clients/acme → the agent loads Acme's memory scope, conventions, tool surface, and credentials. The session starts knowing Acme's context.
cd ~/clients/beta → the agent switches to Beta's scope. Acme's memory is no longer surfaced. Beta's conventions become active.
cd ~/personal/sideproject → the agent loads personal scope, which is separate from all client work.

Nothing else about the user's environment changes. Same shell. Same agent binary. Same vault. The identity switches because the location switches.

The user doesn't have to manage profiles or switch tools. The boundary is the project. The agent respects it.

The trust dimension

Per-project identity isn't just a convenience — it's a trust feature.

Consultants who hand AI tools meaningful access to client work need to trust that the tools won't cross contexts. If the agent remembers a thing from one client and surfaces it for another, the consultant has a confidentiality problem they have to explain to a real human. That conversation is much more expensive than the convenience the shared memory provided.

The agent that maintains per-project identity earns trust precisely because it doesn't surface client A's context in client B's session. The user can confidently use the same agent across all clients because the scope guarantees the boundary.

This is the same trust pattern as a good notes app for journalists, or a good password manager for someone working across multiple companies. The tool is one tool. The contexts are bounded.

What this requires from the agent

Per-project identity requires the agent (or the substrate underneath it) to support a few specific capabilities.

Project detection. The agent has to know which project is active. Usually this is the working directory and the upstream git remote, but it could also be an explicit scope set by the user.

Scoped retrieval. When the agent queries its memory or vault, the query is filtered by active scope. The user can override the filter if they have legitimate cross-project reasons, but the default is scoped.

Scoped writes. When the agent saves a memory, the memory is tagged with the active scope. Future retrievals respect that tag.

Tool routing. When the agent invokes a tool — "deploy," "test," "format" — the active project's tool definition is the one that runs. Project-local config takes precedence.

Credential resolution. When the agent needs a secret, it asks the credential vault for this project's credential. The vault either returns it or refuses; no global fallback that could leak the wrong key.

These are not deep changes. They're disciplined defaults. The substrate that supports them becomes the substrate consultants can actually trust at scale.

A practical setup

For a consultant building this with current tools:

Use a vault that supports scopes. Each client gets its own scope ("acme," "beta," "personal"). Memories, prompts, and credentials are tagged.
Set up per-project agent config. A .agent directory or equivalent at the root of each client's repo. The agent reads it when in that directory.
Define project-local tools. A Makefile or justfile per project, with names like deploy, test, migrate that mean the right thing in this project.
Use direnv or a shell hook for credentials. When you cd into a project, the right credentials become available; when you leave, they unload.
Establish a session-resume note per project. End each session by writing a short "where I left off" note tagged to the project's scope. Next session reads it.

This takes an afternoon to set up across all clients. The payoff is months of friction reduction, plus the confidentiality guarantee that lets you actually use AI tools on client work without worrying about cross-talk.

What this means for AI tool builders

If you build terminal-aware AI tools, supporting per-project identity is what makes the tool viable for consultants and multi-client developers. The audience is large and underserved.

The build moves are:

First-class project detection from cwd and git remote.
A scope concept exposed to memory, tools, and credentials.
A clear "this is the current scope" indicator visible to the user.
Cross-scope querying available only on explicit request.
Default-scoped writes.

A tool that ships these well becomes the default for consultants, who have low tolerance for context leakage. A tool that doesn't ship them becomes a tool consultants stop using once they have a near-miss with confidentiality.

The summary

One shared CLI memory is the wrong shape for multi-client developers. Project boundaries matter; the agent has to respect them at the memory, tool, and credential layers. Per-project terminal identity — automatic scope by cwd, scoped retrieval and writes, scoped credentials, scoped continuity — is what turns a single AI agent into something a consultant can reliably use across all their clients. Build it; the trust this earns is what makes the rest of the AI workflow possible at scale.