How to Build Long-Horizon AI Agents — Mitch Troyanovsky, Basis

Summary

Podcast Summary: The MAD Podcast with Matt Turck — "How to Build Long-Horizon AI Agents" with Mitch Toryanowski (Basis)
August 6, 2026

---

Episode Overview

In this episode, host Matt Turk sits down with Mitch Toryanowski, co-founder of Basis, a pioneering AI company building autonomous agents for complex, real-world tasks, specifically accounting. The conversation is a masterclass in building long-horizon agents, focusing on design principles, the evolution of agent technology, the unique challenges of domains outside coding, data scarcity, verifiable rewards, and the open-sourcing of behavior specifications through a partnership with BrainTrust. Through practical examples and deep technical insight, Mitch offers advice and learnings highly relevant for anyone working on intelligent autonomous systems.

---

Key Discussion Points & Insights

1. The Nature and Challenge of Long-Horizon Agents

• Definition of Agents and the ‘Long-Horizon’ Category
  • Agents are AI systems with autonomy to make decisions in varied environments.
  • “Long-horizon” agents operate over extended periods (minutes, hours, days, or even months), requiring coherence far beyond LLM context windows.
  • Mitch: "LLMs have very large working memories and by default, no short term or long term memory. So you have to leverage these strengths ... to make up for the fact that you don't have ... real memory." (06:58)
• Basis' Approach to Autonomous Tax Agents
  • Agents can handle entire tax returns with minimal human input, mirroring the workflow and reliability expected of trained accountants.
  • Emphasis on outcomes that are understandable and easy for human reviewers to trust—mirroring how engineering or accounting teams hand off and document work.

---

2. History and Evolution of Agent Approaches

• From Reasoning + Acting (ReAct) to Next-Gen Models
  • The journey from the 2022 ReAct framework, where agent systems combined reasoning and acting, through “baby AGI” experiments, to modern, sophisticated reasoning models.
  • Major breakthroughs occurred with models like Opus 3 and 01/03, which improved reasoning, attention span at scale, and the quality of agent coherence.
  • Mitch: "Opus 3 ... was the first model to truly be able to actually understand at long context." (15:54)

---

3. Why Coding Succeeded First, and Barriers in Other Domains

• Coding as a Verifiable Environment
  • Code is inherently easy to check at runtime (unit tests, compilation), providing abundant, cheap, and accurate reward signals for RL and agent feedback loops.
  • Real-world (non-coding) tasks lack these tight feedback loops and are often subjective or multi-faceted.
  • Mitch: "Coding is verifiable at runtime... If you wrote code and you could never run it, even the best engineer would have a syntax error." (22:40)
• Challenges in Accounting & Knowledge Work
  • Complex, multi-thousand step workflows.
  • Scarcity of high-quality, diverse data—especially confidential or synthetic datasets.
  • Difficult to establish ground truth; need to rely more on process evaluation.

---

4. Designing for Reliability: Outcomes vs. Process

• Limitations of Outcome-Based Evaluation
  • Even high-performing outcome-based evals can't guarantee high-quality or safe real-world performance.
  • Mitch: "Are you confident that that now generalizes to the real world, to production, and our answer has been no." (33:29)
• Learning from Human Processes
  • Human organizations rely on steps, checks, reviews, and subjective judgment—not just deliverables.
  • Agent design should borrow these best practices: independent review, process monitoring, and explicit behaviors.
  • Mitch: "Humans are already used to working with non-deterministic systems. It's just those systems are normally their coworkers, not their computers." (27:28)

---

5. Behavior Specs: Transparent, Composable Process Guidance

• What Are Behavior Specs?
  • Behavior specifications are markdown files outlining granular, desired agent behaviors—independent of but used in judging agent performance.
  • Written collaboratively by domain experts and ML engineers to capture both ideal process and agent-specific design.
  • Mitch: "You write down how do you want an agent to behave ... It could be at varying degrees of granularity." (36:48)
• Judges for Evaluation
  • LLM-powered 'judges' review completed task trajectories against the behavior rubric.
  • Maintaining and curating behavior specs requires careful balance—too many become unmanageable; too few risk poor quality.
  • Not shown directly to agents but critical for both human alignment and monitoring.

---

6. Open Sourcing Behavior Specs (with BrainTrust)

• Introducing the Open-Source Behaviors Project
  • Specs both for agent alignment and evaluation.
  • Partnership with BrainTrust provides out-of-the-box judges, examples, and a flexible standard designed for broader adoption in the industry.
  • Mitch: "...the idea is that you can actually write down in markdown. It is actually both a spec and a rubric ... useful for BrainTrust and honestly the whole industry." (55:12)
• Goals for Adoption
  • Build industry standards for agent behavior.
  • Enable others to contribute, extend, and apply to their own domains.
  • Mitch: "We purposely tried to make the standard relatively flexible ... as long as ... a judge could look at the behavior and actually know was the condition ... met, and ... did it ... get exhibited?" (58:27)

---

7. Ontology and Context Engineering

• Importance of Clean Ontologies
  • Agents' performance is tightly linked to quality, clarity, and organization of their runtime data/context.
  • Codebase or business process structure (ontology) affects coherence, consistency, and ability to reuse agent logic.
  • Mitch: "The ontology of your code base always mattered for engineers. It matters just as much, if not more for really good agents over time." (61:09)
• Documentation and Canonical Context
  • Internal documentation must be treated as code—any loss of fidelity or outdated context can break agent performance.
  • Mitch: "The context actually affects the performance at runtime. The organization of the code does not..." (71:41)

---

8. Roles: Language Architects, Agent Managers, Deployed Intelligence

• New Organizational Roles
  • The rise of systems thinkers: engineers, lawyers, operations experts skilled at abstraction, ontology design, and process modeling.
  • Introduction of Deployed Intelligence teams to help firms operationalize and scale agent-augmented processes.
  • Mitch: "We need a lot of them. So if you're listening and you want to join, please hit me up.... good systems thinking ... comes from people who have had to think about some abstraction, some system, something, and design it..." (66:45)

---

9. Self-Improvement, Feedback Loops, and the Future

• Agent Self-Improvement
  • Research at Basis aims to close the loop between evaluator signals (behaviors, outcomes) and agent self-improvement—eventually allowing agents to update their own context, harness, or even code.
  • Signal development (good reward functions & tracking) more limiting than model-level RL at present.
  • Mitch: "As agents get better and they get better at this type of engineering ... you'll start to actually be able to close the loop." (71:41)
• RL as a Future Industry Moat?
  • Mitch argues technical moats are fleeting; business moats and deep domain + deployment are more enduring.
  • He expects much that is currently harness-level context engineering to be swallowed by model advances ("bitter lesson"), but this transition could still take several years.
  • Mitch: "Technical moats are not real moats. There's no portion of basis's long term terminal value that stems from some secret RL trick..." (79:03)

---

10. Advice and Lessons for Builders

• Stay Grounded in System-Level Principles
  • Despite rapid change, underlying paradigms of agent design have remained consistent post large-scale model leaps.
  • Strategic, first-principles thinking is crucial for making coherent product and technical bets, instead of chasing every new release.
  • Mitch: "Things are changing, but it's not like the paradigm is changing, at least not that dramatically. ... really understanding it is very, very key for being able [to] build in this world." (81:21)

---

Notable Quotes & Memorable Moments

• "LLMs have very large working memories and by default, no short term or long term memory."
  — Mitch Toryanowski (06:58)

• "Humans are already used to working with non-deterministic systems. It's just those systems are normally their coworkers, not their computers."
  — Mitch Toryanowski (27:28)

• "If a person is just getting it right because they're going to Wikipedia, the accounting firm wouldn't hire them and so they shouldn't hire us either."
  — Mitch Toryanowski (33:29)

• "The English is more precious because the English affects the performance. The code does not affect the performance."
  — Mitch Toryanowski (71:41)

• "Technical moats are not real moats ... What matters is that right now we are obviously very good at building long horizon agents that can be reliable and deployed in production ... and that's why we move really fast."
  — Mitch Toryanowski (79:03)

---

Important Timestamps

• [01:59] — On why Basis employees "whisper" into microphones; giving agents more context via speech
• [06:12] — Defining "long-horizon" agents
• [13:26] — The Memento analogy for agent design
• [22:08] — Verifiable rewards and why coding agents came first
• [29:29] — Data scarcity for real-world agent evaluation
• [36:48] — The origin and importance of behavior specs
• [55:12] — Rationale behind the open-sourced behaviors standard with BrainTrust
• [66:45] — On hiring and the new roles in agent-centric organizations
• [71:41] — On self-improving agents and closing the feedback loop
• [79:03] — The enduring importance of business moats over technical ones
• [81:21] — Final advice for AI builders

---

Takeaways for Listeners

• Building robust, long-horizon autonomous agents requires a blend of high-quality process definition, careful context engineering, and strategic adoption of best practices from human organizations—not just relying on model advances.
• Process transparency (via behavior specs), clear ontologies, and rigorous human-agent alignment are key for reliability, especially in real-world, high-stakes domains.
• Technical innovation must be paired with operational excellence and product adoption to build enduring value.
• The open-source behaviors project is a strong first step in standardizing agent evaluation and behavior across the industry—contributions and adoption are encouraged.

