The suite

Six products.
One workflow.

One recording becomes a file, the file gets edited, the file runs on a machine, and everything that happens to it after that is watched and recoverable. These are the six pieces of that, what each one is responsible for, and what each one deliberately is not.

Everything on this page is pre-launch. Nothing here is downloadable or purchasable today, and no product on this page has run in a customer environment. This describes what is being built and in what order.

I² Recorder is first, with Operative alongside it because a recording has to run somewhere. Where a description below says a product does something, read it as the behaviour being built rather than behaviour already shipped.

Build order

Five in sequence, and the one underneath them.

01I² Recorder02Workbench03Debrief04Deputy05Vigil

Operative is not a step in that sequence. It is the desktop agent the sequence runs on, so it is being built alongside I² Recorder rather than after it. The order is not a roadmap with dates on it. It is the order in which each piece stops being the thing blocking the one after it.

Chrome extensionIn build. Ships first.

I² Recorder

Records the browser work you already do.

You do the job once, the way you always do it. I² Recorder watches the browser and writes down what happened: the navigation, the click, the field you typed into, the download you waited for. Each action gets a plain language label, so the recording reads as a description of the process rather than a list of screen coordinates.

What comes out is a .gbw file, a zip holding the workflow definition and any code attached to it. It is a document you can open, read and correct. That matters more than it sounds like it should, because the thing that has to be reviewed before an automation is allowed to run is the automation itself.

On replay it matches an element by what it is rather than by where it sat on the screen the day you recorded. A layout change is the most common reason a recorded automation quietly dies, and matching on meaning is the defence against it.

What it does

  • Records clicks, typing, navigation and waits in Chrome
  • Labels each action in plain language as it goes
  • Writes a portable .gbw workflow file
  • Replays by matching elements rather than screen positions

What it does not

  • Record desktop applications. It is a browser recorder, and it says so.
  • Bundle sign in details into the file. A workflow carries a reference, never a key.
Desktop agentIn build.

Operative

The local agent everything actually runs on.

A workflow has to run somewhere. Operative is that somewhere: a Windows tray app and a background service that replays a .gbw on the machine the person already uses, over the network access they already have. No new server, and no new thing for IT to stand up before anyone can start.

It also handles the local file work, and the bridge between the Chrome extension and the machine. Sign in details stay on the machine and a workflow refers to them, rather than carrying them.

Versioning is a snapshot, not a branch. Every save writes a timestamped copy and the last twenty are kept, so rolling back means opening an older file rather than running a release process. For work at this size that is the right amount of machinery, and anything more would go unused.

What it does

  • Replays .gbw workflows locally on Windows
  • Bridges the Chrome extension to the machine through native messaging
  • Reads and writes local files as part of a run
  • Keeps a timestamped snapshot on every save, last twenty retained
  • Keeps sign in details on the machine, referenced by a workflow rather than stored in it

What it does not

  • Need a new server or a new piece of infrastructure.
  • Share workflows between people. Portability covers moving your own work to a new machine.
Workflow editor, cloud serverNext in the build order.

Workbench

Change the automation without recording it again.

A recording is a first draft, and something is always slightly wrong. A step in the wrong order. A value that should come out of a cell instead of being typed. A wait that is a second too short on a slow morning. Workbench is where that gets fixed, and the point is that fixing it does not mean doing the recording again.

Simple mode is for the person who recorded it: change a value, reorder the steps, point a step at a different field. Advanced mode is for a developer: branching, variables, validation rules, conditional paths, and code steps in Python or .NET where the logic genuinely needs code.

That split is the economic argument in one screen. The practitioner does the eighty percent that is just steps. A developer, when one is available at all, touches only the part that actually needs a developer.

What it does

  • Edits a recorded workflow step by step
  • Simple mode for the practitioner, advanced mode for a developer
  • Branching, variables and validation rules
  • Code steps where the logic needs them

What it does not

  • Try to be a general purpose IDE.
  • Require a fresh recording every time a process changes.
Excel intelligenceSpecified. Not built.

Debrief

Reads the workbook and states the rules it is already enforcing.

In a back office, Excel is not a file format. It is where the business logic lives. A nested IF deciding whether a difference is a match or an exception, and nobody remembers who chose the threshold. A VLOOKUP into a mapping tab somebody maintains by hand, sometimes. A red fill that means checked and genuinely wrong, next to an amber that means not checked yet.

