Advisor Brief

A wealth advisor has six client meetings on tomorrow’s calendar. Each one needs 20-30 minutes of prep: pull the household’s portfolio data, scan today’s market events, refresh on the last conversation. Three hours of pattern-following work, the same shape every day.

Advisor Brief is the workflow that handles it. At 6pm tonight, a scheduled Azure Logic Apps run reads the next day’s calendar, looks up each client in CRM, pulls today’s market context, and generates a one-page HTML brief via Claude Sonnet 4.6 on Azure AI Foundry. The brief lands in the advisor’s inbox by 7am, formatted for a three-minute coffee read, before the day starts.

Two pieces of honest framing up front. First, I had never used any of these tools before starting this build: Logic Apps, Azure AI Foundry, the Anthropic API via Foundry, SendGrid, all new. End-to-end took about six hours over a weekend, which is to say this is what a generalist developer can ship in an afternoon once they sit down with Microsoft’s docs, not a battle-tested production system. Second, a real wealth-management firm’s deployment would look meaningfully different: more connectors into the firm’s existing CRM and research feeds, more compliance scaffolding driven by their specific regulatory posture, more integration surface for whatever already exists in the environment. The architecture and the controls described below carry forward. The production version is a much bigger build than this prototype.

what the workflow does

Every brief is structured the same way: client snapshot, portfolio context, market relevance, last-meeting recap, talking points, suggested questions, outstanding action items. The model produces both the structure and the HTML formatting in one pass, so the email arrives ready to read without a downstream rendering step.

A sample brief from one of the test runs is viewable in a separate tab: an annual review for the Tanaka household, with a concentrated employer-stock position and an open gap in the CRM around the 529 plan balances. The recipient address has been redacted; the household and figures are mocked test data.

Every generation gets a row in an audit table: timestamp, advisor, household, model version, token usage. The prototype stops there. A production audit log would add input and output content hashes for tamper evidence and mirror the table to immutable WORM storage.

the architecture

Logic Apps Consumption tier. Daily 6pm recurrence trigger. Three mocked data sources live in Azure Blob Storage: tomorrow’s meeting list, the CRM households table, today’s market brief. The workflow reads all three at the top of the run, then For-Each over the meeting list. The actual JSON files behind those three sources are viewable in a separate tab.

For each meeting: filter the CRM table to the matching household, compose a context-rich user prompt that fuses [CRM] + [MARKET] + [NOTES] tags into a single message, POST to Azure AI Foundry’s Anthropic-shaped endpoint (/anthropic/v1/messages), receive the generated HTML brief, then fork the result. SendGrid handles email delivery. Azure Table Storage receives the audit log entry. Loop back, next meeting.

five engineering decisions

Claude Sonnet 4.6 via Foundry rather than Azure OpenAI. Foundry’s unified model catalog is the defining capability. It supports Anthropic, OpenAI, Mistral, Meta, and others through a single governance layer with consistent content filtering, lineage tracking, and managed authentication. Anthropic was chosen here for Sonnet 4.6’s particular strength on structured-output and instruction-following tasks like this one. The architecture is model-agnostic; swapping to gpt-4o would be a deployment-name change, not a refactor.

Logic Apps rather than Power Automate. The two share the same underlying engine and designer paradigm; a Logic App workflow translates to a Power Automate flow with a connector swap, not a re-architecture. Logic Apps was chosen here because it runs entirely within Azure (no separate M365 tenant required for the dev environment); the same flow would deploy into a corporate Power Automate environment with minimal change.

HTML output generated directly by the model. The brief is a self-contained HTML fragment. Generating HTML directly (rather than producing markdown and converting in a separate step) keeps the pipeline lean and gives the model latitude to make formatting decisions. In practice it added color-coded portfolio drift values and a separate YTD performance table without being asked. The prompt only specifies the section structure; the layout work is the model’s.

SendGrid for email in the prototype, Outlook in production. The Gmail connector for Logic Apps is restricted by Google’s API User Data Policy and cannot coexist with non-Google connectors in the same workflow, which made it a non-starter once I added other steps. SendGrid was the easy second option for a demo running outside any corporate tenant. A Microsoft-integrated wealth-management firm would obviously want the Outlook connector instead, so the brief lands in the advisor’s regular corporate inbox under the firm’s domain. The swap is one connector change in the flow. The output format and the audit/citation pipeline are the same either way.

Citation tagging and hallucination guards. The system prompt requires every factual claim in the brief to be tagged with its source: [CRM], [MARKET], [NOTES], or a combination ([CRM/NOTES]). It explicitly forbids the model from inventing figures or relationships, and instructs it to flag missing or ambiguous fields rather than fill them in. In testing, the model correctly flagged a real CRM data ambiguity (whether $2.8M in money-market proceeds from a recent business sale was included in a household’s reported AUM figure) and refused to manufacture market relevance when the day’s market events were not materially connected to a household’s holdings. Both behaviors were goals of the prompt design, and both showed up in actual runs without further nudging.

the compliance layer

This is a financial services application, and AI-generated content here carries regulatory weight. The build reflects this:

• No investment recommendations. The system prompt explicitly forbids the model from suggesting buy, sell, or hold actions. It surfaces information and discussion topics; deciding what to do with them is the advisor’s job, not the model’s.
• Citation-tagged outputs. Every factual claim is traceable to its source ([CRM], [MARKET], [NOTES], or a combination), giving the advisor a verification path before any client communication.
• Disclaimer on every brief. Each output ends with a footer noting AI generation and the advisor’s responsibility to verify before client communication.
• Audit trail. Every generation is logged with timestamp, advisor, household, model version, and token usage. The date is the partition key for fast daily queries. Content hashes and WORM mirroring would round out a production version.
• Per-advisor delivery only. Briefs are emailed to a single named advisor, never bulk-distributed. Routing pulls from advisor records in the CRM rather than being hardcoded.

what’s actually built

Almost everything visible in the demo above is the easy half of a production system. The CRM is three fake households as JSON blobs in Blob Storage; the market brief is a single static daily summary; the meeting list is two scheduled meetings for the next day. None of that is hard to swap for real connectors. It’s connector configuration plus whatever auth the destination system demands. The pieces that aren’t trivially swappable (the workflow orchestration itself, the prompt design and constraints, the citation framework, and the audit log schema) are the parts I actually built.

where I’d take it

The most interesting extension is making the brief conversational. Right now it’s a one-shot daily email; what unlocks compounding value is exposing it as an Azure AI Foundry agent the advisor can ask follow-up questions of, backed by RAG over CRM history and the archive of prior briefs. Foundry’s agent framework is designed for exactly this. Brief generation becomes one of several agent tools, alongside “show me last quarter’s review notes” or “compare the Tanakas’ allocation to peer households.” That’s where this stops being an automation and becomes a working tool.

The rest of the production roadmap is mostly plumbing and hardening. Real CRM connectivity (Redtail, Salesforce Financial Services Cloud, Wealthbox; the firm’s stack picks the connector). Real market data from an internal research feed or a vendor like FactSet or Bloomberg. Managed Identity instead of access keys on every connector, with secrets in Key Vault. Foundry content-filter policy enforcement at the workspace level. A multi-advisor routing layer if the firm wants more than one advisor on this. Content hashes on every audit row plus WORM mirroring for tamper evidence, and a query UI compliance staff can use without needing to know Kusto. None of these are new architecture problems. They’re the work that happens once a firm decides this approach is worth investing in.