Iterabase technical overview: how AI coworkers work in your systems

What it is

Iterabase gives an operations team a set of AI coworkers that do real work in their real systems (email, documents, web portals, file shares and databases), while people confirm every consequential action. Each customer runs in their own single-tenant environment, with EU zero-data-retention models and a full audit trail.

Iterabase builds your first workflows with you; after that, your Admins can build new coworkers by asking Sofia. A coworker reads an inbound email, pulls the documents apart, looks things up in portals and internal systems, prepares the outcome, and asks a person to confirm before anything leaves the building. Sofia, your chief of staff, sits beside the team in the app and in Microsoft Teams.

Two reference workflows show what that means in practice:

Proof of delivery to invoice. An emailed proof of delivery is matched to an invoice on the customer's file share, checked against read-only ERP data, then uploaded to a carrier portal.
Quote request to sent quote. An emailed request with scanned PDFs triggers rate requests to carrier APIs, web portals and suppliers by email; replies are collected, margin rules applied, a person approves, and the quote is sent.

At a glance

Work comes in

App and Sofia

Microsoft Teams

Your dedicated environment

Workflow runtimewait for replies, pause, safe restart

Document intakevirus scan, OCR, vision reading

Managed browsersauto login, live login handoff

People confirmevery send and submission

Coworkers act on

Web portalsscripted submissions

Outbound emailconfirmed or allowlisted

Runner in your networkoutbound-only mTLS; files, read-only SQL

AI modelsEU-hosted, zero data retention, reached over mTLS

Everything runs in one environment dedicated to you; the only things that leave it are confirmed actions and model calls that are never retained.

Features

Coworkers and workflows

Capability	How it works
Configured for you	Each customer gets their own configuration: workflows, tools, Skills, credential slots, coworker identities, mailbox bindings and value baselines. Shared integration tools ship versioned with each platform release.
Waiting for replies	A workflow can send several requests (for example three supplier RFQs) and wait for all or any replies until a deadline, then continue the same run. No compute is held while waiting.
Parallel steps	Independent branches run side by side and join when all finish; a required branch failing stops the run early.
Honest state	Work shows as Working, Waiting, Paused, Needs you, Failed or Done. Pauses (trial ended, model provider outage, runner offline) resume by themselves.
Safe recovery	A step interrupted mid-way reruns only if it made no writes; otherwise the item stops for a person to restart. Restart resumes from declared checkpoints.
Completion checks	Optional postconditions verify a step's outcome against its evidence before it counts as done.

New itememail, chat, API

Workinga coworker is on it

Doneexact copies kept

Returns to Working by itself, or once a person acts

Waitingfor replies or a deadline; no compute held meanwhile

Needs youconfirm, answer, log in, or release a held email

Pausedtrial ended, model outage or runner offline; resumes by itself

Stops for a person

Failedincludes outcome unknown; Restart starts a new, confirmed attempt

Waiting, paused and needs-you all return to Working; only Failed needs a deliberate restart, so a step that already wrote to your systems is never repeated by accident.

People in control

Confirm before consequence. Every send or submission is either confirmed by a person on the exact content, or pre-approved only for a declared allowlist of recipients. Anything else falls back to confirmation.
Needs you. One list across all work of what waits on a person: confirmations, questions, portal logins and held emails. Each opens its work item.
No silent retries. A send whose outcome is uncertain is marked "outcome unknown", never resent automatically.
Full attribution. Every action records who started it, which coworker acted and through which channel (browser, API, Chat, Teams).

Your turn: one decision at a time, with the exact email that will be sent — Your turn: who prepared it, how the price was built, what was checked, and the exact email. Approve, edit first, or say no.

Email (Microsoft 365 and Google Workspace)

Intake by provider webhooks plus delta catch-up, so no message is missed after downtime; polling only where no public endpoint exists.
Routing: replies are matched to their work first (by thread, then a reference token in the subject, with a sender-domain check); new mail follows the workflow's start policy; duplicates collapse to one item.
Ambiguous or foreign-domain replies are held for a person. Late replies are kept as evidence.
Never auto-replies. Outbound mail goes only through confirmed or pre-approved sending steps.

Send step3 requests out, a token in each subject

Supplier A

Supplier B

Supplier C

Reply matching1. same email thread2. token in subject3. sender domain check

