LangChain at $3 billion: how the company runs on its own agents

On November thirteenth, LangChain announced that it had raised three hundred million dollars at a valuation of three billion. The round was led by CapitalG, the growth fund owned by Alphabet, the parent company of Google. A little over a year ago, the same company was valued at one and a quarter billion dollars. In thirteen months, the valuation grew roughly two point four times.

For someone building a small business, something else is more interesting. Throughout this year, LangChain's chief executive Harrison Chase and his colleagues have described in some detail how their own company runs on agents. How much money goes to coding agents. How the agent that helps salespeople is built. How an agent fixes errors on its own after new code is deployed. And what did not work. That is what most of this episode is about.

First, a short word on what an agent is, because the word will come up often. An agent is a program in which a language model works not once, but in a loop. It receives a task, decides which tool to call, looks at the result, and decides what to do next. This way a model can, for example, find information about a client, write an email, and put it in front of a person for review. LangChain makes the tools that people use to build, run, and test such programs.

It all started as a side project. In the fall of twenty twenty-two, Chase published the first version of the langchain library from his personal GitHub page. In his own words, it was a single Python package of about eight hundred lines. "There was no company at the time, and no grand plan for what the project would become." A month later, ChatGPT came out. Interest in language models rose sharply, and with it rose the interest in a library that helped connect them.

In February twenty twenty-three, Chase and his co-founder Ankush Gola started the company. Chase writes that his co-founder is "a much better engineer than me." The first investor was the fund Benchmark: a seed round of ten million dollars was announced in April of that year. According to the host of the 20VC podcast, Chase said the founders treated Benchmark almost as a third co-founder. Then Sequoia came in. According to a partner at that fund, writing on the day of the new round, LangChain's pitch deck for its Series A in April twenty twenty-three was four slides long.

The early days are best seen through the memories of Julia Schottenstein, the first person on the team who did not write code. Her post says that in the summer of twenty twenty-three the team had eight people, no revenue, and no commercial product. The biggest risk at the time, she writes, was the question "would this LLM technology thing ever do anything useful?" As Schottenstein remembers it, Chase did not quite know what to do with an employee who was not going to program. The small office was silent, and hundreds of code changes were written by hand, because there were no coding agents yet. Product stayed with Chase, and sales and everything else went to Schottenstein.

One more detail about the early period comes from a post by Jessica Ou from the sales and marketing team. She writes that when she joined, the company had "just a couple hundred thousand in ARR", that is, a couple hundred thousand dollars in yearly revenue, and fewer than twenty people on the team. Today, according to employees, there are more than four hundred. The Wall Street Journal, citing the company, puts the number of full-time staff at four hundred thirty-five, with a plan to reach eight hundred fifty by the end of twenty twenty-seven.

The road was not smooth. In the summer of twenty twenty-three, as Chase himself admits, the library drew a lot of criticism. Developers complained that it hid too much behind layers of abstraction, that is, behind ready-made wrappers that are hard to change from the inside. Chase puts it this way: "While langchain was the fastest place to get started, we traded power for ease of use." In twenty twenty-four, the company Octomind published a note explaining why it stopped using LangChain for its agents. Around the same time, the well-known independent developer Pieter Levels advised everyone to simply call the model directly, without extra layers.

The company answered with a product. It built LangGraph, a deliberately low-level library where the developer controls every step of the agent. In October twenty twenty-five, LangChain and LangGraph both reached version one point oh. The company promised not to break its interfaces until version two point oh, and moved the old code into a separate package. For the listener, one idea matters here. The criticism was public and loud, and the company did not argue with it. It rebuilt the product instead.

The key decision behind today's business was made back in the summer of twenty twenty-three. That is when the beta version of LangSmith came out. It is a paid service that records exactly what an agent did: what requests it sent to the model, which tools it called, how much it cost, and where it went wrong. Such a record of steps is called a trace. Besides recording, LangSmith can check the quality of answers against sets of tests. Chase writes that LangSmith was built separately from the library from the very start. You can use it even if your agent was written without LangChain. Later it will become clear why this matters for sales.

Now to the main reason to listen to this episode. How LangChain works with agents inside the company.

Let's start with money. In mid-October, Chase was a guest on the 20VC podcast. Here are his words, from a published transcript of the segment. "I think we spend probably roughly thirty percent of our engineering salary on coding tools. It's actually gone down the last two months, while the number of tokens that we've used has actually gone up." A token is a small piece of text that a model provider charges for. In other words, the amount of work went up, and the bill went down.

