LangChain published a blog post on September 13, 2026 detailing how it built an internal Paid Media Agent, open-sourced the system, and cut the cost of its weekly reporting workflow by 40x while making it 13x faster. The post, estimated at a 19 minute read and categorized under Tutorials & How-Tos and Agent Architecture, was written by Amal Irgashev, Danny Lambert, and Jan Gomez. It describes a long-running agent that lives in Slack, runs every Monday, and now manages a paid advertising program that went from 0 to 20% of marketing pipeline in six months.
The company's sales pipeline grew organically for its first three years through open source, content, YouTube, community, and meetups. In January, LangChain started a paid advertising program to reach new regions and enterprise decision makers, with a goal of scaling from organic to five paid channels in six months. A small marketing team had to track campaigns, creative and targeting experiments, and performance data across every channel, each with its own data schema. Campaign parameters did not map cleanly to outcomes like sales inquiries, signups, or content downloads. Product release cadence accelerated, increasing campaign volume and management complexity.
The agent was built to track product announcements, draft campaigns, add keywords, test variations, and surface proposed experiments for approval. It operates as a continuous learning loop: analyze performance, make a change, observe the outcome, capture learnings, apply insights. LangChain open-sourced it as a starting point for others.
A Knowledge Worker With Its Own Computer
The team built the agent around the principle that a coding agent is a knowledge worker. They treated it like a new paid-media analyst, giving it a computer, software, data access, and documentation. "We wanted an agent that could handle questions we hadn't anticipated, produce numbers we could verify, and act on what it found," the authors wrote.
The foundation is the agent harness. LangChain used its own Deep Agents as the agent harness, which manages access to files, code execution, and working memory and gives the model tools to plan, delegate to subagents, and manage context. Deep Agents provides hosting, sandboxes, Slack integration, and scheduling. Paid-media tools, skills, and business knowledge are layered on top.
Each run gets a LangSmith Sandbox: an isolated microVM with a 32 GB disk and a shell for running commands. The sandbox is equipped with pandas and DuckDB for analysis, openpyxl for spreadsheets, and WeasyPrint and Jinja2 for reports. Business knowledge is stored in Markdown across six skills and a nineteen-page wiki. Software and the wiki are baked into a snapshot, which reduces average startup time by 10 seconds.
The sandbox is compared to a computer, and different agents need different computers. A content generation agent's sandbox might have a headless browser, ffmpeg, media tools, and a brand book. A finance agent might need openpyxl and DuckDB. "Different agents need different computers; the job determines how you design the computer," the authors wrote. "The way you design the agent's workspace deserves as much thought as the tools you give it."
Context is split into five layers ordered by how quickly each changes: system prompt, skills, wiki, live tools, and deterministic code. The system prompt starts with a one-sentence role description, followed by three short sections covering how to operate, where numbers come from, and how to present results, plus pointers to other resources. Skills are six folders of instructions, progressively disclosed at runtime. The agent initially sees only each skill's title and description. The wiki is nineteen pages explaining the funnel, campaign goals, data source ownership, and past decisions, including what the team decided in July. Live tools account for 218 calls for spend, settings, and pipeline data fetched at request time. Deterministic code handles calculations, date windows, account matching, and hard safeguards, such as a rule preventing the agent from cutting the top pipeline driver after one bad week.
The authors call the boundary between skills and the wiki the hardest line to draw. Their test: a skill should "work at another company," whereas the wiki should not. They reference Karpathy's LLM wiki note and their own Wiki Memory as inspiration for the wiki approach.
The first version of the weekly analysis used the model for everything. It loaded all data into context, and the model calculated spend, week-over-week changes, classified performance, and wrote 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.
Now Python 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 authors frame the split simply: use models for judgment and code for consistency. Calculations, source-of-truth rules, and safeguards are better handled in code. Moving calculations to code made the early reporting workflow 40x cheaper and 13x faster, with runtime dropping from 18 minutes to 85 seconds.
The agent runs weekly on Mondays. It combines ad-platform data with lead and pipeline data from the warehouse, then posts a summary and a branded PDF per platform in Slack. Team members can tag the agent in a Slack thread for follow-up questions. The agent can propose new keywords, targeting changes, ad copy, or new search campaigns based on the playbook and encoded judgment.
Six Platforms, Two Sources of Truth
The agent works across six platforms with different IDs, conversion definitions, attribution windows, and campaign hierarchies. 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 serves as the warehouse for lead, opportunity, and pipeline data, and Salesforce is the source of opportunities and pipeline data.
Reconciling the two is not always clean. About 10% of Google spend was missing from the warehouse because video campaigns lack keywords for joining. Meta could tell that an ad generated a conversion, but the warehouse better identified the conversion type, for example "Contact Sales" versus "Sign Up." Source-of-truth rules are encoded in the wiki, and tools that would 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 team's guiding question throughout this work was simple, as the authors put it: "What pipeline did we get for our ad spend?"
The authors argue that you do not need one perfect data model before an agent can work across systems. Instead, define which source is authoritative for each metric. "We found that the agent could answer questions we had never built explicit workflows for by combining what was already on its desktop," they wrote.
Pipeboard's MCP exposes more than 200 ad-platform tools. In June, a smaller read-only catalog required 38,000 tokens just to load tool names, descriptions, and arguments. The solution was three tools for the Pipeboard catalog: Search, which finds up to eight tools; Read, which loads the full schema for a selected tool; and Run, which executes a tool. Campaign writes use a separate approval-gated path. Warehouse tools were reduced to Describe, for available tables and fields, and Run, for analytical queries.
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
The catalog brought the first turn down to about 12,000 tokens, 4x cheaper than loading every schema while maintaining the same judged quality. The catalog has nearly tripled since then, and context cost has stayed roughly consistent. The lesson: give the agent a way to find and query capabilities on demand instead of putting every tool into context upfront.
The team 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.
One Graph, Two Entry Points
LangChain originally built two agent graphs. The weekly report agent was scheduled, artifact-heavy, and used 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 five weeks because of duplicated effort and limitations.
Now there is one graph, instantiated fresh per request 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 mistake was treating them as two products; they are two entry points into the same analysis," the authors wrote. "Use one runtime with a capability profile for each entry point."
The system is hosted on LangSmith Deployment, which handles hosting, scaling, and scheduled runs. LangSmith is described as an agent engineering platform for debugging, evaluating, and deploying agents.
The team tested three architectures for multi-platform analysis: one isolated run per platform, one agent for all platforms, and a parent agent delegating to subagents per platform. Separate runs performed worst, producing multiple Slack messages and struggling to synthesize cross-channel performance. LangChain chose the parent-plus-subagents architecture to keep the parent context small and give each platform its own context window.
Isolation brought its own problems. Two subagents writing to the same location and sharing a "done" flag caused one to stop early. The fix was giving each platform its own report location and completion state. A subagent also got stuck verifying its own work, burned tokens, and tried to build a PDF from scratch. The fix was giving subagents only three tools: read context, compute, and render.
The authors' conclusion is blunt: a subagent gives you a separate context window, and the rest of the isolation model is up to you. They also note that the context window is often the bottleneck, not the model, and that many apparent reasoning failures are actually context failures.
Approvals, Permissions, and the Limits of Slack
The agent can propose changes in Slack, such as adding a keyword, updating geographic targeting, or creating a new search campaign. Only designated team members can edit or approve campaign changes, and the server checks Slack user IDs. 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.
Slack works well for focused decisions but is harder for complex workflows involving many ad groups, bulk edits, or multiple revision rounds. LangChain is moving complex workflows to a dedicated interface while Slack remains the place for lightweight questions, recommendations, and approvals. The authors stress that closing the loop requires more than write access. The agent needs a clear action path with permissions, approvals, and verification.
The Numbers Behind the Program
The paid media program produced measurable results. Paid media went from 0 to 20% of marketing pipeline in six months. Cost per qualified lead fell 30% from June to August, while monthly spend rose about 60% in the same period. On LinkedIn, the largest social channel for LangChain's paid media, CPL was 40% lower than in January. Bringing analysis and reporting in-house instead of using an agency saved about $5K per month.
The agent is open-sourced, including ad-platform tools, paid media skills, a sample wiki, reporting, and approval workflows. It can be deployed to Slack in one command with Managed Deep Agents. LangChain will demo the agent and walk through code and design decisions in an upcoming webinar, GTM Engineering Live: How We Built Our Paid Media Agent, on September 23 at 11am Pacific.
The authors close with a set of operating principles. Treat agents like knowledge workers and give them a well-designed workspace with a sandbox, software, business context, and clear instructions. Use models for judgment and code for consistency. Design agents around the full workflow: find tools, work within permissions, and move from analysis to action. Use abstractions to focus on the agent's job, since Managed Deep Agents handles hosting, sandboxes, Slack integration, and schedules. Optimize for whether the agent can finish the job, because reducing tokens, cost, and latency matters only if it does not make the agent less capable. Let real usage show where integrations need improvement. And over time, LangChain wants its GTM agents to contribute to the same shared knowledge and playbooks.