Now, the door for developers is the CLI, and the door for consumers is Claude and ChatGPT.

You ask a question or describe an outcome, and the agent produces it. In the past, every software application was accessed through a UI or API. But how do agents interface with software?

MCP—Model Context Protocol—is how agents interface with software. Like HTTP for browsers or SMTP for email, it’s a protocol that defines how a calling agent connects to a system, reads its state, and writes back to it. Anthropic introduced it in late 2024. Competing protocols have emerged, but they solve different problems. Google’s A2A handles agent-to-agent coordination, IBM’s ACP handles local orchestration. MCP is the standard for tool and system access, and it’s won that category fast: OpenAI, Google, GitHub Copilot, and Cursor have all adopted it, and the public server registry has grown nearly 8x in the past year.

Every major platform shift forces software companies to rebuild their surface area. With the internet, you needed a cloud strategy. With the iPhone, you needed a mobile strategy, and if you didn’t have one, you watched your users disappear into apps that did. Those shifts also created entirely new categories: SaaS, the app store economy, on-demand everything. The agentic shift is the same forcing function. If your software can’t be reached by an agent, it won’t be reached.

Salesforce just made the most dramatic bet in its 27-year history. At TDX in San Francisco, they unveiled “Headless 360,” a sweeping initiative to expose every capability in the platform as an API, MCP tool, or CLI command. The next generation of Salesforce usage won’t happen in a browser. It’ll happen in ChatGPT, Claude, OpenClaw, and whatever comes next.

At Ramp, Teddy Riker wrote recently that “the 80/20 has flipped: the new 80% of interaction with software will be through agents.” Weekly active users on their MCP grew 10x in three months as more customers started reaching into the product through Claude, ChatGPT, and other agents. His prediction: unless a product can be reached by an agent via MCP, API, or CLI, it won’t survive.

Garry Tan, CEO of YC, is a good bellwether for technical trends. Late last year, he posted that “MCP sucks honestly”—too much context window, bad auth. A few weeks later: “I am coming around to the fact that MCP, done right, can be magic.” By April 2026, he’d open-sourced GBrain, his personal AI infrastructure, exposing 30 MCP tools with full MCP support.

This shift is moving fast, and the tooling hasn’t caught up. It’s arguably a bigger disruption than the shift to cloud or mobile. The entire SDLC needs to be rebuilt for the agentic world: tool schema design, prompt capture, evals, quality gates, production monitoring, regression testing, and observability into what agents are actually doing.

The explosion of APIs in the mid-2000s is a helpful analog. Before Postman, testing an API was manual, inconsistent, and painful. Postman made it visual, reproducible, and shareable, and unlocked an entire generation of API-first development. But Postman was just the start. What followed was an entire ecosystem: Swagger for documentation, OAuth for auth, Kong and Apigee for throttling and metering, Datadog for monitoring, and Stripe for API-based billing. MCP needs all of that built from scratch.

MCPJam started as a fork of Anthropic’s own MCP Inspector and quickly became the most popular MCP testing tool on GitHub. We used it to build our own MCP integrations at OCV, and it spread organically through our portfolio. Almost every company we work with has ended up using it independently. I haven’t seen that kind of unprompted coverage across a portfolio since Stripe and PostHog at YC.

Right now, most MCP integrations ship blind. Teams can’t see what’s working, what’s breaking, or what callers are actually trying to do. Your actual users are invisible to you inside an agent conversation you’ll never see. MCPJam breaks that invisibility and gives you visibility into what’s happening between the agent and the MCP server.

The front door to the internet has changed before, and it’s changing again. This time, the door isn’t a browser, a search bar, or an app store. It’s an agent.

MCP has won the protocol layer. What gets built on top of it, the tooling, the infrastructure, the developer primitives, is still wide open. Every category that got rebuilt for the API era will get rebuilt again for the agentic era. The teams that don’t make that transition won’t survive it.

