RPA consulting services exist because of a bot layer. Clone's architecture has zero.

Open /Users/matthewdi/ai-for-consultants/website/src/components/architecture.tsx and read lines 5 through 42. There is a `const layers` array with exactly six entries: You, Clone Planner, Clone Computer Agent, Clone Memory, Your Apps, Your Business. None of those are a bot. Search the file for the word 'bot' and the count is zero. A traditional RPA architecture would have at least four bot-specific layers: Bot Developer tooling, Bot Inventory, Orchestrator, and Attended/Unattended Runners. Clone's runtime collapses those into the Planner and Computer Agent, which are not per-process bots but one reasoning layer that handles every request.

Every line item in a typical RPA consulting SOW maps to a piece of the bot layer. Assessment and PDD drafting produce the bot spec. Bot development builds the bot. Orchestrator setup deploys the bot. CoE stand-up governs the bot. Managed services maintain the bot. Without a bot layer in the target architecture, those line items have nothing to attach to. The engagement structure breaks because the architecture it is designed against does not exist.

Not as a like-for-like competitor. Those products ship a bot-centric runtime: a studio IDE for authoring bots, an orchestrator for deploying them, and a runner pool for executing them. Clone ships a different runtime with no bot concept at all. The overlap is that both end up driving the same target apps (Gmail, Salesforce, SAP, QuickBooks). The difference is what lives in between your intent and those apps. For RPA: a managed bot inventory. For Clone: a Planner plus a Computer Agent plus a Memory layer.

A UiPath bot is selector-bound. When the label on a SAP button changes, the selector no longer matches and the bot halts or writes to the wrong field. The fix is a selector audit, a redeploy, and a change-order invoice. Clone's Computer Agent reads the live screen each run. A relabeled button is resolved by reasoning about the new label, in-context, on the next pass. The same behavior that makes Clone tolerant to UI changes makes the RPA maintenance line item unnecessary.

A CoE is a 3 to 15 person team that exists to govern a bot inventory over time: bot naming, ownership, retirement, exception escalation, quarterly review. The CoE is a service organization built around the bot asset class. Clone does not produce that asset class. There is no inventory to govern, no naming convention to enforce, no retirement policy to write. The reason the CoE is central to RPA consulting services is the same reason it is absent from Clone's architecture.

You type the request into the same chat window you used for the previous processes. The Planner picks the apps, the Computer Agent does the clicks, and the Memory layer reads your existing voice and templates. There is no new bot to author, no new PDD to draft, no new license to allocate, no new entry in an orchestrator. Time to first successful run for a new process is typically minutes, not the 8 to 14 weeks a per-bot engagement takes.

They are fundamental to RPA because the licensing model is per-bot-per-tier. Attended bots run alongside a human user; unattended bots run headless on a schedule. Clone's runtime does not split execution into those two tiers. The same agent handles both cases, and the cost is flat regardless. You do not pay more because a run happened at 3am with no human watching. The tier split is an artifact of the bot layer, not of automation itself.

Zapier has its own category of consulting services and its own failure modes (brittle triggers, branching that has to be wired up per path, no reasoning layer). The RPA category is distinct: it ships a full-stack bot runtime with PDDs, orchestration, and governance. Clone's no-bot-layer argument applies to both but for different reasons. Against Zapier, the missing thing is configured triggers. Against RPA, the missing thing is bot artifacts. Either way, the surface that a consulting engagement is structured to deliver is not present in Clone's architecture.

In the RPA model it grows with inventory. Each new bot is a new license, a new PDD, a new governance row, a new entry in the maintenance rota. Year-two spend typically exceeds year-one build. In Clone's model the curve is flat: $49 per month on Solo, $129 per seat on Boutique, regardless of how many processes the runtime ends up running. The architecture does not produce new managed objects for each new process, so the cost line does not move with process count.

Clone the repo, open /Users/matthewdi/ai-for-consultants/website/src/components/architecture.tsx, and run `grep -c 'bot' architecture.tsx`. The output is 0. Then read the `const layers` array starting at line 5: six entries, three of which are Clone layers (Planner, Computer Agent, Memory) and three of which are your own (You, Your Apps, Your Business). That five-minute check is the whole argument. Every comparable page on this topic describes a bot-centric architecture as if it were the only option.

The Enterprise plan adds SOC 2 Type II, audit logs, SSO, SCIM, bring-your-own-LLM, and on-prem or private cloud deployment. It does not add a bot layer. The runtime is the same runtime. What changes is where it lives (your infrastructure) and how it is governed (your IT's security review, not a CoE bot-governance charter). The architecture.tsx layers do not grow a seventh entry for enterprise.

Run Clone alongside. New processes land in Clone with no bot to author. The existing bots keep running until their next break or their next vendor migration conversation, at which point the real re-platforming economics become visible. The honest migration path is attrition: stop authoring new bots, let Clone absorb net-new processes, and retire old bots as they break or as the apps they drive change enough that a selector refresh is uneconomic. No one-shot cutover required.