Chase explained how they did it in three steps. He calls the first one simply visibility. The company records all the activity of its coding agents in its own LangSmith. In his words, this way "we could tell who was spending how much, what they were spending it on. We could do analytics over that." In a post on October fourth, he put it more briefly: you can't control what you can't measure.

The second step is basic spending limits. Each engineer has a budget. If they use it up, they can talk to the vice president of engineering, and, as Chase says, "he'll almost always increase it." The point is not to save money on people. Chase says "it's just a safeguard against agents being used incorrectly or going in a bad loop." That does happen: an agent tries the same thing again and again, and every attempt costs money. The limit is set through a gateway to the models, the LLM Gateway. This is an intermediate service that all requests to models pass through, and it can set a cap for each user.

The third step is control over what Chase calls the harness. The harness is everything around the model: which tools the agent can use, what context it receives, when it stops. The company built its own cloud coding agent, Open SWE. In Chase's words, "It's actually the only way I code anymore, because I'm in Slack all the time, so I just message it from Slack and it kicks off."

Why is it easier to save money with your own harness? In his post, Chase explains: "Obviously third party harnesses are tougher to optimize." The 20VC episode summary, which the host says Chase approved, names two techniques: prompt caching and routing between models. Caching works like this. If an agent sends the model the same long opening of a request many times, for example the project rules and a description of the code, the large providers charge several times less for the repeated part. Routing means that simple tasks go to a cheap model, and hard ones to an expensive model. Both techniques are technically real and widely known. The company did not say by what percentage they cut the bill.

At the same time, it matters that engineers are not forced into one tool. In a June post, Chase wrote that spending on coding agents had grown very sharply over several months. The company had to set up tracking for Cursor, Codex, Claude Code and other tools, because, in his words, "we give our team a lot of choice." A LangChain blog post about agent bills turns this into a rule: "Your engineering team will never standardize on one agent (and they shouldn't have to!)"

It is worth stopping here to work out what thirty percent means. LangChain does not disclose its salaries, so what follows is a rough estimate. If an engineer in San Francisco costs the company two hundred to three hundred thousand dollars a year, thirty percent of that is sixty to ninety thousand. That is roughly five to seven and a half thousand dollars a month per engineer, on agents alone. For comparison, a regular subscription to such a tool costs twenty to two hundred dollars a month. Sums like that are possible if an engineer runs several agents in parallel, uses the most expensive models, and works with large amounts of code. But this is very noticeable money.

This number comes with caveats. Chase said "probably roughly", so it is his estimate, not a line from a financial report. It is not known whether it includes the cost of the cloud servers that Open SWE runs on. It is not known how many engineers the figure covers. And there is one more thing that should be said plainly. All three steps, tracking spending, limits through a gateway, and an in-house harness, are exactly the products LangChain sells. The story is true and is also a shop window. That does not make it false, but it is worth hearing with this in mind.

Spending on coding is only part of the picture. At the end of October, Chase published a piece about what he called a company harness. He writes: "We've built internal agents at LangChain across marketing, sales, and engineering, and they have completely changed how those teams work." He admits: "They weren't easy to get right." And he writes that every team arrived at the same five basic building blocks.

The first: the agent lives where people already work. For LangChain, that is Slack. The second: the agent knows who is asking, and for some services it acts on behalf of that person, while for others it uses its own account. The third: the agent has memory, shared by everyone or personal for each user. The fourth: the agent runs code in a sandbox, an isolated environment from which it can still reach services that require a login. The fifth: a large share of runs happen on a schedule or in response to an event, not because someone pressed a button. Inside the company, such agents are called ambient agents.

Chase names identity as the hardest problem. "The thorniest and trickiest problem we tackled was identity." The question sounds simple: on whose behalf does the agent act? In practice it is hard. If an engineer asks Open SWE to fix something, the agent opens a request to change the code under that engineer's GitHub account. But if the agent reviews colleagues' code in the background on its own, it acts under its own account, as a separate application. The sales agent has a mixed setup. It goes into Salesforce, the customer management system, under a fixed service account, but it sends emails on behalf of the employee who called it. For any company that gives an agent access to email and the customer base, this is the main question of security and responsibility.

Chase is frank about memory. In his words, "This is probably the least explored area so far," and there is a lot of work to do. One episode from his piece shows well how such an agent behaves in practice. Chase asked the sales agent to send him a daily summary. In his words, "I asked GTM agent to send me a daily brief, and it created its own cron to do so." The agent set up a scheduled task for itself and started sending it. Nobody programmed that feature separately.

