a16z came in and asked me to walk through how we actually run 11x internally, function by function. Here is the whole stack.
Our customers run 11x to generate pipeline, book meetings, and revive deals everyone else wrote off. Together, those agents are driving hundreds of millions of dollars in pipeline. When you sell something that sits that close to revenue, you cannot build it from the outside. You have to live inside it.
So we do. Almost every function at 11x runs on agents we built for ourselves. The rule is simple: if we would not trust an agent on our own revenue, we are not going to ship it to yours.
Here is what we actually run.
1. We qualify customers with a Claude skill
When I became CEO, I made one rule a rule instead of a hope: we only sell to customers who are going to see real value from 11x. Selling to a bad-fit account is the most expensive mistake a young company can make. It costs you the deal, the renewal, the reference, and the focus you could have spent on the right customer.
So we built a Claude skill that every rep runs before they commit to a deal. It pulls in the emails, call notes, and Slack messages exchanged with the prospect, then weighs them against industry-specific nuance and the patterns we have seen in customers who went on to succeed. If something is missing, it tells the rep exactly which questions to go ask. At the end it returns a confidence score, and reps only close when that score clears 85%.
The discipline is the point. The agent makes the bar legible, and it makes it the same for everyone.
2. A deal handoff agent that carries the context
Here is the equation I care about: customer satisfaction is what you promised during the sale minus what the account team actually delivers. The gap almost always opens at handoff, where the detail of what was promised gets lost between two teams.
So we built an agent to close it. You assign it to grade a deal by @-mentioning it in Slack. It pulls every call from Granola, every relevant Slack thread, and the full email exchange across the cycle, then generates a Notion doc and a kickoff deck for the post-sale team. Nothing about the commitment gets dropped in translation.
The principle underneath it: agents are good at context, people are good at service. Let the agent hold the entire history so the humans can spend their attention on the customer.
3. "Lemmings": codebase agents the whole company can dispatch
For a long time, anyone outside engineering who needed an answer that lived in the codebase had to go interrupt an engineer. That is a terrible use of everyone's time, and it does not scale.
Now we run a company-wide fleet of read-only codebase agents we call lemmings. Anyone can dispatch one from Slack in plain English. They write customer-specific docs grounded in how the product actually works, generate insights for a given account and turn them into something polished, debug and tune a customer's setup, answer product and outcome questions, and build the decks for quarterly reviews.
We built this on LangChain's LangSmith Fleet, which lets you describe a fleet of agents that work across your own code and tools and then call them straight from Slack.
4. The harness that verifies what the coding agents write
We lean on coding agents as hard as any startup. The less obvious thing we figured out early is where the bottleneck goes next. Once agents are writing most of your PRs, the constraint stops being how fast you can write code and becomes how fast you can trust it.
So we invested in our own code harness before we needed it. For every PR an agent opens, it spins up a full virtual environment with Coder and Docker, works out what the change is supposed to do, and writes a test plan. It runs end-to-end tests with Playwright, runs the full regression suite, and drops screenshot evidence of the new feature working straight into the PR. It also runs against mock data that mimics production, volume included, so performance never quietly degrades as we ship.
Writing the code was never going to be the hard part for long. Verifying it is, and that is where we put the engineering.
5. The agentic office of the CEO
I run my own small fleet of personal agents, all built on Claude Cowork scheduled jobs.
The first is a customer brief that lands in my Slack DMs every week. It ingests every customer call through the Granola MCP and tells me what actually matters to customers right now. The second is a meeting prep agent that reads my email, Slack, and Granola, does its own research, and gets me ready for the next day's meetings. The third works through my Slack every evening and flags threads that never got resolved, which is harder than it sounds, because resolution might be an emoji reaction or a decision that happened in a different DM, so the agent has to reason about it rather than pattern-match. The fourth is a weekly market pulse that pulls from the internet and from the objections and competitors that came up in that week's real calls and emails, so I get a read on what the field is seeing rather than what a report says it should be seeing.
The stack, and the point
At a glance:
- Reasoning and agent layer: Claude Cowork, Claude Skills
- Orchestration: LangChain Fleet and Slack bots
- Meetings: Granola
- Docs and decks: Notion
- Code and code harness: Claude Code, Cursor, Coder
The thing I want you to take from this list is how ordinary it is. Outside of the code harness, almost all of it is Claude Cowork and a set of MCPs running on a timer. The leverage comes from being specific about what is worth automating, not from fancier tools.
We build agents for a living. Running on them ourselves is not a marketing exercise. It is how we make sure the thing we sell you is worth running on your own revenue.
Read a16z's post here.