That’s why I’m bullish on MCPJam. It has the right wedge, the most popular MCP testing tool on GitHub, already spreading organically through the best development teams, and a long-term vision for what the agentic SDLC needs to become. The front door is changing. MCPJam is helping teams build for what’s on the other side.

Getting agents right means building them from the runtime up. Runtime is what actually holds credentials, executes tool calls, and manages memory. It’s the foundation everything else rests on. To build it correctly, three things need to be true: it needs to be open, secure, and accessible without a terminal. Each missing piece undermines the others.

Even OpenClaw only delivers on one front (open), despite being the most popular personal AI agent. OpenClaw recently grew from zero to over 350,000 stars and surpassed React as the fastest-growing open source project in GitHub’s history. Run OpenClaw for a week, or any of its current siblings, and two problems become obvious: it’s not secure, and it’s not accessible.

Open but not secure

Peer-reviewed papers now catalog a systematic taxonomy of vulnerabilities in OpenClaw’s architecture. SecurityScorecard’s STRIKE team found tens of thousands of exposed OpenClaw instances — 15,200 directly vulnerable to remote code execution, and 53,300 correlated with prior breach activity. Nine CVEs dropped in a single four-day window in March. Over 800 malicious skills, roughly 20% of the marketplace at the time, were flagged as credential-stealers. Users are losing funds. Users are leaking API keys into LLM provider logs they never consented to. Some have stopped using OpenClaw altogether because they no longer trust it with anything private.

OpenClaw’s core issues have been public for months, and most of them still aren’t fixed, because they’re architectural rather than incidental. Credential handling, skill sandboxing, and network egress weren’t first-class design concerns, so patches land on top of a runtime that wasn’t built for them. New skills and integrations keep expanding the attack surface faster than fixes can close it. That’s why the Claw family of forks and rewrites exists in the first place, and it’s why the fix has to happen at the runtime layer, not in a patch cycle.

Open but not accessible

When an agent holds your most important keys, you should be able to read the code, swap the model and provider underneath, and take your context when you leave. Open source provides this visibility, but it doesn’t guarantee access. Most of OpenClaw’s 3 million users don’t want a developer tool; they want an always-on agent that remembers them, runs while they sleep, and works across every surface they use. OpenClaw wasn’t built for that. Its architecture reflects its origins: a fast-moving project optimized for developer extensibility, not persistent personal memory or multi-session continuity.

Setup requires opening a terminal: using the command line, editing JSON config, generating and pasting API keys, and reasoning about gateways and providers. The median OpenClaw user today is a developer. The median user who would benefit most, the operators, recruiters, solo founders, and small business owners, can’t get past the first config file. The gap between “I want an agent that watches for competitor pricing changes and Slacks me” and “I have that agent running” is still measured in hours of YAML for technical users, and never for everyone else. Workflow integration is where most users give up. The product is trapped inside the audience that needs it least.

The many problems with OpenClaw have spawned a dozen alternatives and rewrites in under three months, each picking an area of weakness to build around.

Yet, none of these has solved the thing that matters most: making any of it securely usable by someone who doesn’t have a terminal open. That’s the gap we want to close.

Building on top of Hermes Agent to close the gap

Hermes Agent, an MIT-licensed project with 100K+ stars from Nous Research, comes closest to closing the gap. It’s a personal AI agent that lives on your own server and remembers you across every session, every model swap, and every device. Memory is stored as plain Markdown files in your filesystem, so you can read it, edit it, and take it with you. The model underneath is swappable: Claude today, a local Llama tomorrow, no rewrites. A built-in scheduler runs tasks while you sleep. The same agent reaches you on Telegram, Slack, email, a browser, or the terminal (once you configure each one), with full context wherever you pick up.

Hermes solves the architecture. What it doesn’t yet solve is getting any of this into the hands of someone who doesn’t live in a terminal.

That’s why OCV is starting an open source agent company, building on Hermes Agent, to ship what’s missing today: onboarding without a terminal, security built into the runtime, and workflow integration that doesn’t require rebuilding your workflow in a config language.