Now more on this sales agent, because for listeners who are looking for customers, this is the most useful part. In March, engineer Vishnu Suresh and Jessica Ou described it on the company blog. Inside, it is called the GTM agent, from the English phrase go-to-market, which means bringing a product to market. Its task is narrow and clear. In their words: "It triggers on new Salesforce leads, checks whether we should reach out, gathers context (including meeting history), and sends a Slack draft (with reasoning + sources) for the rep to approve." So when a new potential client appears in Salesforce, the agent decides whether to write to them, collects the background, and sends the salesperson a draft in Slack, along with an explanation of why it suggests writing this way, and its sources.

The agent has many sources. Salesforce itself, the BigQuery data warehouse, the call recording system Gong, LinkedIn, the contact search service Apollo, and the search service Exa. The agent checks the history of past messages so it does not write to the same person twice. It chooses a different tone for an existing client, a potential client, and a cold contact. The work is split among subagents, each with a reduced set of tools. The agent is built on the company's own library, Deep Agents, and runs on the company's own platform.

It is especially interesting how the agent learns the salespeople's style. When a salesperson edits a draft, the system looks at what actually changed in substance. From the edits, it pulls out observations about style, for example how briefly the person writes and in what tone. These observations are stored in a PostgreSQL database and are taken into account in the next drafts. The authors advise looking at human review not only as protection from mistakes, but also as a way to collect data. Every edit a salesperson makes becomes a lesson for the agent.

According to the authors themselves, the results are these. From December twenty twenty-five to March twenty twenty-six, the share of leads that turned into a qualified sales opportunity grew by two hundred fifty percent. The total value of potential deals in the pipeline tripled over the same period. Salespeople followed up on leads more often: almost twice as often for those who showed weak interest, and eighteen percent more often for those who showed strong interest. By their count, each salesperson saves forty hours a month, and the whole team saves one thousand three hundred twenty hours. Dividing one by the other gives about thirty-three people. Half of them use the agent every day, and eighty-six percent use it every week.

The most honest part of this story is how the main principle changed. At first the rule was strict: "Nothing is sent without an explicit rep review and approval." Later the company added an exception. For leads that are called silver internally, that is, not the top priority, there is a forty-eight hour window. If the salesperson has not approved or rejected the draft within that time, the email goes out on its own. The authors write that this noticeably raised the share of leads that got worked. The logic is clear: emails that people never got around to now do go out.

The authors also admit to something unexpected. Some of the ways the team uses the agent were never built on purpose. "We didn't build any of those workflows intentionally. The agent had the access, and people found the path of least resistance." Over time, the agent came to be used not only by the people who make first contact, but by the whole sales team. An October post by Julia Schottenstein lists what the agent does now. It writes follow-up emails after meetings, builds sales presentations, researches client companies, helps with the team forecast, and warns when something is wrong with a client.

Now about what in these numbers has not been verified. The two hundred fifty percent compares March with December. December is usually a weak month for business-to-business sales because of the holidays. There is no control group, meaning salespeople who worked without the agent during the same time. Besides, in those months the company's flow of inbound requests may have been growing after its previous round and its product launches. The agent's contribution may well be large, but it has not been measured separately from everything else. And a second open question: how many emails go out automatically under the forty-eight hour rule, and were any of them sent by mistake. The company has not disclosed this.

Amal Irgashev builds internal agents at LangChain. In a post on October twenty-third, he described what adoption costs from the inside: "at first it's this slightly alien thing in slack they have to babysit, and it can take hundreds of iterations before people really start trusting it... the agent ends up being the best written record of how the business actually works." This is a useful idea for any small company. To teach an agent to sell, you have to write down in detail, for the first time, how you actually sell.

Back to programming. In March, the company described Open SWE as an open framework for internal coding agents. According to the authors, it was modeled on the internal agents of the payments company Stripe, the finance service Ramp, and the crypto exchange Coinbase. The agent works in cloud sandboxes. Several sandbox providers are supported, including LangSmith's own sandboxes. It can be called from Slack, from the Linear task tracker, and from GitHub. Before starting work, it reads a file of instructions for agents in the code repository. The code example in the article uses a model from Anthropic.

