LangChain has open-sourced the Paid Media Agent it built to run its own advertising campaigns, publishing a blog post on September 13, 2026 that details the agent's architecture, the mistakes its team made along the way, and the results of six months of paid advertising. The company said paid media went from 0 to 20% of its marketing pipeline in that period, and that cost per qualified lead fell 30% from June to August while monthly spend rose about 60%.
The post is credited to Amal Irgashev, Danny Lambert, and Jan Gomez. It describes a long-running agent that lives in Slack, posts weekly reports, and can propose campaign changes that a human must approve before any ad platform is touched. LangChain also said the agent can be deployed to Slack in one command with Managed Deep Agents.
From Organic Growth to Five Paid Channels
For its first three years, LangChain's sales pipeline grew largely organically through open source, content, YouTube, community, and meetups. In January, the company started a paid advertising program to reach new regions and enterprise decision makers. The goal was to scale from organic growth to five paid channels in six months.
That plan ran into familiar problems. Each ad platform uses a different data schema. Campaign parameters do not map cleanly to outcomes. Manual tracking across platforms is difficult and error-prone. LangChain built an agent to handle the complexity: tracking product announcements, drafting campaigns, adding keywords, testing variations, and proposing experiments.
The agent operates as a continuous learning loop. It analyzes performance, makes a change, observes the outcome, captures what it learned, and applies that insight to the next cycle. The company framed the whole effort around a single principle: a coding agent is a knowledge worker.
The results it reports are specific. Paid media went from 0 to 20% of marketing pipeline in six months. Cost per qualified lead fell 30% from June to August. Monthly spend rose about 60% over the same window, meaning the efficiency gain came while the program was scaling, not while it was shrinking. On LinkedIn, the largest social channel for LangChain's paid media, CPL was 40% lower than in January. And by bringing analysis and reporting in-house instead of using an agency, LangChain saved about $5K per month.
The agent's weekly rhythm is the visible part of that work. Every Monday, it combines ad-platform data with lead and pipeline data from the warehouse. It posts a summary and a branded PDF for each platform explaining what changed, why it changed, and what comes next. Team members can tag it in a thread to ask follow-up questions about campaigns, costs, or pipeline. It can also propose new keywords, targeting changes, ad copy, or new search campaigns based on its playbook and encoded judgment.
LangChain built the agent on Deep Agents, its agent harness, to avoid building core infrastructure from scratch. Deep Agents manages access to files, code execution, and working memory. It gives the model tools to plan work, delegate tasks to subagents, and manage context. Every run has a LangSmith Sandbox available by default. The sandbox is an isolated microVM with a 32 GB disk and a shell.
That sandbox comes equipped with pandas and DuckDB for analysis, openpyxl for spreadsheets, and WeasyPrint and Jinja2 for generating reports. Working data and business knowledge are stored in Markdown across six skills and a nineteen-page wiki. LangChain baked the software and the business wiki into a snapshot to keep startup fast. The snapshot reduced average startup time by 10 seconds.
The post is blunt about where the real constraint sits. The context window is often the bottleneck, not the model, the authors write, adding that many apparent reasoning failures are actually context failures. To manage that, LangChain split context into layers. The system prompt is treated as a map, not a knowledge repository. It starts with a one-sentence role description, followed by three short sections: how to operate, where numbers come from, and how to present results. It also contains pointers to the playbook, the wiki, and an index.
Skills are six folders of instructions progressively disclosed at runtime. The agent initially sees only a title and a description for each. The wiki is nineteen pages explaining the funnel, campaign purposes, data source ownership, and team decisions, including records of what the team decided in July. The distinction between the two is deliberate: a skill explains how to do work, while the wiki contains company-specific context. As the authors put it, a skill should "work at another company", whereas the wiki should not. The pattern follows Karpathy's LLM wiki note and LangChain's own Wiki Memory.
Live tools cover 218 calls for spend, settings, and pipeline data that change daily. Deterministic code handles calculations, date windows, account matching, and hard safeguards. One example safeguard is a rule preventing the agent from cutting a top pipeline driver after a single bad week. That rule is enforced in code, not left to the model's judgment.
Two Agents Became One After Five Weeks
LangChain originally built two agent graphs. The weekly report agent was scheduled, artifact-heavy, built as a Deep Agent with a sandbox, a large model, and PDF generation. The Slack agent was a lightweight loop on a cheaper model with Google Ads and warehouse tools, no sandbox, and read-only access.
The split lasted only five weeks. Duplicate implementation, feature lag, and limitations piled up. The mistake, the authors write, was treating them as two products. They are two entry points into the same analysis. The company now runs one graph, instantiated fresh for every request.
Slack mentions and the Monday cron job enter with different run modes. Scheduled runs see a single tool, task(), which delegates to one subagent per platform. Slack gets a broader set of read, warehouse, and campaign-operations tools. It is the same runtime with different capability profiles, hosted on LangSmith Deployment. Because Slack now shares the sandboxed architecture, the agent can open the report PDF and answer follow-ups in the same thread.
The first version of the weekly analysis asked the model to do everything. It loaded every campaign row, keyword, pipeline record, and landing-page check into context. On a frozen test set, a single report processed about 3.9 million input tokens. That run took 1,112 seconds and cost just over $3. Results were also harder to trust, because the model recomputed numbers each time.
Now Python fetches the data, aligns date windows, calculates totals and comparisons, applies fixed rules, and writes compact results to the sandbox. The model focuses on judgment: connecting evidence, explaining causes, evaluating campaigns, and recommending next steps. Moving calculations into code and removing unnecessary model calls made the early reporting workflow about 40x cheaper and 13x faster. Runtime dropped from 18 minutes to 85 seconds.
Six Platforms, Two Sources of Truth, and a Ten Percent Gap
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
LangChain manages six platforms with different IDs, conversion definitions, attribution windows, and campaign hierarchies. The company's rule is that ad platforms are the source of truth for media activity such as spend, impressions, and clicks. The warehouse is the source of truth for downstream outcomes such as leads, opportunities, and pipeline. BigQuery is the warehouse, and Salesforce is the source of opportunities and pipeline data in it.
That division does not always hold cleanly. Google video campaigns did not map into the warehouse because the warehouse joined using keywords, and video campaigns lack keywords. About 10% of Google spend was missing from the warehouse even though Google had the correct spend data. Meta could tell that an ad generated a conversion, but the warehouse was better at identifying the conversion type, such as "Contact Sales" versus "Sign Up."
LangChain encoded its source-of-truth rules in the wiki and removed tools that would query the wrong system. When data cannot be joined reliably, the agent preserves the limitation and includes the source, date window, and attribution model in its answers. The authors' guidance is that you do not need one perfect data model before an agent can work across systems.
Tool access was the other half of the problem. Pipeboard provides an MCP that exposes ad-platform tools, more than 200 of them. In June, that smaller read-only catalog required 38,000 tokens just to load tool names, descriptions, and arguments. Most of that context was irrelevant to any individual request. The warehouse had fixed queries for recurring questions, but new groupings required new tools.
LangChain solved this by giving the agent a small interface. For Pipeboard, that means three tools: Search, Read, and Run. For the warehouse, two flexible tools: Describe and Run analytical query. Search finds up to eight tools based on the question. Read loads the full schema only for the selected tool. Run executes the tool through the server, while campaign writes use a separate approval-gated path.
The catalog brought the first turn down to about 12,000 tokens. That was 4x cheaper than loading every schema, with the same judged quality. The catalog has nearly tripled since then, while context cost stayed roughly consistent. The lesson, per the post: give the agent a way to find and query capabilities on demand instead of putting every tool into context upfront.
LangChain tested fixed warehouse tools, a query interface, and both together across 60 live runs. Fixed tools worked well for routine questions but reported deeper questions as unsupported. Both versions with the query interface answered all analytical questions. The company kept both approaches: fixed tools for the fast path, the query interface for unanticipated questions.
Isolation Is More Than a Separate Context Window
LangChain tested three architectures for isolation: one isolated run per platform, one agent handling every platform, and a parent agent delegating to one subagent per platform. Separate runs performed worst. They produced multiple Slack messages and struggled to synthesize across channels. Both consolidated approaches produced a single output with cross-platform synthesis. LangChain chose the parent-plus-subagents architecture to keep the parent context small and give each platform its own context window.
That choice surfaced new problems. Two subagents writing reports to the same location and sharing the same "done" flag caused one to stop without producing a report. LangChain fixed it by giving each platform its own report location and completion state. Another subagent got stuck verifying its own work, burned tokens, and tried to build a PDF from scratch. Subagents now get only three tools: read context, compute, and render. If render succeeds, the job is done.
The authors' summary of the lesson is direct: a subagent gives you a separate context window, and the rest of the isolation model is up to you. Tools, files, state, return values, and failure handling all have to be designed.
From Analysis to Action, With a Human in the Loop
The agent can propose changes in Slack: add a keyword, update geographic targeting, or create a new search campaign. Permissions are strict. Only designated team members can edit or approve campaign changes, and the server checks Slack user IDs. Requests from unauthorized users are blocked, and the proposal remains pending. The proposed change appears in a Slack approval card built with Block Kit. Authorized reviewers can compare current and proposed values, make edits, and approve the final plan. Code then applies the approved change and checks the ad platform to confirm success.
The separation of responsibilities is deliberate: the agent analyzes and recommends, while the human controls action. The authors write that closing the loop requires more than write access. Slack worked well as a first interface because the approval card lives in the same thread as the analysis and discussion. But as the agent handled more complex work, including many ad groups, bulk edits, and multiple revision rounds, Slack became harder as a primary workspace. LangChain is moving complex workflows to a dedicated interface while keeping Slack for lightweight questions, recommendations, and approvals.
On that last point, the authors say reducing tokens, cost, and latency matters, but not if it makes the agent less capable. They add that they found it more useful to evaluate those metrics alongside completion rate and answer quality. The post also advises using models for judgment and code for consistency, designing agents around the full workflow, and using abstractions so teams can focus on the agent's job rather than infrastructure. Deep Agents manages hosting, sandboxes, Slack integration, and schedules.
The next step is to make the agent more proactive by continuously monitoring performance, surfacing changes, and proposing experiments. The bigger opportunity, according to the post, is connecting learnings across go-to-market. Campaign engagement could inform sales follow-up, and pipeline progression could improve the company's understanding of its ideal customer. The authors write that the biggest opportunity is to connect learnings across GTM, and that they want their GTM agents to contribute to the same shared knowledge and playbooks.
LangChain open-sourced the paid media agent including its ad-platform tools, paid media skills, sample wiki, reporting, and approval workflows. The company also hosted a webinar, "GTM Engineering Live: How We Built Our Paid Media Agent," on September 23 at 11am Pacific.
The post sits alongside three related pieces on LangChain's blog: "Organizing Context in a Multi-Agent Harness" by Thushanth Bengre and Chester Curme, published September 8, 2026; "MCP in LangChain: Stateless Protocol, Elicitation, and More!" by Sydney Runkle, published September 3, 2026; and "Deep Agents vs LangChain vs LangGraph" by Sydney Runkle, published August 6, 2026. LangSmith is described as an agent engineering platform for debugging, evaluating, and deploying agents.
For teams weighing a similar build, the post offers one question as the test of whether the work paid off: "What pipeline did we get for our ad spend?"