Chat and citations won't save your vertical AI

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.

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.

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.

The third layer makes the product resemble a conveyor belt, with the user supervising work rather than personally carrying out each operation.

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.

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.

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.

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:

1. Pause when the agent is about to make an assumption.
2. Ask the user to resolve the conflict. In a Slack-like interaction, the user tags the agent and provides guidance.
3. 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.

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.

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.

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.