---

For further resources and to contribute to the open behaviors standard, check the collaboration from Basis and BrainTrust. For those interested in joining Basis or learning more, reach out to Mitch and the team.

---

Transcript

[Mitch Toryanowski]

Humans are already used to working with non deterministic systems. It's just those systems are normally their co workers, not their computers. And in many ways, like companies and Processes is all about how do you design a system for non deterministic entities to coordinate together to solve a problem. And once you realize that, it's like, well now it's like kind of agent design. Let's say you have 100 evals. Great, they all passed and looks good. Are you confident that that now generalizes to the real world, to production? And our answer has been no. Even if you got it right 100 out of 100 times, if a person is just getting it right because they're going to Wikipedia, the accounting firm wouldn't hire them and so they shouldn't hire us either. You'll see people like freaking out over a code file that isn't abstracted properly. And yet their context is like total. The English is more precious because the English affects the performance. The code does not affect the performance.

[Matt Turk]

Hi, I'm Mattor from firstmark. Welcome to the MAD podcast. Everyone is building AI agents, but outside of coding, most still can do real work reliably. My guest today is an AI builder at the forefront of cracking that problem. Mitch Toryanowski is co founder of Basis, a unicorn AI company whose agents run autonomously for hours, sometimes days, and are already able to complete very complex tasks like preparing entire tax returns end to end. This is a true reference episode on how to build Long Horizon autonomous agents where Mitch shares tons of lessons he learned along the way. Please enjoy my conversation with the deeply insightful Mitch Chojanowski. I want to start with a scene. As I was prepping for this, I came across a video by our friend Stephanie Palazzolo at the Information, and she was describing the experience of walking into the Basis office and seeing a bunch of people whispering very quietly into microphones. So maybe for the top AI builders or people who live on X second by second, this may be already something that everybody understands, but I think for the vast, vast majority of people, just describe, describe what you guys are doing whispering into those microphones.

[Mitch Toryanowski]

Yeah, I think maybe the best piece of advice, not for building agents, but for working with AI in general, is that you need to give it as much context as possible because it by definition is always missing context in some way. Speaking is just so much faster than writing things down. And in fact, when you try to write things down, you are actually essentially trying to summarize all the crazy thoughts in your head. And so that's why it takes A lot of time. And it's useful for you or I because it's rude if somebody just blabbered and sent that to you as a Slack dm, but to an agent, they don't care. It's actually they would prefer it. So it becomes much more productive to be able to whisper your thoughts because you don't want to be shouting. You have these microphones now that allow you to whisper very quietly and still pick up with full fidelity. So that's why we have it. Sometimes people see it and they think it's a little weird when they join the company, but after a month or so they can't go back.

[Matt Turk]

So you whisper into what? Into cursor or into.

[Mitch Toryanowski]

Yeah, into whatever people use. I mean different people use different things, but yeah, codecs or Claude or cursor or whatever people use. And not just engineering. Right. Like all the functions. If you're trying to get something done, if you're trying to describe what you want and all these things.

[Matt Turk]

Okay, great. All right. So what I'm hoping to do today is a bit of a reference conversation on old things around building Long horizon agents. That's in part based on a great thread that you had on X and perhaps more importantly a new open source project that you just released in collaboration with BrainTrust. We're going to talk all about this, but maybe for contextual awareness, basis in two or three sentences, how would you describe it?

[Mitch Toryanowski]

Yeah, basis builds agents to do accounting work end to end. And accounting is difficult. It's not something that is just purely text in, text out. And so it requires the ability for AIs to be able to perform lots of actions over long periods of time and actually be coherent over that period of time to get to outcomes that are good. And that's why we've always been very focused on how do you really build agents that can scale to do that work.

[Matt Turk]

And did you pick accounting because of how interesting that was from an agent based building perspective or the other way around?

[Mitch Toryanowski]

That's a good question. It's probably the other way around, but I do think it is actually quite interesting from an agent perspective. Accounting is interesting for a lot of reasons. It is one, one of, if not the largest knowledge work profession in the country. There are over 3 million combined accountants in the country. And what I think is so cool about accounting actually is that most people don't really think about accounting. They don't think like, oh yeah, why is that even there? Probably most listeners have never thought, why does it even exist? And I know we're going to talk about agents, maybe quickly, 30 seconds, just to convince everyone how cool accounting is. If you think about the real world, so much stuff happens, economic activity. I was just drinking a water bottle there. Someone that bottler had to choose to go buy from that factory or that supplier or decide to open some additional store, a salesperson. And these are all economic decisions that stem from understanding the real world. What's in the real world. Money moves hands. Someone signs a contract, someone delivers the inventory. It's like all these events that occur. And so much of modern capitalism relies on the ability of all these actors to make decisions on these events, like the CEO of that company, the irs, obviously, to decide how much to tax, the bank to lend, credit investors. All these people, they care about the real world, but they can't understand it because it's gigantic. And it involves all of this unstructured and difficult to parse information. And accounting is actually the art of compressing all of that into something that is structured, that now people can look at and understand and make decisions. So something about accounting, you could argue in a meta way is kind of like an intelligence over the economy because it is really a compression activity of all the information that exists. So I think it's a very cool problem to kind of think about still the same thing.

[Matt Turk]

For contextual awareness, we're going to talk about long horizon agents. What is a. I guess what is the long horizon part these days? So that keeps evolving. What falls in that category?

[Mitch Toryanowski]

Maybe I can give my quick definition of an agent. I know, probably everyone knows at this point, but I feel like that's a gotcha question I like to ask in interviews. I tend to think of an agent as an AI or some inference that occurs that has the agency to go and make decisions to do different things. And so by definition, it's a spectrum because you can have varying degrees of agency, right? Like you're constrained by whatever environment you're placed in. And I think long horizon, again, is a spectrum where you're granting the agent, the agency, to make decisions that allow it to be coherent for longer periods of time. Right. So let's say that you were asking an agent to go and look up the weather for you. It might be an agent in the sense that it has the agency to decide what tool to call or what Google search to put in. But it doesn't need to do much work to be coherent over a period of time because you're just getting the weather. But if you're asking an agent to say, go Perform an entire feature, implement some feature in your repo, or asking it to go and make a big Excel workbook. Now, suddenly it might have to operate for longer than a minute. We're talking 10 minutes, 20 minutes, 30 minutes, and potentially even much longer than that. And once you're starting to get into those scales, you start running into the fundamental limits of how LLMs work, in which I always like to say, LLMs have very large working memories and by default, no short term or long term memory. And so you have to leverage these strengths of the LLM to make up for the fact that you don't have good or actually any real short term or long term memory. By, and we could talk more about it by using harnesses and all these kind of advancements to allow them to be coherent over a period of time. So I think once you start getting into the art of trying to get it to be coherent, because you're going past the amount of working memory it has, I'd probably say that's when you're starting to get into what I'd call long horizon.

[Matt Turk]

Great. And still to affirm the conversation, what we're talking about here is autonomous agents. I'm curious, maybe just as an example, what autonomous means in the context of basis. I read that you guys can now have agents that handle end to end tax returns. So maybe walk us at a high level through what that looks like in terms of steps, how long that takes. What does an agent do conceptually, when

[Mitch Toryanowski]

you are really autonomous or doing something over a really long horizon, say doing a tax return end to end, that means that you have a lot of information that is needed to do the work and you have the tools to go and get potentially more information. So let's say imagine you're doing a complicated 1065 and you have all of the different K1s, W2s, other documents, 999s, whatever you need from the company. And then you also potentially depending on what you're doing, you might have the trial balances already. So that tends to be what you need to actually start a tax return. Or you're working with books that aren't even done yet, and the agent then has to actually go and figure out based on all this different stuff, how is it going to tackle it and what's it going to be able to do. And that's where you start getting into some stuff about what the behavior should be that we can talk about. About. Well, what does good practice look like to say, get to a solid set of trial balances what does good look like in order to properly extract out the K1s and the K3s so that you can be confident in the outcome. And for it to be autonomous, it means it's not going back to the user and saying, hey, is this right? Is this right? I need this, I need this. It's like starting the job to I'm done and I'm done does not mean I'm done. You click a button like no one looks at it. It's actually the opposite of that. It's much closer to what you can imagine a preparer doing, or maybe like a first pass or a junior engineer or something of I'm done. Here were the big decisions I made, here were my assumptions, Here were the different things you need to look at. Let's go and review together, right? And if you think about somebody, say in engineering, an engineer handing you a pr, nobody likes being handed a thousand line pr. They're like, it's done, I promise. It's like you don't want to review that, but if you instead handed somebody a great stack that was properly split out and you could understand very easily, hey, here is exactly what this change is and this diff. And I made this big architectural assumption here and here's why I made that change. And you can optimize not just for getting the work done, but for making it easy for your reviewer to understand the decisions that you made. And that's obviously very true in software engineering and it's actually true in, I think, most professions and especially accounting, which we can kind of get more into. And so to me that's, I think, what it means to be autonomous.

