AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。
Tutorials & How-Tos Agent Architecture How we built LangChain's Paid Media Agent September 13, 2026 19 min Go back to blog Create agents Key Takeaways Treat agents like knowledge workers. The strongest results came from giving the agent a well-designed workspace with a sandbox, software, business context, and clear operating instructions. The system prompt became a map that helped the agent find what it needed without carrying everything in context. Use models for judgment and code for consistency. Calculations, source-of-truth rules, and safeguards were better handled in code. That made the agent faster, cheaper, and more reliable, while the model focused on interpreting results and recommending what to do next. Design agents around the full workflow. The agent needed to find the right tools, work within clear permissions, and move from analysis to action. That meant proposing campaign changes, routing them through human approval, and verifying that the changes were applied correctly. For LangChain’s first three years, our sales pipeline grew largely organically, driven by open source, content, YouTube, community, and meetups. In January, we wanted to kickstart our paid advertising program to start connecting with prospects we weren’t reaching organically, such as those in new regions and enterprise decision makers. We wanted to scale from a largely organic growth engine to five paid channels in just six months. This created new challenges for our small marketing team. We had to keep track of new campaigns launching across channels, different creative and targeting experiments, and a growing volume of performance data to understand and act upon. In order to scale and optimize, we had some technical hurdles to overcome. Each advertising platform has its own data schema, making it difficult to reconcile performance across channels. Campaign parameters also do not map cleanly to the outcomes we ultimately care about, such as sales inquiries, signups, or content downloads. As our product release cadence as a company accelerated and the number of campaigns grew, keeping track of what was running, what was working, and what to try next became increasingly difficult to manage manually. We set out to build an agent that could help manage that complexity. It would track new product announcements, draft campaigns, add keywords, test variations, and surface proposed experiments to the team for approval. Over time, it would operate as a continuous learning loop: analyze performance, make a change, observe the outcome, capture what it learned, and apply those insights for future campaigns. Our goal was to make the marketing team more productive while continuously improving campaign performance. In this post, you’ll learn how our paid media agent works, how it supports the marketing team, and what we learned about agent engineering while building it. We’ve open-sourced our Paid Media Agent, so you can use it as a starting point for your own. You can also join GTM Engineering Live: How We Built Our Paid Media Agent on September 23 at 11am Pacific. In this webinar, we’ll demo the agent, walk through the code and design decisions, and answer questions about applying these patterns to your own agents. Key results Paid media went from driving 0 to 20% of our marketing pipeline in six months. Cost per qualified lead (CPL) fell 30% from June to August, while monthly spend rose about 60%. On LinkedIn, our largest social channel, CPL was 40% lower than it had been in January. We saved about $5K per month by bringing analysis and reporting in-house instead of relying on an agency. We also optimized the agent itself by moving calculations into code and removing unnecessary model calls, making an early reporting workflow about 40x cheaper and 13x faster, with runtime dropping from 18 minutes to 85 seconds. What we built The Paid Media Agent is a long-running agent that lives in Slack. Every Monday, it combines ad-platform data with lead and pipeline from our warehouse. It posts a summary and a branded PDF for each platform explaining what changed, why, and what the team should 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 our playbook and encoded judgement. How we built it We built this agent around a simple principle: a coding agent is a knowledge worker. Knowledge work often involves reading files, transforming information, running analyses, and writing things down. A coding agent also does these tasks with files and a shell. We treated the agent like a new paid-media analyst. We gave it a computer, the software it needed to do the job, access to our data, and documentation about how our business works. The Operating System We used LangChain Deep Agents for our agent harness so we didn’t have to build core agent infrastructure from scratch. Just like an operating system, 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 as tasks become more complex. This foundation is the agent harness. We layer our paid-media tools, skills, and business knowledge on top. The Computer Every run has a LangSmith Sandbox available by default. It’s an isolated microVM with a 32 GB disk and a shell for running commands. The sandbox gives the agent a safe, isolated environment to execute code and work with files without affecting other runs or the underlying system. We equip it with pandas and DuckDB for analysis, openpyxl for spreadsheets, and WeasyPrint and Jinja2 for generating reports. Alongside that software are its working data and business knowledge, stored in Markdown across six skills and a nineteen-page wiki. To keep startup fast, we bake the software and business wiki into a snapshot, a saved image that the sandbox starts from. This reduced the average startup time by 10 seconds. 💡 Different agents need different computers. Our content generation agent's sandbox looks more like a video editing workstation, with a headless browser, ffmpeg, media tools, and a brand book. A finance agent might need openpyxl for spreadsheets and DuckDB for heavier data processing. The job determines how you design the computer. Providing the right context Once the agent had a computer, the next challenge was giving it the right context. A human analyst needs to understand their role, the methods they use, the company they work for, what is happening right now, and the rules they need to follow. The naive approach is to put all of that in the system prompt. However, that would lead to a prompt that is overly long, expensive to carry into every run, and likely to go stale. A better way to think about the problem is that the context window is often the bottleneck, not the model. Many apparent reasoning failures are actually context failures. Either the model is missing the right information, or too much irrelevant information is competing for its attention. Instead of treating the prompt as the place where knowledge lives, we treat it as a map. Knowledge lives in structured files with predictable locations, and the agent loads only the context required for the task at hand. 💡 The way you design the agent’s workspace deserves as much thought as the tools you give it. We found that the agent could answer questions we had never built explicit workflows for by combining what was already on its desktop. It had a playbook to guide the investigation, campaign data to work with, and libraries to analyze it. Designing that workspace became part of designing the agent itself. We split context into five layers, and describe each below (ordered by how quickly each one changes): System prompt: Defines the agent’s role and navigation. Ours starts with a one-sentence description of the agent’s role, followed by three short sections: how to operate, where numbers come from, and how to present results. Everything else is a pointer for the agent, e.g. the playbook lives here, the wiki there, read the index first. The prompt tells the agent where to find what it needs. Skills: Six folders of instructions that are progressively disclosed at runtime. The agent initially sees only the title and description for each. Wiki: Nineteen pages explaining how our funnel works, what each campaign is intended to accomplish, which data source owns which number, and what decisions the team has made and why. Live tools: Spend, settings, and pipeline change daily, so the agent fetches them at request time. We have 218 such calls. More on how we keep that from bloating context below. Deterministic code: We use code for anything that should be consistent and reproducible, including calculations, date windows, account matching, and hard safeguards. For example, a rule preventing the agent from cutting a top pipeline driver after one bad week is enforced in code, so the model cannot override it. The hardest line to draw is between skills and the wiki. A skill explains how to do the work: read the data, run the numbers, write the report, prepare a change, and apply the playbook for interpreting paid-media performance. It contains nothing specific to our campaigns. The wiki is everything specific to LangChain: which campaign is for awareness, which should drive demo requests, what we decided in July, and why. 💡 A skill should ‘work at another company’, whereas the wiki should not. In other words, skills capture reusable ways of working, while the wiki contains the company-specific context those skills need to operate. This follows the pattern from Karpathy's LLM wiki note and our own Wiki Memory. Unifying the agent architecture We originally built two agent graphs because the user experiences looked different: The weekly report agent was scheduled and artifact-heavy. It used a Deep Agent, sandbox, large model, and PDF generation. Slack needed answers in seconds, so it used a lightweight loop on a cheaper model, with Google Ads and warehouse tools, no sandbox, and read-only access. That split only lasted five weeks. Every new capability had to be implemented twice. Features reached Slack and the report at different times. Slack could not process attachments because it had no sandbox, and it could not answer follow-ups on Monday reports because those PDFs came from another graph. The mistake 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. We instead isolate state and capabilities for each request. Each thread gets its own sandbox and checkpoint, and each run sees only the tools it needs. Now there is one graph, instantiated fresh for every 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. And because Slack now shares the same sandboxed architecture, the agent can also open a report PDF and answer follow-up questions in the thread that produced it. 💡 The takeaway: Use one runtime with a capability profile for each entry point. The same factory can give different users different skills and permissions. Key technical lessons Putting the agent to work taught us five lessons about getting the numbers right, answering questions we had not anticipated, and turning analysis into action. 1. Use the model for judgement, not computation Our first version of the weekly analysis asked the model to do everything. We loaded every campaign row, keyword, pipeline record, and landing-page check into cont [truncated for AI cost control]