LangChain has published a detailed account of how it built an internal Paid Media Agent to run its own paid advertising, and the company says the system helped take paid media from 0 to 20% of marketing pipeline in six months. The company also open-sourced the agent.
The blog post, dated September 13, 2026 and running 19 minutes, is filed under Tutorials & How-Tos with the tag Agent Architecture. Its authors are Amal Irgashev, Danny Lambert and Jan Gomez. The post is a first-person case study, walking through design decisions, token costs, failure modes and lessons learned rather than a product announcement.
The headline numbers are striking for an in-house build. Cost per qualified lead fell 30% from June to August. Monthly spend rose about 60% over the same period. On LinkedIn, the company's largest social channel, CPL was 40% lower than in January. LangChain says it saved about $5K per month by bringing analysis and reporting in-house instead of using an agency.
The agent itself is long-running and lives in Slack. Every Monday, it combines ad-platform data with lead and pipeline data from LangChain's warehouse, then posts a summary and a branded PDF per platform explaining what changed, why, and what to do next. Team members can tag the agent in a thread to ask follow-up questions about campaigns, costs or pipeline. The agent can also propose new keywords, targeting changes, ad copy, or new search campaigns based on a playbook and encoded judgement.
The open-source release includes ad-platform tools, paid media skills, a sample wiki, reporting and approval workflows. LangChain says you can deploy it to Slack in one command with Managed Deep Agents. Managed Deep Agents is the managed service that handles hosting, sandboxes, Slack integration and schedules. LangSmith Deployment handles hosting, scaling and scheduled runs. LangSmith itself is described as LangChain's agent engineering platform for debugging agent decisions, evaluating changes and deploying in one click. The post's call to action is to try LangSmith or get a demo.
LangChain will hold a webinar titled "GTM Engineering Live: How We Built Our Paid Media Agent" on September 23 at 11am Pacific. The session is meant to demo the agent and walk through the code.
From Organic Growth to Five Paid Channels
For its first three years, LangChain's sales pipeline grew largely organically. Open source, content, YouTube, community and meetups carried the load. In January, the company decided it wanted to kickstart paid advertising to reach new regions and enterprise decision makers. The goal was to scale from an organic growth engine to five paid channels in six months.
That ambition ran into familiar problems. Each ad platform had a different data schema. Campaign parameters did not map cleanly to outcomes such as sales inquiries, signups and content downloads. And campaign volume kept rising. LangChain built the agent to track product announcements, draft campaigns, add keywords, test variations, and surface proposed experiments for approval.
The post frames the agent as a continuous learning loop: analyze performance, make a change, observe the outcome, capture the learning, apply the insight. The company says the way it designs an agent's workspace deserves as much thought as the tools it hands over. Its stated principle is that a coding agent is a knowledge worker, and that the strongest results come from a well-designed workspace with a sandbox, software, business context and clear operating instructions.
The stack reflects that. The agent uses LangChain's Deep Agents as its harness. Deep Agents manages access to files, code execution and working memory, and gives the model tools to plan, delegate to subagents and manage context. Every run has a LangSmith Sandbox available by default, an isolated microVM with a 32 GB disk and a shell. The sandbox is equipped with pandas and DuckDB for analysis, openpyxl for spreadsheets, and WeasyPrint and Jinja2 for generating reports.
Working data and business knowledge live in Markdown across six skills and a nineteen-page wiki. LangChain baked the software and business wiki into a snapshot, a saved image, to reduce average startup time by 10 seconds.
Context is split into five layers: system prompt, skills, wiki, live tools and deterministic code. The system prompt is deliberately small. It holds a one-sentence role description and three short sections covering how to operate, where numbers come from, and how to present results, plus pointers to other resources. The post describes the system prompt as a map that helps the agent find what it needs without carrying everything in context.
The six skills are 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 intent, data source ownership and past decisions, including what the company decided in July. 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, such as a rule preventing the agent from cutting the top pipeline driver after one bad week.
The distinction between the two knowledge layers matters. Skills explain how to do work and are reusable. The wiki contains company-specific context. LangChain's test is blunt: a skill should "work at another company," whereas the wiki should not. The post calls the line between skills and the wiki the hardest one to draw. The approach follows a pattern from Karpathy's LLM wiki note and LangChain's own Wiki Memory.
The first architecture had two agent graphs. A weekly report agent was scheduled, artifact-heavy and built on a Deep Agent with a sandbox, a large model and PDF generation. A 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. Capabilities were duplicated. Feature parity slipped. Slack could not process attachments or answer follow-ups on the Monday reports. The post is direct about the mistake: the team treated the two as separate products when they were two entry points into the same analysis.
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. It is the same runtime 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 the report PDF and answer follow-up questions in the thread.
Six Lessons From the Build
The first version of the weekly analysis loaded every campaign row, keyword, pipeline record and landing-page check into context. 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.
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 connecting evidence, explaining causes, evaluating campaigns against goals and recommending next steps. Moving calculations into code and removing unnecessary model calls made the early reporting workflow about 40x cheaper and 13x faster, with runtime dropping from 18 minutes to 85 seconds.
The broader claim is that models should be used for judgement and code for consistency. Calculations, source-of-truth rules and safeguards are better in code, which makes the agent faster, cheaper and more reliable.
Six platforms meant six sets of IDs, conversion definitions, attribution windows and campaign hierarchies. LangChain defined a source of truth for each metric. Ad platforms are authoritative for media activity such as spend, impressions and clicks. The warehouse is authoritative for downstream outcomes such as leads, opportunities and pipeline.
That rule exposed real gaps. Google video campaigns did not map cleanly into the warehouse because the warehouse joined on keywords, and video campaigns lack keywords. About 10% of Google spend was missing from the warehouse. Meta could report that an ad generated a conversion, but the warehouse was better at identifying the conversion type, for example "Contact Sales" versus "Sign Up."
The rules are encoded in the wiki, and tools that would query the wrong system were removed. When data cannot be joined reliably, the agent preserves the limitation and includes the source, date window and attribution model in its answers. The post's guidance is that you do not need one perfect data model before an agent can work across systems. Define the authoritative source per metric, make the rules explicit, and preserve uncertainty.
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
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 before the agent 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 small interface for finding tools. The Pipeboard catalog 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 gained 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, 4x cheaper than loading every schema while maintaining the same judged quality. The catalog has nearly tripled since then, and the context cost has stayed roughly consistent.
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. The lesson is to give the agent a way to find and query capabilities on demand instead of putting every tool into context upfront.
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. They 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 the parent context small while giving each platform its own context window.
Separate context windows did not automatically produce full isolation. Two subagents wrote reports to the same location and shared the same "done" flag. The first to finish set the flag, and the second mistook that state for its own and stopped without producing a report. The fix was to give each platform its own report location and completion state.
A second isolation failure was subtler. A subagent got stuck verifying its own work. It could not determine whether the PDF had rendered, kept checking files, burned tokens, and eventually tried to build the PDF from scratch. Subagents now get only three tools: read context, compute, render. If render succeeds, the job is done. The post's summary 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: add a keyword, update geographic targeting, create a new search campaign. Permissions are explicit. Teams outside paid media can ask questions, but only designated team members can edit or approve campaign changes. The server checks Slack user IDs. Everyone else is blocked and the proposal remains pending.
A 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 post argues that an agent that only analyzes performance is ultimately a better dashboard. Closing the loop requires more than write access. It requires a clear action path with permissions, approvals and verification.
Slack worked well as the first interface because the approval card lives in the same thread as the analysis and discussion. 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 and keeping Slack for lightweight questions, review and approval. Slack works best for relatively focused decisions, the post says, and is harder for complex workflows.
What the Agent Answers, and What It Costs
The agent's Monday output is designed to answer the question that matters to a marketing team. In the post's words, the team wants to know: "What pipeline did we get for our ad spend?"
That question is why the warehouse work matters. LangChain connects campaign activity and website conversions to leads, opportunities and pipeline in BigQuery, with opportunities data referenced from Salesforce. The agent combines ad-platform data with that warehouse view, then posts the summary and branded PDFs per platform.
The results LangChain reports are cumulative and comparative. Paid media went from 0 to 20% of marketing pipeline in six months. CPL fell 30% from June to August. Monthly spend rose about 60% over the same window. LinkedIn, the largest social channel, saw CPL 40% lower than in January. The company also says it saved about $5K per month by bringing analysis and reporting in-house instead of using an agency.
The token and runtime numbers in the post are unusually specific. The first weekly analysis version processed about 3.9 million input tokens per report on a frozen test set, took 1,112 seconds, and cost just over $3. After the redesign, the early reporting workflow became about 40x cheaper and 13x faster, with runtime dropping from 18 minutes to 85 seconds.
The tool catalog tells a similar story. In June, loading a smaller read-only catalog cost 38,000 tokens before the agent read the user's question. The Search, Read and Run interface brought the first turn down to about 12,000 tokens, 4x cheaper than loading every schema at the same judged quality. The catalog has nearly tripled since then, and context cost has stayed roughly consistent.
LangChain's stated position is that reducing tokens, cost and latency matters, but not if it makes the agent less capable. Those metrics should be evaluated alongside completion rate and answer quality. The post also argues that the context window is often the bottleneck, not the model, and that many apparent reasoning failures are context failures. The naive approach of putting all context in the system prompt leads to an overly long, expensive, stale prompt.
Design Principles and What Comes Next
LangChain also notes that different agents need different computers. A content generation agent might need a sandbox that looks like a video editing workstation. A finance agent might need openpyxl and DuckDB. The workspace deserves the same care as the tool list.
The company says it found that the agent could answer questions it had never built explicit workflows for by combining what was already on its desktop. That is the payoff of the context design: skills, wiki, live tools and deterministic code arranged so the agent can assemble an answer rather than follow a script.
Looking ahead, LangChain wants the agent to become more proactive by continuously monitoring campaign performance, surfacing changes and proposing new experiments. The bigger opportunity, in the company's view, is connecting learnings across go-to-market. Campaign engagement could inform sales follow-up. Pipeline progression, sales conversations and deal outcomes could improve the understanding of the ideal customer and influence the next campaign. The goal is for GTM agents to contribute to the same shared knowledge and playbooks so learnings improve targeting, messaging and experimentation across the funnel.
The post sits alongside related LangChain content. "Building a Harness with Jev" by Sydney Runkle and Hunter Lovell was published September 17, 2026 and runs 5 minutes. "Organizing Context in a Multi-Agent Harness" by Thushanth Bengre and Chester Curme was published September 8, 2026 and runs 6 minutes. "MCP in LangChain: Stateless Protocol, Elicitation, and More!" by Sydney Runkle was published September 3, 2026 and runs 5 minutes.
For teams weighing an in-house paid media agent, the LangChain post offers a concrete ledger. The agent lives in Slack, runs on a schedule, writes PDFs, answers follow-ups, proposes changes behind an approval gate, and verifies that approved changes landed. The company's own framing is that agents should be treated like knowledge workers, and that the strongest results come from a well-designed workspace with a sandbox, software, business context and clear operating instructions.
The open-source release means other teams can test that framing against their own ad accounts. The code includes the ad-platform tools, the paid media skills, a sample wiki, reporting and approval workflows. The one-command Slack deployment with Managed Deep Agents lowers the setup cost. The harder work, based on LangChain's account, is the context design: deciding what belongs in a skill, what belongs in the wiki, what belongs in code, and what the agent should be allowed to do without a human in the loop.