None of that is documentation and all of it is the specification, written in a language never meant to be read as one. Debrief opens the workbook and works out what process it represents from the structure: sheets, headers, formulas, lookups, named ranges, conditional formats. Then it asks about what it cannot infer, while you work, and lets you answer by pointing at a cell.

What comes out is a stated, reviewable description of the rules the workbook enforces. That is worth having even if you never automate anything. One thing to interrogate here, in this tool and in every other one: a workbook's logic is in its structure and the sensitive part is its values, and those two are separable. Always ask which of them leaves the machine.

What it does

  • Reads structure: sheets, headers, formulas, lookups, named ranges, conditional formats
  • Asks about the rules it cannot infer, in the middle of the work rather than in a workshop
  • Produces a written statement of the rules that a person can review and correct

What it does not

  • Remove the need for a person to confirm the rules. It changes who confirms them, and when.
  • Guess at an ambiguous rule and carry on. Ambiguity gets flagged.
Human in the loop recoverySpecified. Not built.

Deputy

When a run hits something it cannot handle, it stops and asks.

Manual work has a person looking at it who notices when a total looks odd. Automation removes the person and, unless somebody designed for it, removes the noticing too. A silently wrong number is worse than a visible failure, and it is the failure mode that ends trust in an automation permanently.

Deputy is the design for it. A step fails, AI attempts a recovery first, and if that does not work the run pauses at exactly that point. A person fixes the one step and the run continues from where it stopped rather than from the beginning.

Every pause and every fix is recorded, so an exception becomes a piece of history rather than a message somebody remembers getting. That record is also what makes the next fix faster.

What it does

  • Attempts an AI recovery on a failed step
  • Pauses and hands over to a person when the retry does not work
  • Resumes from the point of failure rather than the start
  • Records every exception and every fix

What it does not

  • Make the business judgment for you. It brings the decision to a person.
  • Carry on past a failure it did not resolve.
Monitoring and governance, cloud serverSpecified. Not built.

Vigil

The view a CoE gets without having to ask anyone for a status update.

The governance gap in a decade of citizen development was never the tools. It was that nothing owned the automation after it was built. No inventory listing it, no version history, no exception queue, no owner, and the person who built it has moved teams. IT finding out it exists for the first time during an incident is exactly the experience that makes IT hostile to the whole idea, and reasonably so.

Vigil is the answer to that. Every workflow in one inventory with an owner against it, every run in one history, every exception in one queue. The practitioner keeps building. The CoE and IT get a place to look, from day one rather than after the first incident.

This is the piece that turns adoption by one team into something an organisation can formally stand behind, which is the entire shape of the company.

What it does

  • Inventory of workflows and who owns each one
  • Run history with outcome and duration
  • Exception inbox
  • Audit trail across runs, failures and fixes

What it does not

  • Build or edit automations. That is Workbench.
  • Sit between a person and their own work as an approval step per run.
What actually gets installed

Three pieces, not six.

The six names above are products. They ship inside three things, and three things is what an IT approver is actually being asked to look at.

01

The Chrome extension

I² Recorder lives here: the recording controls, the capture of what the page actually is, and the overlays you see while you work. It installs from the Chrome Web Store, which is the distribution channel most IT departments already have a policy for.

02

Operative, on the machine

A Windows tray app and a background service. It runs the workflow, does the local file work, holds the bridge to the extension, keeps the version snapshots, and keeps sign in details on the machine rather than in the cloud.

03

The cloud server

guerrillabots.com. It hosts Workbench and Vigil, the AI calls, accounts and billing. It has no product name of its own because it is infrastructure. What reaches it is the workflow definition, not the portal content and not your figures.

The file in the middle of all of it is a .gbw. A zip holding workflow.json plus any code files the workflow uses. It is readable, reviewable and versioned by snapshot: Operative writes a timestamped copy on every save and keeps the last twenty. Workflows carry references to sign in details, never the details themselves, and they are built for one person moving to a new machine rather than for sharing around a team.

Early access

None of this is buyable yet.

Early access opens in small batches, starting with I² Recorder. Tell us what you do and what you would automate first, and that answer goes straight into what gets built next.

Back to the homepage