[Matt Turk]

So I thought what would be fun and helpful for people listening to this would be to spend a few minutes on, I guess, the history of agents, like we've all heard over the last two to three years. So many different things, so many different terms. Some projects that work, some projects that didn't work. So I think it would be helpful to just go back in time just a little bit. What in AI may feel like prehistory, but in reality it's like what, three years ago, four years ago? So maybe starting in 2022 is the react framework, so not the software engineering, but like reasoning and acting, which I believe was a paper in 2022 that fundamentally said this agents are a combination of reasoning and acting, which you just alluded to. The fundamental question is that largely what's happening, I mean, with a tremendous level of sophistication on top of it. But is the Fundamental theory of an agent.

[Mitch Toryanowski]

Still that I think within the paradigm of modern day LLMs. Yes, more so, more or less, in the sense that I would say it is actually the same, but it kind of extends out further, which I don't really remember if it was part of that paper back then, of needing to use your reasoning to regulate your own state. The analogy I like to always give to people at the company when I'm learning about agents for the first time. Not even just technical people, like anyone at the company actually is the movie Memento. I think Memento, for those who haven't seen it, is a movie in which there's this guy who has short term memory loss and every day he wakes up and he knows who he is and he knows he's a human, he knows some basic stuff, but he doesn't know what's happened in the last couple years. He has no idea. And for him to make progress to any particular goal that could be something like getting groceries or getting revenge or whatever it is, he effectively needs to write stuff down for himself. And then when he wakes up the next day, he reads his notes and essentially builds that up. That's how he builds up knowledge.

[Matt Turk]

Early Christopher Nolan movie, by the way, at a time when everybody obsesses about the Odyssey. This is one of the early, his early works.

[Mitch Toryanowski]

Yes, I think the procedure is the best Nolan movie, but yes. Anyway, so I think that's your point. It is actually about reasoning, but I think, and I don't think it talked about in the paper, it's just there's reasoning in terms of what path is right to go for whatever the task is. Like do I do tax this way or that way? For sure. But there's also reasoning about how do I make sure my next inference step has what it needs to properly interact with the world. Which is easy if you're in a short horizon because you're within the context window. But once you start getting to longer horizons where you're beyond the context window or you're getting to context rot, you need to kind of use and sort of brute force your reasoning to build out your environment, whether that be with sub agents or compaction. We talk more about that, but that's I think, where the reasoning becomes super important.

[Matt Turk]

Okay, great. So the next step after 2022 was probably baby AGI in 2023, which everybody viewed as just like a massive advancement, but that sort of failed. I mean, that was a beautiful experiment, but like didn't quite work out in practice. So why is that? I guess at the time, like people talked a lot about compounding errors and you know how if you had many, many steps and the agents started going astray, then that would compound. Was that what it was from your perspective?

[Mitch Toryanowski]

Yeah, I think back then I think that. I believe, if I remember correctly, that was like GPT4, maybe four turbo at the time. The models back then, for starters, if it was pre Turbo, the context windows were very small. And so if you're going to be coherent, you need to have at least enough stuff in your context that you can organize your own environment. So they didn't have that even when the context windows got larger. I don't think by the time Baby AGI came out, the models were actually good at keeping attention over. Once you got past whatever it was like 20,000 tokens, they were just not smart. It took until maybe Opus 3 for them to start getting smart at 100,000 tokens even. And so baby AGI didn't have that. And then also obviously, and we'll talk more about, they just were not good reasoners. And so if you're not a good reasoner, then you're going to have lots of compounding errors because you're going to make one mistake that's in your kind of per token generation and now suddenly that just compounds and you have no way to have the self awareness to actually self heal in any meaningful way.

[Matt Turk]

So the big breakthrough then was reasoning models.

[Mitch Toryanowski]

Yeah, I would say when I think about what were the big holy shit moments for? I don't know if you can curse, but yeah, what were the big holy shit moments for us, at least for me personally it was probably, or at least the moments in which there was a genuine paradigm shift. There haven't been that many. I would say they were Opus 3, which I think goes underappreciated, but I think was the first model to truly be able to like actually understand at long context. Before if you put anything in 80,000 tokens into GPT4 Turbo, it could not understand it. Opus 3 actually understood it, which was remarkable. I think it was that. I think it was 01. Obviously everyone talks about that. And then I think after 01 it was 03, because I think 03 helped prove that not only could you scale the amount of reasoning at inference time, but with better training, with more compute, better data, et cetera, in the post training phase, you could make the reasoning higher quality, more efficient and just better. And so each incremental token that it reasoned with at inference time was higher quality, which was not obvious when 01 came out. So I think those were to me the big breakthroughs.

[Matt Turk]

Is there something about the fact that those were effectively trained as agents in loops where there's a chain of reasoning where they try something, backtrack, try something else? Is that the fundamental reason why this works better for agents?

[Mitch Toryanowski]

I think it's a couple of things. I think it's that because the model is able to kind of titrate the amount of compute, it's throwing at any specific step in the process. You're able to in any trajectory. There are a lot of decisions that are really hard and some that are really easy and it's just not feasible to have some giant parameter model that's super expensive to serve that has essentially been using all of that compute at every single inference step. And so the ability to reason allows you to titrate that. And I think as you pointed out as a kind of maybe emergent behavior, that if you are a really good reasoner and you can dial it up a lot if you actually look at the amount of compute for an easy step versus a hard step, it's a lot different. With the modern reasoning models, you could become better at self healing because you're going to be pausing and thinking about everything and sort of using that more that kind of thinking versus just doing everything on instinct, which is what was happening. If you're doing kind of like just per token generation.

[Matt Turk]

In your X thread, you talk about something OpenAI did in 2023 when they published something called let's verify step by step where humans labeled about 800,000 reasoning steps. What did that happen then and what was the goal?

[Mitch Toryanowski]

Yeah, so that paper came out so back I think before people. I don't remember the exact history here, but essentially there was a lot of rumors back then about if people remember the information article, like oh, Strawberry solve math or whatever it was. And so I think even before those rumors came out, there was some hints in the literature like this that might have been after the rumor, I actually don't remember, but that math was a. Or these kind of problems that you could verify were maybe good ways to try to train the models to be better at kind of different tasks. And I think this is purely speculation because I was not in the labs, but there was this sort of question back then and through a lot of the history of ML around, are you going to give the reward? Just from whether I got the problem correct or whether it approached it like a good mathematician would approach it. And what's interesting is that in that paper which they published. They showed that actually if you rewarded based on the process rather than just an outcome, you actually got better results within that sample. But that obviously is expensive because that required mathematicians to grade the approach they took to the problem versus if you look, if you fast forward a bit and you look at the deep seq R1 paper where they effectively laid out what I think all the labs were doing at the time, or at least OpenAI was doing in terms of RLVR reasoning from reinforcement, learning from verifiable rewards that effectively had very little process supervision and instead was essentially just saying, hey, did you get the outcome right? Yes. Okay, let me reward you. And then scaling that up, which obviously

[Matt Turk]

worked well still, in the recent evolution of agents, I guess it was last year there was this now famous meter chart that shows that the long horizon agents capabilities double every seven months. Is that something that you're still observing in 2026?

[Mitch Toryanowski]

Yeah, absolutely. I think the meter chart is somewhat inaccurate these days because it's so hard to measure.

[Matt Turk]

Also, the bar is pretty low, right?

[Mitch Toryanowski]

The bar is pretty low.

[Matt Turk]

50% efficient.

[Mitch Toryanowski]

The bar is pretty low. And I think I'm not super familiar with their data set, but my understanding is that it's like the sample size is kind of low. So I don't know about the specifics of that metric, but I think from a vibes perspective, absolutely. The models were able to start being coherent for longer periods by being smarter, but now they're also being specifically trained to do that. So that means they're being trained at how to. How do you have good theory of mind over yourself? Because you need to. If you're going to be outsourcing to a sub agent or if you're going to be writing notes off to yourself. Going back to the memento analogy, you need to think about, hey, I'm going to wake up tomorrow and I'm going to read these notes. What is the most information dense way for me to write this note down so that me in the future will understand it? Well, that requires kind of a theory of mind. And so as these models are being trained more on actually how to do that kind of work, which is very, very non human. Like humans don't have to because we're great at that actually. So we don't have to write for ourselves. Our brain does that for us. You're starting to see it get even farther. I think we're still actually quite early at that. If you look at some of the advancements to Fable 5 and 5.6 SOL and whatnot.

[Matt Turk]

Great. Just to go a little deeper on what you just mentioned, I think a broad context on agents in 2026, the evolution towards autonomous agents would not be complete without actually talking about verifiable rewards. So tell us what it is, where that feels in the overall picture and then perhaps why coding was the first successful sort of autonomous agent use case and how that's related to verifiable rewards.

[Mitch Toryanowski]

