M cenaly.com
💬 Communications, AI & Records

🤖 Digital worker

A browser AI performer for routine in third-party web systems without an API: a Chrome extension under your session, jobs, confirmations, a log

Documentation

Digital worker

A small business is full of web routine in systems that have no API and never will: confirming bookings in a marketplace back office, copying the same data into supplier forms, ticking the same boxes in a partner panel. You cannot build an integration there — but you can put a worker there.

The digital worker is an AI performer that does such routine in your own browser, under your own account. The model is simple: the Chrome extension is the hands, the cloud is the head. The worker does one step at a time, and what to do next is decided by the server.

Open: Admin panel → Digital worker (admin.cenaly.com/digital-worker). The section is off by default — switch on the "Digital worker" card in the app store.

What this is#

Term What it means
Worker (persona) a named performer account: its own browsers, its own skills, its own channel in the work chat. You can have several — per computer, say, or per area of work
Skill the scenario of one routine: steps, fields, rules. It is data, not code: the skill arrives from the server, so new abilities do not require reinstalling the extension
Risk class the legal regime of the site. Green — automation is allowed, or the action happens on our own surfaces; amber — not explicitly forbidden; red — the site's terms forbid it (Booking.com, Airbnb)
Run one execution of a job: steps, collected values, stops and the reason

The section is run by the owner and the manager. The safety switches — the account stop and the blocked domain list — belong to the owner only; the manager sees an explanation in their place and a Ask the owner button.

What you need to start#

What Why
A computer with Chrome, switched on while the work runs the worker's hands are the extension in that browser; a computer that is off means the worker is offline
Your own account in the target system the worker lives on top of the session you have already opened. It never learns the logins and passwords, and we do not store them
The work chat jobs are assigned as text in the worker's channel, and reports and questions come back there
The right to automate this you are responsible for the target site's terms allowing it: the consent and the acceptance state that plainly
The account's AI balance deciding a step and parsing a job is done by a model — those are paid AI calls of the owner

The first screen of the section is not a list of workers but a consent: "Before you start: what exactly happens". Until it is accepted, the list of personas is not shown at all and a browser cannot be paired either. What it says:

  • our extension will act in your browser under your account — everything it opens and does is performed on your behalf;
  • the worker lives on top of an already open session: it never learns the logins and passwords of target systems, and we neither store nor pass them on;
  • the work is visible and stoppable at any moment — both from this section and from the machine itself;
  • the worker never bypasses captchas, two-factor authentication or bot protection; skills that would need that we do not ship.

If the consent text is updated, you will be asked to confirm it again — that is not a fault.

Step 2. The worker and its browser#

  1. Create a worker — the name is free-form ("Masha's laptop", "Bookings assistant"); it can be edited in place with ✎ and affects nothing but the label.
  2. Connect a browser — the dialog starts with step 0: download the extension archive, open chrome://extensions, switch on "Developer mode" and press "Load unpacked". The extension's privacy policy is right there.
  3. The dialog shows a pairing code and a connection string (it carries both the code and the address of your cloud), plus the same QR — photograph it with a phone to carry it to another computer. Paste the string into the extension.
  4. The dialog notices the connection itself and replaces the code with a green "Connected: …". The code is single-use and short-lived — by then it has been spent.

The worker card shows: paired browsers (each can be revoked), the "Online / Offline" status, the live status — idle, working, needs you, paused — and the counter "jobs in progress: N". Exactly one state is red: "needs you". The same number turns red on the section's menu entry.

A worker can be paused or revoked — revoking is irreversible and instantly cuts off all its browsers. Revoked ones do not pile up in the list: they sit in a collapsed "Revoked (N)" block, and each can be tucked away with Hide (the runs and the conversation stay).

Step 3. Where the skills come from#