We’re looking for a founding engineer to lead it. You’d be joining as a founder, with OCV’s incubation resources behind you: capital, GTM, recruiting, design, and a portfolio of agent-adjacent companies to learn from. The right person has shipped systems software, cares about security at the runtime layer, and has strong opinions about UX for people who don’t write code.

If you’ve been watching the Claw family and thinking we can do this right from the runtime up, now’s your chance—apply here.

Fundraising puts you in front of tons of investors who have heard hundreds, if not thousands, of company pitches. Ideally, you’re talking with experienced partners who have invested in multiple successful companies and know a thing or two about how to build a successful startup. So when they give you feedback on why they passed, intuitively, you want to listen. But don’t. Take the no, and ignore the why.

It can be hard to wave off the feedback from investors when you have a perception that they know better than you. Founders often carry this perception because VCs allocate capital, which gives them a significant degree of power. But it’s important to keep in mind that money and power do not equal correctness.

Potential investors are playing a long game

Many VC partners will talk to hundreds of companies in a year and invest in fewer than five. Just because an investor took a call or two does not mean they were ever seriously interested in you or your company. In reality, if they pass, they just don’t believe in you yet. Most likely, your pitch needs improvement. For example, if an investor is confused about your market, you probably didn’t explain it very well. Don’t mistake that confusion as a reason to reassess your market. The worst thing you can do is think you should pivot your business based on something an investor who didn’t invest recommended.

Investors are playing a long-term game. Even if they pass now, they may want the opportunity to invest in the future, so they are going to be very careful about how they manage interactions with founders. The majority of people struggle to take constructive criticism without having an emotional reaction. If an investor is blunt with their feedback, they run the risk of tarnishing their relationship with the founder and may be passed over for future investment opportunities. If they anger a founder, that person may go talk to other founders and share their negative experience, and suddenly, the investor is being shut out of multiple investment opportunities.

Instead of giving real feedback, most investors will share non-controversial, generally accepted feedback to play it safe—something that the majority of people would agree with. For example, they may say something like “the market is too small” or “the market may not pan out how you think.” This may or may not reflect their true opinions. Even more specific feedback like “if the product would do XYZ instead” or “if you targeted this other market instead” should be ignored. The VC has no incentive to give you real feedback and is trying to come up with the least provocative reason to pass. Following advice in this situation could lead to a path that is completely wrong for your business.

Other excuses VCs tend to give are “it’s not you, it’s us” or “the business is too early or too late for us to invest right now.” These excuses are rarely true. The “it’s not you, it’s us” excuse is an age-old way to let someone down easily while avoiding sharing any details. Similarly, investors know the stage of your company when taking the call. Yet, blaming the stage of your company is the number one excuse they use, simply because it gives them an easy out.

We’ve seen this play out across OCV’s portfolio. Mermaid‘s OSS gravity made it the default diagramming framework for AI tools. Its syntax-saturated developer training data got embedded in GitHub, GitLab, and every major doc platform, and became the lingua franca for “diagram as code.” It is now the fastest-growing code-based format in the world, and has driven Mermaid’s exceptional commercial growth.

But the relationship runs both ways. AI is also a cheat code for OSS. AI enables people who are not professional developers to contribute to OSS for the first time. As of early 2025, there were around 35 million professional developers and another 10 million amateurs. Until now, well under 1% of the global population is responsible for all software being built and maintained in athe world. But that is rapidly changing. Over 36 million new developers joined GitHub between September 2024 and September 2025, the fastest absolute growth in the platform’s history, and monthly active OSS contributors doubled from 84K to 175K, driven largely by AI adoption.

This trend reached a fever pitch in March 2026 with OpenClaw, which became the fastest-growing open source project in history. Its contributor guidelines explicitly welcome “AI/vibe-coded PRs,” and the community reflects it: the vast majority of contributors are not classically trained developers. At NVIDIA’s GTC, Jensen Huang called it “the operating system of agentic computers,” comparing it to Linux, HTTP, and Kubernetes. Five years ago, the idea of non-developers contributing to foundational computing infrastructure would have been unthinkable.