It's kind of interesting. I think people get this a little bit wrong. I'm speaking with a little bit of speculation because I don't actually know exactly. But coding, yes, is verifiable in the sense that I can know whether the code passes or not. And so I could train on that. Did you get the problem right? Did you get it wrong? Et cetera, which is useful, but the models being great at coding is partially that, but it's partially, I think, a couple other facets of coding. So number one is that coding is verifiable at runtime. I think that's a very important point because fi, at the end of the day, an agent needs to get signal as to how it's performing. And so imagine if you were an engineer and you wrote code and you could never run it even if you were the best engineer in the world. You're going to have a syntax error in which the thing is wrong at some point. So I think the fact that coding is so easily verifiable at runtime, or at least some parts of it are verifiable at runtime, is obviously very valuable for it being there. And it's cheap to do, it's easy to do within the environment and it's super text based, so it's available anywhere on your local computer. You can just run it. And so I think those aspects of coding actually make it are a lot of the reasons the agents are getting so good at it. I think one more piece of it is that, and I think we probably saw this, if you think about how good agents were at coding, maybe a year ago, a year and a half ago, they could go and implement the thing you told them, but they didn't have the level of taste or level of what is good software. Because even if you train them with verifiable rewards on like, hey, did this unit test pass? Like you could pass all the tests in the world, doesn't mean that you set up the app correctly. It doesn't mean your database was built well. It doesn't mean that you split out the files properly right at the end of the Day coding is subjective, it's an art, and you're not going to solve an art through verifiable rewards. And so I actually think there's a large part of this which is the amount of training data and the quality of training data that the models that the labs have clearly for coding has gotten quite good and they've focused a lot on making sure it's very good so that they're training on high quality code. So I think that's the other part. It's just that maybe because the labs are obviously full of engineers, it's more top of mind and obviously it's part of their strategy. And so it is more top of mind for them to ensure that both their pre training and post training sets have lots of high quality code. And that's what makes the agents great at not just writing code, but now starting to become good at actually engineering. So I think it's all those things together, I think the verifiable rewards are maybe just like the beginning that allows that stuff to happen. But I think the other stuff matters just as much, if not more.

[Matt Turk]

Great. Which brings us to the core of the thesis, which is your work on a domain that's outside of coding. So building Long horizon autonomous agents for I guess the real world, for lack of a better term, outside of that. Okay, so why do agents struggle? You mentioned three reasons. Maybe you mentioned what those reasons are and then we'll go into them turn by turn.

[Mitch Toryanowski]

Yeah, so I think agents struggle for a lot of reasons. I think one, they struggle because they don't necessarily know what good looks like. I think they struggle because it may not be easy to verify yourself at runtime as we were talking about with coding. I think another part is that, and this is maybe not an agent struggle, but maybe it's a UX thing, which is that for coding, engineers are just very in the weeds of it. And so there's kind of a difference where if you were running a Long Horizon agent for coding, if the engineer was not engineering and in the weeds of the code, if instead they were more abstracted away your maybe level of quality and how you make decisions, probably you maybe need a higher bar than you would for coding. Coders are okay with lower bars. That's been true for forever. And so I think all these things add up in making it. And even now with coding, the agents are not yet they're not human level at being coherent over long periods of time. That's obvious because they can't code like a junior engineer on a project for two weeks. So that's worse than a human, even at the start.

[Matt Turk]

So let's take that part about verifiable rewards and the fact that people writing those systems don't necessarily have intuition for what good looks like. So how do you guys solve that? What does passing a test mean for a tax return that, unlike code, doesn't need to compile?

[Mitch Toryanowski]

So the good news is there are some things that can compile. Not all, but you can obviously test.

[Matt Turk]

Either you get sued or you don't get sued.

[Mitch Toryanowski]

Yeah. Yeah. Well, I think the answer for this is you. You look at what humans do. And one nice thing about accounting, which is true in some other professions as well, but accounting is a profession in which you really try and have to be correct. And so because of that, and it's something in which there's so much judgment and process involved, where one of the sayings we have, and I say this on the design side a bit, but it's like humans are already used to working with non deterministic systems. It's just those systems are normally their coworkers, not their computers. And in many ways companies and processes is all about how do you design a system for non deterministic entities, I.e. humans, to coordinate together to solve a problem. And once you realize that, it's like, well, now it's kind of agent design, sort of. And so I think if you needed to think about what is good agent design and what can be verified, you should look at how the humans organize. And if you look at how humans do tax returns, you have steps of verification, you have independent review, you have things that can be deterministically verified. So you can say, hey, obviously, do the TBS add up to zero, right? A very obvious check. Things like, does the Excel not have errors? Is an obvious thing. So there's lots of things like that that too human are obvious, but you need to make sure are properly encoded. And there's other things that are maybe not as deterministically verifiable, but would be obvious to an accountant to look at it, oh, this is wrong. Of like, oh, you deleted this tab in this Excel or you didn't cite this thing or whatever it is. And so you can start to build verifiers effectively from these things that are not deterministically verifiable, but if an accountant would look at it, it would be obvious. And so you can start to think about judges or other forms of verification to get that signal both in your evals, but also at runtime.

[Matt Turk]

So that's one thing I think you pointed in your X thread that there was an issue around scarcity of data. Can you go into this, say, just

[Mitch Toryanowski]

for sake of argument here, you had not just synthetic, but every real tax return across the country, which you actually couldn't do for privacy reasons. Let's say you did have that and you were just like, okay, let me use this as a way to get data that you're not training, but data that allows you to verify how well the agents are doing. The order of magnitude there is tiny compared to standing up math problems synthetically. And you're generating whatever hundred, thousands, millions, et cetera. And so even if you had all the data in the world, you would not be able to scale it. So you need to think about how do you synthetically generate it? And if you think about how to synthetically generate it, that's really hard because you're not just synthetically generating text, you're synthetically generating artifacts that have to be real and diverse. And so now you get up to all the same problems about data diversity and all the different things that you need. And I have no doubt that that problem will be solved over time, but it's not solved today. And so there's this kind of gap between maybe what is possible from a data generation perspective and what is actually possible, what latent capabilities the models have, which is maybe where you get to some of the stuff we were talking about in the thread.

[Matt Turk]

And how do you think about the length of the feedback loop?

[Mitch Toryanowski]

Yeah, I mean, that's the other thing. The length can be very long depending on what you're doing. Performing a 1065 can take a human 20 plus hours easily of actual work. I don't mean like it took them a day, I meant like literal sitting down work. And it could actually take much longer for very complicated returns. And so there's just no way that even if you had all the data in the world, which you can't have, you would be able to have the feedback loop needed to do whatever improvement loop you want it to do to get the agents to be really good.

[Matt Turk]

And again, to make that concrete, how many steps would be involved in compiling a tax return?

[Mitch Toryanowski]

Yeah, I mean, to give you a sense, you could have, for example, 500, 1,000 documents easily. You need to think about how to map those documents against each other, understand what matters. You have to potentially perform lots of different research per different document. You have to potentially think about what they all mean. You have to compile them all into, at least today, into Workbooks of certain types which are like big excels. There's a lot that you have to do. So you're talking steps definitely in the few thousands easily if you're thinking about inference steps. And depending on how you build your system, if you start to span out sub agents for different things, which you kind of have to do, you're increasing that potentially. And that's before you think about other test time compute methods. For example, one thing you could do is say, well, imagine there's a tax question you have to solve and it's insanely difficult. Only an expert would be able to solve this specific tax question. Maybe there instead of the agent doing or spawning a sub agent, you're spawning five and you let them vote. And so there's just lots of other things you can do to throw more compute at the problem. And so based on what you're doing, the amount of steps end up being quite large.

[Matt Turk]

Okay, great. So to play it back, you got very complex processes with many, many, many steps. You don't have a lot of data to figure out what went right or wrong. It's not even always clear what is right or wrong. Although you can at least for certain parts of a problem say definitely whether this is right or wrong, but not always. So very complex problem which leads to how you guys have approached it. And in particular there's this concept that you can't just rely on outcomes, but you need to rely on process. So what is so wrong about relying on outcomes?

[Mitch Toryanowski]

