I spend all day thinking about integrations. It’s my day job. Building a single integration is pretty straight forward: read the docs, download the SDK, try the quick start and tweak to your needs. Building hundreds of integrations on the other hand requires defining standards that work across many integrations.

If you take that standardizing process to its most simplest/general extreme, you end up with a sort of App Standard Model. (I tend to think about B2B SaaS apps, but this applies to any consumer apps too.)

An app is really four things:

  • A set of things, objects/nouns, with properties and relationships. Call this the Schema.
  • A set of Workflows for working with those things. Workflows define actions that can be taken on things, and state about those things in the workflows.
  • A Database of all of the instances of your things, their properties, and where they exist in those workflows at any given time.
  • Interfaces to interact with those instances of things within those workflows. A UI for humans to visually interact, and usually also an API for computers to interact with.

This model is interesting because the ecosystem of apps and integrations are a sort of complex adaptive systems. All of the constituents are constantly cooperating and/or competing to solve more users’/buyers’ pain. And all of that energy is spent combining or unbundling these four things.

Canonical Example: Salesforce

For those not familiar, Salesforce is an app that helps sales teams sell things. Salesforce consists of:

  • A set of nouns that matter for sales people. It can store Companies and details about the humans that work at those companies called Contacts. It has objects for products that can be sold. You can even create your own custom things.
  • It also has a number of workflow. Any heavy Salesforce user will know terms like lead and closed win/lost. This is part of the built in workflow for sales people to manage a deal from the start all the way to getting paid. It also has workflows for sales managers to generate reports on how their team of sales people are doing with all of their opportunities, and predict how they will go.
  • It has a UI (which you may have passionate opinions about), and it has many different APIs.
  • And of course all of that is stored in a database.

A lot of what you’re buying when you or your head of sales buys Salesforce is the knowledge and comfort that Salesforce’s specific combination of things, workflows, and their UI/API have a long history of making other companies money successfully.

As part of the wider ecosystem of apps within a business, Salesforce is often the “Single Source of Truth”. Not because it’s the place where everyone in the company does their work, but because so many other applications have integrated directly with Salesforce, reading data from, and writing data back. The gravitational pull of Salesforce distorts the app ecosystem so much that other sales apps can win simply by having great Salesforce integrations, one of the reasons Outreach is seen as a better SDR tool that Salesloft.

A16z: Owning the Workflow in B2B AI Apps

My old colleague, Zeya Yang, wrote an interesting post about AI apps shifting workflows.

They point out that AI’s current default interface is chat. There’s many examples now of chat UX replacing a more annoying/onerous existing process. Though the more impactful opportunity is an AI simply stepping in to do all the work in the workflow on your behalf. He points to Clay’s Claygent which can perform a relatively standard (but hard to script) account research task as the perfect example. Yes, you could have an AI do each step for you, or you could press “go” and have it do all the work.

The post goes further:

One of our favorite thought experiments on the team is to imagine how an AI-powered CRM would manifest. In the most extreme case, an AI CRM would not at all resemble a CRM as we know it today.

Today, we imagine accounts in a relational database, with static objects and fields housing information, and deals moving through pre-defined stages. However, the emerging design of AI-native apps is to ingest all the contextual data (e.g., all sales activities taking place across all SaaS apps) and represent these relationships in embeddings. This allows AI systems to capture nuance and context that’s hard to represent in a tabular or linear mapping. AI features optimized for a relational database, such as automatically populating fields in a traditional CRM structure, may quickly become outdated.

They’re envisioning changes to the other components of the standard model:

  • Generative UI to streamline a sea of forms, tabs, and field/value pairs to show the most important things for a particular customer or deal. Think Meter’s Generative UI, an experiment that could be run today
  • The database has two changes:
    • Some/most is aggregated and indexed from other apps (each themselves individual standard models)
    • It’s structured with graph/semantic meaning, not only rows/columns