For intelligent automation CoEs

Last mile
process automation.

Automating a process that runs twelve times a year costs your team the same fortnight as one that runs ten thousand times a day. That is why it never gets funded. Last mile process automation changes who does the building: a developer sits with the person who runs the process, records it once, and it ships that week, to your standard and on your inventory.

We call our approach to it Guerrilla Process Automation.

Pre-launch. I² Recorder is being built first.

A back office manager leaning back in his chair, looking fondly at a small plush Guerrilla Bots operative standing on his desk. The operative points at a vendor reconciliation spreadsheet open on his monitor while holding a handheld terminal with green status lights, and a second operative works at a keyboard further along the desk.

RPA got as far as
the funding went.

The last mile is the part of a process that no system owns and one person finishes by hand.

1. Sixexports2. Into theworkbook3. Rulesnobodywrote down4. Check it,then sendOut of your systems,and back into them.Data leaves as scheduled extracts andreturns uploaded. What happens inbetween is six exports, one workbookand the rules nobody wrote down.DONE BY HAND, EVERY MONTHThe last mile,closed.She did the job once andit was written down. Nowit replays itself.GUERRILLA BOTSYOURSYSTEMSERP, CRM, emailAUTOMATEDTHE SAMESYSTEMSUploaded backAUTOMATEDTHE LAST MILEONE MONTH-END PROCESS, END TO ENDONE MONTH-END PROCESS
RewindShowing the same month again. Nothing came back.
A drawing of where the work sits, not a measurement and not a screenshot. Guerrilla Bots is pre-launch, so there is no customer result to put here yet.

That is one process. The rest of this page is why it stays that way, and what the recording actually does.

Where the developer
comes in.

A recording handles the clicks. It cannot write a nested rule, decide what an exception means, or say what is fit for production. That is still you.

The code steps. A workflow calls a Python or .NET step where one is genuinely needed. A recording stops at the edge of what it can see. You write what is past that edge.

What Deputy may attempt. You set what it tries on its own before it stops and asks a person, and what it must never attempt unattended.

What ships. You own the standard: what gets promoted out of UAT, what gets refused, and what the CoE is willing to put its name on.

DEVELOPER HOURS ON ONE PROCESSBoth bars are drawn on the same hour scale, so the difference is the picture.RPAThe conventional build1232128Discovery andwalkthroughBuildUAT cycleChange controland handover64developer hoursPlus the wait for a funded slotGPAGuerrilla Process Automation2 hRead back the recording4 hWrite the code steps1 hSet what Deputy may attempt1 hSign off8developer hoursStarts the week it is recorded56 developer hours backOn one process, on thehours above× your own loaded rateWe do not know it, and it isnot ours to guess× every process in the queueWhich is where the numberstops being smallThese are assumptions, not results.Put your own numbers in: the shape is what matters, and the shape is that therecording removes the build, not the governance.On those hours, one developer's month covers the processes that used to take most of a year.The backlog clears without a hire.DEVELOPER HOURS, ONE PROCESSBoth bars use the same hour scale,so the difference is the picture.RPAThe conventional build123212864 developer hours12 hDiscovery and walkthrough32 hBuild12 hUAT cycle8 hChange control and handoverPlus the wait for a funded slotGPAGuerrilla Process Automation8 developer hours2 hRead back the recording4 hWrite the code steps1 hSet what Deputy may attempt1 hSign offStarts the week it is recorded56 developer hours backOn one process, on thehours above× your own loaded rateWe do not know it, and it isnot ours to guess× every process in the queueWhich is where the numberstops being smallThese are assumptions, not results.Put your own numbers in: the shape iswhat matters, and the shape is that therecording removes the build, not thegovernance.On those hours, one developer's month coversthe processes that used to take most of a year.The backlog clears without a hire.
Round numbers for one process, chosen to be ordinary rather than flattering. Guerrilla Bots is pre-launch and has no customer data, so nothing here is measured. The governance work stays in the second bar: the UAT moves to the person who owns the process, and the developer still signs off.

