AI Agent Business Automations

Intent-based, not brittle coordinate replay — automate SaaS tasks with AI that reads the page, not records the pixels. Updated July 2026.

amux runs business automations as AI-driven browser tasks: pull a daily Stripe payout report, reconcile two dashboards, check insurance eligibility statuses, monitor competitor pricing. The critical difference from traditional RPA (robotic process automation): amux automations describe what to accomplish, not which pixels to click. Each run, the agent reads the current page state and decides actions fresh — it survives UI redesigns, A/B tests, and dynamic content that would break a coordinate-replay script. And because automations run inside the same platform as your coding agents, results hand off directly: a scraper finds bugs, a Claude Code session files PRs.

Why traditional RPA fails and AI agent automation doesn't

The brittle automation problem is old. You record a workflow — click dashboard, select date range, export CSV, rename file — and two weeks later a UI update moves a button 10 pixels and the whole script fails silently. Classic RPA tools from UiPath to Zapier and Selenium scripts share this fragility: they automate the path, not the intent.

AI agent automation flips the model. Instead of recording a path, you describe the goal:

## Goal
Grab yesterday's payout total from the Stripe dashboard.

## Steps
1. Go to https://dashboard.stripe.com/payouts
2. Filter to yesterday's date range.
3. Read the total payout amount.
4. Post it to the amux board as an issue titled "Stripe payout <date>: <amount>".

## Success when
An issue exists on the board with yesterday's payout amount.

Each run, the agent opens the browser in the authenticated profile, reads the current Stripe page — not a recording of it — and decides the action sequence needed to accomplish the stated goal. If Stripe redesigned their UI last week, the agent re-resolves the path. If the date filter moved, it finds it. The plan adapts; the goal stays fixed.

The execution ladder: API-first, vision as a fallback

Not every automation needs a browser. amux automations resolve down an execution ladder, preferring the fastest and most reliable approach that works for each step:

An automation that can use a REST API does — no browser needed. One that can't falls through to the browser vision tier: AI reads the live DOM and accessibility tree, not pixel coordinates. Desktop computer-use is the last resort for native Mac apps with no browser or API alternative, and it requires a physical machine with a screen.

The automation engine caches the resolved plan while the UI is stable and replans on failure — getting the speed/cost of deterministic automation with the resilience of AI.

Composing automations with coding agents — the amux difference

Every other automation tool operates in a silo. Zapier runs your zap and stops. Make.com finishes the scenario and writes to a spreadsheet. The result is disconnected from your engineering workflow.

amux automations are first-class citizens in the same platform as your coding agents. That means:

• A browser automation that finds new crash reports posts them as board tasks — a Claude Code session picks them up and files a PR
• An automation that reconciles billing data detects a discrepancy and sends it directly to a named Claude Code session to investigate and patch
• An automation that scrapes competitor pricing emails a summary via amux's Gmail API integration and creates a board task for the product agent to draft a response strategy

The automation and the coding fleet form a closed loop. No copy-paste, no manual hand-off, no separate tool context to switch into.

What kinds of business tasks are good automation candidates?

Any repetitive web task where the goal is stable but the exact UI path might shift. High-value examples:

Tasks that are not good candidates: one-time actions (write the code instead), tasks that require a human judgment call at every step, or tasks where a direct API does the job — skip the browser agent, just call the API.

How to set up a browser automation with amux

Step 1: Save an auth profile for the target site

Use amux's playwright-auth flow to log into the site once and save the session. From the amux dashboard, navigate to Settings → Browser Profiles and create a named profile for each site you'll automate. After login, Playwright saves the cookies. Every future automation run opens that profile — already authenticated.

Step 2: Write the automation as a plain-English SOP

The SOP is the automation's source of truth. Write it like you'd explain the task to a capable assistant who can see the screen:

## Goal
Check for new denied insurance claims in the payer portal and log each one to the amux board.

## Steps
1. Go to https://provider.payerportal.com/claims
2. Filter to "Denied" status, date range: today.
3. For each denied claim in the results:
   a. Read the claim ID, patient name, denial reason, and amount.
   b. Create a board issue: "Denied claim [ID]: [reason] — [amount]"
4. If no denied claims, create a board issue: "Claim check [today's date]: 0 denials ✓"

## Success when
At least one board issue exists for today's claim check.

## Stop if
A 2FA prompt, CAPTCHA, or login page appears — surface it and halt.

Step 3: Run it via the browser agent API

Send the SOP to amux's browser agent endpoint:

curl -sk -X POST -H 'Content-Type: application/json' \
  -d '{"task":"[paste SOP here]","profile":"payer-portal"}' \
  $AMUX_URL/api/browser/agent

# Poll for completion
curl -sk $AMUX_URL/api/browser/agent/status

Step 4: Schedule it with the amux scheduler

Register the automation to run on your cadence:

curl -sk -X POST -H 'Content-Type: application/json' \
  -d '{
    "title": "Daily denied claims check",
    "session": "automations",
    "command": "Run the payer portal denied claims check SOP",
    "schedule_expr": "daily at 8am"
  }' \
  $AMUX_URL/api/schedules

Step 5: Monitor from your phone

The amux iOS app shows automation run status in real time. Passed runs show a green dot; failed ones show red with the step where it stopped. You get the visibility without being at your desk.

amux automations vs. traditional automation tools

Safety guardrails: what amux won't let automations do

Automations with saved logins and scheduled triggers can cause real damage if they act without appropriate guardrails. amux enforces several non-negotiables:

• Stop on 2FA / CAPTCHA: automations never attempt to bypass authentication challenges — they halt and surface the issue to the dashboard
• Confirm before irreversible actions: any step that submits, sends, deletes, or pays requires explicit allow_irreversible: true in the automation config, and high-stakes targets require per-run human confirmation
• Scoped auth: each automation is bound to one named browser profile — it can't reach sites outside its designated profile's scope
• Visible stop conditions: every automation declares a ## Success when condition — the runner checks it and reports pass/fail clearly, not a silent "completed"
• Dry run: resolve the action plan and preview what the automation would do without executing side-effectful steps

The road ahead: dedicated Automations tab

Today's amux automation stack — browser agent API + scheduler + saved profiles + board integration — enables all the patterns above. The next step, currently in design, is a dedicated Automations tab in the dashboard where you can:

• Create and edit automation SOPs in a Markdown editor (same editor as notes)
• See a list of all automations with last-run status and next scheduled run
• View a step-by-step run log with inline screenshots per step
• Watch a recording of each run (screenshot sequence or MP4)
• Trigger runs manually from the phone with one tap

The underlying platform — browser, scheduler, profiles, board — is already live. The Automations tab surfaces it as a first-class product experience.

git clone https://github.com/mixpeek/amux && cd amux && ./install.sh
amux serve  # → https://localhost:8822

Related guides

• Running 10+ agents in parallel
• AI coding agents overnight
• Custom automation with amux scheduler
• Self-healing agent configuration
• Managing agents from your phone
• amux Concierge — managed automation setup