An AI agent for job application fills and submits employer forms with no person watching, so the part worth reading about is what it does when something goes wrong. Most pages on this topic stop at the form. This one sets out how ApplyEze Autopilot behaves once a team has switched it on: every way a run can end, why a run with an unknown submit is never replayed, which runs get retried, what is checked before a run starts, and the controls around all of it.
ApplyEze Autopilot is set up today for staffing and recruiting teams that work with ApplyEze. If you are job hunting on your own, you can start with 50 free applications on sign-up, no card needed: you pick the matches and queue them in the desktop app, and ApplyEze fills and submits each form. The numbers here are team numbers, and they are not a free user's result. The last section covers what carries over, and gives six questions to put to any agent.
The ways a run can end
Start at the end, because this is where the design shows. Runs are applied or released, and they never wait for a person. There is no folder of half-finished forms for someone to look at on Monday. Every run has to end in one of six ways on its own.
| What happened | What the role becomes | Tried again automatically | Roles, 14 days to 9 Nov 2026 |
|---|---|---|---|
| The form was submitted | Applied | No | 34,541 |
| Already applied | Duplicate | No | 624 |
| The posting was closed | Closed | No | 2,402 |
| The run never started, or an infrastructure problem ended it and it is known not to have submitted | Back in the queue | Yes, at most 3 tries | No row of its own, since it ends as one of the others |
| Submit state unknown | Released | Never | Inside the 9,162 released |
| A real form failure | Released, with its reason | No | Inside the 9,162 released |
Those counts are by the date a role was planned, out of 259,514 planned. Most of the rest were turned down before any browser opened, which the end to end post covers.
Why an unknown submit is never replayed
Take a sample, invented for this post. The agent clicks Submit on a long form. The page sits there, then the connection drops. No confirmation page, no error. Did it go through?
The agent cannot know. So it has two choices, and the world has two states:
| It really did submit | It really did not | |
|---|---|---|
| Replay the run | A second application from the same person reaches the employer, and it cannot be taken back | One application recovered |
| Do not replay | Nothing lost, though our count shows one fewer than was sent | One application lost, and the record shows released |
Three of those four cells are fine or cheap. One cannot be undone, and it lands on the person whose name is on the form. So the rule is built around that cell: an unknown submit is released, and it is never replayed.
We take that cost in our own numbers. A released run with an unknown submit may in fact have reached the employer, and we count it as released all the same, because we cannot show it was applied.
This is good advice by hand, too. If a page hangs after you press Submit, do not press it again. Look for a confirmation email, or check whether the application shows in the employer's candidate portal, before you try once more. Simplify's help page gives its users the same advice after a failed run: "Check whether the employer already confirmed a submission before starting another application for the same job." What a duplicate does to you is in our post on duplicate applications.
Careful retries, and which runs qualify
The other half of that rule is that a run known not to have submitted is safe to send again. Only those qualify: a run that never started, or one an infrastructure problem ended with no submit. They go back in the queue, with at most 3 tries, waiting 15 minutes, 1 hour, then 4 hours. The waits widen so a short fault can clear, and so a long one does not burn every try in the first few minutes.
A real form failure does not qualify. It is released with its reason, because running the same form the same way is unlikely to change the result.
So there are three different answers to "should we try again", and the evidence decides which applies:
- We know it did not go in, and the cause was ours: yes, carefully.
- We know it did not go in, and the cause was the form: no, release it with the reason.
- We do not know: no, ever.
Released is not failed: reading the 79.1%
Here is the figure that sums this up, and how to read it.
Across the 14 systems in the chart, 35,874 runs ended applied and 9,502 ended released, in the 14 days to 9 November 2026. That is 35,874 of 45,376, or 79.1%. Workday, the largest system by count, ran at 81.5% on 15,318 runs. By system it runs from Rippling at 94.5% and BambooHR at 92.8% down to Dayforce at 73.5% and iCIMS at 55.5%. The completion rate post has every system with its counts. On the rival pages we read on 9 November 2026, we did not find a figure like this.
Three things to hold on to when you read it:
- Released means the run ended without an application, for any reason, including a posting that closed. It is not a count of forms we broke. A low share is not always the form's fault.
- Some released runs may be real applications, for the reason above. So the true share that reached an employer could be higher, and we do not count what we cannot show.
- The 35,874 and the 34,541 are not meant to match. The first counts runs settled in the window. The second counts roles planned in the window. Do not add one table to the other.
It was measured on Autopilot runs, on ApplyEze servers, and it includes iCIMS and Dayforce, which the free path does not cover, so it is not what a free account should expect.
What has to be true before a run starts
Nobody is there to catch a bad start, so the checks come first. A free slot asks for the next role, and these all have to hold.
The switches. There are three independent ones: ApplyEze's, the company's and the candidate's. All must be on. Any one of them stops new runs.
The clock. It must be inside the company's working hours, nobody can have paused it, and the candidate must have room left today.
The candidate. The profile must be complete: phone, first and last name, email, a master resume and at least one job on file.
The role. The posting must be on a supported system and still live, the inbox must be connected where the system needs one, and the candidate must be under the employer limit, with no duplicate on record. ApplyEze is built to stop double applications: a posting is checked against the person's history, and a lock stops two lanes applying to the same posting at once.
One browser, one role at a time
One slot works on one application at a time, and the portal calls a slot an "AI recruiter". Each role runs under its own authorization, which lasts at most 2 hours. The browser is real Chrome on an ApplyEze server, using the same form filling as the desktop app. The median was 2.5 minutes from a lane picking up the role to the application going in, and 4.9 minutes at the 90th percentile (17,994 applications, 7 days to 9 November 2026).
Nobody watches each run, but quite a lot watches the system. It is built with the controls a staffing team expects:
- Servers report health every 15 seconds. One silent for 5 minutes stops counting toward capacity by itself.
- The queue lives in the database, so a restart does not lose queued roles.
- Deploys roll host by host: new starts pause, running work finishes, and a failed start restores the old release.
- Alerts are checked every 10 minutes for nothing going out, a low applied rate, deliveries behind, or a candidate short of roles. Alerts annotate and never stop a run.
- A record is kept per role: score, reason, role family, times planned, judged, claimed and settled, status, tries and failure code.
- Every change made through the admin page or the portal is logged, with who made it and when.
- Each company sees only its own candidates, and a recruiter sees assigned ones, enforced in the database with row-level security.
- Webhooks to a company's own system are signed with HMAC-SHA256, with 6 attempts, waiting from 1 minute and doubling up to 1 hour.
What a run does when nobody can answer
There is no approval step before Submit, and a run does not stop to ask. So a question the profile does not cover gets an answer anyway. Hard facts come from the candidate's profile. When a required question is not covered by the saved answers, ApplyEze still fills it rather than stopping the run, so that answer may not come from the candidate. Filling in the saved answers before a run is what keeps those to a minimum.
Some employers ask applicants not to use AI or automation. Whether to apply there is your call. On Autopilot that means putting the employer on the skip list, since nobody decides during a run. There are also limits it will not cross: ApplyEze does not take assessments for you, and a form that requires your full Social Security or national ID number stops that application.
What this means for a solo job seeker
Whatever tool you are looking at, these six questions tell you more than its feature page:
- If you cannot confirm a submit, do you try again? Does it cost me a credit?
- What do you do with a required question I have no saved answer for?
- Can I see exactly what was sent, in my name, afterwards?
- What do you count as a success, and out of what number? Do you publish it by application system?
- What happens to a queued role when the posting closes?
- What limit is there per employer, and does it count applications I sent myself?
A vendor who can answer all six in a sentence each has thought about what happens with nobody there.
On the free path you pick the matches and queue them, and the app runs on your computer while it is open, so keep it on and awake until your queue finishes. Workday and Oracle jobs stay hidden until you connect an application inbox, because those sites email a code. Use Visible mode if you want to watch, or Background if you do not. The same principles carry over in plain form. A form that cannot be finished costs no credit. If a site never confirms, no credit is used, and ApplyEze will not apply there again by accident. Runs end, they do not pause, and you can cancel a single lane. Dry run fills the form and stops before Submit, and it is the preview. So fill in your saved answers, use dry run first, and read your receipts. If you want to see that for yourself on a real posting, your first 50 applications are free, no card needed.
