Skip to content
be-human.ai
← Back to the journal

AI by industry

Superintelligent Agents for Consulting Firms: Memory That Compounds

How a consultancy can turn engagement learnings into governed agent memory that compounds, while keeping client confidences separated and auditable.

A wooden loom with ivory linen threads weighted by green marble, holding a growing woven band on a sunlit travertine table.
Conceptual illustration created with AI · Be Human

Superintelligent agents for consulting firms are AI agents with durable memory, a defined role and human-controlled permissions, built to capture what each engagement teaches and make it reusable by the next team. What makes this safe is governance: learnings are distilled, stripped of client identity and approved by a person before they enter shared memory, while raw engagement material stays behind per-client walls. Done this way, a firm's knowledge compounds with every project instead of leaving when the project team disbands.

Key takeaways

  • Treat firm memory as a governed library with separate tiers, not one shared pile of past decks and notes.
  • Store the lesson, not the artifact: the method, the pattern and the question that worked, with client identifiers removed and a named person approving each entry.
  • Enforce client walls through permissions at retrieval time, not through instructions written into a prompt.
  • Start with one role, a knowledge steward that runs at engagement close, and measure whether later teams actually reuse what it stores.
  • Log every read and write so a partner can answer who saw what, when and why.

Why does consulting knowledge fail to compound today?

Most consultancies already know their best insight is not in a slide. It lives in the head of the manager who noticed that the stated problem was never the real one, or in a retrospective someone wrote on the last day and nobody opened again. Decks end up in folders organized by client, which is correct for confidentiality and useless for learning.

The result is that every new team re-discovers the same scoping traps, re-invents the same interview guide and re-estimates the same kinds of work from scratch. People rotate, senior staff leave, and the firm's experience resets a little each time.

There are two tempting responses, and both are wrong. The first is to give an AI assistant access to every past engagement and let anyone ask it anything. That turns a useful memory into a confidentiality incident waiting for a curious question. The second is to ban the idea entirely because of that risk, which leaves the firm with the same forgotten retrospectives. The workable path sits between them: a memory designed from the start around what may be shared and what may not.

What counts as a learning, and what must stay with the client?

The first design decision is vocabulary. Without it, a well-meaning agent will happily store a client's pricing logic as a best practice. Useful learnings usually fall into three groups:

  • Method learnings: which questions exposed the real issue, which sequence of interviews unblocked the work, which workshop format produced decisions instead of discussion.
  • Pattern learnings: situations that recur across clients in a sector, stated in general terms and without attribution.
  • Delivery learnings: scoping mistakes, assumptions that drifted, staffing mixes that worked, risks that appeared late and could have been caught earlier.

What stays with the client is just as important to define in writing: names and identifying details, financial and strategic specifics, personal data, anything restricted by the engagement contract, and any material the client shared for one purpose only. When the contract is silent, the default is that it stays.

A simple test helps reviewers decide quickly:

A learning is reusable once it makes sense without the client's name, numbers or story attached.

If an entry only works with those details, it is a case file, and case files belong in the engagement vault, not in the firm library.

How should governed memory be structured?

Three tiers cover most consultancies. They are separate stores with separate permissions, not folders in one index.

  • Engagement vault: everything for one client, readable only by the assigned team and the agent acting for that team. Nothing here is searchable from outside the engagement.
  • Candidate queue: proposed learnings written by the agent, each linked to its source inside the vault. Only the reviewer sees the link. Entries wait here until a human approves, edits or rejects them.
  • Firm library: approved, de-identified entries that any authorized consultant can retrieve, each with an owner, a review date and a note on how it may be used.

This design leans on retrieval rather than training. Keeping knowledge in stores the agent looks up, instead of baking it into model weights, means you can see exactly what the agent can draw on, remove an entry when a contract requires it and prove that a deleted vault is gone. Information absorbed into a trained model cannot be withdrawn that way. AWS publishes a useful comparison of retrieval and fine-tuning if your technical team wants the trade-offs laid out.

The same logic appears in other client-wall professions. The approach described in AI for engineering firms: proposals, records and client walls and the ethical-wall thinking in superintelligent agents for law firms transfer well to a consultancy.

A brass funnel with a fine sieve lets pale grains fall into a ceramic vessel while dark grit stays behind, beside a sealed oak box with folded ivory paper.
Conceptual illustration created with AI · Be Human

What does the path from closed engagement to reusable learning look like?

Here is a plan a consultancy can run with one role and a handful of engagements. It is deliberately modest, because the first goal is a trustworthy loop, not a large library.

  • Step one: write the sharing policy. Define the three kinds of learning, the list of things that never leave a vault and who may approve library entries. Keep it to a page.
  • Step two: classify engagements at kickoff. Record any contractual limits on reuse in the vault so the agent and the reviewer both see them.
  • Step three: capture as you go. Let the team drop short notes into the vault during delivery: what surprised us, what we would scope differently, which question mattered.
  • Step four: draft at close. The agent reads only that engagement's vault and proposes candidate learnings in the three categories, each stating the lesson in general terms and pointing to its source.
  • Step five: review as a person. A named reviewer, usually the engagement manager plus a partner or knowledge lead, checks each candidate for re-identification risk, accuracy and usefulness, then approves, edits or rejects it.
  • Step six: publish with metadata. Approved entries go to the firm library with an owner, a sector tag, a review date and a usage note.
  • Step seven: retrieve with a purpose. When a team scopes new work, the agent searches the library and cites the entries it used, so the consultant can judge them rather than trust them blindly.
  • Step eight: review the loop. Each quarter, look at which entries were reused, which were never retrieved and which were corrected, and retire the weak ones.