What changes is where your time goes. Today it goes into building each automation, including the ones that were never worth a developer's week. After this it goes into the parts only you can do, across far more processes than anyone could build one at a time.

Building automations today?

Record it once.

You already know the steps. Doing the job one time is the whole of the build.

HOW ONE OF THOSE JOBS GETS AUTOMATEDRecord it once, check what it captured, then let it run and watch it from one place.01RecordI² RECORDERAND DEBRIEFDo the job once, the wayyou always do it.I² Recorder captures thebrowser work. Debriefreads the workbookalongside it and writesdown the rules it finds,including the exclusionsnobody documented.02CheckWORKBENCHRead it back in plainwords. Correct anythingit misread, and mark thesteps that need adecision ratherthan a rule.03RunOPERATIVEOperative coordinatesthe run on the machineyou already use: thebrowser steps, theworkbook steps and thefiles, in order, on theschedule you set,inside the environmentIT approved.04AskDEPUTYThe run is paced andwatched. When a stepneeds judgement,Deputy tries first, and ifit still is not sure it stopsand asks you rather thanguessing. You answerand it carries onfrom there.05WatchVIGILEvery run lands in onehistory, with anexception inbox. TheCoE sees the inventorywithout being asked tobuild or own it.Nothing here starts with a written specification. The recording is the specification,which removes the step that usually takes the weeks.WHERE THE MODEL COMES INClaude reads the recording back.I² Recorder captures the actionsdeterministically; the model turns theminto plain language, and reads theworkbook logic Debrief finds. Deputyuses it to attempt a judgement stepbefore asking you.Default route is Anthropic'sown API.For an enterprise pilot the same modelscan run through Amazon Bedrock insideyour own AWS account and region, so thecall never leaves your cloud boundary.What reaches the model iswhat you are working on:the cell or element in front of you, thevalues you just changed, and the shapeof the workflow. Not the workbook, notfiles at rest, not sign in details.HOW ONE JOB GETS AUTOMATEDRecord it once, check what it captured,then let it run and watch it from one place.01RecordI² RECORDERAND DEBRIEFDo the job once, the way you always do it.I² Recorder captures the browser work. Debriefreads the workbook alongside it and writesdown the rules it finds, including the exclusionsnobody documented.02CheckWORKBENCHRead it back in plain words. Correct anything itmisread, and mark the steps that need adecision rather than a rule.03RunOPERATIVEOperative coordinates the run on the machineyou already use: the browser steps, theworkbook steps and the files, in order, onthe schedule you set, inside theenvironment IT approved.04AskDEPUTYThe run is paced and watched. When a stepneeds judgement, Deputy tries first, and if itstill is not sure it stops and asks you ratherthan guessing. You answer and it carries onfrom there.05WatchVIGILEvery run lands in one history, with an exceptioninbox. The CoE sees the inventory without beingasked to build or own it.Nothing here starts with a writtenspecification. The recording is thespecification, which removes the stepthat usually takes the weeks.WHERE THE MODEL COMES INClaude reads the recording back.I² Recorder captures the actionsdeterministically; the model turns them intoplain language, and reads the workbook logicDebrief finds. Deputy uses it to attempt ajudgement step before asking you.Default route is Anthropic's own API.For an enterprise pilot the same models canrun through Amazon Bedrock inside your ownAWS account and region, so the call neverleaves your cloud boundary.What reaches the model is what youare working on:the cell or element in front of you, the valuesyou just changed, and the shape of theworkflow. Not the workbook, not files at rest,not sign in details.

What reaches the model, and what does not

I² Recorder ships first and Workbench behind it. Nothing on this page is downloadable today, and the flow above is what is being built rather than what is running. Running the models inside your own AWS account is available on request for a pilot rather than switched on by default.

The automation CoE
governs it.

IT approves the environment, once.

Runs on the Windows machine already in use. No new server, no new network path.

