Remy is an AI teammate for relationship managers and financial advisors in wealth management. It keeps a complete, sourced client memory for every relationship the advisor covers, works through the whole book overnight, and at 07:00 hands over a ready-to-action day: a morning dashboard, a brief for every upcoming meeting and a prepared draft for every open item. The advisor checks, decides and sends. Remy never does.
Remy reads the advisor's mail, calendar, Teams, CRM, portfolio data and client documents, always under the advisor's own permissions. It files what matters into one memory per relationship: 14 topic pages such as compliance, goals, risk and commitments, plus open actions, meetings and a change log.
→ HOW THE MEMORY WORKSWhile nobody is online, Remy works through every client. It spots what needs attention (an expiring document, a portfolio outside its bands, an overdue promise, an upcoming meeting, a market event), writes a brief for each meeting and drafts a letter for each open item.
→ THE OVERNIGHT PIPELINEThe morning dashboard is waiting. The advisor approves, adjusts or declines. Letters go out from the advisor's own mailbox, in their name and voice. Whatever the advisor corrects, confirms or sends flows back into the memory on the next run.
→ GUARDRAILSMemory is not the product. The product is the work Remy builds from it. Overnight, Remy turns the memory into finished artifacts. In the morning the advisor finds them ready, with no prompting. Their job is to check and approve. Anything that reaches a client goes out in the advisor's name and voice, so the client feels they are working with a person.
A value taken from one system and shown in one place. You can point to the field it came from. This is what a chat assistant with connectors does.
A conclusion that exists only because two or more sources were joined. On a call in May the client said they were expanding into Asia; this week the news reports a Singapore office, and the policy on file covers one jurisdiction. Remy flags the gap and drafts the proposal.
→ WHY REMYRead left to right. Sources feed the client memory; Remy turns the memory into the day; the advisor decides and sends, and what they do flows back in on the next run. The guardrails hold across all four.
Every user has a second brain in their personal home folder. It holds one client memory per client, plus a user memory about the user, kept strictly apart from the client memories. Remy mines sources into it, reads from it, and builds that user's dashboard. A desk memory is a separate, shared memory. Remy mines it from the second brains of the desk's members, with its own rules. Every memory is access-controlled, and mining only ever adds. From this memory Remy prepares real work overnight, and the user's role is to check and approve it.
The systems information comes from: chat, Outlook (mail, calendar), Teams (chats, calls), the CRM, other connected systems, and the web. Remy mines them into memory.
Shared files around Remy. That includes one folder of raw documents per client (KYC, portfolio, correspondence, …), and those folders are mined like any other source.
A user's personal memory, in their home folder. It has two parts: one client memory per client, and the user memory. Remy reads it and adds to it. It is where user and Remy talk to each other: the user sees what Remy knows and why.
One folder per client inside the second brain: topic pages (compliance, balance sheet, goals, risk, relationship, network, …), open actions, meetings, a change log, and _meta/ with the identity map and mining and chat logs. Every fact carries its source.
One per user, in the home folder. Each of Remy's skills adds its own cards: the work list, meetings, the market radar, and client lists. The user's ticks go back into actions.json.
One combined memory for a desk or the whole company, built like a second brain: one client memory per client. Remy mines the members' second brains into it, with the desk's own rules. Its page set differs from the personal one.
Part of the second brain, but about the user, not about clients: their preferences and way of working. It is kept completely apart from the client memories and holds no client identifying data (CID) at all. Client facts always go into the client memory.
The client memory is the bank's memory of the relationship. It is an existing platform primitive, not a new store: permissions, search, citation, versioning, retention and backup are inherited. The skills rebuild it on every run and the advisor corrects it in chat or on the page. The documents stay where they are, in the client document folder; the memory records facts and links to them.
Every page has an authorship class that says who may write what, and every fact carries its provenance.
index.mdcompliance.mdscreening.mdbalance-sheet.mdcash-flow.mdgoals.mdrisk.mdtax.mdmandate.mdrelationship.mdcommercial.mdcommitments.mdnetwork.mdin-flight.mdsow.md · referrals.mdWritten by mining (from the sources), remember (from chat) and update (curation). The advisor may edit a topic page directly. Prospects start with a single index.md and gain the full set at onboarding. Which pages are in scope at launch, and which fields are system-of-record mirrors, is set per bank in the design phase. The sufficiency test for the schema: a meeting brief must be reproducible from the memory alone.
actions.md · meetings.mdchanges.mddocuments.mdactions/<id>.email.md_meta/clients/_meta/The authorship class is what stops mining from writing a PEP status onto the compliance page and leaving the bank holding two KYC records.
A brief that shows an amount, date or status renders its basis beside it: an estimate never looks like a balance.
The same client can hold more than one memory at once; these are separate folders, not copies. Promotion between levels and precedence are configured by the administrator. The promotion rule (what, by whom, under which rule) is agreed in the design phase and recorded in the change log.
Exactly one marker per memory, each transition with one owner. Mining may stamp a missing marker from evidence but never moves a confirmed state. The advisor's confirmation is the only sign-off that a prospect becomes a client.
The memory is fed from the knowledge base plus the systems the bank connects. Identity is resolved once per client and source; afterwards connected systems are queried by the stored client ID, and every web hit is re-corroborated. A name alone is never an identity.
The connectors decide what can be read, the identity gate decides which client it belongs to, and only then does the mining pipeline write the memory.
| Source | Permission | Window | Identity key |
|---|---|---|---|
| Client document folder | Folder permissions | Full | Folder name + master client ID |
| Chat | User's session | Across runs | User's own folders; ambiguity asked back |
| Outlook | Delegated: mail read, calendar read, draft create | 30 d back · 7 d ahead | Mailbox, message and event IDs |
| Teams | Delegated: chat read; transcripts where licensed | 30 d back · 7 d ahead | Participant / chat / call IDs |
| CRM / client record | Read | Full | Record ID = master client ID |
| Portfolio / core banking | Read | Full | System ID |
| Web search | Outbound, subject to approval | Current | None stored; two independent keys per hit |
| SharePoint · OneDrive · DMS | Platform connectors | n/a | Via the document folder |
| Custom (MCP server) | As granted per server | Per integration | That system's ID, confirmed like any other |
A connector that is absent is out of scope for that run; every mining report states which sources were used. Fixed windows keep runs predictable and cheap; the mining log makes them idempotent. What each missing connector limits is listed on Before you begin.
| A stored ID wins | Once confirmed, queried by ID, never re-matched by name |
| A name is a hypothesis | Needs a second key (email, phone, account, DOB) or the user |
| Ambiguity stops the merge | Candidates recorded unconfirmed; nothing mined; run reports it |
| Only confirmed feeds a memory | Probable and unconfirmed rows are skipped entirely |
| A real ID arriving later | Folder name stays; identifier added to the map |
This is the gate against cross-client spillover, the one failure a bank cannot accept, and it holds by construction.
The tier decides what content from a source is allowed to do, never whether the source is read. Untrusted content can supply facts but never instruct the system: the main defence against prompt injection from incoming mail and web pages.
refreshupdateredoNine steps, reported live, kept in an install report. Steps 1–2 (find sources, build the memory) are agent work; 3–9 are one command that refuses to run while 1–2 are unreported. Five clients are mined in parallel as subagents, falling back to inline mining where delegation is unavailable. Planning guidance is on Before you begin.
Scheduled tasks turn Remy from a set of on-demand skills into a standing overnight batch: every night the memory refreshes, the monitors raise what needs attention and the briefs are prepared. Nothing in the pipeline sends, decides or writes to a system of record.
What each run touches and how long it takes is on Running, monitoring, upgrading and recovery.
| Time | Cadence | Skill | Purpose |
|---|---|---|---|
| 04:45 | daily | inbox | Inbound client files into the document folders |
| 05:00 | daily | mine (refresh) | Nightly memory update from all sources |
| 05:20 | daily | market-radar | Overnight market scan → per-client impact, book radar |
| 05:30 | Monday | doc-expiry | Weekly KYC document expiry check |
| 05:45 | Monday | screen | Weekly adverse-media and PEP screening |
| 05:50 | 1st of month | portfolio-drift | Drift versus mandate |
| 06:10 | 1st of month | suitability-review | Suitability cycle and material-change check |
| 05:30 | 15th of month | update | Memory curation: dedupe, rephrase, reshuffle |
| 05:30 | 8th of month | referrals | Referral mining; heaviest web run, on its own day |
| 06:00 | daily | meeting-brief | Meetings register and briefs, next five business days |
| 06:20 | daily | actions-sync | Apply dashboard ticks once the mailbox confirms |
| 06:30 | daily | dashboard | Morning page, ready by 07:00 |
| 05:30 | quarterly · optional | sow | Source-of-wealth refresh; normally on demand |
Not installed by default: audit (suggested quarterly for integrity checks). Shaded rows run every night.
| Monitor | Default | Alternative |
|---|---|---|
| Screening | Weekly | Align to the bank's periodic review cycle |
| Portfolio drift | Monthly | Daily/weekly for persistence-based escalation |
| Suitability | Monthly | Weekly for a higher-touch book |
| Referrals | Monthly on the 8th | Quarterly for a large book; on demand for one client before a meeting |
| Actions sync | Once, before the dashboard | Several times a day if midday ticks should land before tomorrow |
| Document expiry | Weekly | Daily is cheap: a pure date comparison |
The cadence is a deployment setting, aligned to the bank's risk-based review cycle.
Before the schedules can be useful the book needs one full pass: the installer. A newly registered prospect gets a per-client catch-up prompt instead of waiting for the night. The install steps are under First run per user.
A skill is a versioned task definition in prose: declared inputs, outputs, permitted tools, write policy, evaluation suite. Where a monitor needs rules, it reads them from a policy file. A skill runs as the invoking user and never grants permissions. All skills produce drafts; none sends client mail or writes to a system of record.
Default cadences for the scheduled skills are on Schedules.
mineBuilds and refreshes the memory from folders and every connector. refresh · update · redoupdateCurates without mining. Never drops an advisor-entered factrememberWrites a chat fact to its page, tagged. forget removes via a logged pathaskAnswers from the memory with citations. Read-onlyauditHealth report: coverage, broken links, unsourced facts, stale mirrors. Read-onlydoc-expiryT−60 / T−30 / expired, "not on file"weeklyportfolio-driftHoldings vs bands, limits, prohibitionsmonthlysuitability-reviewTiming and material changes; dossier, no conclusionmonthlyscreenAdverse media and PEP; two keys per hit; pending dispositionweeklymarket-radar24 h of market news scored per client and booknightlydashboardRebuilds the morning page from all registers; writes nothing elsefocusOne ranked focus day: the recommendations cardmeeting-briefOne brief per meeting, HTML and branded PDFmeeting-followupWrite-up, outcome written back, follow-up draftdraft-emailOne drafted client email in two toneshome · design-systemOpens the dashboard; canonical visual identity and brand-pack overrideregisterNew prospect: namesake check, folders, mining, baseline screening, Day 1 gapsonboardProspect to client: gap check, bundled request, hand-off packonboarding-intakePopulated intake workbook from the onboarding folderoffboardStart or complete without deleting the archivesowSource-of-wealth narrative, proposed; never a KYC determinationinboxFiles inbound attachments into the document folders; never writes the memoryactions-syncDone cards reconciled with the mailbox; reopened if unverifiedreferralsPublic network per client, scoring, graph on network.md, dossiersinstallUnattended first run, nine steps. Never asks, never sendssetupData mode, platform, connectors, user name; verifies connectionsschedulerInstalls, inspects, retunes, pauses, removes the recurring runscheck · versionHealth report, running build, where memory lives, how to run any commandThe two panels below are developer contracts, explained on Extending Remy.
The dashboard reads the register: a new monitor appears on it with no UI work.
The guarantees Remy makes to a regulated institution, each paired with the mechanism that enforces it, and the security posture of the runtime.
| Reviews and sends | Draft in their own mailbox; the sent mail is mined on the next run and the action clears |
| Corrects and confirms | Remember, forget, edit, disposition, adjudicate: tagged, logged, protected; newest never wins automatically |
| Talks to clients | Re-enters through the sources on the next run |
Everything Remy is and produces is a folder or a file in the knowledge base. Three trees, as an operator sees them.