The review in step five is not paperwork. It is the control that turns a pile of notes into institutional knowledge, and it is the point where a person takes responsibility for what the firm now claims to know.

What does this look like in practice? An illustrative scenario

Illustrative scenario: a consultancy finishes an operations review for a regional distributor. During delivery, the team noted that the client's order data lived in several systems that disagreed with each other, and that the project only moved once they ran a reconciliation workshop before starting interviews.

At close, the knowledge steward agent reads that engagement's vault and proposes two candidates. The first says that in operations reviews where order data is split across systems, a short reconciliation workshop before interviews prevents weeks of contradictory findings. The second includes a detail about the distributor's unusual seasonal contract structure. The reviewer approves the first, because it works without any client context. She rejects the second, because in a small sector that structure would point straight at one company, and she tells the agent to keep it in the vault only.

Months later, a different team scopes an operations review for a manufacturer. The agent retrieves the approved entry, cites it and suggests adding a reconciliation workshop to the plan. The consultants never learn which company the lesson came from, and they do not need to. The firm got better; the confidence held.

Which controls keep confidences from leaking?

A good policy fails without technical enforcement. These are the controls worth insisting on:

  • Permissions at the tool layer. Each request to read memory is checked against who is asking and which engagement they belong to, with access denied by default. The OWASP authorization guidance describes this principle well. A line in a prompt saying "do not reveal other clients" is not a control.
  • Separate stores, not filtered views. If the vaults share one index and rely on a filter, one mistake exposes everything. Separate stores limit the damage of any single error.
  • Client documents treated as untrusted input. A report, email or spreadsheet from a client can contain text that tries to instruct the agent. OWASP's prompt injection guidance and its list of risks for language model applications are good references for designing around this.
  • Re-identification review. Reviewers should ask whether a sector expert could guess the client from the entry. Unusual structures, locations, timings and combinations of facts are the usual culprits.
  • Retention and deletion tied to contracts. When an engagement terms out or a client asks for removal, the vault and any approved entries derived from it can be located and handled.
  • Complete logs. Every read, draft, approval and retrieval is recorded, so a partner can review activity and the firm can investigate any concern.
  • Leakage tests. Run recurring test questions designed to pull confidential details across a wall, and treat any success as an incident.

The NIST AI Risk Management Framework is a sensible structure for organizing this work: identify the risks, measure them, manage them and assign accountability. It also gives partners and clients a shared vocabulary when they ask how the firm governs its agents.

The same discipline helps beyond knowledge capture. A consultancy running engagements through a delivery office can apply it to status and risk reporting, as described in AI for a project management office, because the same client walls apply to those reports.

How does Be Human handle this for a consultancy?

Be Human designs, implements and operates this kind of infrastructure for companies. A first engagement defines one useful role, here usually the knowledge steward, along with the memory tiers it needs, the tools it may use, the approval boundaries for publishing to the firm library and an observable success criterion, such as whether proposal teams retrieve and cite approved entries. Managed operations then cover monitoring, recurring evaluations including leakage tests, permission review, integration maintenance, incident response and controlled improvements, with the firm's people keeping control of what enters shared memory.

Firms that already run similar loops in adjacent functions may find useful parallels in superintelligent agents for accounting firms, where client records and advisory insight face the same tension.

Frequently asked questions

Can an agent learn from client work without exposing that client? Yes, if learning means distilled lessons approved by a person rather than free access to raw files. The agent drafts general method, pattern and delivery learnings from one engagement's vault, and a reviewer removes anything identifying before it reaches the firm library. The raw material never becomes searchable outside the engagement team.

Should we fine-tune a model on our past engagements? For most consultancies, retrieval from governed stores is the better starting point. It lets you see what the agent can draw on, correct or remove entries and honor contract limits, none of which is practical once material is absorbed into model weights. Your technical advisers can weigh the options for your specific case.

Who should approve entries in the firm library? A named person who understands both the work and the client relationship, typically the engagement manager together with a partner or knowledge lead. Approval means checking for accuracy, usefulness and re-identification risk. Giving that responsibility to a single owner per entry also makes later corrections simple.

Where should a consultancy start? Pick one practice area and a small number of recently closed engagements, write the one-page sharing policy and run the capture, draft, review and publish loop by hand with the agent assisting. Once reviewers trust the entries and teams cite them in new proposals, expand to more practices and add recurring evaluations.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.

Less busywork. More room for you.

Bring us the work you wish you had time for.

Try a personalized AI agent free for 7 days on WhatsApp ↗