LangChain has open-sourced the Paid Media Agent it built to run its own advertising operation, publishing a blog post on September 13, 2026 that describes how the long-running agent lives in Slack, executes every Monday, and manages campaigns across five paid channels.
The company said paid media went from 0 to 20% of marketing pipeline in six months, while cost per qualified lead fell 30% from June to August and monthly spend rose about 60% over the same period. On LinkedIn, CPL was 40% lower than in January.
The agent, built on LangChain Deep Agents, LangSmith Sandbox, and LangSmith Deployment, tracks product announcements, drafts campaigns, adds keywords, tests variations, and surfaces proposed experiments for approval. It is designed as a continuous learning loop: analyze performance, make a change, observe outcome, capture learning, apply insights.
The blog post is credited to Amal Irgashev, Danny Lambert, and Jan Gomez. It runs 19 minutes and is filed under Tutorials & How-Tos and Agent Architecture.
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 launched a paid advertising program to reach new regions and enterprise decision makers, with a goal of scaling from organic growth to five paid channels in six months.
The challenges arrived quickly. Ad platform data schemas differed from one another. Campaign parameters did not map cleanly to outcomes like sales inquiries, signups, or content downloads. And campaign volume kept increasing.
The team wanted an agent that could handle questions it had not anticipated, produce numbers it could verify, and act on what it found. That framing shaped the build.
The result runs inside Slack. Every Monday, the agent 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, and what to do next. The team 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 playbook and encoded judgement.
LangChain said the agent saved about $5K per month by bringing analysis and reporting in-house instead of using an agency.
The agent is built on the principle that a coding agent is a knowledge worker. LangChain used Deep Agents as the agent harness. Deep Agents manages access to files, code execution, and working memory, and provides tools to plan, delegate to subagents, and manage context.
Every run gets a LangSmith Sandbox: an isolated microVM with 32 GB disk and a shell. The sandbox software includes pandas and DuckDB for analysis, openpyxl for spreadsheets, and WeasyPrint and Jinja2 for report generation.
Working data and business knowledge are stored in Markdown across six skills and a nineteen-page wiki. Software and the business wiki are baked into a snapshot to speed startup, reducing average startup time by 10 seconds.
Context is split into five layers: system prompt, skills, wiki, live tools, and deterministic code.
The system prompt defines role and navigation. It starts with a one-sentence role description, then three short sections covering how to operate, where numbers come from, and how to present results. The rest are pointers.
The six skill folders are progressively disclosed at runtime. The agent initially sees only the title and description of each. The wiki has nineteen pages explaining the funnel, campaign intent, data source ownership, and past decisions, including what was decided in July.
Live tools fetch spend, settings, and pipeline at request time. There are 218 such calls. Deterministic code handles calculations, date windows, account matching, and hard safeguards. One example: a rule preventing the agent from cutting a top pipeline driver after one bad week is enforced in code, not left to the model.
LangChain draws a line between the two knowledge stores. Skills explain how to do work and should work at another company. The wiki is company-specific and should not. The pattern follows Karpathy's LLM wiki note and LangChain's own Wiki Memory.
The authors said the strongest results came from giving the agent a well-designed workspace with a sandbox, software, business context, and clear operating instructions. Their stated approach: use models for judgment and code for consistency.
The first architecture split the work in two. LangChain originally built two agent graphs: a weekly report agent that was scheduled, artifact-heavy, used a Deep Agent, a sandbox, a large model, and PDF generation; and a Slack agent that ran 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. Every new capability had to be implemented twice. Features reached Slack and the report at different times. Slack could not process attachments or answer follow-ups on Monday reports.
The mistake, the authors wrote, was treating them as two products. They are two entry points into the same analysis, backed by the same wiki, skills, tools, and source rules.
Now one graph is instantiated fresh per request. Slack mentions and the Monday cron 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. Slack now shares the sandboxed architecture, so the agent can open a report PDF and answer follow-up questions in the thread.
The authors described the context window as often the bottleneck, not the model. Many apparent reasoning failures, they wrote, are actually context failures.
The first version of the weekly analysis loaded every campaign row, keyword, pipeline record, and landing-page check into context. It then asked the model to calculate spend, week-over-week changes, classify performance, and write the report.
On a frozen test set, a single report processed about 3.9 million input tokens, took 1,112 seconds, and cost just over $3.
The rebuild moved the arithmetic. Python now fetches data, aligns date windows, calculates totals and comparisons, applies fixed rules, and writes compact results to the sandbox. The model focuses on judgment.
That shift produced a large gain on an early reporting workflow. By moving calculations to code and removing unnecessary model calls, LangChain made the workflow about 40x cheaper and 13x faster. Runtime for that workflow dropped from 18 minutes to 85 seconds.
The authors' guidance: use models for judgment and code for consistency, and design agents around the full workflow.
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
Six Platforms, Two Sources of Truth
The agent covers six platforms with different IDs, conversion definitions, attribution windows, and campaign hierarchies. Keeping the numbers straight required explicit rules about which system owns which metric.
Ad platforms are the source of truth for media activity: spend, impressions, clicks. The warehouse is the source of truth for downstream outcomes: leads, opportunities, pipeline.
Two examples show why. About 10% of Google spend was missing from the warehouse because video campaigns do not always have keywords, and the warehouse joined campaign data using keywords. Separately, Meta could tell that an ad generated a conversion, but the warehouse was better at telling what the conversion was, such as "Contact Sales" versus "Sign Up."
Source-of-truth rules are encoded in the wiki. Tools that would query the wrong system for a metric are removed. When data cannot be joined reliably, the agent preserves the limitations and includes the source, date window, and attribution model in its answers.
The authors' takeaway: you do not need one perfect data model before an agent can work across systems.
Pipeboard's MCP server exposes more than 200 ad-platform tools. Loading them all was expensive.
In June, a smaller read-only catalog required 38,000 tokens just to load tool names, descriptions, and arguments before the agent could read the user's question. The warehouse, meanwhile, had fixed queries for recurring questions, and each new grouping required another dedicated tool.
The fix was a catalog interface. The Pipeboard catalog now sits behind three tools: Search, which finds up to eight tools; Read, which loads the full schema for a selected tool; and Run, which executes the tool through the server. Campaign writes use a separate approval-gated path.
The warehouse got two flexible tools: one to describe available tables and fields, and one to run an analytical query. The catalog brought the first turn down to about 12,000 tokens, and it was 4x cheaper than loading every schema while maintaining the same judged quality. The catalog has nearly tripled since then, while context cost stayed roughly consistent.
LangChain tested fixed warehouse tools, the 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.
The lesson, per the authors: give the agent a way to find and query capabilities on demand instead of putting every tool into context upfront. They added that the questions the agent repeatedly struggles to answer reveal where cleaner joins, better definitions, or dedicated tools are worth building.
Why Parent-Plus-Subagents Won
LangChain tested three architectures on live data: one isolated run per platform, one agent handling every platform, and a parent agent delegating to one subagent per platform.
Separate runs performed worst. Each run saw only one platform, produced multiple Slack messages, and struggled to synthesize cross-channel performance. Both consolidated approaches produced a single output with cross-platform synthesis. The company chose the parent-plus-subagents architecture to keep parent context small while giving each platform its own context window.
Isolation brought its own bugs. In one case, two subagents wrote reports to the same location and shared the same "done" flag. The first to finish caused the second to stop without producing a report. The fix was giving each platform its own report location and completion state.
In another case, a subagent could not determine whether a PDF had rendered. It kept checking files, burned tokens, and tried to build the PDF from scratch. Subagents now get only three tools: read context, compute, and render. If render succeeds, the job is done.
The authors' summary: a subagent gives you a separate context window, and the rest of the isolation model is up to you. Subagent isolation requires defining tools, files, state access, return values, and failure handling.
Approvals, Permissions, and Slack's Limits
The agent can propose changes in Slack: adding a keyword, updating geographic targeting, or creating a new search campaign. Permissions are tiered. Teams outside paid media can ask questions, but only designated team members can edit or approve campaign changes.
The server checks Slack user IDs before accepting an edit or approval. Requests from others 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 applies the approved change and checks the ad platform to confirm success.
Slack worked well as a first interface because the approval card could live in the same thread as the analysis and discussion. But as the agent handled more complex work, including many ad groups and creatives, bulk edits, and multi-round revisions, Slack became harder as a primary workspace. LangChain is moving complex workflows to a dedicated interface built around the agent, keeping Slack for lightweight questions, review, and approvals.
The authors noted that closing the loop requires more than write access. They also cautioned that reducing tokens, cost, and latency matters, but not if it makes the agent less capable.
What's Next, and What Is in the Open-Source Release
LangChain's next steps include making the agent more proactive by continuously monitoring campaign performance, surfacing changes, and proposing experiments. The bigger opportunity, the authors wrote, is to connect learnings across GTM so campaign engagement informs sales follow-up, and pipeline progression, sales conversations, and deal outcomes improve understanding of the ideal customer and influence the next campaign. Over time, they want their GTM agents to contribute to the same shared knowledge and playbooks.
The open-sourced paid media agent includes ad-platform tools, paid media skills, a sample wiki, reporting, and approval workflows. Companies can connect accounts, give company context, and deploy to Slack in one command with Managed Deep Agents.
LangChain will host a webinar, GTM Engineering Live: How We Built Our Paid Media Agent, on September 23 at 11am Pacific.
The blog post points to related reading: "Building a Harness with Jev" by Sydney Runkle and Hunter Lovell, published September 17, 2026, a 5 min read; "Organizing Context in a Multi-Agent Harness" by Thushanth Bengre and Chester Curme, published September 8, 2026, a 6 min read; and "MCP in LangChain: Stateless Protocol, Elicitation, and More!" by Sydney Runkle, published September 3, 2026, a 5 min read.
The post also illustrates how the same harness pattern generalizes. It mentions a content generation agent whose sandbox includes a headless browser, ffmpeg, media tools, and a brand book, and a finance agent that might need openpyxl and DuckDB. The original Slack agent used Google Ads and warehouse tools, with a BigQuery warehouse connecting campaign activity and website conversions to qualified leads, Salesforce opportunities, and pipeline.
One question sits at the center of the whole build, and the authors put it plainly: "What pipeline did we get for our ad spend?"