Execution stays local. Sign in details never leave the machine, and neither does your workbook. What reaches the model is the step being recorded.

Every run lands in one history the CoE can see.

WHAT LEAVES THE MACHINE, AND WHAT DOES NOTOne approval for the environment. After that, every run leaves the same trace.EXECUTION STAYS INSIDE THIS LINETHE MACHINE YOU ALREADY HAVEOperativeChromeExcelWindows.Alreadyapproved.No new server. No new network path.One run historyEvery run, in one placethe CoE can open.Run history onlySign in detailsThese never leavethe machine.The approval an IT team gives here is for an environment, granted once, rather than for each automation that runs inside it.WHAT LEAVES THE MACHINEEXECUTION STAYS HERETHE MACHINE YOU HAVEOperativeChromeExcelRun historySign in detailsOne run historyEvery run, in one place.One approval for the environment,granted once, not per automation.
The dashed path is the point. An approver wants to know what a new tool opens up, so the drawing shows the route that stays shut alongside the one that does not.
WHERE THE MODEL ISThe automation is deterministic. The model describes it, and never invents it.YOUR MACHINEonly the step you are onClaudeplain words backYOUR MACHINEThe workbookSign in detailsYour filesThese stay on the machine.Not used for trainingYour process contenttrains nothingExecution stays localThe model never touchesyour systemsVoice runs in IndiaAzure AI Speech,Central IndiaOr your own AWS accountAmazon Bedrock,for a pilotPlain language instead of screen coordinatesThe workbook rules nobody wrote down, read backDeputy tries before it interrupts youWHERE THE MODEL ISThe automation is deterministic. Themodel describes it, and never invents it.YOUR MACHINEonly the step you are onClaudeplain words backYOUR MACHINEThe workbookSign in detailsYour filesThese stay on the machine.Not used for trainingYour process content trains nothingExecution stays localThe model never touches your systemsVoice runs in IndiaAzure AI Speech, Central IndiaOr your own AWS accountAmazon Bedrock, for a pilotPlain language instead ofscreen coordinatesThe workbook rules nobodywrote down, read backDeputy tries before itinterrupts you
Only the step in front of you is sent, and the machine it comes back to is the one it left. Claude and Azure AI Speech are what the product calls today. Amazon Bedrock in your own AWS account is available on request for a pilot rather than switched on by default, and Guerrilla Bots is pre-launch, so nothing on this panel is a shipped product.

Same gates. Different clock.

The UAT step stays and the promotion step stays. What changes is who runs them, and how long you wait to reach them.

Who builds itAn RPA developerYou
To startA funded projectAn approved environment
BuildDays to weeksHours
Sign offA queued UAT cycleYou run the UAT
To productionA change requestA recorded promotion
Code stepsThe whole buildOnly where needed
AfterOwned by the CoEYours, in their inventory

Design intent, not a measured result.

Workbench has an advanced mode with branching, variables and code steps in Python or .NET, so a developer touches the part that actually needs a developer.

Where it runs, what leaves the machine, what reaches Claude, and what gets agreed with IT before any of it starts, all set out on one page.

The governance model →

Where it sits.
And why it stays there.

Jobs that live in the last mile

