What LangChain's Paid Media Agent Teaches About Splitting Judgment From Computation

A marketing team's six-month production agent turned out to be the clearest lesson of the year in how to build one

The most useful agent-engineering document published this month came from a marketing team, not an ML lab. On September 13, LangChain open-sourced the Paid Media Agent it had been running in production for six months, along with a build report that reads less like a launch and more like a postmortem of every decision that went wrong before it went right. The headline numbers are good. Paid advertising went from zero to twenty percent of the company's marketing pipeline. Cost per qualified lead fell thirty percent between June and August. One weekly reporting workflow dropped from eighteen minutes and just over three dollars to eighty-five seconds, roughly forty times cheaper.

But the numbers are not the lesson. The lesson is the one architectural decision that produced them, and it is a decision you can copy today without a marketing budget, a LangChain subscription, or a single line of their code.

That decision is a division of labor. The model does judgment. Code does anything that has to be reproducible. Everything hard about building a reliable agent turns out to be a variation on drawing that line in the right place.

The version that worked, and the version that didn't

LangChain's first version of the weekly analysis did what most first versions do. It handed the model everything. Every campaign row, every keyword, every pipeline record loaded into context, and then a single prompt asked the model to calculate spend, compute week-over-week changes, classify each campaign's performance, and write the report.

It worked. It was also, in their words, inefficient in a way that matters. One report burned about 3.9 million input tokens, because the model had to read all that raw data and then work through the arithmetic itself, over and over. A single run took 1,112 seconds and cost just over three dollars. Worse than the cost was the trust problem: the model was recomputing the underlying numbers every time, which means the numbers could drift every time.

The fix was not a better prompt or a bigger model. It was moving work out of the model. Python now fetches the data, aligns the date windows, calculates the totals and the comparisons, applies the fixed rules, and writes a compact set of results to a file. The model reads that file and does the part it is actually good at: connecting the evidence, explaining the likely cause of a shift, judging whether a campaign is meeting its goal, and recommending what to do next.

Same job. The model went from doing the accounting and the analysis to doing only the analysis. That is the forty-times-cheaper report.

Why "judgment versus computation" is the right cut

It is tempting to read this as a cost-optimization trick, and it is one. But the deeper reason it works is about reliability, and it generalizes far past ad spend.

A language model is a probabilistic instrument. Ask it to sum a column of numbers and it will usually be right and occasionally, silently, be wrong. There is no exception it can raise, no failed assertion, just a plausible number that happens not to match reality. Ask the same model to look at a correct summary and explain why cost per lead jumped last week, and you are using it for the thing it is built to do: weigh incomplete evidence and produce an interpretation.

So the cut is not really "cheap work versus expensive work." It is "work with one correct answer versus work with a defensible answer." Anything with one correct answer belongs in code, because code gives you the same answer every run and fails loudly when it can't. Anything that calls for interpretation belongs in the model, because that is the only place interpretation can happen.

LangChain enforces this literally. A rule that stops the agent from cutting a top pipeline driver after one bad week lives in code, not in the prompt, "so the model cannot override it." That sentence is the whole philosophy. A guardrail written into a prompt is a request. A guardrail written into code is a constraint. If the outcome has to hold every time, it cannot depend on the model choosing to honor it.

The second cut: the prompt is a map, not a container

The judgment-versus-computation split has a sibling, and it solves the other failure mode everyone hits: the context window fills up with things the model does not need for the task in front of it.

The naive move is to put everything the agent might need into the system prompt. Role, methods, company facts, current data, rules. LangChain calls this what it is, a prompt that is "overly long, expensive to carry into every run, and likely to go stale." Their reframing is worth quoting because it is the correction most builders need: the context window is the bottleneck, not the model, and many apparent reasoning failures are actually context failures where the model is either missing the right information or drowning in irrelevant information.

Their answer is to treat the system prompt as a map instead of a warehouse. It carries the agent's role and a set of pointers: the playbook lives here, the wiki lives there, read the index first. Knowledge itself lives in structured files with predictable locations, and the agent loads only what the current task needs. They split it into layers ordered by how fast each one changes: the system prompt at the top, then skills (folders of instructions disclosed at runtime, where the agent first sees only a title and description), then a wiki of company-specific facts, then live tools for data that changes daily, then deterministic code for the things that must never drift.

There is a clean test buried in this for deciding where a piece of context belongs. A skill, they say, should "work at another company." The wiki should not. Skills capture reusable ways of working; the wiki captures the specific facts your skills operate on. If you are ever unsure whether something belongs in a reusable instruction or a project-specific note, ask whether it would still be true at a different company. That single question sorts most of it.

The third cut: let the agent find tools instead of loading them