Run continuesall or any reply, or the deadline

Held for reviewambiguous or foreign domain

A reply that cannot be placed with confidence waits for a person instead of being guessed; replies after the deadline are kept as evidence only.

Documents

One quarantine path for every file, whatever its source: upload, email, runner or tool.
Malware scanning (ClamAV), then text extraction and OCR (Apache Tika, Tesseract) as the canonical reading of each document.
Email containers (.eml, .msg) are unpacked; bodies are sanitised to text.
Handwriting and stamps: coworkers can read page images with a vision-capable model when OCR is not enough.

Uploads

Runner

Tools

Quarantineevery source, one path in

Virus scanClamAV, before anyone opens it

ExtractionApache Tika and Tesseract OCR

Coworkerreads the text, acts on it

Vision modelpage images, for handwriting and stamps

The extracted text is the canonical reading of a document; the vision model is extra reasoning on top, never a replacement for it.

Web portals

Managed browsers let coworkers browse and read portals freely; the browser itself blocks submissions and uploads outside login pages.
Consequential portal actions run only through per-portal scripted tools, under the same confirm or pre-approved rules as email.
Automatic logins with stored credentials and TOTP; sessions are reused per account.
Live login handoff: when a portal asks for an SMS code or similar, an authorised operator completes it in a live browser view inside the app. Nothing typed is recorded, and logging in to the wrong account is refused.

Inside your network

Runner: a signed Windows service (Linux build too) that connects outbound only, over mutual TLS. Enrolled from Settings, Runners; stopping the service is the kill switch.
File shares: reads only within declared folders.
Databases and ERP: declared, parameterised, read-only SQL queries; no free-form SQL.
Credentials stay with the platform and are sent per call, not stored on the runner.
Internal-only portals: the same managed browser can run on the runner, keeping sessions inside the network.

Your network

Runnersigned Windows or Linux service; stop it to cut access

File sharesdeclared folders

ERP databaseread-only queries

Internal portalsbrowser on runner

Your Iterabase environment

Workflow runtimeholds the credentials and sends them per call; declared queries only

No inbound ports into your network. If the runner is offline, work pauses and resumes when it is back.

Your IT team opens no ports: the runner makes the only connection, outwards, and can only run what was declared for it.

Desktop applications Coming soon

Some systems, such as PHC or SAP GUI, have no practical API. The runner operates them the way a person would, on a machine set aside for it.

Dedicated automation machine, in your network

PHC, SAP GUIor another Windows business app

Runnerscreenshots and the UI automation tree

Coworkerreads the screen with the vision model, decides

Scripted capabilitya declared write, confirmed or pre-approved, sent back through the runner

Auto-logon VM or remote session, never an employee PC. On-screen indicator while automated, full local audit log, no admin rights.

Desktop applications through the runner

Dedicated machines only. Automation runs on an auto-logon VM or remote session in your network, never on an employee's PC.
A runner capability, not a second agent. The reasoning stays in your Iterabase environment. The coworker observes through screenshots and the application's UI automation tree, read with the vision model.
The app's own interfaces where they exist: Windows UI Automation, SAP GUI Scripting and COM.
Same safety model as browsers. Reading and navigating are free. Writes, such as posting a document or saving a record, go only through per-application scripted capabilities, declared as writes and confirmed or pre-approved.
Visible and stoppable. An on-screen indicator shows when automation has control, every action is in a local audit log, and stopping the runner service is the kill switch.
Least privilege. The runner account has no domain-admin or broad local rights, one session runs per machine, and secrets never reach the model or the evidence.

Sofia, your chief of staff

One private, continuous conversation per person, with a persona the Admin names.
Reads with the person's own permissions; never more.
Visible memory: the person sees what Sofia remembers and can edit or delete it.
Starts workflows (with confirmation) and ad-hoc jobs, which are tracked like any other work. Delegates research to read-only helper coworkers.
Up to 6 attachments per message, plus references to work, workflows and documents.

Build coworkers by asking Sofia Coming soon

Admins can describe a new job to Sofia and get a working coworker back, built from the same parts the Iterabase team uses.

You describethe job in plain words, with a few examples

Sofia draftsa readable workflow definition

You reviewsteps, rules, what it sends, when it asks

Approved, livea new version, kept on record; change it any time by asking

Built from the same blocks as every coworker

