Hot take: DevRel should own sales pipeline attribution. Why? Because technical buying decisions are now happening through answers, not sales conversations. Increasingly, those answers are being evaluated by coding agents inside a developer’s terminal (e.g. Claude Code) or IDE (e.g. Cursor) long before a demo is booked. I've noticed this more with forward looking companies on our last ~15 sales calls at Inkeep. Enterprise buyers weren't just asking about features. They were telling us they'd already tested our AI against competitors, inside our documentation. One prospect ran 50 questions through our docs before ever booking a demo. Their verdict: "Your response quality was significantly better than our current vendor." That's a buying decision happening before sales even knows the prospect exists. Documentation is where technical buyers & coding agents stress-test AI quality. They evaluate answer accuracy, citations, and whether the knowledge base is complete enough to trust in real workflows. Yet most companies still treat docs as a cost center buried under support or engineering. The shift requires a mindset change, not a technology overhaul. DevRel and DevEx teams already understand what technical buyers need and know how to write good docs (or should at least). So they're closer to the evaluation experience by coding agents or technical buyers than marketing or sales will ever be. Give them conversion metrics. Let them instrument docs as a funnel surface. Track which answers generate pipeline, not just which pages get traffic. So in summary: Developer experience (good APIs, easy authentication, webhooks, test environments, programmatic equivalents for all features) will become the most important differentiators for SaaS products as agents become systems of record and companies adopt agent workflows.

Spoke with a technical CX leader at a 500-person, $100M+ ARR company evaluating Inkeep. It was quiet revealing about the state of technical CX. The key takeaway: CX teams don’t need another way to search faster. What CX leaders need is visibility into what’s changing before customers feel it. The failure mode is always the same. Engineering ships a change. Nobody flags doc impact. Support sees tickets from confused users. The doc team finds out weeks later through escalations. Customer trust drops with every stale page. At scale, that’s not a docs problem. It’s a coordination system problem. Here's the mechanism most vendors miss: 1. Engineering ships a feature change 2. No one flags the doc impact 3. Support gets tickets about outdated content 4. The doc team finds out weeks later through escalation 5. Trust erodes with every stale page Inkeep helps teams close the loop by ingesting customer questions and knowledge sources, analyzing gaps, then acting where work lives. That’s why we built knowledge gap reports and feature gap tracking. And with Inkeep Agents, teams can go a step further by drafting updates, opening the right tickets, and routing work to the right owner. So the takeaway for anyone running CX at scale: Optimize for building systems for maintain information across teams who don't naturally talk to each other.

Forcing your team to take 2 weeks off sounds like a terrible startup strategy. But it's one of the best operational decisions we've made at Inkeep. For the first 18 months of building, nobody took real time off. When you're a small team, every person is load-bearing. PTO feels impossible when there's no coverage. So we made a counterintuitive call last month: every December, we completely shut down the company for 2 weeks. The world naturally slows down in the last 2 weeks of the year, so a forced rest prevents the slow burnout that kills velocity in Q1. We expect a lot from our team. So the standards only holds if we design for sustainability. We're lucky to work an amazing team, and this is a small way we can say thank you for all their hard work during the year. Looking forward to what 2026 has to bring. [Photo from our offsite in Hawaii]

The key to making AI agents actually useful: giving them the tools to talk to your company data and apps. That's 50% of the work (and friction), and where MCP comes in. Here's a "late 2025" tldr. Key concepts: → MCP servers: a service that exposes a set of related tools in an LLM-friendly way, like “create support ticket” or "query knowledge base". → MCP clients: AI Apps that connect to and use the MCP Servers. Examples include Claude, ChatGPT, Cursor or Agents built on platforms like @inkeep. → OAuth 2.1: The way to give an Agent login/permission to that service. Instead of using an API key, there's a "1-click to sign in" interactive pop-up window. There are a few options for where to get MCPs: → Native: Some software vendors provide ready-to-connect servers for their product. E.g. @notionhq has an MCP they maintain and make readily available. → @composio / @nangohq : Libraries of connectors or authentication for popular SaaS services. → Gram by @speakeasydev - platform for converting and remixing existing APIs into MCP Servers (e.g. OpenAPI -> MCP). → Vercel or cloud quickstarts: Most cloud providers have quick-starts for how to create and deploy MCP servers in their respective cloud services. Low level but quick to spin up. When creating your own MCP, you'll likely want to add OAuth 2.1 with PKCE for authentication, especially if you're making the MCP available to your customers. Modern auth providers like @clerk, @descopeinc, @stytchauth , @workos , @better_auth, @scalekitinc and others have solutions or templates for how to add and govern OAuth to your MCP services. Once you have your MCP, then it's pretty plug-and-play to add it to any AI app or agent. More resources below 👇

