Mentoring Team 21 to 3rd Place at RBC's TechPowHer Hackathon

Before the team story, the scale of the event is worth stating plainly — this wasn't a small internal exercise.

178 participants spanning 12 lines of business and 20 different roles, split across 5 use cases, each judged by its own panel. Four VPs sat on our use case's executive panel: Suhanniyah Carpenter (VP, Loyalty & Digital Technology), Shohreh Mouri (VP, Ventures Technology), Ryan Mayor (VP, Personal Credit Technology), and Michael R. Taylor (VP, End User Services).

I was one of 15 mentors for the week. Most of the more experienced mentors, myself included, were actually paired with two teams rather than one — I mentored a second team on a different use case that unfortunately didn't make it to the finale, so this post is entirely about Team 21's run.

Our team was assigned Use Case #5 — Real-Time AI Insights: Transforming Client Conversations into Tailored Financial Solutions, one of five use cases run that week (the others covered agentic commerce, AI-powered hiring, secure digital communications, and AML investigation).

What Advisors Actually Deal With Today

It's worth spelling out the current state, because it's what makes the ask worth solving. Today, when an advisor recruits a new client, the actual work looks like this:

• Digesting unstructured inputs by hand. A prospect shows up with a stack of physical bank statements, scattered investment PDFs, and whatever they said out loud in the meeting. None of it is structured. The advisor (and often their support team) has to read all of it, manually extract the numbers that matter, and reconcile it against what the client said their goals were.
• Building the proposal after the meeting, not during it. Because that digestion takes real time — hours, sometimes spread across days — the financial plan doesn't come back to the client live. It comes back in a follow-up meeting or an email, by which point the moment (and some of the client's enthusiasm) has passed.
• Re-keying the same data into multiple systems. Once a client accepts a proposal, the advisor's team manually opens the account on the custodian platform (Broadridge), re-enters the same client and product details into Client Source, and populates the Investment Policy Statement (IPS) by hand for every downstream system that needs it — pre/post-trade compliance included. It's the same information typed three or four different times, by a person, with all the transcription-error risk that implies.
• Rebalancing on a lag. Once funds actually land in the new account, checking the current holdings against the IPS target mix and deciding what to trade is another manual review — not something that happens the moment the money clears.

None of these steps are hard, individually. They're just slow, repetitive, and entirely dependent on a person doing careful manual work across systems that don't talk to each other — which is exactly the kind of gap generative AI is good at closing, if you architect it as a stateful process instead of a one-off summarizer. That's the ask the use case put in front of us. In short: advisors spend hours manually digesting unstructured client data before they can even start giving advice, and then spend more hours re-keying the same data across systems after the client says yes. The ask was a three-step lifecycle:

1. Build a proposal live, in the meeting, from a prospect's raw documents and conversation — validated by the advisor, then reviewed and tweakable by the client in the same sitting.
2. On acceptance, auto-trigger account opening and IPS (Investment Policy Statement) population across downstream systems — no manual re-keying.
3. Once funds land, trigger a portfolio rebalance recommendation against the IPS target, for the advisor to review and submit.

The judging rubric weighted Creativity (30 pts) and Solution Design (25 pts) heaviest, with GenAI Leverage (20), UX (15), and Impact (10) rounding it out — so whatever we built had to show AI reasoning over the client's actual data, not just render a templated form.

The hardest thing to get a team to see in week one isn't the tech — it's that four scenarios sound like four separate features when they're really one continuous, client_id-keyed lifecycle that just doesn't all happen at the same pace or in the same session. I mapped it out for the team like this:

That distinction — stages 1–3 are seconds apart in one meeting, stage 4 is a batch job days later — is what turned "build four features" into "build one stateful graph and one background job," which is a much smaller and much more honest problem.

I suggested LangGraph as the orchestration layer specifically because the brief's central twist — the client changing their mind mid-meeting — is a loop, not a pipeline. A one-shot chain (extract → generate → done) can't handle "my daughter just got into med school, I need to push retirement back two years" without a full re-run from scratch. A stateful graph can loop back through the same nodes with an updated constraint and keep prior context.

The stack I recommended:

• LangChain for the individual agent logic — document parsing, risk-tolerance scoring against research material, proposal narrative generation.
• LangGraph to orchestrate the four nodes as a stateful graph, so the Refine loop could re-run Align and Generate with a new constraint (e.g., a life event pushing the retirement target out) without discarding everything already extracted.
• Streamlit for both the client- and advisor-facing UI, built on the assumption it's embedded as a panel inside whatever meeting app is already running — Webex, Slack, Zoom — rather than a separate destination the advisor has to switch to.

This is deliberately an MVP stack. LangChain, LangGraph, and Streamlit let a team with one week and no prior multi-agent experience get to a working, demoable graph fast — that was the right call for a five-day build. It is not the stack I'd recommend shipping to production as-is: a real deployment would need a more secure and reliable architecture around it — proper auth and data-handling boundaries around client financial documents, durable state instead of in-memory graph state, a production-grade UI rather than Streamlit, and the harness engineering (retries, guardrails, evaluation, observability) that multi-agent orchestration needs once it's making real recommendations instead of running a demo. Going from a hackathon MVP to something production-grade is its own separate exercise.

