# How Iterabase works > Technical overview of Iterabase AI coworkers. Web version: https://docs.iterabase.com/ > Website: https://www.iterabase.com/ · Book a 30-minute call: https://cal.com/nunocgoncalves/30min · hello@iterabase.com > Pricing: hosted from €790/month (EU) or $990/month (US), billed yearly; or a one-time licence to run it on your own servers, scoped on the call. The first AI coworker is built and run for a week, free. ## 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 *Diagram: Coworkers work inside your environment; people confirm what goes out.* Work comes in - Email - App and Sofia - Microsoft Teams ↓ Your dedicated environment - **Workflow runtime**: wait for replies, pause, safe restart - **Document intake**: virus scan, OCR, vision reading - **Managed browsers**: auto login, live login handoff - **People confirm**: every send and submission ↓ Coworkers act on - **Web portals**: scripted submissions - **Outbound email**: confirmed or allowlisted - **Runner in your network**: outbound-only mTLS; files, read-only SQL - **AI models**: EU-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._ ## 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. | *Diagram: Every item shows its true state, and nothing retries silently.* - **New item**: email, chat, API ↓ - **Working**: a coworker is on it ↓ - **Done**: exact copies kept Returns to Working by itself, or once a person acts - **Waiting**: for replies or a deadline; no compute held meanwhile - **Needs you**: confirm, answer, log in, or release a held email - **Paused**: trial ended, model outage or runner offline; resumes by itself Stops for a person - **Failed**: includes 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](https://www.iterabase.com/assets/screens/decide.webp) _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. *Diagram: One step asks three suppliers; every reply finds its way back to the same run.* - **Send step**: 3 requests out, a token in each subject ↓ - Supplier A - Supplier B - Supplier C ↓ replies - **Reply matching**: 1. same email thread; 2. token in subject; 3. sender domain check ↓ - **Run continues**: all or any reply, or the deadline - **Held for review**: ambiguous 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. *Diagram: Every file takes the same path before a coworker reads it.* - Uploads - Email - Runner - Tools ↓ - **Quarantine**: every source, one path in ↓ - **Virus scan**: ClamAV, before anyone opens it ↓ - **Extraction**: Apache Tika and Tesseract OCR ↓ - **Coworker**: reads the text, acts on it ↓ when OCR is not enough - **Vision model**: page 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. *Diagram: The runner calls out; nothing in your network accepts a connection.* Your network - **Runner**: signed Windows or Linux service; stop it to cut access - **File shares**: declared folders - **ERP database**: read-only queries - **Internal portals**: browser on runner ↓ through your firewall: outbound only, mutual TLS Your Iterabase environment - **Workflow runtime**: holds 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. *Diagram: The coworker watches the screen; only scripted actions change data.* Dedicated automation machine, in your network - **PHC, SAP GUI**: or another Windows business app - **Runner**: screenshots and the UI automation tree ↓ observe - **Coworker**: reads the screen with the vision model, decides ↓ decides to act - **Scripted capability**: a 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. *Diagram: Sofia drafts the workflow; nothing runs until you approve it.* - **You describe**: the job in plain words, with a few examples ↓ - **Sofia drafts**: a readable workflow definition ↓ - **You review**: steps, rules, what it sends, when it asks ↓ - **Approved, live**: a 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. ![Sofia in Microsoft Teams, with a quote confirmation card](https://www.iterabase.com/assets/screens/teams.webp) _Sofia in Teams: the overnight summary, then a confirmation card showing the exact email, approved in the chat._ ## 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](https://www.iterabase.com/assets/screens/today.webp) _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](https://www.iterabase.com/assets/screens/work.webp) _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 | *Diagram: Two weeks from the first call to a decision.* - **Day 0: a call**: 30 minutes, pick the job ↓ - **Days 1 to 7: we build it, free**: You share access, real examples and one person to check the work ↓ - **Day 7: it goes live**: in its own environment ↓ - **Days 8 to 14: a week of real work**: See what it did, what it asked you and the hours it gave back ↓ - **Day 14: you decide**: keep 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.