Family wealth engine
About this agent
A multi-entity wealth-management co-pilot for MFDs, RIAs and multi-family offices, built for households that hold capital across several PANs — individuals, spouses, minors, HUFs, trusts and corporate holding entities — rather than one account. It consolidates every linked entity into a single household view: equity/debt/cash/international split, drift from a target equity band, and, the reason a relational memory graph exists at all, cross-entity concentration that is invisible looking at any one PAN alone, such as the same stock turning up in six different funds spread across different family members. It also routes fresh lump-sum capital toward the entities where it will be taxed most lightly — a senior citizen's higher exemption, a still-unused basic exemption band — while deliberately deprioritising minors because of income-clubbing rules, and tracks estate goals: earmarked corpus, target dates and nominee status, flagging the ones running out of runway. All of the arithmetic — concentration percentages, tax-headroom scoring, drift, funded percentages — runs deterministically in plain Python, never inside the model; zenmem's callLLM is used only to narrate the computed numbers into an advisor briefing and a client-facing rebalance explainer, and every household's data lives in its own project-scoped memory keyed to FAMILY_GROUP_<ID> so it persists across review sittings. It refuses to invent tax advice or holdings data it wasn't given — real scheme-holdings and tax-slab data has to come from a connected database the firm supplies.
What changed with Zenmem?
The same agent, built twice against the same contract — once on Zenmem, once on MongoDB + LangChain/LangGraph.
Before → after
Before With Zenmem
What the team gained
- A household is one project scope, so its entity graph, concentration history and estate goals are read across years — the only span in which a family's tax and inheritance picture makes sense.
- Multiple PANs sit inside one household scope without a join table modelling who belongs to whom.
- An advisor review meeting is session-scoped, so trade simulations that do not survive the sitting never reach the household record.
- Concentration and tax arithmetic stay deterministic outside the model, with memory carrying the narrative around it.
- Firm-wide house views have a scope waiting for them, so adding them later is a call parameter rather than a new store.
How memory is scoped
Three scopes, though only two are wired up today. Project memory, keyed to projectId="FAMILY_GROUP_<ID>", is the household's own — its entity graph, concentration history and estate goals, kept indefinitely because a family's tax and inheritance picture only makes sense read across years, not one sitting. Session memory holds one advisor review meeting: the trade simulations and multi-PAN chat feedback that don't need to outlive the sitting. Company-scope memory, for firm-wide house views, is available in the SDK but not yet used by this workspace — it is flagged as the natural place to add firm-level context that should inform every household's briefing, without collapsing distinct families into one memory.
How it works
Compute, flag, route, narrate, commit.
Consolidate the household
Every linked PAN, HUF and trust is rolled into one snapshot — equity, debt, cash drag and international exposure — and checked for drift from the target equity band.
Flag hidden concentration
Underlying stock weights inside every scheme, across every entity, are summed to catch a single-stock exposure that no one account would show on its own.
Route fresh capital by tax headroom
A lump sum is split across entities by unused exemption, marginal rate and senior-citizen status, capped so no single PAN absorbs it all.
Track estate goals
Earmarked corpus against future milestones — a grandchild's education fund, a nominee not yet registered — surfaced as the things needing action before the next review.
Narrate and commit
The deterministic numbers are handed to zenmem's callLLM for advisor narrative, and an approved rebalance is written atomically into the household's project memory.
What it does
Five engines plus the orchestrator that ties them to zenmem.
Capabilities
- HouseholdEngine.snapshot() — real-time equity/debt/cash/international breakdown across every linked PAN, HUF and trust.
- HouseholdEngine.drift_from_target() — flags a household that has drifted outside its target equity band.
- ConcentrationShield.scan() — top single-stock exposures across the household, ranked and marked info/warning/breach against configurable thresholds (10% / 15%).
- ConcentrationShield.breaches() — every stock over the breach threshold, unbounded, for full concentration-detection coverage rather than just the advisor-facing top three.
- TaxOptimizer.route_lump_sum() — routes fresh capital across entities by remaining tax headroom, with minors deprioritised for income-clubbing reasons and a per-entity cap.
- EstatePlanner.at_risk_goals() / rebalancing_schedule() — underfunded or nominee-missing estate goals, and a step-up contribution schedule ordered by urgency.
- Agent6.run_household_audit() — runs the deterministic engines, then asks zenmem's callLLM to narrate the audit as an advisor briefing.
- Agent6.commit_rebalance() — atomically commits an approved rebalance to the household's project memory, with an optional client-facing explainer narrative.
- Agent6.recall() — ad hoc fetchMemory query against one household's project-scoped memory.