Superintelligent Agents for Financial Advisors: Advice Under Rules

Superintelligent agents for financial advisors are best understood as highly capable assistants that prepare, draft, monitor and cross-check, while a licensed human decides and signs. Their value lies in absorbing the preparation and record-keeping around advice, not in giving advice on their own. In a regulated practice, the design question is less about how capable the agent is and more about which rules it cannot step around.

Key takeaways

• A capable agent should take on preparation, drafting, monitoring and documentation, and leave recommendations and sign-off to a licensed human.
• Compliance and suitability rules must be enforced by the system around the agent (permissions, gates, approved sources), not only by instructions in a prompt.
• Every action the agent takes should leave a record that a supervisor or auditor can replay without asking anyone to remember what happened.
• Start with one narrow role, such as review preparation, and expand only when evaluations and supervisor feedback show it holds up.
• Client messages, documents and web pages are untrusted input. The agent must never treat instructions found inside them as authority.

What can a capable agent do for an advisor, and what should it never do?

Most of an advisor's week is not advice. It is gathering statements, reconciling notes from the last meeting, checking whether a client's circumstances have changed, drafting follow-ups, chasing signatures and making sure the file reflects what was said. That surrounding work is where a capable agent earns its place, because it is repetitive, document-heavy and easy to get slightly wrong when people are busy.

Useful tasks for an agent working under supervision include:

• Preparing a review brief from the client file: goals, stated risk tolerance, recent life events, open action items and documents that are missing or out of date.
• Drafting meeting notes and follow-up emails from an advisor's own summary, for the advisor to edit and send.
• Flagging drift between a client's recorded objectives and what the file now shows, so the advisor can decide whether a conversation is needed.
• Checking draft communications against the firm's approved language and the rules the compliance team has written down.
• Tracking deadlines for forms, disclosures and periodic reviews, and reminding the right person.
• Assembling the evidence pack a compliance officer will want to see for a given interaction.

The list of things it should never do is shorter and firmer:

• Recommend a specific product or allocation to a client without a licensed human reviewing and owning the recommendation.
• Send client-facing messages that contain advice, performance claims or promises without approval.
• Change the recorded risk profile, objectives or suitability conclusions of a client on its own.
• Move money, place orders or alter account instructions.
• Widen its own access, or use information from one client's file to inform another's.

The boundary is not about distrust of the technology. It is the same boundary a firm draws for a capable junior analyst: wide freedom to prepare, narrow authority to commit.

Where do compliance and suitability live in the design?

The most common mistake is to write the rules into a prompt and call the agent compliant. Instructions are guidance, not enforcement. A model can misread them, forget them in a long session, or be steered away from them by text inside a document it was asked to read. Rules that matter need to be enforced in the structure around the agent.

In practice that means four layers.

First, permissions. The agent should have the least access that lets it do its job, denied by default and granted per tool and per client book. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) describes the underlying principles well: least privilege, deny by default, and checking authorization on every request rather than once at login. An agent that prepares reviews for one advisor's clients should not be technically able to open another advisor's files, regardless of what it is asked.

Second, approved sources. Product descriptions, disclosure language, fee explanations and house views should come from a controlled library that compliance owns. When the agent drafts, it retrieves from that library and cites which item it used. If nothing approved covers the question, the correct output is a flag to the advisor, not an improvised answer.

Third, hard gates. Certain actions cannot complete without a named human approval recorded in the system: sending a client communication that touches on recommendations, updating a suitability record, or filing anything with an external party. The gate is a step in the workflow, so the agent cannot skip it even if it wanted to.

Fourth, input hygiene. Client emails, uploaded PDFs and web pages can contain text that looks like an instruction. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) lists prompt injection and excessive agency among the main risks for this reason. The design response is to treat all external content as data, never as commands, and to keep high-impact tools out of reach of any step that reads untrusted material.

Suitability deserves its own note. The agent can organize the facts a suitability assessment relies on, show where the file is thin or stale, and draft the rationale the advisor would otherwise write from scratch. But the judgment that something is suitable for a particular person is the advisor's, and the record should show that the advisor made it, with the agent's contribution clearly labeled as preparation.

For how compliance teams think about evidence, reviews and alerts more broadly, see AI for Compliance Teams: Evidence, Reviews and Alerts.

What does the audit trail need to capture?

If a supervisor cannot reconstruct what the agent did and why, the firm has taken on a risk it cannot see. Good audit design starts from the questions a reviewer will actually ask: who asked for this, what did the agent look at, what did it produce, who approved it, and what changed as a result.

A workable record for each agent action includes:

• The requesting person and the client file involved.
• The sources retrieved, with versions, so the reviewer can see what the agent relied on.
• The draft the agent produced and every edit a human made before it went out.
• The approval: who, when, and what they were shown at the time.
• Any rule check that fired, passed or blocked the action, and the reason.
• Any tool call the agent made, including calls that were refused by permissions.

