A person corrects an answer in an application form. The assistant runs again after another field changes and replaces that correction with an older profile value. Every input may still pass validation. The workflow has nevertheless lost the person's decision. More accurate field detection would not fix the overwrite rule.
Disclosure: An AI agent researched and drafted this article using my public project documentation and the linked Chrome developer guidance. The opening scenario and implementation examples are hypothetical, not reports of user incidents.
In Exempliph.ai's public case study, I describe field mapping that combines AI assistance with explicit profile answers and preserves user edits. The product is built and actively evolving, with separate contexts for job applications and artist festival applications. Its practice workspace provides a place to learn the flow without sending real applications. The case study does not claim universal form coverage.
That preservation rule deserves attention early in an automation project. A reusable profile, a generated suggestion, and an answer someone just reviewed are different sources of authority.
Keep a suggestion separate from the current answer
For a comparable form assistant, I would keep the suggested value separate from the value currently shown in the field. Record where each suggestion came from: a profile fact, a saved answer, a document, or model generation. Also record whether the person accepted or edited it.
A confidence score alone is insufficient. The model may be very confident that it copied the profile correctly while the person has deliberately supplied a different answer for this opportunity. The relevant question is whether the workflow has permission to replace the current value.
An intentionally empty field needs attention too. If someone clears a generated answer, another run should not assume the blank is unfinished work. Clearing can be an edit. Treating all empty values as available space makes it difficult for a person to decline the assistant's suggestion.
I would provide an explicit way to regenerate a selected answer. That action can replace the suggestion while leaving unrelated reviewed fields alone. Show what changed so the person can decide whether to use it. This is a proposed interaction pattern, not a description of every control currently in Exempliph.ai.
Better tools still need a merge policy
Chrome's WebMCP overview, published May 18, 2026 and updated October 7, describes a proposed standard for websites to expose structured tools to agents. Its origin trial is an ongoing development, not a newly shipped universal browser capability. Explicit input schemas and page context can reduce the ambiguity of interacting with a site.
That is promising for forms. If a site states what an action accepts, an assistant has less interface interpretation to do. But a schema saying “this is a phone number” does not decide whether the number in the profile should replace the one the person just entered.
The site's tool handler still needs application rules. For a tool that prepares draft answers, I would make its overwrite behavior explicit, return which fields changed, and identify any fields left untouched because they had been reviewed. A caller should be able to distinguish a completed preparation step from one that needs more input.
This is a design implication of structured tools, not a claim that WebMCP implements field ownership or that Exempliph.ai currently uses WebMCP. The transport can make an operation clearer. The product must define what that operation is allowed to change.
Reconcile changes in the form itself
Conditional questions complicate the rule. Suppose changing an applicant type reveals a new section. The assistant should inspect the current form before proposing answers for that section. An old mapping may now refer to a hidden question, or the same visible label may have a different meaning.
For a comparable implementation, I would retain reviewed answers in the draft while reconciling them against the current layout. If an answer no longer applies, mark that conflict for review instead of silently relocating it into a nearby field. A saved decision remains useful even when it cannot safely be applied automatically.
Chrome's August 26 WebMCP workflow guidance emphasizes defining the user's goal and initial application state, role-playing the interaction, and returning useful recovery information when an action cannot run. Those are relevant engineering practices here. The current form state is part of the input, not just a surface on which to replay earlier actions.
Test the second run
A happy-path test often starts with an empty form and ends when every expected field contains a value. For this behavior, the second run is more revealing. Fill a draft, change one answer manually, then ask the assistant to handle a different question. Check that the correction survives.
Include a cleared answer, a changed profile value, and a conditional section in the test fixtures. Check what happens when a browser session is restored. The expected behavior should describe which answers can change and which require a new decision. These are proposed tests for this ownership rule, not evidence of a completed test suite in my project.
Exempliph.ai's documented manual boundaries include complex widgets, payments, legal declarations, and CAPTCHAs. Preserving a draft is useful precisely because some steps still need the person. Preparation should leave their decisions intact when they resume.
As websites expose clearer tools to agents, browser automation can spend less effort guessing how to interact. Developers can use that opportunity to build a better collaboration model: suggestions that remain inspectable, corrections that survive, and explicit choices about when an answer may change. The useful outcome is a form the person can trust to keep their work.
Top comments (0)