The most durable OSS projects are what Jean Lafleur, co-founder of Airbyte, calls federation-style: where the user persona and the contributor persona are the same. That’s why the most successful open source projects have historically been devtools and infrastructure; the feedback loop between using and building is tight, and the product compounds with every contribution. The alternative is stadium-style OSS, where a small core team builds while the community watches. This is why OSS has historically struggled at the application layer: even if users are smart and opinionated, the bar to contribute has been out of reach.

There’s a growing consensus that building application-layer software is a dangerous proposition, as the cost of software development trends toward zero, so why not build a custom application every time? “AI will kill vertical SaaS” is the new refrain. I’d sharpen that: AI + COSS (Commercial Open Source Software) will kill closed-source vertical SaaS.

Consider Electronic Health Records (EHR), the OG vertical software. An EHR manages patient medical records and the administrative workflows of a medical practice, including scheduling, billing, and clinical documentation. Any EHR vendor will tell you no two practices are alike. They are deeply opinionated and require significant customization to support their particular workflows and requirements.

Epic owns ~40% of the U.S. hospital market and generates $5B+ in annual revenue, a substantial portion of which comes from implementation and customization services. Ask any practitioner how they feel about Epic, and the answer underscores the persistent gap between the people building the software and the people who live in it every day.

Epic will be around for a long time. But I believe it will gradually be displaced by an open core solution. Healthcare organizations won’t vibe-code their EHRs, but they will build and customize workflows within a framework that understands the regulatory environment, the clinical context, and the data model. An open core EMR is a platform for AI-powered customization, workflow automation, and agent orchestration, grounded in the patient and provider data that it protects.

OSS has always been a knowledge-compounding machine: contributors improve the software, which attracts more users, which improves the software. When domain experts who were previously locked out can finally join that loop, the flywheel spins faster and reaches further. This dynamic is true across verticals, but especially powerful in healthcare, where knowledge-sharing is hardwired into the professional ethos.

This is the thesis behind our investment in OpenCoreEMR, which is commercializing the most popular open source EHR in the world—a project built by and for healthcare providers. For most of its history, contributing to OpenEMR required clearing a technical bar that most physicians couldn’t reach. AI is rapidly changing that, and the project is growing exponentially.

OpenCoreEMR is one example, but the pattern will repeat across every industry where domain experts have been locked out of the software they depend on. “AI will kill vertical SaaS” is right in that those experts are now empowered to build. But they won’t build from scratch. They’ll build on open core platforms that already understand the regulatory environment and domain-specific requirements of their field.

Founder and CTO Philippe Lafoucrière brings over two decades of entrepreneurial and engineering experience to the smart home automation space. A serial founder since university, Philippe started Gemnasium in 2011—a pioneering dependency scanning company in the software supply chain industry—which was later acquired by GitLab in 2018. As a Distinguished Engineer at GitLab for seven years, Philippe worked closely with OCV’s founder and general partner, Sid Sijbrandij, an experience that profoundly shaped his approach to building transparent and vision-driven open core companies.

Philippe envisions a future where Selora Homes is the standard for home and building automation. “Software is eating the world, and that includes homes, too. Every home will be a smart home in the future—it’s not a question of if, but when,” said Philippe. “My vision is that Selora becomes the automation and monitoring go-to solution for not just homes, but for all buildings—institutional, commercial, and industrial.”

Bucking proprietary lock-in

Smart home solutions like Control4, Crestron, or Savant force you to choose between reliability and flexibility. They provide a professional installation experience, but trap users in their ecosystem with expensive hardware, limited integrations, and dependency on certified dealers for every change. Mainstream platforms like Apple Home, Alexa, and Google Home offer a middle ground—easier setup than professional systems and better integration than before—but still lock users into their respective ecosystems with limited device compatibility, basic automation capabilities, and reliance on cloud services.

