Matthew Ragone of Range describes how financial planners at his firm build their own AI agents without writing code: while one planner is on a client call, an agent drafts another client's cash flow or insurance analysis, with every recommendation reviewed before reaching the client. Six months in, he reports 24 skills across the company, including 17 in planning, with sales, product, and marketing adopting the same approach. He outlines a five-step process: pick a repeated workflow whose output you can judge, teach it with real cases, package the judgment into a skill, test it five to ten times, and ship it with an owner and separate reviewer. He emphasizes narrating why a document is opened rather than listing clicks, encoding questions and limits (such as 'an agent drafts but never sends recommendations') into the skill, and notes the open challenge of checking quality at scale when output requires professional judgment. # Video Identity Observations ## Video Overview - **Title:** *We Let Our Financial Planners Write the Agents — Matthew Ragone, Range* - **Speaker self-introduction:** *"Hi everyone, I'm Matt Rigon and I'm a financial planner at Range."* - **Format:** A conference-style talk with a stated tutorial purpose: *"This is the build guide. How we did it step by step so you can take it back to your own teams, companies, etc."* ## Intended Audience The presentation addresses a professional, business-oriented audience rather than general consumers: - **Non-engineers at firms adopting AI:** *"Most agent talks you'll hear come from the people who built the platform. This talk comes from someone on the other side, the people you hand the platform to."* - **Leaders responsible for deployment:** *"If you're being asked to push agents out past the engineering org, you're about to hit these exact questions."* - **Team-based operators** — advice is framed for teams (*"hand a half-baked skill to 15, 20, 100 people in your team"*), not solo hobbyists. ## Claimed Scope - **Subject-matter claim:** How domain experts (not developers) can build AI agents, via a five-step code-free method — *"pick, teach, pack, test, and then ship. None of them require writing code."* - **Firm-specific framing:** The speaker leads *"AI adoption for the planning team at Range, which is an all-in-one wealth management company."* - **Regulated-context emphasis:** *"We work in a regulated business. The output is financial advice to real clients. And the review step is not optional."* ## Self-Description Evidence - **Explicit positioning:** *"I'm not an engineer. I'm a certified financial planner."* - **Non-promotional disclaimer:** *"So, this isn't a vendor pitch. It's a method and it's what actually worked for us."* - **Claimed results:** *"Six months in, we have 24 skills across the company and 17 of them are in planning."* - **Contact/channel endpoint:** *"You can reach me for at mattrange.com"* — indicating a personal/professional outreach channel. ## Distinguishing Creator Claims from Demonstrated Patterns - **Claims:** The 24-skill adoption, the organic spread to sales/product/marketing (*"Nobody sent a memo"*), and the code-free nature of the method are creator assertions, not demonstrated in the material. - **Demonstrated presentation pattern:** The talk itself demonstrates the positioned identity — a practitioner-authored, step-by-step, first-person case study with transparent caveats (*"There isn't much field data on this yet"*). ## Notes for Channel-Level Synthesis - Single video; no channel-wide conclusions should be drawn. Observable identity signals: practitioner/expert-led, B2B/professional education tone, explicit emphasis on human review and accountability in regulated AI use. # Delivery Observations — Matt Ragone, "We Let Our Financial Planners Write the Agents" ## Overall Communication Style The delivery is **structured, methodical, and practice-grounded**. The speaker frames himself explicitly as a non-engineer end user, and that framing shapes nearly every rhetorical choice: plain vocabulary, no code, and constant grounding in real advisory workflows. > "I'm not an engineer. I'm a certified financial planner… Most agent talks you'll hear come from the people who built the platform. This talk comes from someone on the other side." --- ## Recurring Themes and Phrases ### 1. Repetition of "review" and oversight language The single most repeated lexical cluster concerns **human review and limits**. It appears at least five times across the talk: - "The review step is not optional." - "The agent doesn't send anything. A planner reviews every single recommendation before a client sees it." - "What it never does on its own." - "You don't grade your own work." - "Who tests it before it ships, who owns it once 15 other people depend on it." This is a stable pattern: every framework or step introduced is immediately paired with an accountability condition. ### 2. Numerical concreteness The speaker leans heavily on **specific numbers** to establish credibility: - "Six months in, we have 24 skills across the company and 17 of them are in planning." - "Run it five or 10 times on real cases." - "A half-baked skill to 15, 20, 100 people in your team." ### 3. Deliberate "this is not a pitch" positioning > "So, this isn't a vendor pitch. It's a method and it's what actually worked for us." and later: > "There isn't much field data on this yet, but this is how we've done it here at Range." He explicitly flags the limits of his evidence, which recurs as a hedging habit. --- ## Teaching Habits ### Numbered, signposted structure The talk is overtly didactic. He announces a roadmap and then follows it verbatim: > "Five steps. Pick, teach, pack, test, and then ship." Each step gets its own header-style sentence: "Step one, pick a workflow you repeat… Step two, show it several real cases… Step three, pack it into a skill…" This is a stable, deliberate teaching structure. ### Imperative, direct instruction The talk uses second-person commands constantly: - "Don't pick something you do every week…" - "Narrate your judgment out loud." - "You need to fix it, save the skill, and run it again and again and again." ### Anticipating the audience's mistakes A recurring habit is naming the common wrong move before giving the right one: - "Your initial instinct is to go for the flashiest work… Don't." - "This is the step everyone wants to skip." ### Analogies for abstraction When the material gets abstract, he reaches for one concrete analogy: > "Think of a skill as a recipe." (One instance only — analogy use appears occasional rather than a signature habit.) --- ## Sentence and Tone Patterns - **Short declarative punchlines** after longer setup sentences: "That narration is the whole game." / "It can." / "The bottleneck has moved." - **Rhetorical question-and-answer pairs**: "What's not settled? Who writes down how your firm does it?" - **Contrast constructions** (X vs. not-X) appear throughout: "It has to know how *we* do it, not how financial planning works in general"; "The steps are easy to write down. The judgment is what makes it your firm's work." - Tone is **calm and practical**, without hype language — no superlatives about AI capability; instead, "Whether a model can draft a cash flow analysis… that question's already been settled." --- ## Isolated Moments (Lower Confidence) - **Humor/lightness** is rare; the closest is "It saved me a few minutes here and there, but I was still doing all of the work manually." Not enough evidence to call self-deprecation a pattern. - The **closing is abrupt and formulaic** ("So, that's it. Thank you so much for listening"), but a single sample can't establish a signing-off habit. --- ## Summary of Stable Patterns | Pattern | Evidence Strength | |---|---| | Review/oversight language attached to every proposal | Strong (5+ instances) | | Numbered, signposted teaching structure | Strong | | Imperative, second-person instruction | Strong | | Specific numbers for credibility | Strong | | Contrast framing ("not X, but Y") | Strong | | Single-analogy teaching | Weak (one instance) | | Hedged evidence claims | Moderate (two instances) | # Video Position Record: "We Let Our Financial Planners Write the Agents" — Matthew Ragone, Range ## Speaker & Context **Matt Ragone**, self-identified financial planner at Range (an "all-in-one wealth management company"). He explicitly frames his perspective: > "I'm not an engineer... I also lead the AI adoption for the planning team at Range." He positions the talk as coming from "the people you hand the platform to," not platform builders, and states it is "not a vendor pitch. It's a method." ## Core Positions ### 1. Domain experts, not engineers, should build agents - None of Range's planners write code; the agents they use daily were written by planners. - **Claim:** Every step of their method "requires knowing the work really well, which is exactly why the people doing the work should also be the ones building it." - Result: skills became more specific ("the person who best knows tax code should be building the tax one") and peer review emerged naturally from existing planning review habits. ### 2. The real constraint is time, not speed > "A planner's constraint was never typing speed... It's that we can only be in one place at a time." - Chatbot use ("make this clearer/friendlier") was useful but he "was still doing all of the work manually." - What matters is **work happening while the planner is elsewhere**: an agent drafts an analysis during a client call; the planner reviews afterward. ### 3. Review is non-negotiable - Working in a regulated business, "the review step is not optional." > "The agent doesn't send anything. A planner reviews every single recommendation before a client sees it." ### 4. Two conditions for useful agents 1. The agent must "work where the work lives" — not a copy-paste chat window. 2. It must know "how Range does it," not how financial planning works in general. This is what he calls a **skill**: "Our firm's way of doing one specific piece of work written down so an agent can follow it." ## Stated Method: Five Steps (no coding required) 1. **Pick** a repeated workflow — avoid the flashiest/most complex; choose frequent, manual, low-complexity work you can judge quickly (e.g., cash flow analysis, insurance reviews). "If you can't judge the output quickly, you can't test it and you can't trust it." 2. **Teach** with several real past cases, narrating judgment aloud ("why you're opening it, what you're looking for"). "The narration is the whole game" — judgment is what distinguishes firm-specific work from generic advice. 3. **Pack** into a skill — not just steps; must include required **questions before starting** and **limits** ("it never sends anything to a client"). "If you only write the steps, you get something that simply just runs on its own." 4. **Test** — 5–10 runs on real cases before anyone else sees it; fix and rerun. Framed as cheaper than cleaning up after rolling out a "half-baked skill" to a large team. 5. **Ship** with an **owner** (keeps it current; "a skill that was right in March can be wrong by December") and a **reviewer** who is not the author ("you don't grade your own work"). ## Reported Outcomes (per speaker's account) - Six months in: **24 skills** company-wide, **17 in planning**. - Adoption spread to sales, product, and marketing "without a mandate. Nobody sent a memo." - All skills written and maintained by planners, marketers, and salespeople — not developers. ## Framing of the Broader Argument - "The bottleneck has moved": whether models can draft a cash flow analysis "has been settled." What's not settled: *who writes down the firm's process, who tests it, who owns it.* - He hedges appropriately: "There isn't much field data on this yet, but this is how we've done it here at Range." — i.e., presented as one firm's experience, not validated industry research. ## Qualifications & Tensions Preserved - The method is explicitly anecdotal, single-firm, in a regulated industry. - Ragone emphasizes drafts are first drafts only; human review remains mandatory throughout — no claim of unattended agent output is made. - His stated identity creates a deliberate tension with typical agent talks: value claimed precisely because the speaker is a practitioner, not a builder. # Speaker & Provenance Record ## Video Identification - **Title:** *We Let Our Financial Planners Write the Agents — Matthew Ragone, Range* - **Video ID:** `01a15ca6-75b8-7cd8-b7eb-836c30db415f` ## Speaker & Role | Speaker | Role | Notes | |---|---|---| | **Matt Ragone** (spelled "Rigon"/"Matt Rigon" in transcript; title metadata says "Matthew Ragone") | **Creator / Presenter**; a **certified financial planner** at **Range** | Sole speaker of the talk. Also states he **leads AI adoption for the planning team** at Range. Explicitly not an engineer; does not write code. | - Format: a **conference-style talk** ("build guide") — single presenter, no co-speakers, no interviews, no narrator track. - No curated speaker metadata beyond the title was supplied; name spelling is inconsistent within the transcript itself (flagged, not resolved). ## Provenance & Referenced Sources ### First-party claims (speaker's own experience, unverifiable from transcript) - Six months in: **24 skills company-wide** at Range, **17 in planning**. - Spread to **sales, product, and marketing** occurred "without a mandate." - Contact offered: **mattrange.com**. - Speaker acknowledges: *"There isn't much field data on this yet"* — i.e., no cited external research. ### Referenced third parties / sources - **None cited.** No external studies, data sources, or third-party experts are referenced. - Mentions of "Claude" (in a recipe/skill analogy) are illustrative only — no vendor endorsement stated. - Speaker claims the talk is "not a vendor pitch," though it describes internal practice at Range. ### Regulatory/compliance context (as stated by speaker) - Range operates in a **regulated business**; outputs are **financial advice to real clients**. - A mandatory **review step**: *"The agent doesn't send anything. A planner reviews every single recommendation before a client sees it."* ## Promotional Segments - **Flagged:** The talk functions partly as a **personal/brand promotion** for the speaker and Range (closing self-introduction and contact info). It is otherwise a method talk; no product sales pitch or pricing/promo codes appear. ## Availability & Interaction Limits - **No curated metadata supplied** in this record beyond the title. - **Comment availability: unknown** — no information present. - No linked resources, slides, or citations were provided in the transcript. ## Evidence Channels Unavailable - ❌ Curated metadata (description, links, comments) - ❌ Cited external sources or data - ❌ Slide visuals or on-screen content (audio/transcript only) Hi everyone, I'm Matt Rigon and I'm a financial planner at Range. I want to show you how our financial planners ended up writing the agents that we use every day and none of us the financial planners for that matter write code. This is the build guide. How we did it step by step so you can take it back to your own teams, companies, etc. So, a quick bit about me because it matters for how you'll hear this talk. I'm not an engineer. I'm a certified financial planner and I spend my days with clients talking about cash flow, taxes, insurance, retirement, estate, you name it. I also lead the AI adoption for the planning team at Range, which is an all-in-one wealth management company. Most agent talks you'll hear come from the people who built the platform. This talk comes from someone on the other side, the people you hand the platform to. We work in a regulated business. The output is financial advice to real clients. And the review step is not optional. So, this isn't a vendor pitch. It's a method and it's what actually worked for us. We started where everyone starts AI as a chatbot. I'd write a client message, paste it in, and ask it to make it a little clearer or friendlier. And that was useful. It saved me a few minutes here and there, but I was still doing all of the work manually. I was just doing it a little bit faster. The change that actually mattered came later. Here's what we figured out. A planner's constraint was never typing speed, for example. It's that we can only be in one place at a time. If I'm on a call with a client, I'm not building someone else's plan. Writing faster doesn't fix that problem. What fixes it is work that happens while I'm somewhere else. So, here's what a day looks like now. I'm on a call with one client. At the same time, an agent is drafting a full cash flow analysis or an insurance analysis for a different client. When the call ends, I open that draft. I fully review it, adjust what needs to be adjusted, and send the client their recommendations. I want to be really clear about that last step. The agent doesn't send anything. A planner reviews every single recommendation before a client sees it. What changed is that the first draft no longer needs me sitting in front of it. Getting there took a lot more than a good prompt. However, two things had to be true. First, the agent has to work where the work lives, not in a separate chat window I'm copying and pasting it into. Second, it has to know how we do it, not how financial planning works in general. The model already knows that, but the agent needs to know how range does it. What we look at first, what we always flag, how we phrase a specific recommendation. That combination is what a skill is. Our firm's way of doing one specific piece of work written down so an agent can follow it. The bulk of this talk is how you build one. Five steps. Pick, teach, pack, test, and then ship. None of them require writing code. Every one of them requires knowing the work really well, which is exactly why the people doing the work should also be the ones building it. Step one, pick a workflow you repeat. Your initial instinct is to go for the flashiest work, whatever's taking the most amount of time and the most complex. Don't pick something you do every week where you already know what good looks like, where you can spot a bad draft at a glance. Additionally, we recommend choosing some of the least complex workflows to start, but some that require the most manual work. For us, that meant things like cash flow analysis and insurance reviews. Just for us here at range, that required the most manual work. And if you can't judge the output quickly, you can't test it and you can't trust it. So look for two things. You do it often and you know how to judge it. Step two, show it several real cases for previous plans you've delivered. Take several actual client cases and walk through the work start to finish. And as you do it, narrate your judgment out loud. Not just next I open the pastub, why you're opening it, what you're looking for, what would make you stop and ask a question. That narration is the whole game. The steps are easy to write down. The judgment is what makes it your firm's work instead of generic advice. Step three, pack it into a skill. A skill isn't just a lip a list of steps. Two things matter most. The questions it must ask before it starts. What does it need to know? What should it confirm with me instead of simply guessing? And the limits it must respect. What it never does on its own. In our world, the big one is that it never sends anything to a client. It drafts and then a planner decides if it gets sent or needs to be adjusted. If you only write the steps, you get something that simply just runs on its own. If you write the questions and set the limits, you can get something you can trust. Think of a skill as a recipe. Once Claude knows how to do the skill, it will repeat your process on command. Step number four, run it five or 10 times on real cases before anyone else sees it. This is the step everyone wants to skip. Every run teaches you something the skill didn't know yet. An edge case, a question it should have asked, a spot where it sounded confident and was wrong. You need to fix it, save the skill, and run it again and again and again. Five to 10 runs sounds like a lot, but it's a lot less work than cleaning up after you hand a halfbaked skill to 15, 20, 100 people in your team. Step five, ship it with an owner and a reviewer. The owner keeps it current. Our processes change, tax rules change, and a skill that was right in March can be wrong by December. The reviewer checks it before the team relies on it. And it's someone other than the author. Same as a plan, you don't grade your own work. Once other people depend on a skill, somebody has to be accountable for it. That's the difference between a clever personal shortcut and something a team can build on. So, where are we at currently? Six months in, we have 24 skills across the company and 17 of them are in planning. And here's the part I didn't expect. It spread to sales, product, marketing, all without a mandate. Nobody sent a memo. People saw what the planners were doing and started building their own agents. Every one of those skills was written and is maintained by planners, marketers, and salespeople, not developers or engineers. A couple of things changed once subject matter experts started building for their own niche. The skills got a lot more specific. The person who knows insurance, for example, best builds the insurance skill. The person who best knows tax, tax code, tax law should be building the tax one. and a review came naturally. We already review each other's plans and that's just how planning works. So now we review each other's skills in that same way. It's the same habit, just a new thing to review. So why does this matter right now? Because the bottleneck has moved. Whether a model can draft a cash flow analysis, that question's already been settled. It can. What's not settled? Who writes down how your firm does it? who tests it before it ships, who owns it once 15 other people depend on it. If you're being asked to push agents out past the engineering org, you're about to hit these exact questions. There isn't much field data on this yet, but this is how we've done it here at Range. So, that's it. Thank you so much for listening to this talk. I'm Matt Rigon from Range and you can reach me for at mattrange.com. Have a great day.