The most concrete, immediately stealable piece is how they handle tools. The paid-media agent needs a lot of them. One integration alone exposed more than two hundred ad-platform tools. Loading even a read-only slice of that catalog cost about 38,000 tokens just to describe the available tool names and arguments, before the agent had read a single word of the user's question. Most of that was irrelevant to any one request.

So they stopped loading the catalog and gave the agent a way to search it. Three tools sit in front of the whole thing: search finds up to eight relevant tools for the question, read loads the full schema for only the selected one, and run executes it. Writes that change a live campaign go down a separate, approval-gated path.

The result: the first turn dropped from 38,000 tokens to about 12,000, roughly four times cheaper, at the same judged quality. And the property that makes this worth adopting is that it holds as you grow. Their catalog has nearly tripled since, while the context cost per turn stayed roughly flat, because the agent still only ever loads the handful of tools a given question needs.

If you have ever watched an MCP-heavy setup spend its whole budget describing tools nobody called, this is the pattern that fixes it. Do not put the tools in the context. Put a search over the tools in the context.

Put this into practice

You do not need the repo to use any of this, but it helps to have it open. LangChain open-sourced the agent under Apache 2.0, and there is an offline demo that runs with no model key and no ad accounts: uv run paid-media-agent demo --with-proposal runs a scripted analysis against synthetic data. Clone it to read the assembly, not to run your ad spend.

The lowest-friction way to apply the ideas to your own agent is to work through them in order.

Start by listing everything your agent currently does inside the model and marking each item as judgment or computation. Totals, date math, joins, threshold checks, formatting, ID matching: all computation. Move them into a function the agent calls, and have that function write results to a file the model reads. You will usually find your token count and your error rate drop together.

Next, take one hard rule you are currently expressing in the prompt, the "never do X" you keep reminding the model about, and move it into code that the model physically cannot route around. A prompt rule is advisory. Make the one rule you actually care about a real constraint.

Then look at your system prompt and ask how much of it is knowledge versus how much is a map to knowledge. Pull the stable facts out into files the agent loads on demand, and leave pointers behind. Apply the "would this be true at another company" test to decide what is a reusable skill and what is project-specific.

Finally, if your agent carries more than a dozen or so tools, replace the wall of tool definitions with a search-read-run interface. Even a crude version, where "search" is a keyword match over tool descriptions, will pay for itself the first time a request only needs two of your forty tools.

The honest limitations

This is a field report from one team on one workload, and it should be read that way. Marketing analytics is a domain where the judgment-versus-computation line is unusually easy to draw, because the computations are mostly arithmetic over tabular data. In a domain where the "computation" is itself fuzzy, say, deciding whether two customer records refer to the same person, the line blurs and some of the clean separation LangChain describes gets harder to reproduce.

The performance numbers are self-reported and come with a natural incentive: the post exists partly to sell LangSmith and Managed Deep Agents, which is the recommended and paid deployment path. Live writes to real ad accounts are off by default and gated behind a configured policy and human approval, which is the right default but also means the "agent takes action" story is more supervised than the framing suggests. And the forty-times-cheaper figure is a comparison against their own worst first draft, not against a well-built baseline, so read it as "how much they saved by fixing an obvious mistake" rather than a benchmark against other architectures.

There is also a subtler caveat. Moving work into code makes the agent cheaper and more reliable, but it moves the fragility, it does not remove it. The bugs LangChain describes at the end, two subagents sharing a "done" flag and suppressing each other's reports, a subagent burning tokens trying to verify its own output, are all in the code and the orchestration, not the model. You are trading a class of probabilistic errors for a class of deterministic ones. That is a good trade. It is still a trade.

What to take from it

The reason this post traveled is that it is not really about paid media, and it is not really about LangChain's stack. It is about a way of thinking that any builder can adopt: the model is a colleague you give a workspace, not an oracle you pour everything into. You decide what it should reason about and what it should never be asked to compute. You give it a map to its knowledge instead of the whole library. You let it find its tools instead of memorizing them.

Draw those three lines well and you get most of the reliability and most of the savings. Draw them badly and you get a 3.9-million-token report that might have the numbers wrong. The model is the same in both cases. The difference is entirely in what you decided to hand it.

Sources: How we built LangChain's Paid Media Agent (LangChain, September 13, 2026); open-paid-media-agent repository (Apache 2.0).

Medium metadata

Title: What LangChain's Paid Media Agent Teaches About Splitting Judgment From Computation
Subtitle: A marketing team's six-month production agent turned out to be the clearest lesson of the year in how to build one
Tags: AI Agents, LangChain, LLM, Agent Architecture, Software Engineering
Recommended feature image: a split panel, one side a calculator and spreadsheet grid, the other side a thought bubble, with a clean dividing line down the middle
Canonical: publish to fervorai.dev first, import to Medium via canonical URL