Conversation is for applicants, not operators

Every product launched in 2026 ships with a chat surface. The page loads, a friendly bubble blooms in the corner, and a model stands ready to do whatever the user wants. We built one too. We also refused to build one in the place most teams in our category would have put one. The difference between those two decisions is, more or less, the product.

Where AI surfaces matters as much as what AI can do. A visa platform has two very different users sitting on opposite ends of it. Applicants, who are doing this for the first time and don't know the rules. Operators, who are doing the same case for the thousandth time and know the rules better than the form does. A surface that's right for one is almost always wrong for the other.

Why everyone reaches for the chat surface

It's easy to be cynical about the chat-in-the-corner reflex, but the reasons are real. A chat surface ships in a week. It demos beautifully. It collapses an unbounded set of features into a single textbox, which means the team doesn't have to decide which workflows are worth designing. You can launch with a chat, watch what people ask it, and call the resulting transcript a roadmap.

The trap is that the chat is doing the design work the team didn't do. When a user types "where's my case?", the model has to interpret intent, fetch state, format an answer, and hope the user accepts it. None of that work shows up on the roadmap. It just becomes the model's problem at runtime, every single conversation. A real status surface, by contrast, is built once and then it's just there.

Chat is fast to ship and slow to operate. That trade-off can be the right one. It depends entirely on who you're building for.

Applicants are discovering, so we built them a chat

An applicant comes to a visa workflow knowing one thing: they want to go somewhere. They don't know what documents the destination wants, what financial threshold applies, what the embassy considers a valid itinerary, or in what order any of it has to happen. The traditional answer is a 20-page PDF that asks for everything at once and rejects the entire submission if any one field is wrong. Industry-standard completion rates for that flow sit around 40 to 50 percent.

This is genuinely a discovery problem. The applicant doesn't know the shape of the work, and a guided conversation is one of the few interfaces that can teach the shape while the work is happening. Aero, our applicant-facing intake, asks for one thing at a time, validates it against the country's rules immediately, and lets the user back up when they get something wrong. We see completion rates above 70 percent, almost double the PDF baseline.

The chat surface earns its keep here because every conversation really is different. Two applicants asking for the same visa class can have wildly different starting situations: one is a salaried employee, the other is self-employed; one has a partner from a third country, the other doesn't. A conversation can flex around those differences. A static form cannot, or rather, it can, but only by becoming so long and conditional that nobody finishes it.

Operators are executing, so a chat would have hurt them

An operator's day looks nothing like the applicant's. They aren't discovering the rules; they wrote half of them. They've processed this country's cases hundreds of times. What they need from the platform isn't a guide, it's a working surface: a queue of what's pending, a clear view of what AI has already touched, a fast path to override or approve, and an audit trail that survives a regulator asking what happened in March.

A chat surface fights all of that. If the AI's output is in a transcript, the operator has to read prose to find out whether a passport scan passed validation. If the AI is something the operator has to ask, then a step the operator forgot to ask about is a step that quietly didn't happen. If the AI's reasoning is buried in conversational backscroll, the audit trail is whatever the model decided to summarize, which is not what the regulator wants.

The test isn't whether operators would use a chat. They would. We use chat in our own work all day. The test is whether a chat is the surface that makes operators good at their job, and for repetitive, structured, auditable work, the answer is no.

What we built where a chat would have gone

Three places where the obvious move was a chat, and what we did instead.

The "ask the AI to review this case" feature, which we didn't build

The shape this usually takes is a panel inside the case where the operator types "review this" and watches the model produce findings. We considered it and didn't ship it. The problem is that "review" is what the AI should be doing already. If the operator has to ask for it, half the cases won't get reviewed, and the half that do will be the obvious ones the human could have caught.

Instead, AI is a first-class assignee on the case queue. It picks up new cases the moment they enter the relevant state, runs the same checks every time, and writes its findings to the case as structured fields with confidence scores. The operator's view doesn't show a chat box. It shows a row in their queue with the AI's pass-fail decision, the specific rules that triggered, and a one-click path to escalate or override. The AI is more present this way, not less. It just isn't talking.

The "chat with our visa-rules assistant" feature, which we replaced with a diff

Operators do need answers about why a country wants what it wants, and the obvious play is a rules chatbot. But the question an operator actually has, in production, is almost never abstract. It's "why did this case fail validation?" A chat answer to that is a paragraph of prose. The thing the operator needs is a diff: here is what the rule requires, here is what the document contains, here is the gap.

Because country requirements live as structured data (we covered the shape of this in an earlier post), the platform can render that diff directly on the failing document. The operator sees the rule, the value, and the delta in a single glance, with a link to the rule's source and version. There's no question to ask, and therefore no answer to misinterpret.

The "chat with the agent processing your batch" feature, which became a timeline

Nyx, our autonomous fulfillment engine, drives embassy portals on the operator's behalf. The temptation, when you have a long-running agent doing browser automation, is to let users converse with it. "How's case 1234 going?" "Did the upload work?" "Why did you stop?"

We built a timeline instead. Every action Nyx takes (logged in to the portal, selected the applicant, uploaded the passport, hit a CAPTCHA, escalated for human handoff) is a structured event with a timestamp, a screenshot, and a confidence note. The operator can scroll the run the way they'd scroll a deploy log. There's no question they can ask Nyx in chat that the timeline doesn't already answer better, with the added benefit of being replayable months later when an audit shows up.

The test we use

When we sit down to design a feature and the chat-shaped option is on the table, we ask one question: is the user discovering, or executing?

Discovery means the user doesn't know the shape of the work yet. The interface's job is to teach that shape while the work is happening. Conversation is genuinely one of the best tools we have for that, because the shape of the conversation can be the shape of the user's understanding, and both can change as you go.

Execution means the user knows the shape and is repeating it. The interface's job is to make the work visible, fast, and auditable. Queues, tables, diffs, timelines, and one-click actions beat a chat surface here every time. Not because chat is bad, but because chat optimizes for the wrong things: flexibility instead of speed, and persuasiveness instead of clarity.

We built a chat where it earns its keep, and we left it out everywhere it would have gotten in the way. That's most of what "AI as an operator, not a chatbot" actually means in practice. The headline sounds like a refusal, but the real position is more boring and more useful: pick the surface that fits the user, then invest in making it good.