Open SWE has two roles. When a person asks, it prepares code changes on that person's behalf. And in the background, it reviews every request to change code opened in the company, this time under its own account. The second role deserves a question. Having a model check every change is expensive in tokens, and work in a cloud sandbox is paid for separately, on top of the tokens. How much this costs the company is not in public sources.

The most engineering-heavy story of the year is about agents fixing themselves after code is deployed. In an April post on the company blog, engineer Vishnu Suresh describes a system built for the sales agent. After every deployment, it looks for new errors, decides whether the deployment caused them, and starts an agent that opens a request with a fix. The key detail is that errors are not handed straight to the coding agent. Suresh explains: "Rather than feeding errors directly into Open SWE (which is tempted to make changes), I add another gating mechanism."

Here is how it works. If the program itself failed to build, the build log and the list of changes go straight to the agent. Errors on the live server are harder. The system takes the error log for the past seven days as the normal background. Unique IDs, timestamps, and long numbers are cleaned out of the error text, so that identical errors fall into one group. Then, for an hour after the deployment, it watches whether there are more errors than usual. For this it uses a simple statistical model, the Poisson distribution. An alarm goes off only if the rise in errors can hardly be explained by chance.

Then a triage agent steps in. It looks at which files changed in the deployment: production code, settings, tests, documentation, or utility scripts. If what changed is not the code that runs on the server, the fix is blocked. Only after that does Open SWE take on the error and open a request for a change. Suresh writes that "the entire flow from error detection to proposed fix happens without any manual intervention." But the agent is not allowed to merge the fix into the main code: the developer gets a notice that the change is ready for review.

Suresh names the weak spots himself. The one-hour window misses errors that show up later. Grouping errors by pattern may miss that two errors that look different are really the same one. And the system always fixes forward, that is, it writes a fix, even though sometimes it would be wiser to simply roll back the deployment. This example is valuable precisely because of its modesty. The agent is not let near the code right away. First, the noise is filtered out by ordinary statistics that are decades old.

One more detail comes from Chase's interview on the Sequoia fund's podcast in January. He says that in the past, when a user complained about a problem, they were asked to show their code. Now the answer is different: "Send us a LangSmith trace. We can't really help you debug if it's not that." Inside the company, in his words, "no one's coding manual anymore." The company has its own server for connecting agents to LangSmith, and a command-line tool. Chase explains that "coding agents are actually great at using CLIs", that is, command-line tools. The agent downloads the traces itself, works out what went wrong, and fixes the code.

At the same time, Chase does not hand everything over to agents. In the same interview, he says: "even when I kick off Claude Code, when it finishes, sometimes I pull it up and look at the code that it actually wrote." He also talks about a failure. He had a personal email agent with its own memory, built up over a long time. The company made an agent builder, and Chase wanted to move his agent into it. But not all of the memory came along. As of the interview, he says, "I still haven't fully switched over because it kind of sucks now compared to what it was before." In the same conversation, it turns out that this agent has also been sending emails to the Sequoia interviewer for two years: "It's been emailing me for two years."

There are other admissions, but they should be handled carefully, because they are known only from retellings of the 20VC episode. According to these retellings, one badly configured plugin cost the company about forty thousand dollars in a week. The company shut down its commercial product for agent memory, because it turned out to be too general and found no demand. And Chase, according to these retellings, called the decision made about a year and a half ago not to build its own model gateway "one hundred percent the wrong decision." Today the company has such a gateway, and it sells it.

The third internal agent, Content Studio, works for marketing. As Chase describes it, it drafts blog posts, images, presentations, and videos in the company's style and with an understanding of how the company positions itself. There are fewer details about it than about the other two, and the company has given no numbers on its work.

Now to the main question for people building their own business. How did LangChain get its customers?

The main channel is free open source code. The libraries langchain, langgraph, and deepagents are released under the MIT license, which means anyone can use them for free, including in commercial products. A developer starts with a free library. Then they need to understand why their agent is behaving strangely, and they turn on trace recording. From there, some of these developers move on to the paid LangSmith. Sydney Runkle from the open source team writes that "langchain's open source powered our seed round, and it's still our foundation."

The reach numbers are large. According to Runkle, the company's packages are downloaded more than two hundred million times a month. Public statistics from the Python package index for the last thirty days show that langchain itself was downloaded almost one hundred fifty-seven million times, and the package for recording traces in LangSmith about ninety-three and a half million times. The main repository on GitHub has almost one hundred fifty thousand stars. But it is important to understand what exactly this measures. A download is not a person and not a customer. Most downloads come from automated builds that install the package again on every code check. Also, monthly downloads of langchain in June were twice as high as in October. These numbers show the size of the ecosystem, but not the number of paying customers.

