LangChain has open-sourced the Paid Media Agent it built for its own marketing team, publishing a detailed engineering writeup on September 13, 2026 that covers the architecture decisions, the results, and the lessons learned along the way. The post, estimated at a 19-minute read, is credited to Amal Irgashev, Danny Lambert, and Jan Gomez.
The headline numbers are striking. Paid media went from 0 to 20% of marketing pipeline in six months. Cost per qualified lead fell 30% from June to August, even as monthly spend rose about 60% over the same period. On LinkedIn, the largest social channel, CPL was 40% lower than in January. And by bringing analysis and reporting in-house instead of using an agency, the company saved about $5K per month.
The agent itself is a long-running system that lives in Slack. Every Monday it combines ad-platform data with lead and pipeline data from the warehouse, then posts a summary and a branded PDF per platform explaining what changed, why, and what comes next. The team can tag the agent 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 the playbook and encoded judgement.
The writeup is unusually candid about what went wrong before it went right. It documents six lessons, several of them learned by building the wrong thing first, and it includes the specific token counts, runtimes, and dollar figures behind each course correction. The release ships with ad-platform tools, paid media skills, a sample wiki, reporting, and approval workflows, and it 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 launched a paid advertising program to reach prospects outside those organic channels, including new regions and enterprise decision makers. The goal was to scale from organic growth to five paid channels in six months.
The challenges were not just about budget. Each ad platform has its own data schema, and campaign parameters do not map cleanly to outcomes like sales inquiries, signups, or content downloads. A small marketing team faced the job of tracking campaigns across channels, managing creative and targeting experiments, and coping with growing performance data. Product release cadence accelerated, which increased campaign volume and made manual management harder.
The agent was designed with specific goals: track product announcements, draft campaigns, add keywords, test variations, surface proposed experiments for approval, and operate as a continuous learning loop. That loop means analyzing performance, making a change, observing the outcome, capturing the learning, and applying the insight to the next round.
The design principle behind all of it is simple to state: a coding agent is a knowledge worker. The team treated the agent like a new paid-media analyst. It was given a computer, software, data access, and business documentation.
LangChain used its own Deep Agents as the agent harness to avoid building core infrastructure from scratch. Deep Agents manages access to files, code execution, and working memory, and gives the model tools to plan, delegate to subagents, and manage context. It also handles hosting, sandboxes, Slack integration, and schedules.
Every run has a LangSmith Sandbox available by default. That is an isolated microVM with a 32 GB disk and a shell. The sandbox comes loaded with pandas and DuckDB for analysis, openpyxl for spreadsheets, and WeasyPrint and Jinja2 for report generation.
Business knowledge is stored in Markdown across six skills and a nineteen-page wiki. The software and business wiki are baked into a snapshot, a saved image, to speed startup. That reduced average startup time by 10 seconds.
Context is split into five layers, ordered by how quickly each changes: system prompt, skills, wiki, live tools, and deterministic code. The system prompt is a one-sentence role description plus three short sections covering how to operate, where numbers come from, and how to present results. Everything else is a pointer. As the writeup puts it, the system prompt became a map that helped the agent find what it needed without carrying everything in context.
Skills are six folders of instructions progressively disclosed at runtime. The agent initially sees only the title and description of each. The wiki is nineteen pages explaining the funnel, campaign intent, data source ownership, and past decisions. July is referenced as a past decision point in the wiki.
Live tools account for 218 calls for spend, settings, and pipeline fetched at request time. 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 one bad week.
The distinction between a skill and the wiki is deliberate. 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.
The writeup notes that different agents need different computers, and the job determines how you design the computer. A content generation agent's sandbox has a headless browser, ffmpeg, media tools, and a brand book, resembling a video editing workstation. A finance agent might need openpyxl and DuckDB. The paid media agent needed its own specific set.
Two Agents, Five Weeks, One Graph
The first architecture split the work into 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 with a cheaper model, Google Ads and warehouse tools, no sandbox, and read-only access.
The split lasted only five weeks. Every 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, according to the writeup, 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. The fix was to use one runtime with a capability profile for each entry point.
Now there is one graph, 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. The same runtime runs with different capability profiles, hosted on LangSmith Deployment, which handles hosting, scaling, and scheduled runs.
Slack now shares the sandboxed architecture, so the agent can open a report PDF and answer follow-up questions in the thread that produced it.
Six Lessons, and the Numbers Behind Each One
The first version of the agent loaded every campaign row, keyword, pipeline record, and landing-page check into context. It then asked the model to calculate spend, compute 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. That is roughly 18 and a half minutes for one report, at a cost that would compound quickly across platforms and weeks.
The rewrite moved the math into Python. Code 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. The result was a reporting workflow that became about 40x cheaper and 13x faster, with runtime dropping from 18 minutes to 85 seconds.
The broader point in the writeup is that calculations, source-of-truth rules, and safeguards were better handled in code, making the agent faster, cheaper, and more reliable. Use models for judgment and code for consistency.
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
LangChain runs across six ad platforms, each with different IDs, conversion definitions, attribution windows, and campaign hierarchies. The writeup is direct about the temptation here: trying to normalize everything into one perfect schema would have added complexity without necessarily making the data more trustworthy.
Instead, the team defined which system is authoritative for each metric. Ad platforms are the source of truth for media activity, meaning spend, impressions, and clicks. The warehouse is the source of truth for downstream outcomes, meaning leads, opportunities, and pipeline. The warehouse is BigQuery, and the CRM feeding it is Salesforce.
Two concrete problems illustrated why this matters. Google video campaigns did not map cleanly into the warehouse because the warehouse joined on keywords, which video campaigns lack. About 10% of Google spend was missing from the warehouse as a result. Meta could tell that an ad generated a conversion, but the warehouse was better at telling what the conversion was, for example "Contact Sales" versus "Sign Up."
Source-of-truth rules live in the wiki, and tools that would let the agent query the wrong system 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 lesson stated in the writeup is that you do not need one perfect data model before an agent can work across systems. Defining which source is authoritative for each metric matters more.
Pipeboard's MCP server exposes more than 200 ad-platform tools. In June, the smaller read-only catalog required 38,000 tokens just to load tool names, descriptions, and arguments before the agent had even read the user's question. The warehouse had fixed queries for recurring questions, and each new grouping required another dedicated tool.
The fix was a three-tool catalog sitting in front of the Pipeboard 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 Pipeboard's 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. That is 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.
The team also tested fixed warehouse tools, a query interface, and both together across 60 live runs. Fixed tools worked for routine questions but reported deeper questions as unsupported. Both versions with the query interface answered all analytical questions. LangChain kept both approaches: fixed tools for the fast path, and the query interface for unanticipated questions.
The underlying claim is that the context window is often the bottleneck, not the model, and that many apparent reasoning failures are actually context failures. Give the agent a way to find and query capabilities on demand instead of putting every tool into context upfront.
The team 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 for this workflow. They produced multiple Slack messages and struggled to synthesize across channels. LangChain chose the parent-plus-subagents architecture to keep parent context small while giving each platform its own context window.
Two isolation bugs surfaced. In the first, two subagents wrote reports to the same location and shared a "done" flag. The first to finish could cause the second to stop without producing a report. The fix was giving each platform its own report location and completion state. In the second, a subagent stuck verifying its own work 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 lesson is that a subagent gives you a separate context window, and the rest of the isolation model is up to you.
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, and unauthorized requests are blocked while the proposal remains pending.
Proposed changes appear 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 explicit: the agent analyzes and recommends, and a human controls whether action is taken. Closing the loop requires more than write access. The writeup says to give the agent a clear action path with permissions, approvals, and verification built in.
Slack worked well for focused decisions because the approval card lives in the same thread as the analysis and discussion. But Slack became harder as a primary workspace for complex work: campaigns with many ad groups and creatives, bulk edits, and plans needing several rounds of revision.
LangChain is moving complex workflows to a dedicated interface built around the agent. Slack remains for lightweight questions, recommendations, and approvals. The writeup's framing is that Slack works best for relatively focused decisions, while more complex workflows need a dedicated interface.
One question the writeup highlights as a natural fit for Slack is "What pipeline did we get for our ad spend?" That is the kind of focused, high-value question the thread-based interface handles well.
The Results and What Comes Next
The business results after six months: paid media at 20% of marketing pipeline, CPL down 30% from June to August, monthly spend up about 60% over the same period, LinkedIn CPL 40% lower than in January, and about $5K per month saved by in-housing analysis and reporting. The reporting workflow itself became about 40x cheaper and 13x faster, with runtime falling from 18 minutes to 85 seconds.
The writeup's summary of what worked: the strongest results came from giving the agent a well-designed workspace with sandbox, software, business context, and clear operating instructions. The way you design the agent's workspace deserves as much thought as the tools you give it. Reducing tokens, cost, and latency matters, but not if it makes the agent less capable. Those gains should be evaluated alongside completion rate and answer quality.
The questions the agent repeatedly struggles to answer reveal where cleaner joins, better definitions, or dedicated tools are worth building. That is the integration roadmap, derived from real usage rather than guesswork.
Next, LangChain wants to make the agent more proactive by continuously monitoring campaign performance, surfacing changes, and proposing experiments. The bigger opportunity is connecting learnings across go-to-market so that campaign engagement informs sales follow-up and pipeline progression informs ideal customer understanding. The goal is for GTM agents to contribute to the same shared knowledge and playbooks.
The company is also hosting a webinar, "GTM Engineering Live: How We Built Our Paid Media Agent," on September 23 at 11am Pacific.
The writeup points to related LangChain content: "Building a Harness with Jev" by Sydney Runkle and Hunter Lovell, published September 17, 2026 at a 5-minute read; "Organizing Context in a Multi-Agent Harness" by Thushanth Bengre and Chester Curme, published September 8, 2026 at a 6-minute read; and "MCP in LangChain: Stateless Protocol, Elicitation, and More!" by Sydney Runkle, published September 3, 2026 at a 5-minute read.