Talk by Atul Ramachandran (Filed Inc) on why chat interfaces, citation trails, and accuracy metrics don't fix vertical AI products. Drawing on building AI data entry for tax firms (80%+ accuracy vs a 50-60% industry baseline, yet persistent user complaints), he argues the core issue is shifting verification work onto users rather than removing it. The talk presents three design patterns adapted from the evolution of coding AI: embed AI in existing workflows rather than separate platforms; choose the right unit of work so users can verify quickly at a macro level ("1000 feet first"); and encode edge cases as reusable skills and memory rather than chasing model improvements. Speaker bio: Atul Ramachandran is CTO and cofounder of Filed (AI infrastructure for tax firms), an open source contributor in the JavaScript ecosystem (NodeGui), based in Stockholm, Sweden. # Observation Document: Channel Presentation Evidence ## Video Overview - **Title:** "Chat and citations won't save your vertical AI - Atul Ramachandran, Filed Inc" - **Format:** Conference-style talk (implied by "thank you for your time... good luck out there" closing and direct address to an audience of builders). ## Creator Self-Description (Explicit Claims) - **Speaker identity:** *"I'm Atul. I'm the CTO and co-founder at Filed."* - **Experience claim:** *"I've been fortunate enough to build products for more than a decade now."* - **Company scope:** *"at Filed, we build products for tax professionals in the US."* - **Funding claim:** *"We have raised more than $17 million to do so."* - **Growth claim:** *"just last month, we closed more revenue than what we have done in the one year alone before that."* ## Intended Audience - **Vertical AI / SaaS product builders**, evidenced by the opening: *"I'm sure many of us are building products in... a vertical industry. For it be healthcare, legal, or taxes."* - Framed as peer-to-peer advice sharing: *"I've learned quite a bit... most of the learnings of building these AI agents for the taxes industry is essentially transferable to any other AI product."* ## Claimed Scope of Expertise - **Vertical AI product design**, specifically agentic product architecture: delegation, skills, monitoring, control, and metrics (*"design for delegation, not participation"*). - **Tax-industry operations** as a concrete case study: *"in case of taxes... there are like three different tasks that we have identified in the tax workflow, which take more than a an hour."* ## Observable Presentation Patterns - **Structured, thesis-driven delivery:** opens with a contrarian claim (*"citations and chat alone will not... allow you to keep the promise"*) and closes with a numbered summary of takeaways. - **Analytical framing devices:** three-level abstraction model (employee → self-service → *"agentic delegation"*) and the **conveyor belt metaphor** where *"AI agents are your workers... while the users are the supervisors."* - **First-person product evidence:** descriptions of Filed's own implementations, e.g., *"we trace back each and every value that the AI agent produced"* and *"before we do data entry into your tax software... we create a plan for them."* - **Metric-recommendation style:** proposes **weekly active sessions** over weekly active users as a success measure. ## Claims vs. Demonstrated Patterns — Distinction - **Claims (creator assertions about the company):** funding amount, revenue growth, decade of experience — unverifiable from material alone, stated by the creator. - **Demonstrated:** product-design methodology, tax-workflow knowledge, and presentation style — directly evidenced by the transcript content itself. # Delivery Observations: "Chat and citations won't save your vertical AI" — Atul Ramachandran ## Tone & Overall Style - **Conversational, informal presentation style**: Frequent filler words ("uh," "um," "you know") appear throughout, e.g., "Uh they allow you to be flexible," and "it's important that these tasks are repeatable or sort of repeatable with definitely applicable to each of their, you know, use cases." - **Direct, opinionated framing** at the opening: "I'm here to tell you that citations and chat alone will not keep allow you to keep the promise that you made to the customers." - **Empathetic audience-address**: "I'm sure many of us are building products in what in a vertical industry." ## Vocabulary & Terminology - **Repeated industry phrase pairing**: The triad **"healthcare, legal, or taxes"** recurs ("For it be healthcare, legal, or taxes" / "in vertical industry space like health care, legal, and taxes"), framing the audience as vertical-AI builders. - **Introduced coined framing**: "three levels of abstractions" (physical presence → digital transformation → "agentic delegation"). - **Technical jargon used casually**: "long-running background agents," "hallucinations," "skills," "traces," "weekly active sessions." - **Alliterative/paired slogans**: "Design for delegation, not participation" — repeated nearly verbatim at the start and in the takeaways. ## Recurring Phrases & Teaching Habits - **"Think of it this way" / "think about it"** as a recurring explanation prompt: - "So, think of it this way. The Previously, in a conveyor belt..." - "If you think about it, even when you're coding..." - **Example-anchored teaching**: Moves from abstract points to concrete cases ("in case of taxes," "in case of coding," "think of it like in case of bank transactions"). - **Self-referential credibility moments**: "I'm Atul. I'm the CTO and co-founder at Filed... We have raised more than $17 million to do so." - **Numbered-structure teaching**: "there are four key pieces," "The key takeaways are first of all... Secondly... And finally." - **Real product evidence**: Cites internal metrics — "last just last month, we closed more revenue than what we have done in the one year alone before that." ## Communication Patterns - **Extended metaphors as scaffolding**: - **Bank metaphor** for the three abstraction levels ("Let's imagine a bank... banks became online"). - **Conveyor belt metaphor** for agentic products, sustained across multiple segments ("You can think of a product You have agentic product as a conveyor belt... users as the supervisors of the conveyor belt"). - **Figurative language for trust/control**: "it should feel like... they're taking the users are taking the wheel, not abandoning the car." - **Problem → solution rhythm**: States a limitation, then offers a fix (e.g., chat/citations limits → "four key pieces"; WAU limitations → "weekly active sessions"). - **Explicit takeaway recap** at the end, restating the three main points — a stable closing habit. - **Uplifting close**: "Uh thank you for your time. Um and good luck out there." ## Disfluencies & Verbatim Delivery Notes - Transcribed stumbles and self-corrections are common, suggesting lightly-scripted or extemporaneous delivery: - "will not keep allow you to keep the promise" - "It produce It will get you most of like 80 to 90% there" - "the the person who's doing the task" - Occasional audience noise in the transcript (">> [snorts]") and speaker throat-clearing ("[clears throat]") — isolated moments, not a pattern. ## Stability Assessment - **Stable patterns** (repeated across segments): metaphor-driven explanation, "think of it" prompts, numbered lists, vertical-industry triad, example-grounded claims. - **Isolated/uncertain moments**: The "[snorts]" and "[clears throat]" annotations appear once or twice only and cannot support any delivery pattern claim. Audience reaction beyond these annotations is not observable in the transcript. # Position Record: "Chat and citations won't save your vertical AI" **Speaker:** Atul Ramachandran, CTO and co-founder at Filed Inc (self-identified in transcript). Product for US tax professionals; raised more than $17 million. ## Central Claim > "Citations and chat alone will not allow you to keep the promise that you made to the customers." Atul argues vertical AI products (healthcare, legal, taxes) that promise to "save time or money" fail when chat and citations are the only interface. ## Critique of Chat and Citations - **Chat** is good for input: flexible, fast to build, unconstrained by UI. But it is **synchronous** — customers must wait and cannot leave the platform. - **Citations** ground answers in truth, help users verify, and reduce hallucinations by forcing agents to present references. But they "put the verification burden back into the customer," adding extra work — contradicting the promise of agents working "while I sleep." ## Historical Framework: Three Levels of Abstraction Using a bank metaphor: 1. **Physical era** — tasks delegated to employees; bottleneck = number of employees. 2. **Digital transformation** — users do tasks themselves via apps; bottleneck = number of users. 3. **Agentic delegation** (current) — users delegate long-running work to agents; the user-count bottleneck also disappears, enabling more value generation. ## Core Metaphor: Product as a Conveyor Belt - AI agents = **workers**; users = **supervisors**; the product = the belt and surrounding infrastructure. - Guiding principle: **"Design for delegation, not participation."** ## Four Components of an Agentic Product ### 1. Delegation - Target tasks that take **more than a couple of hours** and are repeatable. - Filed identified three such tasks in tax workflows. - These become **long-running background agents** — "where the core value is." ### 2. Skills / Teaching - Background agents get "80 to 90% there" but users want work done *their* way. - Skills capture user preferences — "the last 20%… where the real value is." - At Filed, skills are captured **automatically** from product usage, not via a separate skill-creation interface (which he claims "won't work"). - References an unnamed existing product with automatic, learning skills as precedent. ### 3. Monitoring - Users must track multiple long-running tasks — e.g., **task lists** and **traces**. - Filed traces "each and every value that the AI agent produced" in a user-readable format: "This is where the trust is built." ### 4. Control / Intervention - Users must be able to take back control when judgment is needed or things go wrong — "taking the wheel, not abandoning the car." - Filed's approach: the agent **pauses** when it must make an assumption; the user responds in a chat-like interface, tagging the agent. ## Bonus Points - **Layering, not replacement:** just as bank branches didn't vanish with mobile banking, level-two features should remain because users only delegate when they trust they can retake control. - **Dangerous/irreversible actions:** present a plan for approval first — e.g., Filed requires plan approval before data entry into tax software that could erase existing data. ## Metric Shift - **Weekly active users (WAU)** suited the do-it-yourself era but not delegation. - Replace with **weekly active sessions** — tasks completed by human or agent even when the user is offline. - Goal: sessions go **up**, users go **down** — "It should not be zero, of course." ## Key Takeaways (as stated by speaker) 1. Design for delegation, not participation. 2. Treat the product as a conveyor belt; users are supervisors, not operators. 3. Measure weekly active sessions instead of weekly active users. # Speaker Attribution & Provenance Record ## Video - **Title:** Chat and citations won't save your vertical AI - Atul Ramachandran, Filed Inc - **Video ID:** `01a15ca8-abc1-7c0e-90fb-d44736a5b7e6` ## Speaker Inventory ### Primary (and only) speaker - **Name/Role:** **Atul** — self-identified as **CTO and co-founder at Filed** (creator/speaker role) - Claims **10+ years of product-building experience** (self-stated) - Company context stated: Filed builds products for **tax professionals in the US**, has **raised more than $17 million** (self-reported claim) - Growth claim: "last month, we closed more revenue than what we have done in the one year alone before that" (unverified self-report) ### Other voices - A non-verbal audience sound (**[snorts]**) appears mid-transcript; no identifiable secondary speaker or dialogue. No guest, narrator, or interviewer present. ## Provenance & Claims - **First-party claims:** All substantive claims (growth figures, funding amount, Filed's workflows) are self-reported by the speaker; no external verification in transcript or metadata. - **Referenced third-party products/services:** - Unnamed product with "automatic skills" cited as example ("a prime example you would have used a product called this before") — **name omitted in transcript** - Mentions of **Slack** and generic **tax software** as illustrative examples - **Concepts/frameworks presented (speaker's own framing, not cited sources):** three levels of abstraction (physical presence → digital transformation → agentic delegation), conveyor-belt metaphor, four components (delegation, teaching/skills, monitoring, control), weekly active sessions vs. weekly active users metric. ## Promotional Segments - **Self/company promotion flagged:** Speaker's introduction (~"who am I" segment) promotes Filed's funding, growth, and positioning — factual record only, no quality judgment. ## Availability & Metadata - **Curated metadata:** None supplied beyond title. - **Comment availability:** **Unknown / not indicated** in source material. Chat and citations won't save your vertical AI. I'm sure many of us are building products in what in a vertical industry. For it be healthcare, legal, or taxes. And usually doing so, we sell one promise to the customers. Either we're going to save you money or save you cost. And usually the pitch goes, AI agents are here. Uh they will do the work for you while you sleep. Now, primary interface that we use for this are chat and citations. To interact with any AI agent, right? Chats are usually used for inputs. Uh they allow you to be flexible. You can talk to the agents as you please. While citations are used usually used for outputs. They allow you to see the results, verify the results, and so on. Now, I'm here to tell you that citations and chat alone will not keep allow you to keep the promise that you made to the customers. Promise of, you know, saving time and money for them. So, who am I? I'm Atul. I'm the CTO and co-founder at Filed. Uh I've been fortunate enough to build products for more than a decade now. Um at Filed, uh we build products for tax professionals in the US. We have raised more than $17 million to do so. And about 2 years now doing this, we have seen massive growth in the space. Uh just to give you an idea, last just last month, we closed more revenue than what we have done in the one year alone before that. So, the growth has been tremendous and we're very excited for this. Doing this entire journey for the last 2 years, we've learned quite a bit, you know. Uh And I think most of the learnings of building these AI agents for the taxes industry is essentially transferable to any other AI product. Now, chat is great. Like it allows us to build fast. It allows customers to interact with products in ways that was previously possible. It's a communication platform, right? Uh you can interact with agents to do tasks, flexible tasks that were not constrained to the UIs that you have built. Uh citations are also amazing. They ground answers in truth. Other than allowing the users to verify the outputs, they also serve another purpose. They allow the agents to essentially be more accurate because now they are forced to present the references to their answers. Agents are Agents perform much better with So, they reduce hallucinations essentially. But this is There's a key problem here, right? Chat is synchronous. If you think about it, even when you're coding, you're Let's say you're using product code as as as long as you're typing the request. Once the request is typed, you're waiting for the agent to respond. This synchronous medium does not allow the customers to leave the platform and go and do their work. Similarly, citations also puts the verification burden back into the customer. So, think about going and reviewing the agent's work now one by one to ensure everything is correct. Especially in vertical industry space like health care, legal, and taxes, this becomes very crucial because now this this adds an extra work, and customers usually complain that no the promise of, you know, agents doing the work for me while I sleep is not really kept here. Now, before we dive in, I want to take you through a brief history of how products have evolved. Specifically, I think there are three levels of abstractions, I would call it. So, let's imagine a bank to make it an make it easier. Let's imagine a bank. The banks used to have a physical presence before. You would go to a bank branch, you would take the money out by talking to a employee of the bank, right? And the point here was the the person who's doing the task is the employee of a particular company. So, you as a user would go in, you would delegate the task to an employee, they would do the task for you, and then, you know, come back with the result. Be it withdrawing money or seeing how much balance you have and so on. \>\> \[snorts\] \>\> Now, this essentially meant the bottleneck was the number of users number of employees that a company had. That's the bottleneck for creating value, right? Now, as time progressed, digital transformation era came. Basically, banks became online. You could Now, the users can essentially open up the mobile app or or the online portal and can make the transaction themselves. Can actually go and see the balance himself. This was great. Because now the bottleneck moved from the number of employees a company have to number of users that the company have. The more users meant more value you can generate. Now, I think we have reached a point of another transformation layer called agentic delegation. So, no longer the users are coming in your product to use the product. I think they're coming to delegate more and more work to AI agents to do. So, the point here is um if a user \[clears throat\] comes to your product and starts delegating work, long-running work, what would happen here is there's the bottleneck of number of users also goes away. So, it's no longer than amount of value that you generate is the amount of the number of times the user have visited your platform because agents can do the work while the users have gone to sleep, you know, have delegated the task and went off. So, the bottleneck has shifted, meaning you can generate more value than ever before for your customers. Okay, so to make it easier, I You can think of a product You have agentic product as a conveyor belt, you know, and the users as the supervisors of the conveyor belt. So, think of it this way. The Previously, in a conveyor belt, usually there's a number of tasks that are happening. There are workers who are doing the work for you, and there's a supervisor who is delegating the task, you know, and monitoring how the things are going. Similarly, now AI agents are your workers in that conveyor belt, while, you know, the conveyor belt and the entire infrastructure around it is your product. So, users can come in, uh which who is the supervisor, can come into the product, can start delegating tasks to the agents. And this would mean it give it would give an idea of what are the tools that you need to build in your product to make this happen. So that the agents can do the work and the supervisor or the user is, you know, pretty confident that the work is happening. All right. So, how do we build this conveyor belt? So, think of this this way. Like, when you're trying to build a product feature, think if a user wants to delegate a task instead of doing it themselves in your platform, what does what would that interface look like? Essentially, design for delegation, not participation. Now, to keep it more concrete, I think there are four key pieces when building a agentic product. And there are four key features or components that you need to have so that this conveyor belt that we're imagining can work. So, first thing is the easiest one. You need to find the task to delegate. The the tasks that are coming in the conveyor belt are delegatable, right? And that can generate value for users. Second is, you need ability for users to teach the agents of, you know, uh the supervisor should be able to come in teach how the work needs to be done. And lastly, uh there's no point of a conveyor belt where you cannot monitor the work yourself, right? And and of course, intervene when something goes wrong. Now, let's take delegation. Um so, delegation means, you know, coming and handing over the task to another person, right? So, think of your users coming to a platform and delegating a task or handing off task to an AI agent. So, when building for this particular piece, you as a developer or a product engineer have to find tasks that your users do that take more than a couple of hours. So, in case of taxes, um there are like three different tasks that we have identified in the tax workflow, which take more than a an hour for our users to perform. Similarly, in your industry, you can figure out, you know, which are those tasks. It's important that these tasks are repeatable or sort of repeatable with definitely applicable to each of their, you know, use cases. And these tasks are what you use to build what you call a long-running background agents. This is where the core value is, you know, because you're taking off hours of work from your users' hands. Awesome. Um so, next is, you know, uh in any industry, in any professional industry, uh like in case of coding, for example, everyone every single user have their own preferences and have have their own way of doing a task. An example is, you know, coding, for example, we every single company or every single group of developers have their own ways of dealing with best practices and their own conventions and practices that they follow. So, if you create a background agent, for example, and it does this end-to-end task of creating a product in case of coding, for example, it will produce output, sure, right? It produce It will get you most of like 80 to 90% there, but think of it this way, like that will not yet solve the problems of of the user, right? As a user, you would want it to do it the way that you do the work. So, this is where skills come into play. Skills already exist in the today's world of agent development. So, we need to ensure that your product also has skills in place to capture where you can teach your agents how your users do the work. This is the last 20% of the of the work that you need to take care of. This is where the real value is, the quirks of the work, you know, that you're capturing. In our case, in Taxes, we capture all the all of these skills automatically. You do not need to have like a complete separate interface where users you go and create skills, that won't work. In many cases, you need to like look at the product usage and figure out whether you can create a skill for that particular use case or not. So, we automatically do in our case, and a prime example you would have used a product called this before. They also have like automatic skills. So you use and it keeps on learning as you use the product. Now monitor. Monitor is monitoring is a key key part right. So since agents are long running now the whole point is they'll be like multiple tasks that are running and the users need to keep track of what is happening in this world. So so one simple example here could be a task list that you can do to keep track of where the processing is for each of those tasks. And second example here is like building traces in your product, you know. Trace how the agent did the work that it did. They're long running tasks so there will be multiple pieces that are moving. So you need to trace back. So in our case we trace back each and every value that the AI agent produced in a particular, you know, in the format that the users can easily see. This is where the trust is built. So it's and this is where the visibility is built so it's it's paramount that you know, you build this correctly. This is where most of the complaints can be get getting addressed if you build this right. And lastly, think of it this way, right? Control. So when something requires a judgment or when something goes wrong your platform should inspire confidence that the users can take back control. This is critical because level three product or the conveyable product that you're building will allow you the your customers to, you know, schedule a lot of tasks. But if they don't have the confidence that, you know, if something goes wrong they can take them back control then then the users will completely lose trust. So it should feel like, you know, they're taking the users are taking the wheel, not abandoning the car and, you know, creating a new car, for example. So ideally it should go like you pause the belt, fix the problem, you start it back up again. In our case we could do it very simply by, you know, pausing whenever the agent was trying to make an assumption, we pause. And then the users would come in just like in Slack or any other chat platform. They can come and tag the agent and respond with how to deal with that particular conflict. Okay, some bonus points I said. Um so, just as physical bank branches didn't disappear when the mobile banking arrived or you know, when the level two arrived, um I don't think when the agent take layer up to just it's an abstraction over the last two layers that you know, all other mobile apps and things like that will disappear. Uh the point here is a user can user will only come and delegate work they believe that you know, they can always take back control. So, so first step is you know, and having giving that the confidence that they can take back control, you know, when they when something goes wrong. So, you need to build level two features into your product as well. That's the key point here to build trust. And second thing is some actions are usually irreversible and are dangerous actions. And in those cases, you need to present a plan. So, think of it like in case of bank \[clears throat\] transactions, for example, before making a bank transaction, the plan should be there, you know, if the certain amount of value is going somewhere else. Same way in our cases, when we before we do data entry into your tax software, which can erase their existing data, we create a plan for them so that they can approve the plan before they move on. These are the key pillars that allows customers to feel you know, control and allows customers to feel as if you know, if something goes wrong, they can take back control at any point in time. And lastly, since we're building products now completely differently, like we're not building for the users to come in and use the product, we're building for users to come and delegate work. It's important that we change the way we measure this value. So, the most popular metric that customers that the the products use today are weekly active users. Now, this is great in the in the era where, you know, people used to come and do the work in the platform themselves. But, it doesn't really translate well with agent and delegation. So, the point is we we have to change the way we measure. And the I think the the appropriate measure here is weekly active sessions. It's I treat it as, you know, a task that is completed by a human or an agent even when the user is not in your platform. So, uh your actual aim should be the weekly active users go down while weekly active sessions go up, right? Because you want your users to have enough trust in your platform that they can come and delegate your task as much as possible. And those tasks are executed without a human help as much as possible. So, the number of sessions should go up. Weekly active sessions should go up while number of weekly active users in your platform should ideally go down. It should not be zero, of course, but should go down. So, what are the key takeaways? The key takeaways are first of all, design for delegation, not participation. Design your products in a way that users are coming in to your product to delegate work, not do it themselves. Secondly, to do to make that possible, you need to think of your product as a conveyor belt. So, users are now the supervisors, they're not operators. They're coming here to delegate work and monitor, you know, figure out if there are problems and then take actions. And finally, you need to change the way you measure how the work is done, uh not the time on the platform. Uh so, weekly active sessions instead of weekly active users. If you keep these three in mind, you will be able to build a very successful uh vertically air product, I think. All right. Uh thank you for your time. Um and good luck out there.