C
CONXA

Product docs

Platform Overview

How Conxa turns recorded software workflows into local MCP skills that AI tools can execute reliably.

Updated June 11, 20268 min read

Summary

  • Conxa has three surfaces: Build Studio for recording and compiling, Conxa Cloud for coordination, and the customer runtime for local execution.
  • The cloud hosts packages, installers, billing, team management, LLM proxying, and telemetry. It does not operate customer applications.
  • End users run skills through a local MCP runtime that syncs packaged workflow definitions and executes them on their own machine.

What Conxa does

Conxa turns a human-performed browser workflow into a precompiled skill package. A product team or operations team records the workflow once, reviews the captured steps, compiles the workflow into structured execution data, and distributes it to end users through a branded installer.

The finished skill is exposed to AI tools through the Model Context Protocol (MCP). Instead of asking an AI model to rediscover a product interface on every run, Conxa gives the local runtime a stable execution artifact with selectors, recovery metadata, validation expectations, and update information.

Execution stays local

Conxa Cloud coordinates packages, updates, billing, and telemetry. Workflow execution itself happens on the end user machine through the local runtime.

The three-system model

Conxa is deliberately split so each system has a narrow responsibility.

SystemWho uses itWhat it does
Build StudioSaaS vendor or enterprise builderRecords browser workflows, captures UI context, reviews steps, compiles skill packages, and builds installers locally.
Conxa CloudWorkspace admins and buildersHosts published packages and installers, manages billing and teams, proxies compile-time LLM calls, and stores operational telemetry.
Conxa RuntimeEnd customer or internal operatorRuns as a local MCP server, syncs skill packages, launches Playwright, executes steps, and reports execution telemetry.

This separation matters for privacy and reliability. Build-time artifacts can be improved with AI assistance, while runtime sessions and target-site credentials remain local to the machine that executes the workflow.

Typical data flow

  1. A builder signs in and creates a plugin or workflow in the Build Studio.
  2. The builder records the workflow in a controlled browser session and reviews the captured steps.
  3. The Build Studio compiles the workflow locally into a skill package, using Conxa Cloud only for authorized compile-time LLM proxy calls when needed.
  4. The builder publishes the data-only package and a branded installer to Conxa Cloud.
  5. The end user installs the runtime, which registers with Claude Desktop or another MCP-capable client.
  6. The runtime syncs skill packages from Conxa Cloud, executes skills locally, and sends compact telemetry back for observability.

What the cloud does not do

  • It does not run customer workflows inside Conxa infrastructure.
  • It does not need the end user target-application passwords to execute a skill.
  • It does not receive local browser session files used by the runtime.
  • It does not replace the customer application API or require the SaaS vendor to build a native integration.

The cloud is a coordination and distribution layer. That boundary is a core product property, not an implementation detail.

Who uses Conxa

  • SaaS product teams that want to make their product usable by Claude or other AI tools without building a new integration for every workflow.
  • Enterprise operations teams that want repeatable local execution for browser-based internal work.
  • Automation consultants and internal IT teams that package operational workflows for non-technical users.

Related docs