An RPA alternative built on AI agents and governed workflows

Robotic process automation records or scripts the clicks and keystrokes a person makes, then replays them. Its strength is reach. If a legacy application has no API, a bot can still operate it through the screen, and the work gets done without anyone touching the old system.

Its weakness is that it follows rules and has no sense of meaning. A bot that expects an invoice number in one place on a page stops working when a supplier moves it. A bot that meets an unusual email has no way to decide what to do except to escalate it to a queue. The result in many organisations is a set of brittle scripts that someone maintains full time.

AI agents are close to the opposite. They read unstructured input, such as an email, a contract or a support message, decide what it means and choose a next step. They do not need the layout to stay the same. In exchange they are less predictable, so the controls around them matter: what the agent may touch, what needs a person to approve, and what gets recorded.

Studio is a visual builder for agents and workflows in one model. A workflow handles the fixed steps and an agent handles the step that needs reading and deciding. You can test the change against a set of known cases before it goes live, release it in stages and roll it back.

Studio connects to more than 100 tools and has an API for systems it does not cover, and any model reachable through the Swfte Connect gateway can be used. Each run is traced, with logs and token-cost telemetry per step, so you can see what the agent read, what it decided and what it cost.

Governance is part of the build flow. Role-based access and human-approval steps in workflows are part of Studio (configurable data-retention policies are designed for, not shipped), and Nexus can apply policy to what an agent is allowed to do while it runs. That is the part of the old RPA estate that is hardest to retrofit: knowing who authorised a robot to do what.

Take supplier invoices arriving by email. A typical bot reads a fixed-layout PDF, copies fields into the finance system and sends anything it cannot parse to a person. A governed agent does the same job differently.

• Can: read the email and attachment, extract the fields whatever the layout, match the supplier and purchase order, and draft the posting.
• Cannot: approve its own payment, change supplier bank details, or touch records outside accounts payable.
• Needs approval: any invoice above the agreed threshold, any mismatch with the purchase order, and any first invoice from a new supplier.
• Records: the email it read, the fields it extracted, the model used, the posting it drafted, who approved, and the outcome.

Do not retire the bots first. A sensible path starts with the bots that break most often, and leaves the rest alone.

• List your bots and mark each by how often it fails and why. Layout changes and unexpected input are the cases an agent handles best.
• Pick one process with a clear owner and a measurable error rate. Rebuild the judgement step as an agent and keep the old bot running beside it for a period, comparing results.
• Keep a human approval on anything with money or customer impact until the record shows the agent has earned more room.
• Leave screen-only steps with the bot. A workflow can call it or hand it work through whatever interface it exposes.
• Retire a bot only when its replacement has run clean on real volume and someone has signed off.

Studio tiers: Free (10 workflows, 5 agents, 2,000 executions per month); Pro $39; Team $99 (3 users included); Enterprise custom. Studio meters executions, and model usage passes through the Connect gateway, so cost tracks the work the model does.

RPA licences are usually priced per robot or per user, and several vendors publish few price points. Compare on the cost of the whole process, including the people who keep scripts alive, not on the licence line. We have not verified current RPA vendor prices for this page, so we do not quote any. Ask each vendor for a written quote on the same volume.

A short list of cases where another tool is the better answer.

• The application has no API and you must operate it through its screen.
• You need a very large catalogue of pre-built connectors. Studio lists 100+ tool integrations, and the largest integration platforms list many times that.
• You need to self-host the product yourself today. Dedicated or private deployment is scoped with Swfte as an engagement, not self-serve.
• You need SAML single sign-on or SCIM provisioning to be generally available. Both are in development.