Put AI on the Decision, Not in a Chat Tab

A product team adds a chat tab and calls the application intelligent. The tab can draft, search, and, if someone was in a hurry, call the same APIs the form used to call. Users still need a vendor, a quantity, a warehouse, and a price the ledger will accept. Those fields did not disappear. They moved into a sentence the model has to parse, and the failure moved with them.

Put the model on the judgment: which record is meant, what the page seems to say, how a reply might be worded. Put the commit on a structured action the application already knows how to validate. Engineers decide what that action is allowed to change. The model assists the proposal. Tools verify the proposal before anything is stored or sent.

A form is how a write stays valid

Forms feel clumsy when they ask a person to type facts the system already stores. That is a reason to prefill them. It is not a reason to throw away the constraint. A required field, a foreign key, and a permission check are how the system refuses an order that cannot exist. A chat box that writes the same record without those checks is a weaker form, because the user cannot see which field failed until the damage is downstream.

The OWASP Top 10 for Large Language Model Applications names a related failure excessive agency: a model given tools, permissions, or autonomy beyond what the task needs. A chat tab bound to create, update, and send tools is that failure with a text box in front of it. Narrow the tools to the one action the screen is for, and make the action pass the same validation the form used.

Choose the surface from the job

Read-only answers still need an abstention path. If retrieval finds nothing the caller may see, the honest response is that the feature does not know, which is the design in When AI Should Refuse. Writes still need a state that waits for a person when the action is consequential. That state machine is described in Human-in-the-Loop AI Architecture.

Propose a struct, then confirm the struct

1. The user states an intent, or the screen already has the context, such as the open ticket.
2. The model returns a proposed action that matches a schema you wrote: identifiers, quantities, and an action name from a fixed list.
3. Code checks types, permissions, and invariants. A failed check returns the field, not a paragraph of apology.
4. The screen shows the structured action for edit and confirmation. The user confirms fields, not a blob of prose.
5. A worker performs the write. A second request with the same idempotency key does not perform it again.

This is slower to demo than a tab that calls tools on its own. It is also the version you can explain to an auditor: here is the proposal, here is the check, here is the person or rule that accepted it.

Illustrative scenario: reorder from a sentence

This scenario is illustrative. It is not a shipped Vasiva product flow.

A buyer types: “Reorder what we bought last March for the Austin warehouse, same gloves, forty units.” A model can propose a vendor, a SKU, a quantity, and a warehouse by reading prior orders the buyer is allowed to see. The screen then shows those four fields, editable, on the purchase form. Submit runs the normal validation. If last March’s order cannot be found, or two SKUs match “gloves,” the form does not invent an identifier. It leaves the field empty and says what it could not resolve. The buyer completes it or stops.

A chat tab that places the order from the sentence skips the moment where two SKUs were ambiguous. The structured screen makes that moment visible. The model did the useful part, which was finding the prior order. The form did the necessary part, which was refusing to guess.

Checklist for the surface you are about to build

• Write the job in one line: look up, classify, extract, or commit.
• If the job commits, name the schema and the existing validation the proposal must pass.
• List the tools the model may call. If a tool writes, sends, or spends, it is not on that list until a confirmation step exists.
• Show the proposal as fields. Keep the transcript, if you keep it, as history rather than as the record.
• Define the empty case: what the screen does when the record, the page, or the permission is missing.
• Give the commit an idempotency key.
• Put a person on any action the business would not want explained as “the model decided.”

Questions that usually come next

Are forms obsolete once a model can parse intent?

Forms collect a constrained write. They are a poor interface when they ask people to type facts the system already has, and prefilling fixes that. They remain the right commit surface when a field must be valid before anything is saved. Parsing a sentence does not remove the field.

When is a chat tab an honest product?

When the job is a lookup, the answer is read-only, the user can see the source, and the feature may say it does not know. A chat tab that creates or changes records needs the same schema, validation, and confirmation as the form it replaced.