Triggers

Steps, waits

Tools

Skills

Credentials

Confirm rules

Building a coworker with Sofia

Brief it like a new hire. Describe the job in plain words, with a few real examples attached. Sofia asks what she needs to know.
A readable workflow definition. Sofia drafts the trigger (mailbox, chat or API), the steps, any parallel branches, waits for replies and deadlines, and the checkpoints a restart resumes from.
Tools from the library. Steps use the release's integration tools and your configured connections: email, documents, portals, the runner. A job that needs a connection that does not exist yet is flagged, not improvised.
Your rules as Skills. Margins, tone, thresholds and exceptions become written instructions the coworker follows, visible in the draft.
Credentials stay write-only. The draft declares the credential slots it needs; an Admin fills them in Settings. Sofia never sees the values.
Consequences declared up front. Every send or submission is marked as a write, and is confirm by default or pre-approved only for recipients you list.
You approve, then it runs. Nothing runs until an Admin approves the draft. Each change is a new version you review, and the previous one is kept.

Microsoft Teams

Each coworker and Sofia is its own Teams app, generated for the customer and installed by their Teams admin.
Users are linked automatically through Microsoft Entra single sign-on.
Coworkers notify and take answers; confirmation cards show the exact content being approved.
A direct message to Sofia is the same conversation as in the app.

The app

Today, Work, Team, Sofia and Reports, in English and European Portuguese, usable at phone width.
Time given back: hours saved are estimated from successful runs × a per-workflow baseline, shown to everyone; the detailed business-value view is Admin-only.
Plan and usage: Admins see their plan, active workflows and usage.

Today: the morning brief, what needs you and what was done — Today: a short brief, the decisions waiting, and the hours given back so far.

Work: every item grouped as Working, Waiting, Needs you and Done — Work: every item by state. A paused item says why and resumes by itself; a failure says plainly that nothing was sent.

APIs

Work API with personal and automation keys, in fixed permission presets.
OpenAI-compatible inference API for the customer's own systems, with model filtering and metered usage.

Trust, security and data

Your data stays in an environment that serves only you, and leaves it only for model calls that are never retained.

Area	What we do
Isolation	One dedicated, single-tenant environment per customer. No shared databases or workers.
AI models	EU-hosted models under written zero data retention; they keep nothing, and nothing trains on your data. Vision-capable. Provider keys are held centrally; your environment connects with its own mutual-TLS identity. Bring-your-own key and local models stay inside your environment.
Sign-in	Email and password, or single sign-on with Microsoft Entra ID or Google. SSO users still need an Admin-approved access request; Admins keep a break-glass password.
Roles	Admin and Operator. Sofia and every coworker read with the authority they were given, never more.
Integration secrets	Entered by Admins against declared slots, stored write-only and never shown, returned or logged.
Support access	SSH over AWS Systems Manager: no open ports, and every session is recorded.
Usage records	Metered and exportable without any message or document content.
Backups	Continuous database log shipping plus daily base backups and a continuous document mirror; 30-day point-in-time restore. Credentials are included, encrypted with a recovery key (AWS KMS for hosted; held by you for self-hosted). After a restore, work that had made writes is held for review.
Leaving	Teardown deletes the whole environment and proves it with a resource sweep. The same recovery tool migrates a hosted environment to self-hosted.

Deployment and buying

Most customers start hosted; the same release can run on your own hardware.

	Hosted	Self-hosted
Where it runs	A dedicated AWS environment we operate, public HTTPS via a network load balancer	A single customer server (x86)
Backups	To our S3, encrypted with AWS KMS	To your S3-compatible storage, with your recovery key
Commercials	From €790/monthFrom $990/month, billed yearly	One-time licence, scoped on the call

Day 0: a call30 minutes, pick the job

Days 1 to 7: we build it, freeYou share access, real examples and one person to check the work

Day 7: it goes livein its own environment

Days 8 to 14: a week of real workSee what it did, what it asked you and the hours it gave back

Day 14: you decidekeep it hosted, self-host, or stop at no cost

The first two weeks

How to start. We build your first workflow for free and have it live in a dedicated environment within a week, then run it on your real work for seven days. If you continue, paused work resumes where it stopped. If you stop, nothing new starts, you pay nothing, and teardown deletes your data.

Plans grow as your team does. We size yours on the call.