Linear #159: Connective Tissue Startups in the AI Age, Who Wins? System of Action OR System of Record
One vSaaS breakdown. One biz story. One 'how to'. In your inbox once a week.
Today’s newsletter is sponsored by Xplor Pay, a full-service payment provider. They make it simple for software companies to accept payments, enhance the customer experience, and boost revenue. Their flexible partnerships, including PayFac as a Service, are structured to help SaaS providers scale with confidence and streamline their payments operations.
Learn more at xplorpay.com
Alright, let’s get to it…
This week, we’re diving into three meaty topics that every vSaaS founder needs to be thinking about: a construction API business that’s quietly becoming critical infrastructure, why “connective tissue” startups are the non-consensus opportunity of the AI age, and the heated debate between Systems of Record vs. Systems of Action.
Grab your coffee. This is a good one.
Agave is Building the Connective Tissue for Construction Tech
Most people have never heard of Agave. But if you’re building anything in construction tech, their name might be on your radar.
These folks raised a $2.9M seed round back in August 2023—led by Accel, with Y Combinator as their accelerator—to solve one of the most persistent problems in construction software: nothing talks to each other.
Here’s the setup. Construction is a $12 trillion global industry that’s been notoriously slow to digitize. Over the last decade, that’s changed. Construction companies have gone from zero software to five, ten, sometimes fifteen different systems running their operations. Procore for project management. Foundation or Viewpoint for accounting. Autodesk for design. ServiceTitan for trade contractors. Sage 300 for financials. The list goes on.
And none of these systems talk to each other. At least not easily. When your field teams want to see real-time budget data in Procore, but your accountants live in Sage 300, that’s hours of manual data entry. Every. Single. Day.
What Agave Built
Agave built a unified API that connects 30+ construction software systems. One integration, access to everything. They didn’t just build a generic API aggregator—they built data infrastructure specifically for construction workflows. They understand that a “timecard” in one system needs to map to “labor costs” in another. That “project budgets” need to flow bidirectionally between PM tools and ERPs.
The numbers they share on their site are solid: 2.6 million expense records synced, 900,000 job cost transactions, 560,000 timecards. That suggests real usage, not just tire-kickers.
But Here’s Where It Gets Interesting
The employee data on Agave tells an interesting story. According to Tracxn, they had 6 employees at the end of 2022. PitchBook reports 31 employees, while other sources suggest they’re closer to 40-42 people now. Let’s assume they’re somewhere in the 30-40 range as of late 2025.
That means they went from 6 people to 35+ people in roughly three years. That’s meaningful growth—you don’t 6x your team if things aren’t working.
So what does that tell us?
One interpretation: the problem is harder than it looks. Building and maintaining 30+ integrations in construction—where many systems have terrible APIs or no APIs at all—is brutal engineering work. Maybe they need more engineers than salespeople right now because they’re still building foundational infrastructure.
Another interpretation: they’re being disciplined and capital-efficient. With $2.9M in seed funding (actually reported as $3.4M total across two rounds), they’re probably trying to stretch that capital and prove the model before raising a big round.
That could mean a few things. Maybe they don’t need it yet and are cash-flow positive or close to it. Maybe they’re building the product foundation before scaling GTM. Or maybe they’re finding it harder than expected to get customers to pay meaningfully for integration infrastructure.
The Go-to-Market Puzzle
What’s interesting about Agave is they’re selling to both sides of the market. They sell directly to contractors who want their systems to work together. But they also sell to software vendors who want to offer integrations without building them all themselves.
That’s smart in theory—dual distribution with network effects. The more contractors use Agave, the more software vendors have to integrate. The more vendors integrate, the more valuable it becomes to contractors.
But here’s the challenge: who actually pays, and how much? Contractors are notoriously price-sensitive and slow to adopt new technology. Software vendors might view this as a cost center rather than a revenue driver. The value proposition is clear—save hours of manual work—but capturing that value in dollars is the hard part.
I LOVE connective tissue plays, but they have always taken time. This is hard engineering work paired with tough biz model.
But when companies figure it out (IE Clever) they can become the industry standard and get very big. That’s my hope for Agave here.
The Competitive Landscape Nobody Talks About
Agave isn’t alone here. The construction integration space is getting attention. And you’ve got to ask the uncomfortable question: will one of the big players—Procore, Autodesk, Oracle—just build this themselves?
Procore already has an App Marketplace with integrations. They could theoretically unify that into a developer platform. Autodesk has been consolidating their construction products under Autodesk Construction Cloud. Oracle owns a bunch of construction ERP systems. If any of them decide integration infrastructure is strategically important, they have the capital, the distribution, and the customer relationships.
On the flip side, Agave’s neutrality could be their moat. They’re not competing with any of these systems—they’re Switzerland. That might matter to vendors who don’t want to integrate through a competitor’s platform. But it’s also possible that neutrality isn’t enough if the big players offer “good enough” integration for free.
Why This Will Work
Construction operates on razor-thin margins—3-5% net in many cases. Eliminating hours of manual data entry isn’t a nice-to-have when you’re operating at those margins. It’s the difference between profitability and going out of business.
The TAM is massive. Construction software is only about 25% digitized. As more companies adopt multiple systems, the integration pain only gets worse. Agave could be positioning themselves at exactly the right moment—after the first wave of construction tech adoption, but before the big players consolidate.
And there’s genuine IP here. Building connectors for legacy construction systems—many of which have SOAP APIs from 2005 or worse—requires deep domain knowledge. That’s defensible in a way that connecting modern REST APIs isn’t.
Why This Might Not Work
API integration businesses are notoriously hard. You’re essentially signing up for infinite maintenance work. Every time Procore or Autodesk or Sage changes their API (which happens constantly), you have to update your integrations. Every edge case, every custom field, every quirky data structure—that’s on you to handle.
The unit economics question looms large: how much can you charge for this? If contractors won’t pay much and software vendors see you as a feature not a product, your ACV might stay low. And if your ACV is low, you need massive scale to build a venture-scale business.
The Honest Take
Look, Agave is trying to build something genuinely hard. The problem is real—anyone in construction will tell you the integration pain is brutal. They’ve got smart investors (Accel is a top tier fund). They’re executing methodically, growing from 6 to 35+ people over three years.
The next 6-12 months will be telling. If they close a strong Series A and accelerate hiring to 100+ people, they could become the standard infrastructure layer for construction. If they stay at this pace, they might end up as a nice acquisition target for one of the big players—good outcome for founders and investors, but not the “own the infrastructure layer” outcome.
Or maybe—and this is the contrarian take—they bootstrap their way to profitability and build a solid business that throws off cash and doesn’t need to play the VC game. There’s nothing wrong with that outcome, even if it’s not what Accel was underwriting.
Either way, it’s worth watching. Because if Agave or someone like them cracks this, they won’t just be a nice tool. They’ll be the nervous system that makes the entire construction tech ecosystem function.
What do you think—is infrastructure the play here, or will the big incumbents just bundle this into their existing products?
The Contrarian Case for Connective Tissue Startups in the AI Age
Here’s a question I keep coming back to:
Are “connective tissue” startups about to become way more valuable, or are they about to get completely disrupted by AI?
I’m talking about companies like Agave (construction) and Clever (education)—the API integration layers that sit between systems and make data flow. The unsexy middleware that nobody thinks about until it breaks.
Most people I talk to think AI will make these companies obsolete. The logic goes: AI agents will just “figure out” how to connect systems. They’ll write their own API calls, handle authentication, normalize data on the fly. Why would you need a middleware layer when AI can do it all?
I think that take misses something important. But I also think the bull case for connective tissue companies isn’t as obvious as people make it sound.
Let me walk through both sides.
The Bear Case: AI Makes Integration Companies Obsolete
Let’s start with why connective tissue companies might be in trouble.
AI agents are getting really good at API orchestration. Tools like LangChain, AutoGPT, and various agent frameworks can already read API documentation, write integration code, test it, and handle basic error cases. If you’re a developer who needs to connect two modern SaaS products with clean REST APIs, you can probably prompt an AI agent to do it for you in the next 12-24 months.
If that becomes reality, why would anyone pay for an integration layer? Just point your AI agent at the systems you want to connect, give it API credentials, and let it figure out the rest. No monthly subscription to Merge or Finch. No integration setup. Just natural language: “Hey Claude, sync our Procore data with Sage 300 every night at 2am.” This isn’t a reality though in most industries, only with generic SaaS tools that have their API’s well documented.
AI agents could potentially handle that maintenance too. If an API changes, the agent adapts. If there’s an error, it debugs and fixes it.
The third problem: incumbents might just solve this themselves. If you’re Procore or Salesforce or Oracle, you already have massive engineering resources. Building a unified API platform isn’t technically impossible—it’s just a lot of work. If you decide it’s strategically important, you can build it. And you have distribution advantages that startups don’t. You already have the customer relationships. You can bundle integration for free or near-free.
Plaid’s near-acquisition by Visa for $5.3 billion (before regulators killed it) shows that incumbents are thinking about this. If the big players decide integration infrastructure is a strategic control point, they have major advantages. Vertical industries typically move slower than the “tech world”and can usually follow proven playbooks by massive companies.
The Bull Case: AI Makes Clean Data Pipes MORE Valuable
Now let me make the opposite argument, because I think it’s actually stronger than people realize.
AI agents need clean, structured, real-time data to make decisions and take actions. They’re only as good as the data they can access. Right now, most company data is fragmented across 10-20 different SaaS tools, each with its own data model, authentication scheme, rate limits, and quirks.
An AI agent can’t just “figure it out.” Sure, it can read API documentation and write code. But can it handle the reality of production integrations? When Procore’s API goes down mid-sync? When Sage 300 has a field that means something completely different than the similarly-named field in Foundation? When you hit rate limits and need to implement exponential backoff? When one system uses OAuth 2.0 and another uses API keys and a third uses SAML?
That’s not a prompt engineering problem. That’s years of accumulated domain knowledge about how these systems actually work in production.
Here’s where it gets interesting. Connective tissue companies don’t just move data—they normalize it. They understand that a “timecard” in one construction system needs to map to “labor costs” in another, that “employees” and “contractors” have different field structures, that dates might be in different formats. They handle all the boring, critical infrastructure work that AI agents would struggle with.
And that becomes MORE valuable in an AI world, not less. Because now instead of just helping humans integrate systems, you’re providing the clean data pipes that AI agents need to actually function.
The Hidden Opportunity: From Plumbing to Intelligence
But here’s where the real opportunity lies, and why I think this is genuinely non-consensus.
Most founders think of connective tissue companies as infrastructure plays. Build the API layer, charge for API calls or seats, scale up, exit. That’s the playbook.
I think that’s the wrong endgame.
The real opportunity is Connective tissue companies may be the most suited to build industry-specific agent platforms.
Iimagine being Agave with construction data from thousands of projects. You could build AI that:
Predicts which projects will go over budget with scary accuracy
Recommends optimal resource allocation based on similar projects
Identifies procurement savings opportunities by seeing pricing across contractors
Flags schedule risks before they cascade
The connective tissue layer doesn’t just move data. It becomes the smartest product in the vertical, because it has visibility that nobody else can replicate.
Where This Works (and Where It Doesn’t)
I don’t think every vertical supports a connective tissue company. And I don’t think every integration problem is worth solving this way.
Connective tissue companies probably win when:
The data model is complex and domain-specific. Construction workflows, healthcare records, legal documents, manufacturing processes—these have tons of nuance. Generic AI agents will struggle. A “timecard” means different things in different construction systems. Mapping these correctly requires deep domain expertise that takes years to build.
There are 5+ major incumbents with terrible APIs. If you’re integrating modern SaaS products with clean RESTful APIs, AI agents can probably handle it. If you’re integrating legacy construction ERP systems with SOAP APIs from 2005 (or worse, no APIs at all and you need to screen scrape), you need humans who’ve built connectors for every edge case.
Real-time reliability matters. If dropping a few records is fine, AI can probably wing it. If you’re syncing payroll data where mistakes mean employees don’t get paid, you want infrastructure built by experts who’ve thought through every failure mode.
Compliance and security are critical. Healthcare, finance, legal—industries where data handling has regulatory requirements. Generic AI agents won’t know HIPAA compliance rules or SOC 2 requirements. Specialized middleware companies will.
The vertical is fragmented and unlikely to consolidate. If there’s one dominant player who’s going to eat the whole market, they’ll probably build integration themselves. If there are 5-10 strong players who all hate each other, neutrality becomes valuable.
Connective tissue companies probably lose when:
The systems being connected are modern and API-first. If you’re connecting Stripe to Slack to Notion, AI agents can probably handle that without middleware. The APIs are well-documented, the errors are clear, the authentication is standard.
The integrations are too one-off or custom. If you need a weird workflow that only your company uses, paying for a platform might not make sense.
The incumbents decide integration is strategic. If Salesforce or ServiceNow or Procore decide CRM/FSM/construction integration is a must-have and bundle it for free, startups have a problem. Competing with free is hard.
The vertical is too small. Building connective tissue infrastructure is expensive. You need engineers who understand the domain. You need to maintain dozens of integrations. If the TAM is $50M, that’s not a venture-scale business.
The Honest Truth
Building a connective tissue company is very hard. You’re signing up for infinite maintenance work. Every API change is your problem. Every edge case is your problem. Every quirky data structure is your problem.
The economics are challenging. Customers might not want to pay much for “plumbing.” You’ll constantly battle the perception that you’re just infrastructure.
The competition is real. Incumbents can bundle integration for free. AI agents are getting better at one-off integrations. Other startups are raising capital to go after the same opportunity.
But if you pick the right vertical, build genuinely great infrastructure, and evolve into the agentic layer, you could build something incredibly valuable. The companies that own the data pipes in an AI world will have a strategic position that’s hard to replicate.
The question is whether you believe AI makes integration easier (bear case) or makes high-quality integration infrastructure more valuable (bull case). I honestly don’t know the answer. But I think it’s one of the most important questions in vSaaS right now, and I think more founders should be thinking about it.
Quick question - want to join a slack group with other vSaaS founders/operators? No noise just all signal / supporting one another.
Fill out this form and we’ll get you added.
System of Record vs. System of Action—Can You Win Without Owning the Data?
This is probably the most important strategic question in vSaaS right now, and I don’t think anyone has a definitive answer yet.
The question: Can you become the “System of Action” without being the “System of Record”?
Or put differently: If you don’t own where the data lives, can you still own where the work gets done?
Big shoutout to David Yuan and Tidemark for crystallizing this framework in their essay “The Race to Become the System of Action.” After reading it and talking to a bunch of founders, I’m still not sure which side wins.
Let me break down both sides, because both have real merit.
First, The Definitions
System of Record (SoR): The authoritative source of truth for critical data. Where data is created, stored, and maintained. Your ERP, your CRM, your practice management system, your EHR.
System of Action (SoA): Where humans and AI actually DO things. Where decisions are made and actions are triggered. Where the “work” happens, not just the recording of work.
The shift that’s happening: Software used to help you RUN your business. Now AI can help you DO the work itself. And those might be different products.
The Old World vs The New World
In the old world, System of Record and System of Action were the same thing. Your construction ERP both stored your data AND was where you did your work.
In the new world, those are splitting apart. AI transcription tools let doctors do clinical documentation without typing into the EHR. AI scheduling assistants book meetings without touching your calendar. AI underwriting tools make lending decisions without being the loan system.
Which one wins? The place where data lives, or the place where work gets done?
The Case for “You NEED System of Record to Win”
Data gravity is the ultimate moat. If you own the source of truth, switching costs are massive. Nobody wants to migrate years of historical records.
If you’re the System of Record, you control access. You decide who gets API access. You can throttle competitors. You can change terms. System of Action players are at your mercy.
Trust matters. Customers trust their System of Record because it handles compliance, security, auditability. Some AI startup might be flashier, but do you trust them with mission-critical data?
You can always build the action layer on top. It’s easier to go from System of Record to System of Action than the reverse.
The Real Challenges If You’re NOT the System of Record
If you’re building a System of Action without owning data, you face serious problems.
Challenge #1: Access. You need API access from the incumbent. What if they cut you off? What if they rate-limit you? You’re building on someone else’s infrastructure. Twitter killed third-party clients. Salesforce has restricted partners. One API change and you’re toast.
Challenge #2: Data Quality. Garbage in, garbage out. If the System of Record has bad data, your actions will be bad too. Plus you’re often working with stale data from API syncs, not real-time database access.
Challenge #3: Integration Tax. Every new feature requires integration work. Every new customer needs a new ERP connector. You’re constantly playing catch-up instead of building core features.
Challenge #4: They Can Bundle. If you get traction, the System of Record can copy your features and bundle them for free. They have deeper pockets, existing distribution, and zero integration costs.
The Case for “You CAN Win as System of Action”
Now the opposite argument, which I think is actually compelling.
AI is flipping the control point from “where data lives” to “where work gets done.” Users don’t care where data is stored. They care about getting their job done. If your product is 10x better, they’ll use it.
The System of Record is often optimized for admins and compliance, not end users. ERPs are clunky. EHRs are hated by doctors. These systems were built for managers, not for people in the field doing work.
That creates an opening. If you make someone’s life dramatically better—save them hours per day—they’ll use you. And they’ll force their company to integrate.
The “integrate and surround” playbook:
Find the “Hero User” who does the work and has pain AI can solve
Build something magical for them that works standalone initially
Get traction, force integration via user demand
Once integrated, pull more data, add features, replicate key SoR functionality
Become the new control point
AI transcription tools in healthcare did this. Started as voice-to-text. Now they suggest codes, flag compliance issues, auto-generate referrals. They’re not the EHR, but they’re where doctors do clinical documentation.
Threading the Needle: If You’re NOT the System of Record
Here are strategies to reduce risk:
Strategy #1: Become Indispensable. If users can’t live without you, the System of Record has to integrate or risk churn. Build 10x better UX. Create viral loops. Move fast before the incumbent wakes up.
Strategy #2: Build Your Own Lightweight SoR. You don’t need feature parity. Just own the critical data that makes your System of Action work. AI transcription tools started storing notes, now they store structured patient data.
Strategy #3: Cross-System Workflows. Don’t depend on ONE System of Record. Pull from multiple sources. Become the orchestration layer. Like Agave integrating Procore AND Sage 300 AND Autodesk. No single incumbent can cut you off.
Strategy #4: Adjacent Value Pools. Don’t compete with the incumbent’s core revenue. Find orthogonal streams. They make money on software? You make money on payments, financing, insurance, procurement. Use their data but monetize differently.
How to Win as BOTH System of Record AND System of Action
If you’re the incumbent:
Own the Full Workflow. Don’t just store data. Build tools that help users do their work. Map every job to be done. Where are they using other tools? Fix that.
Leverage Your Data Moat. Build AI models on your proprietary data. Offer predictions and automations challengers can’t replicate.
Bundle Aggressively. Make System of Action features free or cheap. Use SoR revenue to subsidize the action layer.
Control Integration. Be strategic about API access. Restrict it, increase costs, add friction to slow challengers down.
Move Fast on Threats. When you see a System of Action startup getting traction, copy them, buy them, or partner. Don’t let them establish a beachhead.
Who Actually Wins? It Depends
There’s no universal answer. It depends on:
How strong is the data moat?
How painful is the Hero user’s problem?
How fast does the incumbent move?
What are the switching costs?
How important is real-time data?
Strong data moats and high switching costs favor System of Record. Severe Hero user pain and slow incumbents favor System of Action.
The Real Lesson
The future belongs to companies that help customers DO the work, not just RECORD it.
Whether you get there by being the System of Record that adds great action features, or by being a System of Action that builds a lightweight SoR, doesn’t matter. What matters is owning where value is created.
This debate isn’t settled. Both approaches can win. And EVERY vertical’s winners in this new age will vary. Both have major risks. Be honest about which position you’re in and what it takes to win from there…
Have a product or service that would be great for our audience of vertical SaaS founders/operators/investors? Reply to this email or shoot us a note at ls@lukesophinos.com