These closed platforms can hold customers hostage with restrictive licensing and costly maintenance requirements. Even consumer-friendly options like Apple Home require HomeKit-certified devices and offer only simple automations, while Google Home pushes users toward Google’s ecosystem with similarly constrained automation rules. Neither platform gives users meaningful access to their own historical data or the ability to create complex, multi-condition automations.

Meanwhile, free and open source solutions like Home Assistant offer flexibility and support for over 2,000 integrations across every smart home protocol imaginable. There’s little incentive for customers to stay locked in with a single ecosystem when more smart device companies are providing open firmwares and embracing the “Works with Home Assistant” label, according to Philippe. “The power of Home Assistant is that it works with almost everything,” said Philippe. “This means homeowners can use a single application to manage all of their devices instead of scattered apps for each device brand.”

However, setting up DIY solutions like Home Assistant requires significant technical expertise. “When something stops working, homeowners have a steep curve to fix their problem,” said Philippe. “People don’t work on their home automation systems every day. It’s easy to quickly forget how and what you did, making troubleshooting later a headache.” While technical troubleshooting Home Assistant is part of the appeal for the technically inclined, it’s a huge hurdle for the average homeowner trying to make home automation simpler—a problem that worsens with scale.

Building the future of connected spaces

Selora Homes’ open core approach brings professional installation and support to Home Assistant’s robust open source foundation. “We want to make smart simple,” said Philippe.

For homeowners, the platform will deliver professional peace of mind through 24/7 monitoring, expert technical support, and guaranteed response times. Features like secure remote support, continuous security monitoring, and automated security updates ensure reliability. Automatic backups with quick recovery and optional High Availability configurations will ensure zero downtime.

For professional installers, Selora Homes will provide a comprehensive business management suite including centralized customer dashboards, team collaboration tools with role-based access, professional ticketing systems with SLA tracking, and direct Home Assistant technical support. The platform offers secure remote access through just-in-time tools like Tailscale for troubleshooting, proactive monitoring, and alerting for all installations, and managed updates with rollback capabilities. These features enable installers to scale their operations while maintaining high service levels.

Beyond operational tools, installers can join the Selora Homes Network, a marketplace where homeowners can discover and connect with certified professionals in their area. This means installers not only streamline their existing business but also gain access to new customer leads, expanding their reach without additional marketing costs. As part of our installer network, professionals benefit from increased visibility while homeowners get vetted, qualified experts who understand the platform.

Strengthening the open source foundation

Building on open source Home Assistant ensures customers avoid vendor lock-in and can reliably use a wide variety of devices. “Home Assistant’s open source automation framework is changing this smart home market,” said Philippe. “There’s already more than two thousand integrations, and you can create an integration for pretty much anything that you might think of. If your device has a network connection or is available through an API, you can integrate that with Home Assistant.”

Philippe’s approach to building Selora Homes reflects a deep commitment to strengthening rather than fragmenting the Home Assistant ecosystem. “That means contributing back to Home Assistant whenever we can. “It’s the foundation of our offering, and we want to be good players in the market and make sure that Home Assistant is getting all the benefits from the changes that we’re going to make,” he said.

This philosophy stems from Philippe’s belief that open source represents a fundamentally better way to build technology. “Our goal is to make Home Assistant usable to customers who know nothing about Home Assistant,” said Philippe. “The foundation is free and open source, but we’re building an out-of-the-box solution for people who probably wouldn’t use Home Assistant on their own.”

Join the waitlist

Selora Homes is now inviting early adopters to join the waitlist. We’re looking for homeowners who want professional-grade smart home automation without the complexity, and installers ready to grow their business with our platform. Selected participants will get early access to the platform, direct input on feature development, and exclusive pricing when we launch. Whether you’re frustrated with your current smart home limitations or you’re an installer looking to scale your operations, we want to hear from you. Register for early access and help us shape the future of connected homes. Space is limited as we carefully onboard users to ensure the highest quality experience.