The robot that applies to jobs: how it really works

“A robot that applies to jobs for you” became a headline in 2026, and the reports mostly tell the same story: the market got too big to read by hand, the hiring side automated years ago, and now a program can apply on your behalf. All of that is true. The trouble is that the article ends at the click and the work starts there. This post is the part that gets left out — what the robot does after it presses Apply, where it gets stuck, and how anyone proves the employer really received it. Everything here comes out of our own code and our own measurements, with dates.

What the press got right, and what it left out

What they got right: this can be automated, and the people hiring automated their side a long time ago. What gets left out is three things, and they are exactly the three that decide whether any application arrives at all.

Finding the posting is the cheap part. Gupy — the hiring platform behind most large Brazilian employers — has a public search that answers with structured JSON: title, full description, city, workplace type, deadline. No login, no browser. We checked it live on 13 August 2026. Reading a whole national market is a solved problem; the form is what costs.
Almost nobody separates “filled in” from “sent”. They are different events, and only the second one matters to someone looking for work.
Half the platforms require a candidate account. Gupy, InfoJobs, Sólides and vagas.com.br accept nothing from someone without a registration. And on Gupy the identity is the national tax number, which changes everything — we come back to that at the end.

Autofill is not an application

A browser extension fills what is on the screen. A robot that applies has to decide things before there is a screen: is this posting still open? is there an account on this platform? is that account's session still valid? does this required question have a truthful answer in this person's data? Not one of those questions has a field next to it.

In Brazil the wall arrives late, and that is what fools people. A Gupy posting is public when you are signed out: the whole description, the company, the deadline. The demand for an account only shows up at the moment of sending. Anything that measures success by the page loading believes it went fine right up to the exact point where it did not.

How a robot fills a Gupy form, field by field

Gupy is not one form. It is two layers, and they live in different places. The first is what the account already carries — tax number, schooling, address, résumé — filled once, at registration. The second is the questions that particular employer wrote for that particular posting.

The account layer is a single screen: country of origin, tax number, email, confirm email. The tax number is required and only appears once the country is Brazil.

Then comes “now complete your profile”: full name, mobile and date of birth. Those last two are where automation dies quietly. The mobile has to go in as eleven Brazilian digits with no country code, no spaces and no dashes — with any of them the Continue button simply does nothing, and the page never says why. The date has to be day/month/year: in international format the input mask swallows the digits and Continue freezes the same way. After that, a password, and Gupy always sends a registration confirmation email that has to be opened before the account is good for anything.

The employer's questions are not on the public posting: they arrive inside the HTML of the company's own careers page. That matters for one practical reason — a page that could not be read looks exactly like a posting that asks nothing. Our code treats the two differently on purpose: if the careers page cannot be read, it refuses to send at all rather than submitting with every employer question blank.

Short text and long text	filled
Single choice and multiple choice	filled
Per-question attachment	goes to the browser
Conditional question	goes to the browser
Résumé on the account	checked first
Question with no truthful answer	goes to the browser

Per-question attachments and conditional questions are the two the fast path will not do: one needs a signed file upload for that question alone, the other only appears depending on an earlier answer. In those cases the whole application goes back to a real browser, which fills it the slow way. The rule behind that is short: half a submitted application cannot be taken back.

The proof that the application went out

Here is the distinction nobody explains. When the application is created on Gupy, the server answers 201 — created. That is a fact about a request, not about an application. The proof our code accepts is a different one: it goes back and reads the application out again, from your own list of applications on Gupy. If it is not there, the robot is forbidden from saying it was sent.

On an ordinary form, outside the account circuit, the witness is the network: the submit request to the form's own site and the number the employer's server answered with, written into the application's timeline in those words. When the network cannot witness it, a confirmation written on the page is required instead. With neither, “sent” is forbidden and the application stays open for another attempt. Beside it sit the screenshot of the moment it went, the log of what went into each field and the times. When an attempt dies against a wall instead, more is kept than the picture: the page's own HTML, the numbered outline of controls the software was reading off, and the network log — so that “the submit never left” and “the submit left and came back 422” stop being the same observation. The auto-apply page shows the whole thing assembled.

How many a day makes sense, and why 10 not 1,000

It is not a shortage of postings. One Brazilian hospital group's board on Gupy carried 1,699 open postings when we looked, and 425 of those were nursing. Volume is not what is missing. A role that fits one particular person is.

In four days of a real search we read 360 postings across eleven job sites. Forty-seven matched the target — 13% — and nine became applications. On the accounts we run today, the number of roles a day genuinely worth someone's name lands between one and eight. So the ceiling here is ten a day and three hundred a month on the paid plan, one a day and twenty a month on the free one. A ceiling, never a target: on a day when nothing clears your bar, nothing is sent.

A thousand a day is a different proposition. It means not reading, and it means being visible: a hundred applications from one person in one morning shows up to a recruiter, and hiring software has started answering that pattern with fraud checks. That bill lands on the candidate.

What it must never answer for you

Tax number, phone and date of birth are never invented. If the profile has no tax number, that is a clean stop naming the missing fact — the account that already exists is saved first, and the question comes back to you. Guessing a number there would be fraud, not automation.
Work authorization and visa get the conservative answer. Never a claim your data does not support. It is the one field on a form where a wrong answer is a lie rather than a typo.
Identity questions are not answered for you. On an application the robot does not tick gender, race or orientation. On the platform profiles that will not save a résumé without an answer, it picks “prefer not to say” — the only option that asserts nothing about anybody.
Your LinkedIn account is not touched. The product never creates, holds or uses a session there, and no application ever goes out through a linkedin.com address — such a link is closed, not attempted. Postings we read; accounts we do not.
Approving a role stays yours. What comes close without convincing waits for your yes in a review queue, and no rule promotes anything out of it on its own to fill the day's quota.

And there is the case that breaks the general rule: on Gupy, the identity is the national tax number. Anyone who has ever applied through it already has an account, and no second account can exist for the same number — we checked live on 21 August 2026, and two people's tax numbers resolved to their own personal email addresses. There is nothing to register and no way in on our own: only they have that password. In that one case the dashboard asks for the login, and it is the only place in the product where that happens.