I also gave the team a scripting rubric mapped directly to the judging criteria, so every live AI response — not just the final slide — hit creativity, named the responsible node out loud, referenced a specific detail from the prospect's own documents, and closed with a concrete time-or-effort-saved statement. Judges span very different domains; you can't assume they'll infer what's happening under the hood; you have to say it.

Everything above — the architecture, the framing, the scripting — is just the plan. None of it wins anything on its own. So before getting to what got built, here's who built it: six co-op students, fully remote, most without prior multi-agent experience, who out-executed teams with every structural advantage over them. 3rd place out of 22 teams, please welcome Team 21: Debug & Conquer:

• Jerry Chen
• Jocelyne Li
• Minhui Roh
• Camberly Hernandez-Paredes
• Taha Mirza
• Jaden Moore

That's genuinely the team, mid-huddle, pointing at "less time assembling, more time advising" on the whiteboard behind them — the line they'd landed on as the actual goal behind the solution, not just a tagline for the slide. Everything they built, from Extract through the day-one rebalance, was in service of that one sentence.

Team 21 built and demoed the two hardest scenarios — the golden path — end to end, live, with a shared laptop screen:

Scenario 1 — the messy first meeting. A prospect arrives with a stack of physical bank statements and a disorganized folder of PDFs. The advisor uploads them live on screen; within seconds, Extract → Align → Generate produces a structured financial plan. That's the "wow" beat.

Scenario 2 — the real-time tweak. Mid-meeting, the client says "actually, my daughter just got into med school — I need to push retirement back two years to cover it." The advisor drags a retirement-age slider, Refine loops back through Align and Generate with the new constraint, and the plan updates live — no reload, no re-upload.

Those two carried the judging weight and had to be flawless live, so they got rehearsed hardest. But the team also carved out time in the 7-minute run to push into the back half of the lifecycle:

Scenario 3 — one-click onboarding. The client clicks Accept on the digital proposal, and that single click auto-triggers the account-open process — on the custodian platform (Broadridge) and on Client Source — and populates the Investment Policy Statement across the downstream systems that need it. The team scripted this as a visual "data flowing into Broadridge/Client Source" beat, with the populated IPS view left on screen for the advisor to point at directly.

Scenario 4 — the day-one rebalance. Once funds actually land in the new account — days later, not in the same meeting — the system compares the current cash position against the IPS target mix and produces a rebalance recommendation on a "Review & Submit" screen, for the advisor to check before anything is submitted. This was the stretch scenario, held for whatever time was left after 1–3, but it's what closes the loop from proposal to a funded, invested account — and it's the answer the team had ready when judges asked "what happens after the client says yes and the money actually shows up?"

Five winning teams were chosen across the five use cases. Team 21 took 3rd place — a strong result for six co-op students, most of whom hadn't touched LangGraph before the week started, going from a use-case email to a scripted, judge-ready live demo in five days. They didn't just follow the implementation plan and scenarios I handed them — they understood the why behind the architecture well enough to turn it into real, working code on their own.

Two things made that harder than it sounds. First, the whole team was fully remote for the week, which makes fast iteration on a shared codebase and a live demo genuinely more friction-prone than working side by side. Second, they were co-op students, not full-time hires with the week cleared for this — they still had their day-to-day work with their home teams to keep up with, and had to carve out hackathon time around it. Landing 3rd under both constraints is the part I'm proudest of.

I really appreciate the trust they put in me and in the process I laid out for them — that means a lot. But honestly, the credit belongs to the six of them. I set the pace and the structure; they were the ones who showed up, put in the work, and delivered. That's not something a mentor can force — it comes from the team. 3rd place in a one-week hackathon, while remote and juggling their day-to-day co-op work, is no small thing, and they should all be genuinely proud of what they built. The fact that they came together as co-ops and shipped something real speaks volumes about where they're headed.

Being on the mentor side of RBC's Women in Technology and Operations initiative for a week like this was a genuinely good use of the time — watching six people go from "what's a state graph" to confidently narrating node names to a VP panel is the kind of compression you don't get to see very often. It was a great experience mentoring all of them, and I'd do it again in a heartbeat.

My colleague Vinupriya, it was great to connect with you.

Catching Michael R. Taylor (VP, End User Services) after the results were announced — one of the four executive judges who sat through every team's seven minutes and Q&A for our use case that week.

• Name the loop, not the pipeline. The entire "real-time" story in the use case name lived in one architectural decision: a stateful graph that can re-enter itself, versus a linear chain that can't.
• One lifecycle beats four demos. Mapping all four scenarios onto a single client_id timeline — some seconds apart, one days later — turned an overwhelming brief into a scoped, sequenced build plan.
• Script the AI's voice to the rubric. When judges span a dozen lines of business, you can't assume domain fluency. Every live response named the node that produced it and closed with a concrete value statement.
• Build the golden path first, stretch goals second. Of four scenarios, the team fully executed the two that carried the judging weight, live, rather than spreading effort thin across all four.
• MVP stack ≠ production stack. LangChain, LangGraph, and Streamlit were the right choice to get a working demo out in a week — they are not what I'd recommend for a production deployment handling real client financial data without hardening the security, state durability, and orchestration guardrails first.
• Remote + co-op ≠ excuses. A fully remote team of co-op students still balancing their day-job workload placed 3rd against teams with more built-in advantages on both fronts.