A ready-made skill from the store. The "Digital worker" category card in the app store opens an installation wizard: which worker gets the skill, with which parameters (they will travel into the other system's form) and an explicit agreement with the risk class. There are few ready platform skills so far — this is a young section, and today the main path is the second one.

Learning by demonstration. You show the routine once by hand, and the system assembles a scenario from it:

  1. Give the separate consent to recording ("Allow training"): recording only runs while REC is lit; passwords and hidden fields are never written by construction; the voice of your comments goes to the server solely to be transcribed.
  2. Press record in the worker panel in the browser and perform the operation, commenting aloud if you like.
  3. The section shows a training session with the stages "upload → transcription → analysis", and out of it comes a skill draft.
  4. Open the draft: parameters (some marked "from voice"), rules, steps in plain words, linter warnings and the analysis questions — what remained unclear. An answer rebuilds the draft; the worker can ask the same questions in the chat.
  5. Testing up the ladder of trust — a rung cannot be skipped: Shadow run (changes nothing, reports "I would click here") → Co-drive (the worker highlights the target, you click, it verifies) → Attended (it acts itself but asks before every action).
  6. Promote to work — an acceptance dialog opens: with separate checkboxes you confirm that you are entitled to act in those back offices, that you will honour the sites' terms, that you will not bypass protections, that you are responsible for the data entered, that the route is yours, and that the platform may stop the skill on a substantiated complaint. After that the draft becomes a personal skill of your account — nobody else sees it.

If the route breaks on a live site, the worker will ask to be shown the routine again; the draft wizard has Needs another recording for that.

Installed abilities live in the worker card as the Skills block: name, version, risk class, a map-health chip (it appears when there were misses on page elements over the last week). The row's buttons are "Run now", "Dry run", "Change parameters", the "enabled" toggle, "Delete" and "Schedule".

Step 4. Assign a job and watch the work#

Jobs are assigned as text in the work chat: in the worker's channel ("assign to the worker") you write what needs doing — and get an "accepted: …" reply that becomes the root of a thread with the job's status. Step reports are folded under it into an accordion, so a schedule that runs every 15 minutes does not turn the channel into a hundred messages.

What is going on is visible on the Jobs tab (?tab=runs):

  • The status in plain words: queued · working · waiting for your answer · waiting for you · done · failed · cancelled · outcome unknown.
  • Who assigned it, where it came from (chat, schedule, admin panel, test run) and an estimate "usually ~N min" — the median of completed runs of the same skill (with one or two runs no estimate is promised).
  • The Needs attention filter comes first and shows exactly the jobs where the worker is standing still, waiting for a human.
  • Row actions: "Open run", "Open in chat" and "Cancel" (on an unfinished one, with a confirmation — the step in flight will be abandoned).

The run card answers "what is it doing now and why did it stop": the position "step 3 of 7", the trail of what happened, the current step, What the worker collected (fields that look like passwords and codes are stripped by the server before sending) and the reason for stopping in plain words — "the site map is out of date, show me the route again", "a captcha is in the way", "the session dropped", "clicked, but saw no confirmation — please check by hand". The same card holds Done, carry on (after you solved the captcha or signed in) and Repeat the job — a new job with the same parameters.

When the worker runs into a human, it does not stay silent: the browser shows an operating-system notification with an "Open panel" button and repeats the reminder every five minutes, while a "the worker is waiting for you" row appears in the shared to-do queue — next to orders and bookings.

Step 5. Confirming the irreversible#

Where an action cannot be undone, the worker stops and asks. The question arrives as a card in the chat: a summary of the facts, a deadline and "Yes" / "No" buttons. If it is about a list of rows, the rows come with checkboxes and a "Confirm the selected" button. The answer goes into the channel as an ordinary message from you — a decision before an irreversible action must stay in the conversation, with an author and a timestamp.

The "yes" itself is not a word but a bundle of four checks:

Barrier What it closes
A one-time token a second "yes" to the same question no longer works
A fingerprint of the facts you confirm exactly the data you were shown
A deadline the question does not live forever: hours for the green class, minutes for the red one
Re-reading right before writing, the worker re-reads the facts from the page and compares them with what you agreed to; if they differ, it asks again

Who may do what depends on the risk class rather than on a button:

Action Green Amber Red
Ask the worker any participant any participant any participant
Assign a job any participant manager and above owner only
Confirm the irreversible any participant manager and above the owner, and not the job's author

That last cell is the four-eyes rule: whoever already decided "this must be done" skims their own read-back.

Step 6. Schedules and safety switches#

A schedule is set with three forms instead of a cron expression: "every N minutes", "every day at HH:MM", "on selected days at HH:MM". The clock comes from the chosen location. The time you enter is a median, not an alarm: start jitter is mandatory and cannot be switched off, only narrowed — a worker that starts at exactly 09:00:00 is spotted by any analytics on the other side at a glance. There are also quiet hours: a trigger that falls into the window is moved to its end.

The risk class decides what is possible: the red class has no schedule form at all (only a run while you are there), and the amber one warns that background work here happens without you and the risk is yours. Too short a period is refused — each class has its own minimum. A schedule that fails three times in a row switches itself off and says so; a disabled or removed skill puts its schedules to sleep without deleting them — bring the skill back and switch them on again.

Safety switches (owner):

  • Stop all workers — an emergency switch for the whole account: every worker stops at once, jobs are not lost but wait in the queue until the stop is lifted.
  • Blocked domains — a list of hosts the worker will not visit whatever a skill declares. It is stronger than the skill itself and reinstalling the skill does not help.

Limitations#

  • Chrome only, and only on a computer that is on. The extension is still installed by hand in developer mode — there has been no Chrome Web Store release yet. The extension has no QR scanner of its own: the QR is there to carry the connection string to another machine.
  • The section is young. There are few ready platform skills in the catalogue, and we have honestly not measured "how many hours it saves". The real path today is learning by demonstration on your particular system.
  • Bypassing protections is not supported in any form. A captcha, a second factor or bot protection is a polite stop and a request to a human, not a task for the worker.
  • Red sites — only while you are there. For Booking.com, Airbnb and the like there is no background schedule at all, and the branch of the interface that would install such a skill with a schedule simply does not exist. Where an honest API integration exists, we offer that instead of a worker.
  • There are no screenshots of steps. The run card tells you in words what happened but keeps no pictures of the page.
  • A forgotten question does not pile up forever: a run that has waited for a human for more than six hours takes the worker off shift and says so. The "the worker is waiting for you" row in the to-do queue clears itself after a day.
  • A worker belongs to the account, not to a location — which is why its row shows up in the to-do queue of any location.
  • We hold no credentials of yours and never will. If the session in the target system drops, only a human can sign back in.
  • AI calls are paid. Deciding a step, parsing a chat job and analysing a training recording spend the owner's AI balance; with an exhausted balance the worker cannot decide a step.
  • Training voice is transcribed in the cloud of the brand you work in and is kept exactly until the transcription is done; training without a microphone is valid too — there will simply be more questions for you.

Troubleshooting#

Symptom What to check
The extension says "code not found" paste the whole connection string, not just the digits of the code: it carries the address of your cloud. The code is single-use and lives for minutes — take a "New code"
The worker is "offline" the browser is closed or the computer is off; check that the worker panel is open and on shift (the panel can come up together with Chrome)
A red "needs you" chip a captcha, a dropped session, a second factor or a missing site permission. Do it by hand in the same browser and press "Done, carry on"
"The site map is out of date" the target site changed: show the routine again ("Needs another recording" in the draft wizard) and the route will be rebuilt
The skill is on but no job is taken the skill's toggle is off, the skill was removed, or the extension has no host permission — the panel says "Skill 'X' needs access to …" with an "Allow" button
A schedule switched itself off the reason is written in the row: three failures in a row, the skill is disabled or removed, the worker was revoked
A job from the chat is rejected the risk class does not let this role assign it: amber needs a manager or above, red needs the owner
The status is "outcome unknown" the worker clicked but saw no confirmation. Check by hand whether it went through: it will not retry on its own
All workers are standing still the account stop is on — lift it in the card at the bottom of the section (owner only)

A symptom-by-symptom guide is in troubleshooting; if nothing helped, write to us — how to get help.

FAQ#

Do I have to hand the worker a login and password to another system?#

No, and that is the main difference from "robots" that are handed credentials. The worker acts on top of a session you opened yourself, in your browser. It never sees the passwords, and we neither store nor pass them on.

You are responsible for the target site's rules allowing such actions, and we make that question visible: every skill has a risk class, every irreversible action has your confirmation, and before running your own trained skill you sign an acceptance of responsibility. Bypassing captchas and bot protection is not supported in any form.

How is this different from an integration?#

An integration talks to the other system through an API — fast, reliable and without a browser. A worker is for places where there is no API at all. If a site has a decent API, we build an integration rather than a worker.

Can I just tell it anything in words?#

The worker does what it has been taught: a job from the chat is parsed into a run of an installed skill with parameters. "Do something useful" it will not perform, and it will honestly say it has no such skill.

Does the computer have to be switched on?#

Yes. The worker's hands are the extension in the browser on your machine; a computer that is off means "offline", and jobs simply wait in the queue.

How many workers can I create?#

As many as you need — one per computer, for example. Choose the persona's name so that the to-do queue tells you which machine to walk to.

What if the worker makes a mistake?#

It does not perform an irreversible action without your "yes", and at an unclear point it stops and calls a human. Everything it did is in the run card: the steps, the collected values and the reason for stopping.

Who can press "stop"?#

The owner and the manager can pause a worker; the account stop and the blocked domain list belong to the owner only. A paired browser can also be revoked from the machine itself.

Was this article helpful?
Documentation
Guest demo menu Open this screen in the demo Start free