The decision to make LangSmith independent of the library widened the funnel. Even people who left LangChain after the criticism can use the paid service. A good example is the company Clay. According to LangChain, it uses LangSmith to monitor hundreds of millions of agent runs a month.

Julia Schottenstein names the first large customers personally: specific people at Cisco, Workday, Rakuten, LinkedIn, and Klarna. Her post says they "believed that betting core parts of their company AI strategy on the Lang stack would work out." How exactly the first paying customer arrived, through an inbound request, an introduction, or a conference, is not in public sources.

From there, growth can be traced through the company's own statements. In February twenty twenty-four, when LangSmith became generally available, the company reported more than eighty thousand sign-ups and five thousand active teams a month. In October twenty twenty-five, it said that thirty-five percent of the companies on the list of the five hundred largest in the United States use its products. Now LangChain writes that more than seven thousand organizations use LangSmith, from fast-growing startups to Nvidia, Toyota, and Salesforce.

Here again a caveat is needed. Seven thousand organizations are not seven thousand paying customers. The free plan also gives you an organization account. How many of these seven thousand pay, the company does not disclose.

There are other channels too, all of them more expensive than open source. The company's own conference, Interrupt, held in May in San Francisco, which according to the company had more than a thousand attendees. Sales through the marketplaces of the cloud platforms Microsoft Azure, Amazon, and Google Cloud. A large company can pay out of a budget it has already committed to its cloud provider, and it does not need to take a new vendor through procurement.

Another channel is investors who are also customers. The previous round included the venture arms of Workday, Cisco, and ServiceNow. The new one includes Salesforce and MongoDB. When a large company invests in a vendor, it becomes easier for it to also become that vendor's customer, and the other way around.

The most expensive channel is engineers who work directly at customer sites. According to The Wall Street Journal, LangChain has forty-seven such engineers and thirteen architects. Neil Dahlke from this group writes: "When I joined LangChain in twenty twenty-five, Deployed Engineering was a handful of people and customers asked if agents could do the thing. We're past fifty DEs now, and they ask how to run lots of agents and prove with evals they still work." This is how large deals get closed, but it is close to consulting, and it does not scale well.

And finally, customer stories as marketing. In the funding announcement, the company writes that Workday cut the time to deploy a new agent "from five months to under a day." If you open the detailed write-up of this case on LangChain's website, it turns out to be about something else. Before, building a prototype agent took four to five months, with no guarantee that it would ever reach production. Now an agent gets into a test environment in less than a day. A test environment and work with real users are different things. The wording in the announcement is stronger than what the case study itself describes.

Now about money. Here the company is almost completely closed. It has not disclosed its revenue for twenty twenty-six. The last known estimate is twelve to sixteen million dollars in annual recurring revenue as of June twenty twenty-five. That figure comes from TechCrunch, based on four sources, and the company did not confirm it. How much it costs to acquire a customer, how much goes to marketing, what the margin is, and how much customers pay in their second year compared to the first, none of this is in public sources. In October twenty twenty-five, a company representative said it was "not yet profitable", but "fairly efficient in spend."

LangChain makes its money on LangSmith. The free plan gives one seat and five thousand basic traces a month. The Plus plan costs thirty-nine dollars per seat per month and includes ten thousand traces and a small server for running agents. Everything beyond that is counted in the company's own units, at one dollar per unit: server time, sandboxes, and runs of the tool that finds and fixes agent errors by itself. Large companies get individual pricing, and they can also install it on their own servers.

Why the economics of such a company may be difficult can be seen from the model itself. The core is free, and most users of the libraries pay nothing. The volume of traces grows along with the volume of customers' agents, and storing and processing them is expensive. Clay alone means hundreds of millions of runs a month. Co-founder Ankush Gola writes that the company built its own database, SmithDB, to handle the special demands of this kind of load. In the agent builder Fleet, the cost of the models is included in the price, so the margin there depends on what model providers charge. And sixty engineers and architects working at customer sites are expensive service work.

Let's add a rough calculation. This is not company data. If the full cost of an employee in the United States is two hundred to three hundred thousand dollars a year, then four hundred thirty-five people cost roughly ninety to one hundred thirty million dollars a year. This cannot be compared with revenue, because the company has not named its revenue. There is one more figure for reference. If revenue at the time of the previous round was about sixteen million a year, then the valuation of one and a quarter billion was almost eighty times higher. For the new round, there is nothing to base such a calculation on. Three billion is the price investors agreed to pay for a stake, not revenue and not profit.

