Skip to content
Iter Labs

AI automation · RPA

Robots that do the data entry in your systems.

They post invoices and contracts, pull reports and update records in the ERP and web portals you already use, through the same screens as your team or an API when there is one. Every action is logged.

Book your free assessment (opens in a new tab)See the case studies

Python and Playwright · Numbers measured from execution logs

Illustration: a robot fills in an outgoing invoice in the ERP, screen by screen, checks the total and posts it, while the rest of the batch waits in the queue.
Illustrative data
What we automate

The retyping between one system and the next.

Most repetitive office work is moving data: from a spreadsheet into the ERP, from the ERP into an email, from one system into another. That is the work we hand to robots.

  • Invoices and contracts in the ERP

    Each one takes several screens: header, items, tax data, attachment. The robot fills every screen, checks the totals and logs each record.

  • ERP reports by email

    The list someone filters by hand every Monday. The robot pulls it on schedule, emails it and records every run with its result and duration.

  • Document intake

    A contract finalized in one system, then retyped into the ERP, attachment and all. The robot reads the source, a spreadsheet or the other system's API, and posts each record.

  • Email and documents

    Decisions and attachments get lost in long threads. We build search and answers over your email and documents, with AI models that run on your own hardware.

How it works

Same screens as your team. A record of every step.

Robots built in Python with Playwright. When the system has an API that covers the job, the robot uses it; when it doesn't, the robot works through the same screens your team uses.

01Logged-in session

Your team logs in. The robot uses that session.

The robot can attach to a browser your team has already logged into, instead of keeping a password. Your people sign in as usual, and the password stays with them.

  • No password stored in the robot

  • The same browser and screens your team uses

  • Read-only access whenever the task allows it

Illustration: the team's browser, signed in to the ERP, with an invoice robot attached to that session and no password stored.Illustrative data
02Orchestrator

Several robots, one login, one at a time.

Robots that share an ERP login knock each other out of the session. An orchestrator gives the session to one robot at a time, in order, and records who had it and when.

  • A first-in, first-out queue

  • A time-limited lease, renewed while the robot works

  • An audit trail of every handoff

Read the contract robot case
Illustration: an orchestrator gives the shared ERP login to one robot at a time, with a queue, a time-limited lease and an audit trail of every handoff.Illustrative data
03Logs

Every action goes into the log.

Each record posted, each check and each stop is written down with the time. When something goes wrong, the log shows the exact step where the robot stopped.

  • One entry per record, with its result

  • Checks such as the item sum against the invoice total

  • The exact step where a run stopped

Read the invoice batch case
Illustration: the activity log of an invoice robot, one line per action with its time, including the checks and a stop at the step where a screen didn't match.Illustrative data
04Scheduled reports

The Monday report arrives on its own.

At the set time, the robot pulls the list from the ERP and sends it by email. Every run is recorded with its result and duration.

  • Runs at the time you set

  • Every run recorded with its result and duration

  • When a scheduled run failed, a new run delivered the report the same morning

Read the weekly report case
Illustration: the Monday email with the contracts that end in the next 15 days, and the run history, where a scheduled run failed and a new run delivered the report the same morning.Illustrative data
Results

What the logs show.

Three projects for a Brazilian industrial construction group (precast concrete and construction). Robot times come from execution logs; manual times are team estimates and say so.

  • 2 h 42 min

    to post 300 invoices into a web-based construction ERP, about 32 seconds each

    Measured

    Execution logs · May 8, 2026

    See the invoice case

  • ≈25 h

    for the same 300 invoices by hand, at 5 minutes each

    Team estimate

    Not timed

  • 21 of 22

    weeks the robot delivered the Monday report of expiring contracts

    Measured

    Execution logs · June to October 2026

    See the report case

  • 156-274 s

    per contract with 2 to 6 items, measured in validation

    Measured

    Validation logs · July 2026

    See the contract case
What we've built

The automations we've built, most of them in production.

Live, delivered or a product of our own: every project says where it stands. Clients stay anonymous.

See all projects

Private AI

AI that stays on your hardware.

For search and answers over your email and documents, we use AI models that run on local hardware. With the on-premises option, documents and model inference stay inside your network.

How we handle security and data

  • Search and Q&A across your email and documents

    Ask in plain language and get answers from your own email and documents. Open models and the search index run on local hardware (Ollama and SQLite). In use since May 2026.

  • Offline meeting transcription in Portuguese

    Transcribes live and writes the summary, decisions and tasks on the same computer. 5.1% word error rate on our own benchmark.

Questions

Straight answers.

Do we need an API?

No. If your system has an API that covers the task, we use it: it is the most stable route. If it does not, the robot works through the same screens your team uses. Many projects use both. In one of our case studies, the robot reads an internal platform through its API and then posts each contract in the ERP.

Where do the robots run?

Where your setup calls for it: on a computer at your company, attached to a browser your team has already logged into, or as a service on a Linux server. The contract robot in our case studies runs on a Linux VPS. We settle that with your IT team before the pilot.

What happens when the ERP screen changes?

The robot stops at the step where the screen no longer matches what it expects, and the log shows exactly where. Scheduled robots send a failure alert by email, and we update the robot. Screen changes are the main upkeep of a screen-based robot, which is one more reason to use an API when there is one.

Do you keep our passwords?

Not when we can avoid it. The robot can attach to a session your team has already logged into, so the password stays with your people. A robot that runs on its own schedule needs its own sign-in. For those, we ask for the minimum access the job needs, read-only when possible, and walk your IT team through the setup.

Is this AI or RPA?

Both, and we tell you which is which. The robots in our case studies follow fixed rules: the same steps every time, with checks such as matching the item sum to the invoice total. AI models come in where text has to be read or answered, like search and Q&A across email and documents, and they can run on your own hardware.

How does a project start?

It starts with the free 30-minute assessment. Next comes a pilot on one task, in 2 to 4 weeks, so you can judge the result before committing to more. Then the robot goes live with monitoring: a log of every action and failure alerts.

Free 30-minute automation assessment

Find the three repetitive tasksthat cost you the most.

In 30 minutes we map the three most expensive repetitive tasks in your operation and tell you what automating them would cost.

Book your free assessment (opens in a new tab)Send a message