I think this analysis has valid arguments, but misses the mark on specialized enterprise systems with proprietary data & context flywheels. The core issue is that raw LLMs are general-purpose by design. General-purpose tools aren't specialized enough for specialist-level work. That's why context engineering has become critical. Because what the LLM reads fundamentally determines its outputs, creating a massive delta between 80% and 95% accuracy. This matters because enterprises buy outcomes, not capabilities. Foundation model providers will keep expanding horizontally. But there is a structural limit to how deep they can go in every domain. OpenAI can't become the best in customer support, legal research, and medical diagnosis all at once. Each vertical needs domain expertise, proprietary data, and specialized tools. That's where I think the real opportunity lies — not building thin wrappers on LLMs, but architecting self-learning multi-agent systems that utilize A2A and MCP primitives to achieve specialist-level performance. And I think this is where multi-agent systems will shine in particular because every team of agents gets its own set of specialist role, knowledge access, tools and expected output to get real work done. In this environment, every customer interaction becomes training data for fine-tuning and specialization. If you're building in a domain where you can accumulate proprietary interaction data faster than foundation models can replicate your specialized performance, the velocity equation changes. Startups can build a compounding data advantage that improves as models get better over time. This is why data & context is a form of MOAT, and why I think multi-agent systems are the prime architecture that will separate the winners.

We're giving away $10,000 🔥. Ask: help us find killer TypeScript engineers to join our technical staff to work on the frontier of building AI Agents-- all in open source. We look for any type of background: team members range from MIT alum who have backgrounds in aerospace and physics to core maintainers of open source projects with 100k+ GitHub stars. The common factor is technical excellence and being obsessive about how people use what you create. Why join @inkeep? → Work at the cutting edge of AI: multi-agent systems, AI workflows and durable systems, context engineering, generative UI, etc. → Work with top-notch customers: Fortune 500 to fast-growing startups, including many leading AI companies. → Build in the open: the entire tech stack is TypeScript and open source → End-to-end ownership: drive and design features from APIs/SDKs to UX We're an ideal fit for senior+ engineers who want to join a fast-growing startup to work at the frontier of AI with a high-velocity team. To get the referral bonus: → tag engineers or share the profiles of devs I should talk to (I'll dm) → make an intro over email ([email protected]) Reposts appreciated -- we're looking to hire multiple engineers by end of the year.

With Composer 1 being released by Cursor, it marks perhaps the first time a non-frontier AI-lab releases an AI model that rivals the frontier models. Credit to Cursor. The model is blazingly fast! I think this speaks to interesting developments in the software business model. That’s because the switch to Agent-driven apps — where chat becomes the prominent UI — introduces higher marginal costs to using software. This shifted many AI-apps to Usage-Based pricing-models. So with every prompt (or batch of prompts), it came at a cost to their end user. But with the introduction of vertically integrated models like Composer, Cursor is effectively swapping a high variable cost (via API calls) for a larger more likely fixed cost in building their own runtime. Ownership of the model layer is likely to unlock new defensibility, better margins, and faster model iterations. That’s because the data generated in AI apps, leads to training more of models like Composer, which then helps create a more differentiated UX to attract users (and then generating more data with repetitive cycle). This likely shifts value to the compute & orchestration layers, but we’re yet to see. Our DevRel lead Gaurav Varma wrote piece about it. Check it out!

Many of the most successful devtool startups of our Y Combinator batch were -unrelated- to AI. See: - @resend - email for developers (+creators of react-email). - @infisical - OSS secret manager for securing engineering infra - @getreflex - OSS framework to build modern web apps in pure Python - @nangohq - OSS platform for making product integrations with 3P APIs - @highlightio - OSS monitoring platform for modern full-stack apps ~70k GitHub stars combined 🤯 Plenty of alpha in focusing on ease of use and extensibility. AI or not.