The company has not said in detail what the new money will go to. The publication SiliconANGLE reports that it will go to hiring in engineering, sales, marketing, and customer deployment. In total, according to the press release, LangChain has raised about four hundred sixty million dollars.

The market around it changed noticeably this year. Langfuse, an open competitor in agent monitoring, was bought in January by ClickHouse, a database company. The service Arize was bought by Dynatrace, a major monitoring vendor, and the deal closed by October. The competitor Braintrust raised eighty million in February at a valuation of about eight hundred million, and some of its customers overlap with LangChain's. Back in October twenty twenty-five, OpenAI released its own set of tools for building agents. Anthropic and Google have their own tools for agent developers. So LangChain competes at the same time with independent startups, with large monitoring vendors, and with the model makers themselves.

LangChain's main argument against these competitors is neutrality. The company does not make models and does not sell cloud services, so it promises not to tie a customer to any single provider. As Mo Jomaa from CapitalG told The Wall Street Journal, "It's an insanely competitive market... but each of those players is trying to lock you into their ecosystem, lock you into their models, lock you into their infrastructure." In the funding announcement, Chase himself writes that "every company will need to own its intelligence. Companies should be free to choose the best models for their needs, control their data and infrastructure, and continuously improve their agents." It is worth noting that the lead investor in the round is Alphabet's fund, and Alphabet has its own models and its own cloud. LangChain's neutrality is a promise, and it will be tested for years.

There is also a deeper reason investors are willing to pay. At the end of October, Chase wrote: "It feels like everyone is converging on the same agent architecture: an LLM, running in a loop, calling tools, running in a sandbox." If the design of an agent becomes common ground, the value shifts to what surrounds it: memory, monitoring, quality checks, control over spending and access. That is exactly what LangChain sells. According to retellings of the 20VC episode, Chase said there that "It's still really hard to build them... Like really, really hard," because "they don't behave how you want them to behave." The business rests on that difficulty.

So what follows from all this? First. A company that sells tools for agents runs on agents itself, and does not hide that it is expensive. Thirty percent of the engineering payroll is an estimate, not a report, but the scale of the number suggests that spending on agents is becoming a separate large budget line, comparable to salaries. Second. Almost all of LangChain's internal agents are built the same way: they live in a messenger, run on a schedule, offer a person a draft, and learn from that person's edits. There is nothing magical about this, and it can be repeated. Third. Even this team, according to one of its own people, may need hundreds of iterations before people start to trust an agent. And the loudest numbers about the effect of agents were measured without a control group.

What can a listener do tomorrow? If your team already uses coding agents, start with Chase's first step. Gather in one place who is spending how much on models. Without that, any talk of saving money is empty. Give each person a personal limit. Not to cut back the work, but so that an agent stuck in a loop does not burn a week's budget overnight.

If you are looking for customers, look at how the sales agent is built. It does not write emails out of nowhere. It reacts to a new lead, gathers everything your systems know about the person, and gives the salesperson a draft with an explanation. A setup like this can be built even for a team of two. Start where the authors advise: "Start with a definition of success, not code." And compare the result not with the worst month of the year, but with a period that is similar in season.

If you deploy code often, take a closer look at the idea of a filter in front of the agent. Do not hand every error to an agent to fix. First check with a simple count whether there really are more errors than usual, and whether they are linked to the latest deployment. And let a person still review the fix.

And if you are building your product on open source, the LangChain story shows both the strength and the limit of this model. Open source gives you huge reach almost for free. But reach is not revenue. People start paying for what is hard to do themselves: monitoring, storage, security, support for large teams. Think ahead about which part of your product will be like that.

On November twentieth, LangChain promised to show new LangSmith features. That will make it clearer where the company takes the product after the round. Revenue remains the main open question of this whole story.

The bottom line is short. LangChain grew from an eight-hundred-line side project into a company valued at three billion dollars, by turning a free library into a funnel for a paid service. Inside, it runs on agents that live in Slack, offer people drafts, and learn from their edits, and it says openly that this is expensive and not easy. How much the company earns, and whether its economics add up, cannot be told from public sources.

That is all for today. My name is Evgenii Arsentev. I bring artificial intelligence into companies and build AI content factories for businesses: systems that produce short videos for social media. Thanks for listening.