AI Engineer World's Fair 2026
Chat and citations won't save your vertical AI
Read the talk
Chat and citations won't save your vertical AI
Vertical AI saves time when users can hand off work, teach preferences, inspect progress and intervene without restarting the task—not merely exchange messages.
From a talk by Atul Ramachandran
Who does the work while the customer sleeps?
If an AI agent promises to handle work while a customer sleeps, what must the product provide beyond a chat box and cited answers? In healthcare, legal work and taxes, the commercial promise is to save customers time and money. Chat provides flexible instructions; citations give customers a way to inspect the output. Those are useful interfaces, but neither alone completes the handoff of responsibility.
Atul Ramachandran approaches this problem as CTO and co-founder of Filed, which builds products for US tax professionals, following more than a decade of product work. Ramachandran reports more than $17 million raised and, after roughly two years building Filed, more revenue closed in the preceding month than in the preceding year. That experience supplies the setting for lessons he believes apply beyond tax software.
Chat makes products quick to build and lets users request tasks beyond the actions anticipated in a fixed interface. Citations make answers easier to check. Ramachandran also argues that requiring references improves agent accuracy and reduces hallucinations. That is a reason to retain citations, not to treat a source pointer as a guarantee that every associated claim is true.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Waiting and checking are still work
Consider the foreground interaction Ramachandran describes in Claude Code: type a request, submit it, then wait for the agent to respond. The user remains attached to the exchange. Current Claude Code also supports background commands; the problem illustrated here is the synchronous interaction pattern, rather than an absolute limitation of the product.
After the response arrives, citations can return another job to the customer: review the agent's work one result at a time. In healthcare, legal work and taxes, checking consequential outputs is substantial work. A product can generate an answer faster while still requiring the customer to supervise the entire process. The promised saving depends on reducing participation in the workflow, not just accelerating a response.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From bank branches to delegated work
Banking provides a useful progression. At a physical branch, a customer asks an employee to withdraw money or retrieve a balance. The employee performs the task, so employee capacity constrains service. Online portals and mobile apps then let customers perform transactions and check balances themselves. More customers can create value at once, but each still has to operate the software.
Agentic delegation introduces another layer: the customer hands off a long-running task, and work continues after the customer leaves. In Ramachandran's model, this loosens the connection between value delivered and visits to the product.
| Product layer | Who performs the work? | Constraint in this model |
|---|---|---|
| Physical branch | Company employee | Employee capacity |
| Digital self-service | Customer using software | Customer participation |
| Agentic delegation | Agent acting on a handoff | Work can continue without a visit |
The third layer makes the product resemble a conveyor belt, with the user supervising work rather than personally carrying out each operation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build the infrastructure around the agent
On a conveyor belt, workers perform tasks while a supervisor assigns work and watches its progress. In an agentic product, agents are the workers; the product supplies the belt and the infrastructure around it. The engineering question is therefore larger than how to communicate with an agent: what lets a supervisor delegate work and remain confident that it is happening?
Design for delegation, not participation. For each feature, ask what its interface would look like if the user wanted to hand over the task instead of performing it. Four capabilities follow:
- Delegate: Identify valuable tasks that agents can take over.
- Teach: Let users communicate how the work should be done.
- Monitor: Make ongoing work visible.
- Intervene: Let users correct problems and exercise judgment.
Together, these capabilities make the conveyor belt usable without requiring its supervisor to become another worker on it.
Start task selection with work that consumes substantial professional time. Ramachandran recommends looking for tasks taking more than a couple of hours; Filed identified three unnamed tax-workflow tasks that each took users more than an hour. The distinction matters: the recommendation is a search heuristic, while the tax tasks are his concrete example.
These tasks should be repeatable, or at least partly repeatable, while allowing differences between individual cases. A background agent needs a recurring kind of work to perform, but it cannot assume every client's circumstances are identical. This is where long-running agents can remove hours of effort from the user's hands.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Teach the agent how this professional works
A completed generic task may still fail to meet a professional's requirements. Coding teams, for example, have their own conventions and definitions of best practice. An agent can build a product end to end yet leave the team with substantial work to make the result fit those conventions.
Ramachandran illustrates the gap by estimating that a coding agent might get 80–90% of the way there, then describing preference capture as the last 20%; these are illustrative estimates, not measured completion rates. Skills capture the particular way a user wants work performed, including the quirks that determine whether an otherwise plausible result is actually useful.
The product also has to make teaching practical. Ramachandran says Filed captures skills automatically from product usage instead of asking tax professionals to visit a separate interface and author them. The design task is to recognize which interactions reveal reusable preferences. He points to Wispr Flow as another example of learning through use. Its documented vocabulary learning is a bounded example of adaptation, rather than evidence that arbitrary professional skills can all be inferred automatically.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make progress and generated values inspectable
Once multiple long-running tasks can proceed together, the user needs visibility at two levels:
- Task status: A task list shows where each job is in processing.
- Work traces: An inspectable record explains how the agent performed the job and produced its outputs.
Ramachandran says Filed traces every value the agent produces in a format users can readily inspect. A status list answers what is happening; a trace helps answer how a particular result came to be.
The monitoring slide pairs a task table with tax documents whose highlighted fields are connected by green lines. This makes the distinction concrete: users can see the collection of jobs and inspect relationships between documents. Ramachandran connects that visibility to trust and to addressing customer complaints about the work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Pause, resolve the problem and resume
Visibility is not enough when an agent needs judgment or something goes wrong. Users must believe they can take control, particularly when they have scheduled many tasks. Ramachandran compares intervention to taking the wheel of a car: the customer should not have to abandon the vehicle and build another one. Applied to the conveyor belt, the requirement is continuity of work through a correction.
Filed's described interaction follows a short procedure:
- Pause when the agent is about to make an assumption.
- Ask the user to resolve the conflict. In a Slack-like interaction, the user tags the agent and provides guidance.
- Resume the work after the problem is resolved.
Chat still has a useful role here. It becomes a way to supply missing judgment at a specific interruption, rather than the place where the user must remain for the entire task.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep direct controls and approve consequential actions
Mobile banking did not make physical branches disappear. Similarly, an agentic layer does not eliminate the need for ordinary software controls. Users need the self-service capabilities of the previous layer so they can reclaim work when necessary. That ability helps make delegation credible in the first place.
Dangerous or irreversible actions need an additional boundary: present the plan before executing it. Before a bank transaction, show the intended movement of money. Before entering data into tax software, show what the agent intends to do when the operation could erase existing data. Ramachandran says Filed creates a plan for approval before proceeding with that kind of data entry.
A small TypeScript representation makes the approval boundary explicit. Here, a proposed replacement of a tax field remains separate from the current data until approval. Dismissing or leaving the plan pending preserves the existing value.
typescript
type Decision = "pending" | "approved" | "dismissed";
type TaxData = { wages: number; filingStatus: string };
type EntryPlan = {
decision: Decision;
proposed: Pick<TaxData, "wages">;
};
function applyPlan(current: TaxData, plan: EntryPlan): TaxData {
if (plan.decision !== "approved") return current;
return { ...current, ...plan.proposed };
}
const current: TaxData = {
wages: 72000,
filingStatus: "single",
};
const plan: EntryPlan = {
decision: "pending",
proposed: { wages: 75000 },
};
const awaitingApproval = applyPlan(current, plan);
// wages remains 72000; filingStatus remains "single".
The field and amounts illustrate the boundary rather than a particular Filed tax case. The accompanying slide shows an Excel report plan marked awaiting approval, with controls to approve or dismiss it. Both the plan and the interface preserve the distinction between proposed work and authorized action.
Manual controls and approval plans serve the same larger purpose: customers can delegate without surrendering the ability to intervene. They can correct work in progress and decide whether a consequential next step should happen at all.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Measure completed work instead of attendance
If customers now arrive to delegate rather than operate the product, success metrics must change too. Weekly active users made sense when users had to visit the software to perform the work. It is less informative when the product can deliver value while they are absent. Ramachandran proposes weekly active sessions instead.
He defines a session as a task completed by either a human or an agent, including completion while the user is away. This is a completed-task definition, not a conventional browsing-session count. His desired direction is for weekly active sessions to rise while weekly active users decline, because more delegated tasks should finish with less human help. Active users should not fall to zero: customers still need to assign work, supervise it and intervene.
That changes the product's design target. The user becomes a supervisor who hands off work, monitors it, identifies problems and takes action when needed. The product earns its place by making that arrangement dependable. Its value is the work completed on the customer's behalf, rather than the time the customer spends inside it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Further reading
How to attach document citations to generated answers and expose precise source locations for review.
Research on evaluating answer quality and citation support, illustrating why cited answers still require verification.
Updates since the talk
- Introducing Filed ProworkArticle
Filed's July 2026 product announcement explains background preparation, review inside existing tools, and firm-specific Playbooks built from corrections.
Instructions for vocabulary corrections and automatic dictionary learning, including supported platforms and exclusions.
Current controls for background commands, task tracking and interruption in Claude Code.
Read the complete timestamped transcript
- 0:01
Chat and citations won't save your vertical AI.
- 0:06
I'm sure many of us are building products in vert-- in a vertical industry, for, be it healthcare, legal or taxes. And usually doing so, we sell one promise to the customers, either we're gonna save you money or save you cost.
- 0:18
And usually the pitch goes, AI agents are here, uh, they will do the work for you while you sleep.
- 0:25
Now, primary interface that we use for this are chat and citations to interact with an AI agent, right? Chats are usually used for inputs. Uh, they allow you to be flexible.
- 0:35
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.
- 0:44
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. The promise of, you know, saving time and money for them.
- 0:54
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.
- 1:07
We have raised more than seventeen million dollars to do so. And about two 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.
- 1:21
So the growth has been tremendous, and we are very excited for this. Doing this entire journey for the last two years, we have learnt quite a bit, you know.
- 1:29
Uh, and I think most of the learnings of building these AI agents for the taxes industry is essentially transferable to any other agentic product. Now, chat is great. Like it allows us to build fast.
- 1:41
It allows customers to interact with products in ways that was not 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.
- 1:53
Uh, citations are also amazing. They ground the 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.
- 2:10
Agents, um, agents perform much better with citations, so they reduce hallucinations, essentially.
- 2:16
But this is, there's a key problem here, right? Chat is synchronous. If you think about it, um, even when you're coding, you're, let's say you're using product code. As, as, as soon as you're typing the request, once the request is typed, you're waiting for the agent to respond.
- 2:31
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, um, one by one, to ensure everything is correct.
- 2:49
Especially in vertical industry space like healthcare, legal, and taxes, this becomes very crucial because now this adds an extra work and customers usually complain, you know,
- 2:59
uh, the promise of, you know, uh, 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.
- 3:09
Specifically, I think there are three levels of abstractions, I would call it. So, uh, let's imagine a bank to make it an eas-- make it easier. Let's imagine a bank.
- 3:19
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?
- 3:26
And the point here was, uh, uh, the, the person who is doing the task is the employee of a particular company. So you as a user would go in, you would delegate a task to an employee, they would do the per-- task for you, and then, you know, come back with the result.
- 3:39
Be it withdrawing money or seeing how much balance you have and so on. Now, this essentially meant the bottleneck was the number of users, the number of employees that a company had.
- 3:50
That's the bottleneck for creating value, right? Now, as time progressed, digital transformation era came. Basically, banks became online. Uh, you could-- now the users can essentially open up the mobile app or the, or the online portal and can make the transaction themselves, can actually go and see the balance themselves.
- 4:06
This was great because now the bottleneck moved from the number of employees a company have to the number of users that the company have. The more users meant more value you can generate.
- 4:18
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.
- 4:33
So the point here is, um, if a user 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.
- 4:45
So it's no longer the amount of value that you generate is the amount of the number of times the user have visited your platform. 'Cause agents can do the work while the users have gone to sleep, you know, have delegated the task and went off.
- 4:58
So the bottleneck has shifted, uh, meaning you can generate more value than ever before for your customers. Okay. So to make it easier, I-- you can think of the product, your agentic product as a conveyor belt, you know, and the users as the supervisors of the conveyor belt.
- 5:15
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.
- 5:26
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, the, which, who is a supervisor, can come into the product, can start delegating tasks to the agents.
- 5:45
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.
- 6:00
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?
- 6:14
Essentially design for delegation, not participation. Now, to keep it more concrete,
- 6:21
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.
- 6:33
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.
- 6:43
Second is you need ability for users to teach the agents of, you know, uh, the supervisor should be able to come and teach how the work needs to be done.
- 6:53
And lastly, uh, there's no point of a conveyor belt [chuckles] where you cannot monitor the work yourself, right? And, and of course, intervene when something goes wrong.
- 7:04
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 a task to an AI agent.
- 7:18
So when building for this particular piece, you as a developer or a product engineer
- 7:24
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 a tax workflow which take more than an hour, an hour for our users to perform.
- 7:38
Similarly, in your industry, you can figure out, you know, which are those tasks.
- 7:42
It's important that these tasks are repeatable, uh, or sort of repeatable, but are differently 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.
- 7:56
This is where the core value is, you know, because you're taking off hours of work from your users' hands.
- 8:03
Awesome. Um, so next is, you know, uh, in any industry, in any professional industry, uh, like in case of coding, for example, everyone, uh, every single user have their own preferences and have, have their own way of doing a task.
- 8:17
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.
- 8:30
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,
- 8:37
it will produce output, sure, right? It produce-- It'll get you mostly like eighty to ninety percent there. But think of it this way, like that will not yet solve the problems of a, of, of the user, right?
- 8:48
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 agentic development, so we need to ensure that your product also has skills in place to capture, so that you can teach your agents how your users
- 9:05
do the work. This is the last twenty percent 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.
- 9:17
In our case, in TaxUs, we capture all the, all of these skills automatically. You do not need to have like a complete separate interface where users will go and create skills.
- 9:25
That won't work. So 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.
- 9:33
So we automatically do in our case, and a prime example, uh, you would have used a product called Whisperflow. They also have like automatic skills. So you use, and it keeps on learning as you use the product.
- 9:46
Now, monitor. Monitor is, monitoring is a key, a key part, right? Uh, so since agents are long-running now, the whole point is, uh, there'll be like multiple tasks that are running, uh, and the users need to keep track of what is happening in this world, right? [chuckles]
- 10:01
So, uh, 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.
- 10:12
You know, trace how the agent did the work that it did. They're long-running tasks, so there'll 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.
- 10:28
This is where the trust is built, so it's-- and this is where the visibility is built, so it's ins- it's paramount that, you know, you build this correctly. This is where most of the complaints can be get, uh, getting addressed if you build this right.
- 10:41
And lastly, uh, 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.
- 10:53
This is critical because level three product or the conveyor belt product that we're building will allow you- the, your customers to, you know, s- schedule a lot of tasks.
- 11:04
But if they don't have the confidence that, you know, if something goes wrong, they can take back control, then, um, then the users will completely lose trust. So it should feel like, you know, they're take-- the users are taking the wheel, not abandoning the car and, you know, creating a new car, for example.
- 11:21
So ideally, it should go like you pause the belt, fix the problem, you start it back up again. In our case, uh, we could do it very simply by, you know, pausing wherever the agents was trying to make an assumption, we pause, and then the users would come in, just like in Slack or any other chat platform.
- 11:38
They can come and tag the agent and respond with how to deal with that particular conflict.
- 11:46
Okay. Some bonus points as well. 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 agentic layer approaches, it's an abstraction over the last two layers that, you know, uh, all other, uh, mobile apps and things like that will disappear.
- 12:07
Uh, the point here is a user can-- user will only come and delegate work to believe that, you know, they can always take back control. So, um, so first step is, you know, uh, having-- giving them the confidence that they can take back control, you know, when they-- when something goes wrong.
- 12:23
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, uh, some actions are usually irreversible and are dangerous actions.
- 12:35
And in those cases, you need to present a plan. So think of it like in case of bank transactions, for example. Before making a bank transaction, the plan should be there, you know.
- 12:44
If a certain amount of value is going somewhere else. Same way, uh, in our cases, when we-- before we do data entry into a 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.
- 12:59
These are the key pillars that allows customers to feel, you know, control and allows customers to feel as if, uh, you know, if something goes wrong, they can take back control at any point in time.
- 13:11
And lastly, since we are building products now completely differently, right? We are not building for the users to come in and use the product. We're building for users to come and delegate work.
- 13:21
It's important that we change the way we measure this value. So the most popular metric that customers, uh, that, uh, the products use today are weekly active users. Now, this was great in the, in the era where, you know, people used to come and do the work in the platform themselves.
- 13:38
But it doesn't really translate well with agentic 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.
- 13:50
It's-- I treat it as, you know, a task that is completed by a human or a 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?
- 14:03
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.
- 14:13
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 it should go down.
- 14:25
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.
- 14:38
Secondly, to do-- to make that possible, you need to think of your product as 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.
- 14:51
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.
- 15:00
If you keep these three in mind, you will be able to build a very successful, uh, vertical AI product, I think.
- 15:07
Okay. Uh, thank you for your time. Um, and good luck out there.