The future of software is software that bends to the user, not the user bending to software.

Before AI, users of a piece of software all interacted with the same interface. Customizations were light — a few different views, a theme, maybe a colour. When users think about "personalization" on Netflix, the layout is the same for everyone, just with different imagery. The result is software that has a one-sized-fits-all feel, rather than being hyper-customized to a user.

The exception, historically, has been enterprise software — where forward-deployed engineers customize the product per customer to make it land. Most enterprises end up paying for that work, one way or another. Most don't get it.

The SAP failure mode

Every fund manager we talk to has scar tissue from this. They've seen SAP rollouts fail. They've watched eFront, Allvue, Carta ask their team to bend the way they do FundOps, LP CRM, transactions, and reporting to fit the software's model. They paid for it anyway, because the alternative — a custom-built internal tool maintained by one over-extended ops person — was worse.

Software that requires customers to change behaviour does not scale. It fails. It has always failed.

Coding agents change the cost basis of customization

Coding agents have now gotten good enough that the forward-deployed-engineer model can be inverted. Instead of one FDE customizing the product for one customer, an AI agent can absorb the customer's existing workflow — their bespoke waterfall model, their hand-rolled covenant rules, their idiosyncratic LP reporting cadence — and bend the platform to fit it.

The fund manager doesn't redesign their software. They keep doing what they've been doing for the last decade. The software changes shape around them.

A private credit fund in Mexico has a custom waterfall model built from a trust deed, a hedging model, and a projection model — all in spreadsheets. They want deal monitoring on top of those. They want to use Mexico's centralised banking system (the SAT) as a data source instead of bank statements. They want real-time underwriting that uses their own rules, not a vendor's. They don't want to redesign a UI. They want a system of record that meets them where they are.

A US-based emerging-manager VC wants their LP CRM to mirror the way they actually run fundraising — quarterly check-ins, multiple meeting threads per LP, follow-ups pinned to specific commitments. They don't want to learn another vendor's way. They want their way, automated.

Both are the same product. Different shapes. The same primitives — agents, modules, connectors, a system of record — assembled by AI to fit each customer's existing workflow.

The three jobs

Fund Operations Automation. Reconciliation files from the prime broker are mapped by AI, every break gets a root-cause classification, settlement fails surface with CSDR penalty estimates, NAV closes run an 8-step workflow with three human sign-off gates. The ops person who spent Monday reconciling spends Monday reviewing.

Allocator & ODD Automation. When an LP sends a DDQ, the answer bank drafts 80% of it from prior responses. The due-diligence data room gets assembled from the deal files already in the system. The follow-up email writes itself from the meeting notes. The allocator-facing work that piled up gets processed before the 9am call.

Governance & Audit Evidence. Nothing executes automatically. Every AI-proposed action — amend a trade, send a DK, accrue a fee, advance a deal stage — lands in an approval queue. The GP clicks Approve. The action logs to an immutable event stream with a timestamp and a cost trace. When the auditor asks, the answer is already there.

What this means for software companies

To enable this, the whole stack of software delivery has to be rethought. How does a developer ship software that's accessible to a customer's coding agents? Do they deliver source code rather than packaged binaries? Can agents only modify front-end visual elements, or are there ways to modify middleware and data flow on the fly to enable the interesting use cases? How do shared primitives ship with full intention that they will be heavily modified per customer, while still upgrading cleanly?

These are open questions. We're answering them at Kela by treating our product as a system of record plus a set of primitives — FundOps modules, an agent runtime, MCP, connectors, dashboards, an answer bank, retrieval — that AI can compose against each customer's actual workflow.

AI should meet customers where they are today, not change their behaviour. Otherwise it fails like most SAP implementations do.