AbstractOps as Operations Control Plane
Hari Raghavan, CEO of AbstractOps, on the composable enterprise
This shows AbstractOps was already getting paid to solve a painful back office problem, then using that services work as the training ground for software. In practice, the team was handling repeatable HR, finance, and legal tasks across a messy stack of payroll, banking, cap table, contracts, and documents, then turning the most common workflows into product while keeping humans for exceptions and judgment heavy edge cases.
-
The wedge was not replacing every tool. It was sitting above them as a system for company records and workflows. Hari describes AbstractOps as a translation layer across HR, finance, and legal, while Roster separately describes it as an index of company records, distinct from Rippling’s employee record model and Ramp’s transaction ledger.
-
The product shift works because key partners were becoming more programmable. Hari pointed to Mercury as both strong software and API first infrastructure, and Mercury now exposes read and write APIs for accounts, payments, and transactions. Carta also moved toward a developer platform, making cap table data more accessible to partners and downstream tools.
-
This is also why competition with Carta, Mercury, Deel, and Rippling was only partial. AbstractOps owned the cross functional corporation workflow, contracts, payments, stakeholder records, onboarding, compliance, and vendor management, while those partners owned their system of record inside a narrower domain such as banking, payroll, cap table, or employee operations.
The likely end state is a more software heavy operations layer that looks less like outsourced back office labor and more like a control plane for the company. As more partners expose APIs and founders standardize on a smaller modern stack, more of AbstractOps’ manual playbooks can become product, which expands margin, scale, and defensibility at the same time.