Yeah, the problem with relying on outcomes. So if you have a multi thousand step trajectory, or even honestly one that's like an hour long, you will have evals that will say what good looks like? And it could be entirely verifiable. Do the numbers match? And it could be parts that having LM as a judge, there's some rubric, et cetera. And let's say you have 100 evals, great, they all passed and looks good. Are you confident that that now generalizes to the real world, to production, and our answer has been no, you actually cannot be confident of that. And so you shouldn't only rely on that. In the same way that if an engineer came to you and said, hey, all my tests pass end to end unit tests, etc. Does that mean that they architected the database properly? Not necessarily. That doesn't actually tell you that there are a lot of ways to pass outcomes without having done the process properly. But what we have found is that there are, especially going back to my point earlier on analogizing to human organizations, there's lots of learnings from how humans do work. And so I think it is a mistake to throw out those learnings and say bitter lesson, throw out those learnings. We're just going to have the agents at runtime develop an entirely new way to do a tax return. That is because bitter lesson, yada yada, will be better than the hundreds of years of human history that have gone into learning about the right process. Maybe that will one day be true. I'm not saying that it will never be true. And I do think it is possible going back to the data bottlenecks that we talked about earlier. And I think if you throw enough data and enough compute in an outcome based process, you can eventually get there, but not soon. If you're not going to get there soon and you have this latent potential in the models, what you really need to do is think about let's take the learnings from how humans do things from what good process looks like. You can't copy that exactly because there is a lot of thinking you have to do about good agent design. It's not like the models out of the box today are incredible at being coherent of long horizons. There's actually a lot of work there about behaviors for sure. You can instead put in place certain evals or potentially in the future reward functions that look at whether it followed the process properly or not. And maybe the example I mentioned, the thread, which I'll just say for the audience is imagine you're doing something as basic as tax research. If you ask some tax question, the agent could definitely get it right. They could know it from their pre training knowledge, they could read some blog and get it correct. But a real accountant would not trust that they would want you to cite the primary source. So even if you got it right 100 out of 100 times, if a person is just getting it right because they're going to Wikipedia, the accounting firm wouldn't hire them and so they shouldn't hire us either. And so we think it's really important that. No, actually our agents are not learning from the pre training knowledge or reading from a blog. They are going to the actual code and verifying the information with the primary source, which is what you would ideally want a real tax accountant to do as well.

[Matt Turk]

So you guys created that concept of behavior specs. So walk us through what that is, behavior very practically. Is that a markdown file? What does it look like?

[Mitch Toryanowski]

Yeah. So the original idea, actually my co founder Matt came up with the idea literally about two years ago. We were talking about auto AGI even back when we had agents that weren't fully, I guess, agentic as you think of them today. And they had restricted choices. Even back then you still wanted to think about, okay, what kind of choice you wanted to make at this fork in the road. We actually used to call it internally meta behaviors because the idea was that you're defining a behavior, but it's at a meta level because it's all across all the behaviors agent will have in all the different trajectories. So the idea was that instead of trying to write the prompt, you have to first align on what the metabhavior is. And so that was actually the first purpose of this concept, I swear to God, literally two years ago. And over time that kind of evolved. And we ended up calling it behaviors just because it's a bit simpler. And the idea is that you have a markdown file in which you write down how do you want an agent to behave? Simple as that. It could be at varying degrees of granularity. So let's say you have something that's very specific, like you need to go to look at the primary sources. Maybe you want to be more specific. Maybe you're like, no, you should always go look at specifically the IRS website. Or another example could be, imagine you're making PowerPoints and a behavior is. Well, before you return the PowerPoint, you should render it an image. So you know if you made any formatting issues. So you put that in a markdown file. And ideally that is a markdown file that is now that can be self contained. So one that humans can look at in a line like, yes, this is the behaviors that we want. In part because behaviors are actually subjective exercises. We can talk more about that. It's just as much of a product thing as it is an intelligence thing. And then it's something that a judge can look at where the judge can look at a trajectory and say, hey, did the agent exhibit this behavior or did the condition occur that it would need to exhibit this behavior? And if so, did it actually exhibit that behavior? And then you can grade it accordingly.

[Matt Turk]

And so who writes the markdown files or supervises the process of writing? Humans. Okay, and those humans are accountants?

[Mitch Toryanowski]

That's a good question. It depends a bit. I think it is a combined effort between accountants and ML researchers at the applied level. Because you're not just saying, for example, hey, the behavior is you should go to the website, you might be saying, hey, the behavior is that you should be like, for this type of Research, you should be spawning a sub agent with full history because you need to build up that context. There's a lot of agent machinery that comes into play. And so you kind of have this thing where there is what is a good process looks like for a human, but then you need to translate it into agent language and then decide and there's a combination there where you're also talking about what are the agent mechanics. And so I'd say it's a dual effort between accountants and ML researchers. And we have a whole team, actually it's called accounting Product Operations where it's accountants whose essentially what they do is they work very closely with the research teams to build out rubrics, both outcome based rubrics, and then also behaviors.

[Matt Turk]

And how do you think about precision versus making sure that the system doesn't break? So you mentioned go check the IRS website. Is there a possibility that at some point, actually what you should do your one is go to the IRS website, but then in two years from now there will be a different location for the information?

[Mitch Toryanowski]

No, that's a very, very good point. Which is exactly why the behaviors are not actually shown to the agent. So the behavior could say, hey, you should go to the IRS website. That doesn't mean the agent is told to go to the IRS website, right? It might be, it might not be, it sort of depends. But the point is that the way I think about it is the level of, as the kind of agent engineer, systems engineer, you are making the decision as to how specific do you want to be with the situation. Obviously you prefer to be less specific. I think as people who are good at building agents know, it's much better at the margins to be able to give principles and the whys and more context and let them figure it out. And so with behaviors you want to actually not define every possible thing that can happen, but just say no, no, we know that, for example, let's say you're making PowerPoints. Taking a picture of the PowerPoint before you give it to the user is going to catch issues. We know that for a fact. Right. And so we as the agent engineers are going to take a stand and say out of all the different things you as the agent are going to do, this is the thing I'm going to grade you on. And then maybe you're being a little bit more specific there. If you want, you can be more specific, like use this exact tool. But ideally you don't have to. It depends on kind of how your system is built. So I think your Level of specificity depends on maybe what specific outcome you're sort of trying to drive and how that much that outcome generalizes to the universe of situations. Like. Like if you're producing PowerPoints, of course taking a picture makes it better. But let's say instead your agent actually is a super fast agent. Well, make. Taking a picture takes time. So maybe a super fast agent, you don't want for it to take a picture of the PowerPoint because now you went from it taking 30 seconds to taking one minute. But if you have an ASIC agent that's taking 20 minutes, you went from 20 minutes to 20 minutes, 30 seconds. Do it every time. And so this goes back to my point on the product aspect, where it's not just an intelligence thing, it is a subjective exercise about how do you want the agents to behave in production broadly. And actually I think it's why it's so critical to product building.

[Matt Turk]

So we were talking a few minutes ago about that 2023 effort by OpenAI that required 800,000 human labels. How is what you're doing in 2026 different?

[Mitch Toryanowski]

So, yeah, good question. So we are today at least not actively rewarding the underlying model. So we're not currently post training our own models by rewarding them on this process. I do think that's a very interesting area of research. We can talk about that later. But that is not actively what we're doing right now. It is something we're actually researching separately. But that's more in the future. And so if you kind of, if you maybe take a step back, it's useful to sort of analogize the work of agent building and context engineering to the work of training a model directly. I think when people think about context, people say prompts context. I think the mental model people have usually is like, oh, I wrote some English model, what to do. I think it's the wrong mental framework. I think the framework I like is thinking about it as training data, except you are just training the model at runtime. It is training data. And because the model is learning at inference time, the total amount of training data is far lower. The total amount of context in your system that the agent would progressively learn or discover throughout its trajectory. Obviously orders of magnitude lower than the amount of data that you're training, like post training a model on. And so what you're doing is you're essentially taking this data and you're trying to ensure that it is of the highest quality to get the agent to exhibit the behaviors that you want it to exhibit. And Obviously the data is only one part of it. There's the harness, what are the tools, what are the capabilities, the environment, there's all that part of stuff, obviously which model you're using, things like that. And so what's different here is that we're taking this signal and using it to improve the entire agent system, which requires far less data scale than if we were trying to take the signal and more literally reward it in an RL capacity to the underlying model.

[Matt Turk]

You mentioned a judge a few minutes ago. Maybe walk us through how you train that judge to do what or how you instruct that judge to do what. And I guess the obvious question of who judges the judge.

[Mitch Toryanowski]

Yeah, I think that's true. Not just for behavior evals, but also for outcome based evals in general. It's a great question. I wish we had more time to go deeper on this. The reality is we just don't have the time or resources to spend a huge amount of effort like perfecting every judge. But I'll give you kind of the high level. Generally what you do is you need to build an intuition for if the judge's taste is correct. And I do think an interesting area of potential post training research is on judges and potentially taste there Today you need to set up the judge so that it has the information it needs to make the decision and it has the right kind of framework to do that and that it has the data and mentality to do that. So I'll give you an example with behaviors that you could imagine being pretty complicated. So right now at least the behavior judging is relatively expensive because it's a pretty advanced judge in that it is also an agent. It's not a judge in the traditional sense. It's literally an agent because it has to look at the trajectory. So it's quite expensive. You can imagine in the future. And I think folks like BrainTrust and others are starting to think about this is like how can you label trajectories better so you can potentially more easily filter the trajectory to only the potentially relevant parts to give to a judge instead of having it look at the whole trajectory in some ways. But if you have a trajectory, especially if you have a long horizon, one that might have a lot of sub agents, you as the judge need to think about, well, where do I go in this trajectory? How do I understand it? You probably want to have a map of it in some form. Who am I even judging? Imagine you have an agent system with depth of seven. You could have literally seven layers of sub agents. Am I judging whether the root behaved properly or am I judging one of these other agents? And so you need to actually properly prompt and potentially tune the judge so it has a good understanding of knowing where to go judge, understanding the behavior itself, what is the condition and understanding how to judge whether the behavior occurred.

