Talk by Katelyn Lesse and Angela Jiang of Anthropic arguing that agent tokens are not fungible and should be assigned distinct jobs rather than simply given bigger budgets. Using a fixed ~600,000-token budget on a financial analysis benchmark, they compare strategies: an advising strategy (an executor that consults a separate adviser mid-task), a grading strategy (a rubric-defined grader scores attempts and sends the executor back to iterate), and a dreaming strategy (reading the executor's transcripts, writing findings to memory for the next run). An advice-using agent scored 89 versus 76 for pure execution under the same budget. When the benchmark is rescored so anything short of a perfect run counts as failure (an 80% accurate P&L is useless), the execute baseline passes about 42% of the time, requiring roughly three runs (~1.8 million tokens true cost), while advise and grade reach the same result for less; the winning strategy depends on whether token efficiency or single-run reliability is the goal. # Channel Identity Observations — Video: "Tokens Should Have Jobs" ## Speaker Self-Identification (Explicit Claims) - **Speakers identify as Anthropic platform leaders**: > "I'm Caitlyn and I lead platform engineering at Anthropic" and > "I'm Angela. I lead platform product at Anthropic." - The two speak as representatives of a team: > "a concept that we've been spending a lot of time thinking about and working on with our team." ## Intended Audience - Addressed to **engineers building agentic systems**: > "if you're building an agentic system and you're trying to accomplish some specific outcome... you're trying to get something done with agents." - Delivered at a **developer/AI engineering conference**: > "We're super excited to be here at AI Engineer with all of you." - Recurring second-person framing targeting builders and businesses: "What does this mean for you as a business?" ## Claimed Scope of Content - **Core conceptual thesis**: > "tokens are not fungible" — tokens can be assigned distinct "jobs" (executing, advising, grading, "dreaming") within a fixed budget. - **Strategy framework presented**: - **Advising**: executor can "call out to an adviser for advice." - **Grading**: rubric-based evaluation — "you can have a grader provisioned that grades how well the executor did." - **Dreaming**: "the dreamer is actually able to inspect the work and the transcripts of the executor... writes them to memory." - **Experimental evidence claimed**: a benchmark of financial-analysis tasks ("we created a bench of a bunch of tasks related to financial analysis") with reported numbers (e.g., execute 15% oneshot accuracy; "execute went from 0.15 to 76"; "advise is at 89"; 600,000-token fixed budget; ~1.8 million "true total token cost" for execute). ## Product/Platform Presentation - Promotes an Anthropic platform offering: > "cloud managed agents which is our [ag]entic solution that we give to you within the cloud platform" (transcript renders Claude as "cloud"). - Claims some strategies ship out of the box: > "some of these... like dreaming and outcomes we actually give to you out of the box within cloud manage agents." - Claims extensibility: > "you could also invent completely new jobs" and construct "really complex setups." - Forward-looking product claim: > "a big goal that we have over time is to get our models better and better and our platform better and better at dynamically constructing these strategies for you." ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Business-decision framing**: concrete use cases per strategy (sales agent follow-up flags, customer-service refund rubrics, recruiting feedback loops) — domain examples aimed at product builders. - **Quantified, experiment-driven argument style**: repeated move from raw accuracy to cost-per-perfect-answer analysis ("what matters to you is the cost to you to get to that perfect answer"). - **Practitioner takeaway emphasis**: > "if you take away one thing... tokens are not fungible... you should give your tokens jobs." - Conversational, demo-style talk format with co-presenters alternating sections. ## Notes and Caveats - Transcript quality issues ("fable is back online," "cloud" for Claude, "fungeible") — quoted evidence reflects the supplied transcript verbatim. - No curated metadata was supplied; identity observations rest solely on title and transcript. - No claims about private motivations were made by speakers beyond stated goals ("a big goal that we have over time..."). # Delivery Observations: "Tokens Should Have Jobs" ## Overview A two-speaker conference talk (tag-team format, marked by `>>` at speaker changes) delivered conversationally at AI Engineer. The delivery is structured around a central metaphor, three named strategies, and a data walk-through. ## Tone - **Friendly and energetic**: Opens with > "We're super excited to be here at AI Engineer with all of you." - **Conversational, low formality**: Frequent fillers and hedges: > "you know, we're doing this bench" / > "Um so we we've got executes" - **Hypothetical framing** used to invite the audience along: > "we've been wondering is that actually true?" ## Vocabulary & Metaphor - **Central metaphor sustained throughout**: tokens as workers with "jobs" — > "what if we gave tokens jobs?" - **Personification of tokens/agents**: executors "execute," dreamers "dream": > "Or maybe you have tokens that are dreaming." - **Domain jargon used fluently**: "alpha," "fungible," "test-time compute," "oneshot," "rubric," "bench," "primitives." - **Informal quantifiers**: > "a whopping 600,000 tokens" ## Recurring Phrases & Patterns - **"So" as a pivot word** at nearly every transition: > "So let's go take a look at the first strategy" / > "So another example is grading" / > "So what we did was..." - **Repeated "what if" / "let's" constructions** to walk through experiments: > "Let's just oneshot it" / > "Let's make this concrete with some experiments." - **Formulaic naming pattern**: each strategy is introduced with "The last strategy we have is..."-style scaffolding, then defined by roles (executor/adviser, executor/grader, executor/dreamer). ## Teaching Habits - **Concrete use-case pairing**: each abstract strategy is immediately grounded in a business example — sales agent (advising), customer service refunds (grading), recruiting agent (dreaming). - **Self-critiquing experiments**: presenters flag their own weak evidence: > "this isn't really telling us much because sure, Drain did really, really well, but it used a whopping 600,000 tokens." - **Audience-directed takeaway**: > "if you take away one thing, the thing we want everyone to think about is this idea that tokens are not fungeible." - **Audience segmentation** in conclusions: token-efficient businesses vs. reliability-focused businesses, each with a recommended strategy. - **Numbers stated verbally and repeatedly** (15%, 76%, 89%, 600,000, 1.8 million) to anchor each experimental point. ## Uncertainty Notes - Speaker attribution between Caitlyn/Katelyn and Angela is **not consistently identifiable** in the transcript; the transcript itself renders the name inconsistently ("Caitlyn," "Kayla") — likely transcription artifacts, so per-speaker delivery differences can't be reliably separated. - A segment around [709–720] appears garbled (> "fable is back online... Fable is the one that's actually advising"), suggesting either a live demo interruption or transcription noise; delivery intent there is unclear. - Some patterns (e.g., frequency of "So") are strongly evidenced; others, like audience interaction, are not observable from the transcript alone. # Observation Record: "Tokens Should Have Jobs" — Katelyn Lesse & Angela Jiang, Anthropic ## Speakers - **Katelyn (Caitlyn) Lesse** — leads platform engineering at Anthropic - **Angela Jiang** — leads platform product at Anthropic ## Core Thesis - Standard practice for improving agentic outcomes is increasing **budget** (more tokens or more expensive tokens), resting on an implicit assumption that tokens are **fungible**. - The speakers question that assumption: "What if we gave tokens jobs?" — i.e., allocate some tokens to roles beyond execution. - A **strategy** is defined as a setup where some tokens execute and other tokens perform a different job. ## Proposed Strategies ### Advising - Split into an **executor** and an **adviser**; the executor can call out for advice and check whether its next step is correct. - Example use case: a sales agent where the adviser helps flag overdue follow-ups or stalling deals. ### Grading - Define "good" in a **rubric**; a grader scores the executor's output against the rubric. - Pass → done; fail → iterate until a good outcome. - Example: customer service agent deciding refunds against specific criteria encoded in a rubric. ### Dreaming - A **dreamer** inspects the executor's work and transcripts and writes findings to **memory**, which is picked up by the executor next round. - Example: recruiting agent where accumulated feedback sharpens subsequent rounds. ## Experiments (financial analysis benchmark) - Benchmark of financial-analysis tasks benchmarked against expert human financial analysts. - **One-shot run:** Execute achieved **15% accuracy using ~39,000 tokens**; Dreaming did very well but used **~600,000 tokens** — noted as not a meaningful comparison. - **Fixed budget (600,000 tokens across all strategies):** Execute rose from 0.15 to **0.76**; Advise and Grade rose from the 60s to **near 90s**. - Key claim: if budget alone mattered, all strategies should be equal at equal budget; instead there is **alpha** — e.g., Execute 76 vs. Advise 89. ### Expert-real-world lens (Angela) - For real financial analysts, a result below **100% accuracy is not useful** (e.g., a P&L with wrong numbers forces recomputation or another run). - Rescoring: **perfect pass/fail** at 100% accuracy. Execute passed ~42% of the time; complex strategies up to **75%**. - **True cost analysis:** Execute at ~40% pass rate → ~3 runs expected → ~1.8M tokens for a perfect answer (600k × 3). Advise and Grade were described as **token-efficient**; Grade/Dream lean toward **reliability** (maximizing perfect-run percentage). - Business implication: optimization goal varies — token efficiency → advise-type strategies; reliability → grade or dream. ## Takeaway > "Tokens are not fungible." — smart role assignment within a fixed budget likely yields better outcomes than brute-force execution. ## Platform Implementation - Anthropic built a harness for individual agents — the architecture underlying **Claude managed agents** (their agentic solution in the Claude platform). - A **meta harness** handles multi-agent orchestration and coordination between executor/adviser/other agents. - Dreaming and outcomes strategies are available **out of the box** in managed agents. - With these primitives, they claim it is "relatively trivial" to compose strategies (execute → advise → grade in a loop → dream), build complex architectures, and **invent new jobs** beyond those presented. - Future goal: models and platform **dynamically construct strategies** during work. ## Qualifications & Caveats Preserved - Speakers explicitly flag that the one-shot comparison "isn't really telling us much" due to unequal token spend. - The fixed-budget alpha is described as "minimal, but it does exist." - No claim that one strategy dominates universally — choice depends on whether the business optimizes for **efficiency** or **reliability**. # Attribution Record — "Tokens Should Have Jobs — Katelyn Lesse & Angela Jiang, Anthropic" ## Speakers & Roles - **Katelyn (Caitlyn) Lesse** — **Co-presenter / speaker**; self-identified: *"I'm Caitlyn and I lead platform engineering at Anthropic."* Speaks on behalf of Anthropic. - **Angela Jiang** — **Co-presenter / speaker**; self-identified: *"I'm Angela. I lead platform product at Anthropic."* Speaks on behalf of Anthropic. Both are **first-party representatives of Anthropic** presenting the company's own work; no guest, narrator, or external voice appears. ## Provenance & Sources Referenced - **Internal experiments** (presenters' own): a benchmark of **financial analysis tasks** designed to replicate expert human financial analyst performance, with figures such as 15% vs 76% accuracy, budgets of ~39,000 and ~600,000 tokens, 42–75% perfect-run rates, and ~1.8M-token "true cost" analysis. Attributed to the presenters' team ("what we did"). - **Anthropic platform claims**: description of **Claude managed agents** (transcribed as "cloud managed agents") architecture, described as an agentic solution offered within the platform. ## Promotional Segments (Flagged) - **Platform/product promotion**: presenters promote Anthropic's **managed agents offering**, including claims that "dreaming and outcomes" strategies are given "out of the box" and that constructing architectures with these primitives is "relatively trivial." This segment functions as **first-party product marketing** within the talk. ## Third-Party Claims - None present. All claims are first-party (Anthropic's own experiments and product). ## Uncertainty Notes - Transcript is auto-generated; some names/terms appear garbled ("Caitlyn" vs title's "Katelyn," "cloud/Claude," "greater" for "grader," "Fable" as a presumably-anonymous agent name, "funegeible/fungeible"). Identity assignments between the two speakers' turns are not marked in the transcript; role split inferred from self-introductions and cross-references ("As Kayla/Caitlyn mentioned"). - No timestamps available in the transcript. - **Comment availability**: no metadata supplied; unknown. Good morning. We're super excited to be here at AI Engineer with all of you. I'm Caitlyn and I lead platform engineering at Anthropic. \>\> And I'm Angela. I lead platform product at Anthropic. And today we want to talk to you about a concept that we've been spending a lot of time thinking about and working on with our team, which is this idea that we think that tokens should have jobs. So if you're building an agentic system and you're trying to accomplish some specific outcome, you're trying to get something done with agents, there's one lever that everybody pulls in order to get a better outcome, and that's usually increasing your budget, which means you spend more tokens or you spend more expensive tokens. But we've been wondering is that all there is underlying this assumption of uh using the budget is this kind of implicit perspective that every single token is basically fungeable. And we've been wondering is that actually true? Are all these tokens actually fungeible? And to test that, we've been thinking, what if we gave tokens jobs? So, if you think about the way that you would normally set up an agent to go accomplish a task, you give it that task, you give it this token budget, and then all the tokens that are being spent are basically indiscriminate in the sense that they're all doing one job. They're just executing. But what if you take some of those tokens and they're not just executing, they're doing some other job. So, for example, maybe you take some of your tokens and they're advising the tokens that are executing. Or maybe the tokens that are executing try to get something done well and you take some other tokens and you actually grade how well the executor is doing so that it can iterate and try again. Or maybe you have tokens that are dreaming. They're reflecting back on the job that other executors have done and writing learnings to memory so that they can do it again. And what we call each of these if you take some tokens that are executing and some tokens that are doing some other job. Let's call this a strategy. So let's go take a look at the first strategy, the advising strategy. Here we're splitting up an executor and an adviser. The executor obviously executes, but crucially they can call out to an adviser for advice. And then they can take this advice and figure out if they're doing the next step correctly. This is really helpful in use cases. For example, if you're building a sales agent, in an ideal world, you'd have that sales agent be able to actually help the sales rep flag when a follow-up is overdue or deal is stalling. In this construct, having an adviser to be able to kind of make sure that all the different pieces are actually working is really helpful. So another example is grading. Let's say you're executing and you kind of know exactly what good really does look like. You can define this in a rubric and then each time an executor tries to accomplish that outcome, you can have a grader provisioned that grades how well the executor did while looking at that rubric. And if the executor did a good job, then great, it can be done. But if it didn't do such a great job, you can iterate again until you get that good outcome. So an example in practice of when you might want to use this is let's say you have a customer service agent and you're running a store and your customers are writing in and they're saying, "H, I should get a refund for this thing." And your customer service agent needs to be able to respond. You probably have some like pretty specific criteria on when you would give somebody a refund. And so what you can do is define a rubric that uses that criteria. You can have a grader that goes and looks at the work that the customer service agent is doing and decide is it getting it right and is it coming to the right outcome. And the last strategy we have is dreaming. So in dreaming there's an executor who naturally executes and then there's a dreamer. The dreamer is actually able to inspect the work and the transcripts of the executor and then it takes any of the findings that it has and it writes them to memory. This memory is repicked up by the executor for the next round. So ideally would have improved. A great use case for this is if you're building a recruiting agent. Now recruiting requires a lot of interaction with feedback on whether or not a candidate does or doesn't make sense and if it's a good fit between both parties. And so by taking all this type of data, if you build a dreaming type of strategy on this agent, it's actually able to kind of sharpen the next round so that it's more and more increasingly useful. So let's make this concrete with some experiments. So what we did was we created a bench of a bunch of tasks related to financial an analysis. And what we were doing with each of these tasks is trying to replicate in the real world a expert human financial analyst. How well would they do on each of these various tasks? And so what we did was we start with a control that's just executing. Let's try each of these tasks and we'll eval them when we're literally just executing. But then we can experiment with each of our strategies and see how well we perform. So, we start with a super basic experiment. Let's just oneshot it. Let's take each of our strategies and we'll go and just make an attempt to accomplish these tasks and we'll see how accurate we are. And so, you can see here with executing um it didn't do so well. 15% accuracy, but because it was just a oneshot, the strategy got to choose how many tokens it would actually spend on its own. And so, you can actually see that execute decided not to spend that many tokens, only 39,000. And as we go into our larger strategies, our more complex strategies, we did choose to spend more tokens, but we did a better job. So, this isn't really telling us much because sure, Drain did really, really well, but it used a whopping 600,000 tokens to get there. That's right. So, in order to actually figure out if varying the jobs produces any alpha, what we need to do is hold the budget constant. And to do this, we're going to take Dreaming's budget, that 600,000 or so, as the maximum budget that is fixed across the board. And we give every single strategy this budget in order to analyze how well it's performing. And as expected again, if you give a lot of strategies more budget, you are going to see performance increase across the board. So execute went from 0.15 to 76. Advise and grade went from the 60s to closer to the 90s. And that's again expected given the fact that if you give things more test time compute, they should generally perform better. But if that was the only thing that mattered, we should actually expect to see execute, advise, grade, dream actually all be at the exact same level given the exact same token budget. But what we're actually seeing is that there is an alpha or there is a difference and therefore an alpha for us to exploit. If you look at execute at this exact same budget level, it gets to 76 but advise is at 89. So while a minimal, it does exist and so there is alpha for us to take a look at. Now, we decided to take a look at this analysis from a completely different lens. And as Kayla mentioned, you know, we're doing this bench for a very complex set of financial tasks in the real world. And we wanted to analyze the usage of agents with actual experts. So, if we look at a financial analyst expert, right, the kind of task that they need to do with an agent is that they're giving it something very concrete like let's say make a P&L and then they're getting the result back. Now if that result is 80% accurate on a bench that sounds great but in reality what that means for that expert is they have to go back and recomputee that P&L themselves or alter or alternatively send it through another run and that's because in this kind of domain for this kind of task if you're not 100% accurate it's actually not useful. You cannot make up an income number or you can't make up a cost number right you have to make sure that it's 100% accurate. So with this lens of the real world consequence associated with this domain, we needed to recomputee our experiments and score them a bit differently. Crucially, we needed to make sure that our experiment had this kind of construct where if it was scored perfectly, we'd actually give it a pass. And if it scored anything less than 100% on that kind of task, we would actually mark it as a failure. So let's look at a different cut of our data from our experiments with this lens where we're looking for this perfect run 100% accuracy pass. And let's look at what percent of the time each of these strategies was able to achieve a pass. Um so we we've got executes um down at 42% and we've got our more complex strategies doing a bit better up to 75% accuracy. Um and again this doesn't necessarily tell us a ton because um you know each of these strategies might um choose to use different budgets over time, right? So what we did here was we fixed the budget and we said within a fixed budget, how well do each of these strategies perform? And so what really matters to us actually is if you're trying to get this perfect answer and you're in the real world, you're running a business, what matters to you is the cost to you to get to that perfect answer. And so one way we can think about this is we had our execute strategy for example. The execute strategy around 40% of the time will give you that perfect answer. So on average, you can expect to have to run it three times and you should hopefully sometime in those three runs get a perfect answer. And as we talked about earlier, we fixed our budget to that highest token budget strategy, which was 600,000 tokens. So if you spend 600,000 tokens in each individual run, you have to run approximately three times. You can expect on average to have to spend 1.8 million tokens with the execution strategy to get to your perfect answer. And so if we take this analysis and run it across the board against all these strategies, this is actually the true cost it took in this domain for that agent to be useful for that strategy. So as Caitlyn mentioned for execute, which is our baseline, this is going to be 1.8 million true total token cost for you. But advise, grade, and dream are showing us a bit of difference. Crucially, advise and grade are actually quite token efficient when you think about the actual usage of the end output of each of these agents. So what does this mean for you as a business? Well, it actually really depends on what kind of thing you want to optimize for and it's going to vary, right? There's going to be businesses who say, "Actually, for me, the most important thing is to be really token efficient. In that case, you should probably pick the advised type of strategy in order to solve for that particular domain in which you want to optimize that." There's going to be other areas or other businesses where you're going to say, I'm not going to care so much about token efficiency because what I really care about is reliability of that answer and so I need to maximize the percentage of runs in which I get that perfect answer. In which case, you would actually pick completely different strategies. You probably lean towards grade or dream. So if you take away one thing, the thing we want everyone to think about is this idea that tokens are not fungeible. You can use your tokens to execute. You can brute force your way through your task and you can throw more budget at it. But if you get really smart about having your tokens do these different jobs and try these different strategies, you're very very likely to be able to get a better outcome for the task at hand within a fixed budget. And so let's talk a little bit about how we actually build strategies and how we bring this to life. Um so we've done a lot of work to create a really excellent harness for individual agents. Um and if you see this uh picture at the bottom here, this is actually the architecture that we've used for cloud managed agents um which is our Aentic solution that we give to you within the cloud platform. And what we do on top of this is we start to get into the meta harness level like the multi- aent orchestration and execution level where this strategy can go and be um coordinated between our executor and our adviser or the other agents within our strategy. And some of these um like dreaming and outcomes we actually give to you out of the box within cloud manage agents. So with those set of primitives it's actually relatively trivial for us to construct this kind of you know architecture where we're able to combine these different types of strategies and figure out how to they should work together. So for example it's relatively trivial for us to say okay now with this I can take a task and I should be able to execute it but also allow it to advise and fable is back online. So we could actually say Fable is the one that's actually advising uh the executor. And then I can take all these results and say send them to a greater so that I can make sure that this is verifying in a loop that makes sense. And if it passes, that's awesome. I want to send all of that stuff to Dreaming and make sure that my next run is better than ever. And of course, you don't have to stop there, right? If the right primitives are there and the right coordination is there, then you can actually construct really complex setups that fit for all the different types of dynamic problems that you have. You can invent these kinds of large-scale architectures, again, very triv. And you could also invent completely new jobs, not just the ones of the pieces that Caitlyn and I have presented in this conversation. So, a big goal that we have over time is to get our models better and better and our platform better and better at dynamically constructing these strategies for you as you're doing work. But in the meantime, as we're working our way there, we would love for you to continue to think about this idea that you should give your tokens jobs and you should use different novel strategies by combining these primitives in order to get the outcomes that you want for your tasks. \>\> Thanks for joining us.