Each one is structured enough to write down and each one is too small to ever reach a developer. If your week has one of these in it, you have found the last mile.

  • Every month, working day three

    The MIS pack

    Three exports out of three systems, pasted into one workbook, refreshed into the summary a director reads. Same shape every month, assembled by hand every month.

  • Every Friday

    The three way match

    Purchase order against goods received against invoice. Most rows agree and take seconds. The handful that do not are the actual job.

  • Weekly, and again at month end

    The bank reconciliation

    Two records that should agree. The work is deciding what agreement means: exact on reference, or amount within a tolerance nobody ever wrote down.

  • Every month, at the close

    The accruals and prepayments schedule

    Last month's reversing journals out, this month's estimates in, then the lot shaped into the journal upload template. Which costs accrue and which get deferred is a convention held in one workbook.

  • Every month, before consolidation

    The intercompany match

    A receivable in one entity against a payable in the other, in two ledgers that never quite agree. The tolerance you may write off, and the rate you translate at, are conventions rather than settings.

  • Every month, before the cut-off

    The payroll input file

    Attendance, overtime, leave and deductions collected from three places and shaped into the one file the payroll system will accept without complaining.

  • Weekly, before the buying run

    The reorder point run

    Stock on hand against the reorder point, less what is already sitting on an open purchase order. The lead time each supplier actually keeps to is a number that lives with the planner rather than in the system.

  • Every settlement cycle

    The marketplace settlement report

    Download the settlement file, separate fees and returns from sales, tie the payout that landed in the bank back to the orders it covers.

  • Every week, off the ageing report

    The collections chase

    The ageing report split into buckets, then a reminder per customer with the right invoices attached. Which accounts get chased this week and which get left alone is a call nobody has written down.

Ordinary jobs, deliberately. The last mile is the work that is too ordinary to get funded.
ALL THE RECURRING WORK IN A BACK OFFICEEvery recurring job in the building, sorted by what it would take to automate it.Already automatedHigh volume, many systems, a real budget behind it. Theautomation CoE built these and watches them.Enterprise RPABuilt and watched bythe automation CoE.The last mileStructured and repetitive. It runs on a schedule and the rulescould be written down. But it is one person for a few hours aweek, so it never clears the funding bar. Ranked correctly, andstill sitting there next year.Weekly or monthlyOne or two systemsOne person owns itTHE LAST MILEStructured. Repetitive.Never worth a developer.Judgment workExceptions, calls, and chasing other people for the thing theydid not send. A person should keep this, and does.Kept by peopleNot a volume problem.Automating it would bethe wrong answer.The bar a CoE applies is volume and criticality, which is the right bar. Work that falls under it is simply unfunded, and stays that way.RECURRING BACK OFFICE WORKEvery recurring job in the building,sorted by what it takes to automate it.Already automatedHigh volume, many systems, a realbudget behind it. The automation CoEbuilt these and watches them.ENTERPRISE RPATHE LAST MILEThe last mileStructured and repetitive. It runs on aschedule and the rules could be writtendown. But it is one person for a fewhours a week, so it never clears thefunding bar. Ranked correctly, and stillsitting there next year.Weekly or monthlyOne person owns itJudgment workExceptions, calls, and chasing peoplefor the thing they did not send. Aperson should keep this, and does.KEPT BY PEOPLEThe bar a CoE applies is volume and criticality,which is the right bar. Work that falls under itis simply unfunded, and stays that way.
The middle band is drawn largest because that is the shape of the split, not because anybody has measured it. Guerrilla Bots is pre-launch and has no customer data to put a number on this.

Every process has one. Too small to fund on its own, and too large to ignore on the last working day of the month.

The ones you had
to say no to.

You ranked them correctly. That is what makes them hard: correct and unresolved are the same thing to the person who raised the ticket.

  • Every one of them was the right call.

    A business case needs volume. Twelve runs a year against a process doing ten thousand a day is not a close decision, and it will not be next year either.

  • None of them go away.

    A declined request is not a closed one. It goes back to being done by hand, and it comes back next quarter with the same numbers.

  • And you never see the hours.

    No system reports them, because no system owns the work. It surfaces as a person who cannot take leave at month end, which reaches you as a resourcing problem.

Six pieces.
One workflow.

  • I² RecorderDo the job once. It writes down every action.
  • OperativeRuns it on the Windows machine you already use.
  • WorkbenchChange a value or a step without recording again.
  • DebriefReads your workbook and states the rules it enforces.
  • DeputyA step fails, it stops and asks you.
  • VigilOne inventory, one run history, visible to the CoE.
All six in detail →

We are picking a small
group to build alongside.

MIS, payroll, accounts payable, bank reconciliation, marketplace settlement. Tell us the process that never made the queue.