AI agent for filling web forms and tender applications
Dozens of external portals — government and corporate platforms, each with its own set of fields, line length limits, mandatory attachments, and file naming rules.
The data, meanwhile, sits in the accounting system, email attachments, and folders on the network drive, rather than in one place. Manually transferring data into forms takes hours per application and almost always creates a discrepancy with the source.
The cost of an error is higher than it seems: a missed mandatory file, a detail with a typo, or a date in the wrong format — and the application is sent back for revision or rejected on formal grounds, even before substantive evaluation.
When tender applications are prepared on the last day, there is no time for rechecking — some applications do not go out at all.
The AI agent changes the scheme: it parses the structure of a specific form, maps the fields to sources in the accounting system (1C, exports, registers), pulls in the required scans and certificates, checks mandatory status, and fills the form.
The human remains at the confirmation step before sending — that is, at the decision, not at the transfer.
Automation of applications removes routine from the specialist: instead of manually filling web forms, they check a ready draft. At the same time, the AI agent works with the forms that exist — there is no need to modify third-party platforms. Below we explain how this is arranged and what remains under the customer's control.
What changes in the process of preparing applications and commercial data
Before implementation, an application was assembled manually: the specialist opened the accounting system, transferred the company card, banking details, and line items into the customer's form, then proofread everything line by line.
One lot took hours, and with a flow of dozens of applications, the work was rushed. The agent removes the mechanical part — collecting and transferring data — while the human is left with verification.
Details stop being a source of returns. Discrepancies in the name, INN, KPP, address, and banking data are the most common reason an application is sent back for revision.
The agent takes values from a single reference data source, checks checksums, and fills the field with an indication of the source, so a mismatch is visible before sending, not after a commission's remark.
The workload on the key specialist changes qualitatively. Previously, the most experienced employee — the one needed for the pricing part and technical requirements — was occupied with copying and verification.
Now their time goes to substantive sections, while routine assembly runs in parallel across several applications.
Submission predictability increases: each application has a status, a list of unfilled fields, and a deadline reminder.
Missing the submission deadline stops being an ordinary risk — the application is assembled in advance and sits ready to send; all that remains is to decide on price and terms.
We measure the effect by four values: time per application, share of returns due to discrepancies in details, number of applications per specialist, and share submitted on time.
We take them at the start and repeat after implementation, so the result is measurable rather than declarative.
AI agent operating modes: autonomous and with confirmation
The operating mode is not a checkbox in settings but a different level of trust in the data and a different cost of error.
The agent extracts values from the supplier card, commercial proposal, and constituent documents, maps them to the form fields, and then follows one of three scenarios: fills and sends on its own, prepares a draft for review before sending, or only prompts the operator.
| Mode | How the agent behaves | When it fits | Limitations |
|---|---|---|---|
| Autonomous mode | Fills the form and submits the application without human involvement; resolves disputed fields with a default value | High-volume similar applications, platforms with a predictable form, data already verified | An error goes into the submitted application; an action log and rollback rules are required |
| Filling with confirmation | Prepares the entire draft, highlights low-confidence fields, submits after operator confirmation | Tenders with price and legally significant wording, new platforms | Requires operator time — minutes per application |
| Operator prompts | Does not touch the form, suggests a value next to the field and a link to the source | Unfamiliar forms, one-off purchases, training on new document types | Speed depends entirely on the operator |
The choice of mode sets the level of trust in the data, not the convenience of the interface: if sources contradict each other, the agent should not silently choose a value.
Therefore, modes are assigned section by section — details and contacts can be given to autonomous mode, while the price proposal and declarations are kept on confirmation.
Changing the mode does not require rewriting the scenario: rules are inherited from the field type, and the log records which value was inserted and from which document.
How implementation proceeds: stages of engineering work
We start not with model configuration but with inventory: the agent will not fill a field if it is unknown where to get the value and by which rule to normalize it.
Therefore, the work proceeds sequentially — from form audit to trial operation, and at each stage there remains an artifact that can be checked.
- Audit of forms and data sources. We collect all forms and tender platforms, analyze field structure, mandatory status, and format constraints. In parallel, we record sources: details, product cards, price lists, document scans, application correspondence.
- Field map. We map each form field to a source and extraction rule: data type, normalization of dates and addresses, units of measurement, what is considered a valid value.
- Configuration of filling scenarios. We describe the logic: what is filled automatically, where human review is needed, how the agent behaves when data is missing — leaves the field empty or requests clarification.
- Testing on trial applications. We run the scenarios on accumulated applications and compare against a reference: the share of fields filled correctly on the first try, which discrepancies repeat. We fix errors in the field map, not in an individual response.
- Trial operation. The agent works in prompt mode: the operator sees the prepared option and confirms it. This builds statistics on forms that were not included in the test set.
- Handover to operation. We provide documentation on the field map, the procedure for updating it when forms change, and instructions for operators. After handover, the customer's team makes changes to scenarios themselves.
Configurations, access rules, and procedures after implementation
Implementation ends not with a demonstration but with the handover of a set of artifacts by which the system can be operated and developed without us. Below is what physically remains with the customer in their environment and repository.
- Agent settings and field markup schemes — configurations for each form type: mandatory fields, value sources, pre-submission checks.
- Access rules and user roles — a "role → action → data scope" matrix: who starts filling, who confirms submission, who sees drafts.
- Action log — for each application: who initiated it, what the agent inserted automatically, what the operator corrected manually, and how the submission ended.
- Procedure for working with forms — the order of queue processing, escalation rules for rejection, and points where human review is mandatory.
- Operator instructions — scenarios for resolving markup errors, re-running, adjusting the data source, and contacting support.
- Integration scheme and rollback plan — systems involved, key storage procedure, return to manual mode without losing applications.
- Support procedure — updating rules and versions, frequency of markup quality checks, responsible parties by area.
Handover takes one or two working sessions with your team — after that, the system is run by an internal engineer or administrator, and we get involved only in logic changes.
Case study: high-volume tender application filling
The tender department of a holding with eight business lines handles a flow of applications for the supply of equipment and services.
Before implementation, each application was assembled manually: the specialist opened the platform form, transferred details from the counterparty card, searched for current certificates in the network folder, and entered characteristics from the catalog.
One application took 35–50 minutes, and at peak seasonal demand the department processed only part of the invitations — the rest were closed by the submission deadline.
What was changed in the workflow
The main losses were not in typing but in repeat applications: most items had already been submitted in other lots but were assembled again from scratch.
We broke down the platform forms into fields and linked them to an internal reference data source — details, certificates, and characteristics are taken from a single source with version and expiration date control.
The agent inserts data into the form, marks fields without a confirmed value, and sends the application for review: without specialist confirmation, submission does not go out.
A profile is saved for each item, and repeat submission is assembled from history — only the lot terms change.
Metrics before and after
The implementation case results were recorded as follows: time per application — from 35–50 minutes to 5–7; share of rejections for formal reasons — from 12% to 2%.
The flow grew from 30 to 90 applications per week with the same tender department headcount, because what was removed was not typing speed but the repeated assembly of the same data.
We separately checked the link with the Unified Information System in the Field of Procurement: discrepancies between cards disappeared, since the source of details is now single.
What to do if forms on portals change frequently?
The agent does not bind to rigid coordinates and field order — it relies on semantic features: label, hint, input type, neighboring labels, and block structure.
Renaming a field, rearranging sections, or changing markup does not break filling: mapping is recalculated on the fly based on a combination of features, not a single hardcoded rule.
The field map is a separate description layer, not code: it specifies which application detail corresponds to each field, which formats and validation rules apply.
Updating the field map after a portal change takes minutes and does not require rebuilding the solution — the description changes, the agent itself remains the same.
After filling, the agent goes through the form again: it compares the entered values with the source data, checks masks, mandatory and hidden fields, and the form's reaction to input.
Discrepancies do not go through as is — the field is marked and sent for manual review rather than filled at random.
We maintain the field description update as part of the solution: we monitor markup changes on connected portals, record them, and transfer them to the field map. The customer does not need to keep an engineer who manually rewrites rules after every change on the portal side.
Every action remains in the log: you can see which field was recognized, what was inserted, and what was verified. Resilience to portal changes becomes predictable — instead of chasing a changing form, you get a process that recovers in one verification cycle.
Technical concerns and limitations of the solution
Accuracy here is a measurable quantity: the agent inserts values extracted from your documents and does not guess the missing. Each field stores a link to the source fragment, so the reviewer sees where the figure came from.
On models of the OpenAI level, the share of fields accepted without correction is configured for a specific set of forms, rather than taken from general statistics.
How accurately does the agent fill fields?
Numbers, dates, and amounts undergo format and range validation; text fields are checked against a reference of valid values.
If a document contains two contradictory values or a field is not found, it remains empty and goes into the human review queue rather than being filled by a guess.
How are attachments and tabular appendices processed?
Attachments are parsed into text and tables: rows are matched to application line items, files are attached with their names and order preserved.
If the platform accepts only a certain format, the document is converted, while the source remains in the application draft for verification.
What data accesses does the solution need?
A separate account with permission only to submit applications and a token with a limited validity period. The agent does not receive access to internal systems, correspondence, or databases, and the action log shows which document was read and which field was filled.
What happens if filling is interrupted?
The application draft is saved after each confirmed step along with an idempotency key. A repeated run continues from the last step rather than from the beginning, so duplicates do not go to the platform, and an unfilled application is not submitted at all.
Let's discuss the task: where to start the work
The first meeting is a working one, not a presentation. We analyze which forms and applications you fill out now, who is responsible for this, and which fields most often cause errors.
To make the conversation concrete, it is enough to send document samples and access to a test environment — we clarify the rest as we go.
- List of input data: 5–10 examples of already completed forms (PDF, DOCX, XLSX), blank templates, and internal filling instructions, if any.
- Map of value sources: where the AI agent gets data from — company card, registers, past applications, reference data. We note what is available in machine-readable form and what will need to be put in order.
- Rules and constraints: mandatory fields, requirements for value formats, and checks that an application fails when there is a discrepancy.
- Failure scenarios: what the agent does when data is missing or contradictory — leaves the field empty, marks it for a human, or requests clarification.
- Work plan: stages from template analysis to delivery, with points where you see an intermediate result.
- Timeline estimate: what the duration depends on — the number of form types, quality of reference data, complexity of external portals.
- Pilot scope boundaries: one form type or one department, to verify accuracy on real data before scaling.
- Acceptance criteria: share of fields filled without corrections and the procedure for tracking errors.
Based on the meeting results, you receive a short document: a list of input data, a stage-by-stage work plan, a timeline estimate, and agreed pilot boundaries. Describe the task — we will come back with an estimate and plan.