[Matt Turk]

Are there any trade offs with that approach? So what comes to mind is yes, having a human validated process guarantees or at least help secure a rigorous approach that's less likely to fail. At the same time, you are not going to get a move 37 kind of result where actually the AI would do much better work, much more efficient work by sidestepping this part and fast forwarding through those three steps. What are the pros and cons and trade offs?

[Mitch Toryanowski]

It's a good question. Well, I think for starters, and again, one thing I want to make sure is clear, I think to everyone listening is that writing a behavior down is expensive because it is something where you are now keeping state. You need to keep it up to date if the way you are making the model or the agent exhibit this behavior is through context. Now you have potentially duplicate states, depending on how you're thinking about it.

[Matt Turk]

And

[Mitch Toryanowski]

because of that maintenance burden, you ideally want to have as little behaviors as possible. So it's not that you look at what it takes to do a tax return and you say, hey, let's write all the best practices down and see if it's doing it. It's that you take the couple that you think are most important that have the largest amount of generalization to production and are the most impactful and you care about those, not everything. So I think that that's one important part. So ideally, if you do it properly, you still have rooms for the move 37s in theory. But I think there's another part here which is that what are you selling to someone if you are trying to. Just like if you were to hire an engineer and at your job, the company, you have a process and the process is like, I'm just making this up. But you write a quick architecture diagram and you chat with the CTO and you get it approved and you make a PR and you split up the PR in 10 different smaller PRs into a stack and then you merge it in and you make sure you have your end 10 test and you deploy it. That's the process. Imagine an engineer came to you and they're like, hey, here's my 1000 line priority. I'm going to merge in the production right now. What if it's better Than what you. What if it's a move 37 it could be better than what the CTO would have came up with. But that doesn't mean it's good like that. Good in the sense that doesn't mean the CTO or the company is happy about that result just because it's better.

[Matt Turk]

Right.

[Mitch Toryanowski]

Because at the end of the day, the reason you perform work is not because any individual unit of work is incredible, but because you can scale it to a company, to a system, whatever it is, to an organization. And so the thing that someone is buying from us is not this will be the best ever tax return. They're buying the confidence that the best looking one. Yeah, the best looking one or it moved 37 the TBE's over here or something. Right. They're buying that it's going to be consistent and reliable and something that they can trust that actually will. They will. You know, just like with a human, they can learn to trust more and more and then granted more agency over time. Right. And I think that that level of trust and reliability, like that's what you need to deploy into the real world. You don't need the move 37s. You need that maybe at the Olympiad math competitions, but not doing work in the real economy.

[Matt Turk]

Yeah. As I listen to you, one of the many things I find fascinating is that you're doing all of this without having actual insight about how the underlying model works. Like all of us, you're sort of guessing and inferring from how the model behaves through artifacts and judging from tool calls and how does that work. And then maybe walk us through each time a model changes or the next version of the model gets released, do you have to then look at everything that you've been doing in the light of that new model?

[Mitch Toryanowski]

Such maybe goes back to the Opus 301003 because I do think one thing that's really important when you're building agents, but definitely you're building a company around it, is you shouldn't be that surprised. You should have a model of the world and as things change, you should update your model. But to be successful, you can't just update your model all the time. You need to be right a little bit. And I do think that if you really internalize some concepts about this, that you now have this, forget even about the internals for a second. Forget about this. You have this magic box and you have this magic box for this alien, I like to call it sometimes. And you could send in huge amounts of data into this Alien. And it will be able to reason and learn at inference time within that magic box and then come back to you with output that, you know, now that tool calling obviously works and whatnot. You can plug into the rest of the system. That's kind of all you really need to know. And I think once you really appreciate what that means and then you take it to its logical conclusion, a lot of stuff starts to fall out of that because you start to understand. It's like, okay, well wait, if I have this magic box that can do this, does that mean that it could decide to call another magic box? Does that mean that it could potentially string together multiple of them in a row? Does that mean it could leverage. Obviously, at that moment, it's a magic box. But it has some state. We know this. It has an activation state. That's how the caches work. So there's some activation state that by definition is going to be biased to that current trajectory. And so maybe for review, you want an uncorrelated trajectory, right, where it's like a new box and it's just a smart. And I think if you build these kind of LLM intuitions and you combine them with maybe basic principles of organizational design and management, I think you start to get to maybe what is the frontier of agent building.

[Matt Turk]

Fascinating. Practically, how do you build that LLM intuition? Is that by just reading papers all the time or talking to researchers, or getting a sense for where the state of the art is going?

[Mitch Toryanowski]

Yeah, I think it's none of that, actually. I think it is all about. I mean, I think reading Twitter and whatnot, just understanding is good, but I actually think a lot of people over index on that. I think a lot of people, they think like, oh yeah, I saw this tweet, I saw this. It's the next cool thing. I think the problem is, without a fundamental grounding in how things work and what is possible, it's easy to feel like things are moving around a lot when they're actually not. Things have really not changed since 03. I would say almost everything since 03 has been relatively on. I don't really want to say on trend, and I knew this exact trend, but I would say it's all within the same paradigm. Nothing paradigm shifting has changed since 03. And I think the best way to understand it and learn about it is to just use them in your own work a lot. I think especially in coding and just trying to understand things. A good mental model is, let's say I tried to have an agent implement some feature for me, and it didn't do the way I want it to. Why? What is actually the limiting factor? You know, it's kind of like the famous Elon mindset. It's like, okay, you go to the main limiting factor and you figure that out. I think if you apply a similar mindset to agents and you understand why could it not automate this? Was it actually not smart enough? Probably no, they're pretty smart. They've been pretty smart for a while. And so if you apply that mindset to your own work, I find that is quite useful for building intuition. And I see that actually with people I interview a lot of the people with the best agent intuition, actually, Yes, a lot of people come from ML backgrounds, but people who don't, a lot of them are ones who are just really good at automating their own work, really good at thinking about it, really good at understanding what is the system to build. I did a talk at Data Driven about Ontologies, whatever, a year and a half ago or something, and I think there are a lot of people who think about ontologies in their own repo. And those people who are actively thinking, not just how do I prompt a model, but how do I build a system? They start to build really good intuitions.

[Matt Turk]

So we make sure to cover it before the end of the conversation. What is it exactly that you're open sourcing with BrandTrust like workers through the project, where people find it, the genesis of it. Why are you partnering with BrandTrust specifically on this?

[Mitch Toryanowski]

If we go back to the idea of behaviors, the idea is that you can actually write down in markdown. It is actually both a spec and a rubric. We called it specs and there were some people who asked, isn't this a rubric? And it is, it's both. The reason it's both is because it is not just used to grade or potentially reward the agent, it's also used to align the humans. I think that is an underrated point in that how you want the agent to behave, as we talked about earlier, is actually a subjective question. And so internally, you need to build processes to all agree on, hey, this is the product. How do you want the agent to behave? Going back to the example about the fast PowerPoint verification, you want a standard search, write that down. The project came about because I was actually having coffee with the CEO of BrainTrust, Ankur, and I forget why, honestly, but I still tell you I was explaining this concept to him. I was talking about this because we were doing this internally and I thought it was very cool. He got pretty excited about it. And one thing that I had internally that I'm trying to think about is we, I think do a lot of really cutting edge work, but it's not something we talk about much because to be honest, we're working all the time.

[Matt Turk]

Yeah. Right before we started recording, you were showing some internal slacks between your co founder Matt and yourself. And if I may disclose them, Matt was sending you a slack at 4:00am, those prompt refactors. Yeah. And that was last night. So it was a Sunday night as we were recording this and you showed how you were replying it to that slack at 6am so yes, 996 in full action amongst the co founders of basis.

[Mitch Toryanowski]

Yes, yes, yes. There's no 996 for Matt and I, it's 24, seven for the rest of the company. It's people work hard, but it's definitely not a996. And so we wanted to talk about it more and just share what we're doing. And we don't have a lot of resources to blast out to people. And so we were talking, I was like, well, I actually think this could be really good for, useful for brain trust and honestly the whole industry. Because if you have a standard that could be something that people define and can get automatically slurped up into observability platforms, monitoring platforms, and for people maybe who are less advanced, it could also have out of the box judges or ways to define, hey, here are the behaviors and you don't have to configure your own judge, you can actually get it to judge it for you and see the results. And so he got pretty excited about that. And so that's where the collaboration came from. So that's what the open source repo has. It has a couple small examples, it has an example judge that you can use. It has examples of actually written behaviors that you can leverage and sort of build your own. And I think it is useful to think about how to adopt the standard, but I think it is also maybe more importantly thinking about how to adopt the mindset of not thinking that an agent operating over 10 hours is a black box. It's not. It has a lot, a lot, a lot of data and you're probably doing a disservice to your customers if you don't understand how it's going about the work.

[Matt Turk]