This record should live outside the agent's own memory, in a store the agent can write to but not edit or delete. Observability practices for software systems apply directly here. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) explains traces and logs as ways to follow a request through many steps, which is exactly the shape of an agent workflow with retrieval, drafting, checking and approval.

There is also a governance dimension. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organizes AI risk work around governing, mapping, measuring and managing. A wealth management firm does not need to adopt it wholesale, but its structure is a useful checklist for who owns the agent, what it is allowed to do, how its quality is measured and what happens when it fails.

Internal audit and second-line teams will want to sample these records periodically. The approach in AI for an Internal Audit Team: Evidence, Samples and Findings shows how the same kind of structured trail makes sampling faster and findings easier to trace.

Illustrative scenario: preparing an annual review

This is an illustrative scenario, not a description of a real firm.

An advisor has a set of clients with annual reviews coming up. Today, preparing each one means opening the CRM, scanning old notes, finding the latest statements and checking whether anything about the client's life has changed.

With a supervised agent in place, the week before each review goes like this:

• The agent assembles a brief from the client file: stated goals, recorded risk tolerance, last review's action items, documents on file and their dates.
• It flags that the risk questionnaire is older than the firm's review interval, that a beneficiary form is missing, and that a note from a recent call mentions a planned home purchase that is not reflected in the goals.
• It drafts an agenda and a short pre-meeting email for the advisor to edit. The email uses only approved language and asks the client to confirm their circumstances, without suggesting any product.
• The advisor edits the email and approves it. The approval is logged with the version the advisor saw.
• After the meeting, the advisor dictates a summary. The agent drafts the file note and a follow-up email, and marks any sentence that sounds like a recommendation so the advisor and compliance can look at it first.
• Updates to the risk profile or suitability record wait in a pending state until the advisor confirms them.

Nothing in this flow lets the agent decide anything on a client's behalf. What changes is that the advisor arrives at the meeting prepared, the file is current, and the evidence pack exists before anyone asks for it.

A related pattern appears in other document-heavy, regulated work, such as the reminders and status updates covered in AI for Mortgage Brokers: Documents, Updates and Reminders. Where tax or accounting coordination matters, Superintelligent Agents for Accounting Firms: Close to Advisory is a useful companion.

What is a sensible plan for a first deployment?

A first deployment should be small enough to supervise closely and useful enough that advisors want to keep using it. The following sequence works for most practices.

• Choose one role. Review preparation or post-meeting documentation are good candidates because the output is reviewed by a human by default.
• Write the rules down in a form a system can check: which communications need approval, which records the agent may read, which it may propose changes to, and which it may never touch.
• Define what the agent can access. Give it read access to the minimum set of client data and a separate, restricted way to propose edits.
• Build the approved content library with compliance, including disclosure language, fee explanations and phrases to avoid.
• Set the approval gates in the workflow itself, with named roles and a record of what the approver saw.
• Create an evaluation set from realistic past cases, including awkward ones: stale files, contradictory notes, clients who write in with instructions embedded in an email. Guidance on designing such tests is in [Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents).
• Run in shadow mode first. The agent prepares, the advisor works as usual, and the two are compared before any output reaches a client.
• Move to supervised use with sampling by compliance. Review a sample of outputs and the audit records on a regular schedule.
• Define the stop conditions: what triggers a pause, who can pause the agent, and how an incident is reviewed.
• Expand scope only after the evaluation results and supervisor feedback support it, one capability at a time.

The success criterion should be observable and modest: for example, that reviews are prepared from a current file, that no client-facing message left without approval, and that every record can be replayed.

How does Be Human's managed approach handle this?

Be Human designs, implements and operates personalized AI infrastructure for companies, with the agent's identity, memory, tools, permissions and operating context kept under human control. A first engagement for an advisory practice would define one useful role, such as review preparation, along with the memory and tools it needs, the approval boundaries, and a success criterion that can be observed. Managed operations can then cover monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so that the rules the firm has set continue to hold as the agent and its connected systems change. Service is remote and available in English and Portuguese.

Frequently asked questions

Can a superintelligent agent give investment advice to clients directly? In a regulated advisory practice it should not. The agent can prepare materials, organize facts and draft communications, but recommendations should be reviewed and owned by a licensed human, and the system should block client-facing advice from leaving without that approval.

How do we keep the agent inside our compliance rules? Enforce the rules in the system around the agent: restricted permissions, an approved content library, mandatory approval gates and complete logging. Instructions in a prompt help, but they should be treated as guidance, with the structural controls doing the enforcing.

What happens if a client email contains instructions aimed at the agent? The agent should treat all client messages and documents as data, not commands. Tools that can change records or send messages should be unreachable from steps that read untrusted content, and any attempt to redirect the agent should be logged and surfaced to a human.

Where should a wealth management firm start? Start with one narrow, reviewable role such as annual review preparation or meeting documentation. Define the rules, the approvals and the success criterion first, test against realistic past cases, and expand only when supervisors are satisfied with what they see in the records.

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