How do you automate a government portal that has no API?

You automate the interface the portal actually gives you: the forms. We built OFFSET, which files Greek short-term-rental declarations directly to the portal of ΑΑΔΕ, the Greek tax authority. ΑΑΔΕ has no API for this, so the agent drives a real browser and clicks the same fields a person clicks.

That sounds like a workaround. It is an architecture, with rules that decide whether a declaration gets filed once or twice.

Why click through forms instead of calling an API?

Because there is nothing to call. Many systems that businesses are legally required to use, tax portals chief among them, expose exactly one interface, and it is a web form designed for a person with a mouse. The obligation does not wait for the integration to become convenient. A computer-use agent closes that gap: a model controls a real browser, reads the page the way a person reads it, and acts on the same fields. Nothing changes on the portal's side, which is the point. The form is the API you were given.

This is a different discipline from calling a documented endpoint. An endpoint returns a status code. A form returns a page, and the page was written for a human, so the agent has to read consequences instead of codes. That difference decides most of the engineering below.

What breaks when the agent runs in production?

Everything a person quietly tolerates. The session expires in the middle of data entry, because government portals log you out on a timer, and our filing estimates include those timeouts because they are part of the job. The markup changes without an announcement, and validation errors come back as prose aimed at humans. Maintenance windows appear on no status page.

The real engineering problem is state. When a session dies halfway through a monthly batch, the agent has to know, with certainty, whether the declaration it was typing got submitted before the cutoff. Retrying without knowing files it twice. So the agent records its intent before acting, logs back in, verifies against the portal's own submission listing, and only then continues. That is idempotency, an old database idea doing new work in a browser. The model is the cheap part of this system. The bookkeeping around it is the build.

What does the agent do when it is not sure?

It stops.

A guest-messaging agent that misreads a question costs an apology. A filing agent that misreads a field costs an amended declaration and an uncomfortable phone call. The tolerance for confident guessing is zero, so the shape that survives production is prepare, approve, submit: the agent assembles the filing from source data, a person approves it, and only then does the agent press submit.

Most production agents live at exactly this setting. Bain surveyed 951 companies and found only 7% running fully autonomous agents in production. The boundary shows up across our own work too: askHermis, which we built, answers 85% of guest queries instantly, and the remaining 15% go to a person. A filing agent runs a stricter version of that line, because the cost of a wrong answer is asymmetric. Autonomy is a dial, and on government paperwork it is set low on purpose.

What does the arithmetic look like?

Estimated, not measured: filing one short-term-rental declaration by hand takes 4 to 7 minutes, including the portal's session timeouts. An operator with 30 properties averaging 8 stays a month files roughly 240 declarations, which is 16 to 28 hours a month, or EUR 224 to 392 at a EUR 14 per hour loaded cost. Your numbers will differ, and an audit replaces these with yours.

On the other side of the ledger the model is cheap. At list prices checked on 6 August 2026, a heavy agent run of 500,000 input and 50,000 output tokens on Claude Opus 5 costs $3.75, per Anthropic's published pricing. At that unit price, inference is rarely what limits a back-office agent. Human review time is the budget line that matters, which is one more argument for an approval gate designed to be fast.

Who wins from this architecture, and who should wait?

The firm of five wins the most. A group with a compliance department has already absorbed the portal: those 28 hours sit inside somebody's job description and nobody counts them. For a five-person operator the same obligation is evenings. The same obligation is a budget line for the group and a Tuesday night for the small firm.

Wait if your records live in six places. An agent inherits your data exactly as it is, and a filing agent fed contradictory booking records will stop and ask so often that the approval gate becomes the job it replaced. If the source data is clean, the agent runs quietly. And when a system does offer an API, use it: OFFSET ingests from Airbnb, Booking.com and PMS systems, and the browser is reserved for the one system that offers nothing else.

One caveat, and it is ours to own. The 4 to 7 minutes is an estimate read off the form fields and the timeouts, and nobody stood over a filer with a stopwatch. If you have timed your own filings, we would rather use your number than ours.

The place to start is a count, and it fits on one line of a spreadsheet: which task in your company is done through a browser because the system behind it has no API, and how many minutes did it take last month? If the answer comes back in hours, that is the kind of work we scope.