And what would you want people to do with this open source project? Presumably contribute to it, use it for their own purposes. How does this become an industry standard?

[Mitch Toryanowski]

Yeah, it's a great question. I don't actually know. I think the coolest thing would be for people to contribute ideas to it. I think there's a lot of work left to do. I think it's just the beginning. I mentioned a couple things earlier, but there's so much to do around one, how you make good judges. Two, how do you properly label and dissect trajectories to make it easier for judges to understand? Because at the current level of expense, you couldn't run this in all of production, for example, because you're running judges on every single trajectory. But there's a lot that can be done, I think, with building out the work that sits on top of the behaviors. And I think also just seeing we purposely tried to make the standard relatively flexible, similar to skills, where it is just a markdown. There's not an overfit. Hey. And you need to have these exact five words. You can make it very broad and you can make it very specific, as long as it is still self contained to the point that a judge could look at the behavior and actually know was the condition for it to be exhibited met? And if so, did it get exhibited or did it not get exhibited? And as long as it has that, there's a lot of leeway there. And so I think we wanted that to be flexible.

[Matt Turk]

So what else should AI builders think about as they build autonomous long horizon agents? So we talked about judges, we talked about behavior. You just mentioned ontology, which in your talk at Data Driven and OIC you had mentioned, as well as a world for agents to live in. Where does that fit in the picture?

[Mitch Toryanowski]

Yeah, they're super important. A lot of people, when they see the word, when they think about agents, their mental model always goes to coding agents because that's everyone's experience with at least the people who probably listen to this podcast. People think about coding agents. A lot of coding agents are interesting because they obviously have a harness that they get shipped in, they have certain tools, they have certain behaviors encoded in them. In the context. Codex, by the way, is open source. I highly recommend people go look at the open source repo, but they don't control their runtime training data because their runtime training data, which goes back to my analogy earlier, which is your context, is actually the repo they're working on. And so you could have Codex, the same agent on one code base perform somewhat well and then another code base perform spectacularly because that code base has much better runtime training data. That is, it has potentially good skills or good context about how to operate in the code base, because there isn't contradictions and confusions, whatever it is. And so the ontology of your code base, it always mattered for engineers. It matters just as much, if not more for really good agents over time. That actually I think goes up another level if you're thinking about non coding agents, because in coding you don't own the runtime training data, in non coding you do. Right. Like most of the data that an agent sees when it's a basis agent basis owns, it's training data that we have to ensure works really well. And again, when I say training data, I mean like effectively handwritten context or things that are part of your broader progressive disclosure. Some could be handwritten, some could not be. Whatever it is. And because the agent is always starting from scratch, designing that ontology in a way that is ergonomic for the agent is super key to building something that's long running. That's both like the data that is maybe static, like skills and whatnot that all the agents have. But also once you get the really long horizons, if you're talking about a stateful agent that's maybe operating over months, days to months now, suddenly you have an ontology of going back to the memento example of information the agent's left for itself, which if you're operating for maybe a couple hours, could be a couple notes. If you're operating for months, you're talking folders and you have so much knowledge and context that describes the lived experiences of the agent that suddenly this new agent, well, new that is standing up with effectively very compacted context, has to get it back into the state of mind of its entire lived experience. And so the ontology designed to make it easy for it to do that, and the behaviors you encode that properly ensures it's doing that well are sort of the key to making it work really, really well.

[Matt Turk]

What does that even mean, designing an ontology? An ontology practically is what. It's a graph database. It's a series of relationships.

[Mitch Toryanowski]

Yeah, it could of different. There are different formats. I think the simplest way to think about it is honestly just a file system in which you have some structure. Obviously most people, you do virtual file systems and so you have a lot of flexibility there. So there could be other types of metadata associated with the files and the folders. There could be connectors in nodes in some graphdb if you wanted. Obviously there could also be embeddings. There's so many different sources of data that you can get to help enrich. And now, by the way, as models are getting cheaper and cheaper, more and more of that actually can just be done using inference instead of using determined things like graphs or things like embeddings. If luna costs is free, then suddenly you could run lunas across your entire ontology and summarize stuff for the agent up or things like that. And so that's kind of how I would think about it. And maybe also one more piece. It's not just the. The ontology doesn't just mean the structure of the folders in ontology traditionally. It's also like the language, what are the objects and the concepts? Because at the end of the day, if you're being trained at runtime, you need to ensure you're not confusing concepts together and that things kind of generally make sense. And so that's what I mean by defining the world. You're defining what the agent can expect to see as it goes and explores the kind of world around it.

[Matt Turk]

You mentioned somewhere that internal documentation for agents has to be treated like a code base. Delete a crucial paragraph and you break the agent, just like deleting a line of code. Is that documentation something outside the ontology that the agent goes search like a tool call? How does that all work and what are the best practices?

[Mitch Toryanowski]

Yeah, that's a good question. So just to quickly separate, just now when I was talking about the ontologies and the historical, I kind of was referring more to inside of the basis product and the kind of production product in terms of internal use of agents, like, let's say, coding agents or maybe other internal agents that we might make there. It's kind of interesting because you're in. Depending on what you've set up, your environment might be less controlled by your ontology because to your point, in the real world, you have to go and access linear and GONG and pylon and all these different things. And so I think one of the keys for internal agents is having a very keen understanding of what is canonical versus what is not canonical. And so just like if I'm a human who joins an organization, I could go and read all the gongs. But what is our sales strategy today? If you watch the gongs from two years, you'll get a lot of context, but you won't know what your current sales strategy is. There must be some canonical piece of documentation. In practice, a lot of times humans learn this by just talking to people and you kind of learn stuff. But with agents, it's hard to get that and more Importantly, if you want real organizational intelligence, you don't want an agent hearing one thing from one person and another thing from another person or having them have kind of different written records of like what is the current sales pitch or how do we make our decks or how do we make our emails. You need one canonical source. And that's why I think for true agent native companies, especially in the future, today I think it's still quite early, but especially in the future, having a clear understanding of what your company canon is and organizing that in an ontology that makes sense and ensuring that that is kept up to date just like code in some form, I think ends up becoming one of the most important parts of a human's inside of a

[Matt Turk]

company and within the basis teams you're hiring for jobs that quite literally did not exist two years ago, like language architects or agent managers. Who are those people? What do they do and what's a good background for them?

[Mitch Toryanowski]

Yeah, we need a lot of them. So if you're listening and you want to join, please hit me up. Great question. We're still figuring that out. It's not easy. Here's what I know you need. I think this has probably gotten someone in vogue recently, but I think one skill that really matters is good systems thinking. And where does good systems thinking come from? It comes from people who have had to think about some abstraction, some system, something, and design it in such a way that it performs in a plethora of situations. So obviously if you're a really good engineer, engineering is systems thinking. Now I think the majority of engineering historically has not been really systems thinking based. It's been a little bit more execution oriented. But if you think about the hardest engineering, like hey, I'm trying to design what the systems are going to look like, or I'm trying to create the right abstraction that really is high on systems thinking. But it's not the only profession that's like that. I think law actually is kind of like that in many ways. I think about, I think maybe the founding fathers would have been really good context engineers or agent managers because you had to write a piece of English that was going to be interpreted at runtime literally millions of times by lawyers and judges and whatnot. And so if you're writing a law, and I don't mean like some politician, but if you're actually trying to write a law and trying to write a. Well, you're trying to somehow write something in English that will abstract at just the right level across the universe of situations and you have to have theory of mind over the judicial system, to think about how they'll interpret it. It's funny, you'll look in certain airports and sometimes they'll have these signs. It's like, don't bring a gun, don't bring a sword, don't bring blah, blah. And it's like you can list out 30 things to your point on Brittle rules and so same thing, you can list out 50 brittle rules or you can write the right abstraction that somehow covers it just perfectly. So I think anything where you need to think in abstractions in that way, I think is good practice for being a good systems engineer. I think people who've had to manage the most complex Excel models in the world is honestly not that dissimilar either. So I think there's a lot of potential backgrounds for.

[Matt Turk]

I think I did that. Driven. When you spoke, you were talking about your deployed intelligence team and you were saying deploying agents at a firm was like onboarding 300 brilliant alien employees who have no context. Hence the deployed intelligence team. So what do those people do? Are they still around or has that concept evolved?

[Mitch Toryanowski]

No, no, no, of course. The DI team is awesome. I think to this day I need to go Google it. But we definitely came up with the term deployed intelligence. I know, because if you Google it, we are the first company that comes up. It's a cool name. I don't know if other people have taken on the name. I don't think it's actually caught on yet. But the idea is actually it's not fdes, so it's not like engineers who are coming in and building something custom for you. It's also not these kind of agent PMs you see now at some companies that I won't name, where it's like these PMs are kind of coming in and building an agent for you using an agent builder. It's actually neither of those. It's people who have a deep empathy and understanding of the profession, of what it takes to put in place good process and what it takes to be successful when suddenly you can start to offload certain things to agents. The DI team's job is to come work with our accounting firms to help them transition into this new era. We're giving them magic, but if we don't teach them how to leverage the magic, not just in the day to day, but how it changes the nature of the firm. How does it change what kind of business they can take on, who they hire? How can they scale to be that firm of the future? That everyone wants to be. That's what the DI Team works really closely with people to do because it wouldn't be fair to ask them to go and learn that themselves or do that themselves. Instead, they bring a lot of the knowledge about their firm, about how things have worked, obviously their people. And we can combine that with our knowledge on how to deploy agents and I think together get to something where it can be a really, really frontier accounting firm.

[Matt Turk]

Speaking of frontier, maybe as we start getting to the end of this conversation, I would love to spend a little bit of time on that. Obviously big topic in 2026 is the concept of self improvement. Where does that fit in your p. AT basis and with autonomous agents? I think you talked about agents developing a theory of mind about other agents. So at a system level, paint that picture for us. What does self improvement look like?

[Mitch Toryanowski]

Yeah, we actually internally, one of our, in the thread I talked about some of our research directions. One of our big research directions is how do you actually close the loop, as we like to call it, going from hey, an agent made a mistake or not performing well or whatever, we've gone and improved the system to do that. And I think that closing the loop is going to happen pretty fast. I think you'll have, I don't know about the entire loop being closed, but I think you'll be relatively close by end of year. I think that. So as agents are getting better theory of mind over themselves and therefore other agents, you have two things happening. One is at runtime they're being better at orchestrating sub agents and also regulating their own environment for themselves. But it also means they're becoming better context engineers. They're becoming better harness engineers. Right now they are far, far, far worse at engineering agent systems than they are at engineering most software. Far worse. Because by definition that kind of work, which is so novel, has not seen a large amount in their training data. And so they have very bad intuition. Actually, I think a lot of the mistakes a lot of agent builders make is they have this weird intuition that slop in your context or your agent is somehow more acceptable than slop in your code. And you'll see people freaking out over a code file that isn't abstracted properly. And yet their context is total shit. Which is hilarious because the context actually affects the performance at runtime. The organization of the code does not affect the performance at runtime time. And so I think a lot of obviously because of built up behaviors, a lot of engineers, they treat the code as more precious than the English when actually The English is more precious because the English affects the performance. The code does not affect the performance. Assuming the logic is the same, it does not affect the performance. And so I think as agents get better and they get better at this type of engineering of how do you build agent systems, you'll start to actually be able to close the loop. Because in order to close the loop, right, you need to take the signal that you are getting and you need a lot of signal. One of the pieces of behavior, one of the points of behaviors, is a way to get more signal. Whereas if you only have outcome based evals, your signal is pretty sparse. So how can you take all of that signal and actually now use it to improve your system? Right, you proliferate it throughout the system. And that could be done by an agent that is like updating the context, like changing the nature of the tool, updating the harness, et cetera. And I think you'll probably, in a way that is generalizable, that doesn't overfit, you can do it today if you want it to overfit to some signal. But if you wanted to do it in a way that generalizes, the agents need to get a bit better still. And there's some more work to do there.

[Matt Turk]

What about self improvement at the model level? So I think you mentioned earlier that you guys don't do yet much reinforcement learning on the model itself. You're doing mostly harness work, if that's correct. But is that the next big bet to start doing actual reinforcement learning on behavior adherence?

[Mitch Toryanowski]

Yeah, it's a great question. The way I think about it is that the hard part of reinforcement learning is deciding what is your reward function and then deciding how you are going to allocate that reward over whatever occurred. So that is like the active research that we are doing, because that's what behavior, it's a source of signal that you can use to craft into a reward function. Same with some of the other kind of production monitoring work and some of the evals that you build. And so deciding how to build good signal and doing the research and understanding what does it mean, especially in a non perfectly verifiable domain, that's the work we're doing. Whether you take that signal and then proliferate it through the weights through formal RL or you proliferate it through the harness through whatever you want to call it, like informal RL or harness engineering, I think is a separate question from the development of the signal. But I think the development of the signal is really the hard part. And that's the part that we're really focused on. And today we don't go directly into the weights. And primarily the reason we don't do that is because a lot of the advancements the models are having when it comes to orchestrating themselves yield far more performance gains than benefits you would have of updating models directly. I think that might asymptote. We'll see. But I think that's one of the reasons that you don't go to the weights yet. I do think that is a very interesting research direction as well that we'll start pursuing. And so for us at our level, at the kind of applied application level, that's the kind of research that we're doing. But I suspect that in order for the models to actually do real work in the economy, that's the only way you can get there. I don't believe that if you were to train a model and you scale up the amount of pre training compute and you scale up the amount of post training from perfectly verifiable rewards that suddenly will output a model that will do a tax return reliably, it might do one that's really good. But the question is not does it do really good? Does it do it at the level of quality, reliability, scalability that would be expected from somebody operating with it.

[Matt Turk]

Do you worry about the bitter lesson though that you mentioned earlier in this conversation? Do you think that all this work that you guys brilliantly and others are doing at the harness level are going to be eventually swallowed up by the model?

[Mitch Toryanowski]

Oh, I assume it will be swallowed up, yeah. I'm not worried about it. That is absolutely the future. And in fact, if you look at my thread as a hint to this, I think I said the behaviors don't get shown to the agents yet. And the reason is because if you are truly bitter lesson pilled, then in the future this whole idea of trying to context engineer it will just go away and you'll just specify, hey, I want these behaviors, it'll just work. And so I definitely think it'll get swallowed up. No question. I think that how long it'll take to get swallowed up, I don't know exactly. I think it's probably sub five years. I don't think it's sub two years. I think it's probably sub five years. And so for us, we're in hyperscale mode. We can't wait for the bitter lesson to arrive to perform tax returns accurately. And so that's why I think that'll be one of the keys to Doing it. I do think that. I don't know, this is now total speculation, but I do suspect that maybe some types of process rewarding for this type of work might end up being pretty important for optimizing the compute that the labs even use over time. Because I don't know if you want to move 37 every single profession in the economy. We have a lot of learnings already and there's kind of no reason to do that would be my guess.

[Matt Turk]

So do you think of doing your own RL as some kind of moat against being swallowed up by model performance? As you think about applied AI companies of the future, will they all be RL labs of some sort?

[Mitch Toryanowski]

So generally, and if anyone's currently trying to found a company, I recommend thinking this way. Technical moats are not real moats. There's no portion of basis's long term terminal value that stems from some secret RL trick we found that nobody else found. So that doesn't matter. What matters is that right now we are obviously very good at building long horizon agents that can be reliable and deployed in production and we'll continue to be the best at that. And that allows us to win market share and get deeply embedded. And that's why we move really fast. Because the work we're trying to do is to go and proliferate maybe before you get to AGI, whatever you want to call that. So I think that most of the moats that will exist will be business moats. That is true in the AGI era. I would argue that's also been true in the pre AGI era. I don't think that Salesforce can write a better SQL query than I can. The moat that Salesforce has is not related to their technology. Right. It's related to their business position. You know, it's the powers, it's the workflows that they own. It's all so many of these different things that come with being embedded in. And that's what matters, not the technology. The technology is a temporary dislodgement that allows someone like us, who obviously didn't exist three and a half years ago, to now suddenly be able to do all this kind of work. I do think though for a long time, maybe to your point, that it's not like it will be in a total commodity. Because just like you could have a bunch of genius humans doesn't mean that all the genius humans are equivalent in being able to do a tax return. Because at the end of the day there are certain things that you care about for that that are subjective. And I do think that building up the competency of the work we're trying to do is actually really important for us to be able to deliver really good quality for, I think, for the foreseeable future.

[Matt Turk]

All right, Mitch, it's been absolutely brilliant to close. Any advice for AI builders? Anybody like building agents today? In addition to everything that you've talked about, like the do's and don'ts and lessons learned and anything that comes to

[Mitch Toryanowski]

mind, I think maybe the biggest lesson I would say is it's easy to look at the world and how fast things are changing and say, oh, things are just one thing here. One thing here is ADHD on Twitter. It's crazy. The Chinese labs are released something every day and feel powerless to make first principle decisions. Whereas I actually think if you treat the new world as an underlying paradigm shift in the same way that I shift the cloud or something, some underlying paradigm shift, and you try to extrapolate, okay, you have these things, what does it mean if the intelligence became X better or if it didn't? I think you'll build a lot more coherent systems and make a lot better strategic bets, both at a technical and at a business level. Things are changing, but it's not like the paradigm is changing, at least not that dramatically. And so I think really understanding it is very, very key for being able

[Matt Turk]

build in this, in this world, which was absolutely fantastic. Thank you so much for sharing all of this. Really appreciate it.

[Mitch Toryanowski]

Of course. Thank you so much for having me.

[Matt Turk]

Hi, it's Matt Turk again. Thanks for listening to this episode of the MAD podcast. If you enjoyed it, we'd be very grateful if you would consider subscribing if you haven't already, or leaving a positive review or comment on whichever platform you're watching this or listening to this episode from. This really helps us build a podcast and get great guests. Thanks and see you at the next episode.