为什么 AI 提升了个人百倍效率却难以改变企业：构建生产级可靠 Agent

I'm Mitch. I'm one of the two co-founders of Basis. We are based right here in New York City and the thing that we focus on is how can we get agents to do production-scale work reliably enough so that we are trusted and used end-to-end by accounting firms across the country. So, a lot of our research really focuses on this. How can you get these agents to do real work in the real economy?

At Basis, one of the things we have is that humans are already used to working with non-deterministic systems. It's just those systems are normally their co-workers, not their computers.

And so, I actually think to answer this question, it's useful to maybe look at the existing way we organize intelligent systems, which are companies.

Organizations need to trust that the people doing the work at every level are doing it in a way that is going to produce good outputs consistently at scale, right? If look at this image here, the uh here I'm showing an accounting firm, but this could honestly be any company, traditional company. The person who is the head of the firm, they have literally no idea about the exact day-to-day of the people at the very bottom. And yet somehow they trust the work is going to be done.

How does that happen? It doesn't happen through deterministic systems, right? People are not deterministic. They're intelligent entities.

And instead there are processes that are put in place, and those processes, if we believe the people who, you know, put them in place, think that those processes will generalize to good outcomes, then they can be comfortable that even though the people executing the processes are not deterministic, you will generally get to good outcomes if you follow the process.

You wouldn't expect the firm to just let anyone Google, you know, extract PDF and then just use whatever they want to go extract it, because now you wouldn't have process.

As I said earlier, everyone already has co-work, ChatGPT, Codex, Cloud Code, but where is that productivity?

Our opinion is there are two main problems that come with what I'll call coding-style agent products, where you're working with an agent and you just tell it to go and do something.

The first problem is that there is a competency gap, because agents, as you think of them as you think of them today, they outsource the complexity to the user. Right, if I'm the user, I now have to manage my skill and memories and think about how to when I should use the agent. I have to have like theory of mind over it. This is really hard. And for those who are here, maybe you guys find it easy, but I promise for the wide majority of knowledge workers, they have no idea how to do any of this.

Which goes entirely against the way that organizations scale. The process should be coming from senior leadership down, not from any individual employee deciding how they're going to do their job. Right, if you going back to my example, if every employee just made up their own way of extracting data, you know, even back in 2018, that wouldn't be a good outcome.

And so, we believe strongly that the key [snorts] to building production agents that actually do work end-to-end is solving these two problems.

And the second is the process gap. You need agents to be reliable. Not having a stroke of genius one day and forgetting something the other day. It's not about being perfect. Humans are not perfect. Right, nobody is looking for perfect. What you're looking for is reliability and consistency and trustworthiness.

So, what does that actually look like? We think that to be simple and reliable where you know it's you don't have to think about what to do. The agent can just do it for you without the user knowing the internals. To do it the same way consistently, you have to be you have to be opinionated.

I want to point out that getting it right isn't actually the main task, because again, humans are imperfect themselves. The point is to do it in a similar way. It's okay if you you can't do something. But you should be consistently able to not do something, and then you get better, just like a person does. If you suddenly one day are an expert at something, and then you miss something very basic that would be expected, now you're not reliable.

So you have to be opinionated.

What's an example of an opinion? Let's say we have an agent, and we need to go and read a PDF. So in this case, what is the best way to read a PDF? There's many ways. You can throw it into a VLM, you can go write some Python code and use an open-source OCR library, you can work with one of the many OCR-specific model providers. You could do an OCR, and then you could have the VLM check its work. You could have five VLMs check its work. You could do 100 VLMs and take the best of them. There's literally infinite possibilities here.

And so if you just said, "Agent, extract Excel extract PDF," you might get good outcomes, but they're not going to be reliable. Right? Not because the process it did was bad, but because the process it did was not opinionated.

And so, there are lots of different ways to develop opinions. And one of the key points here, I'll just make before I move on to talking about how to use the opinions, is that the opinions are not just about accuracy, right? We just talked about the example of taking a picture of a PowerPoint. Well, that adds latency, right? You may not want that. Maybe the agent only makes formatting mistakes one out of a hundred times, and you're okay with that. And so, therefore, you don't have to take a picture of the PowerPoint. The point isn't exactly what the opinion is. And this talk, we're going to focus not on how to develop opinions, but why opinions matter, and then how to leverage those opinions as you scale in production.

How do you know that the evals generalize to production? Right? You might have a thousand cases or a hundred cases. But in production, if you're doing real work, you're going to have hundreds of thousands of situations. And that's only going to increase as the trajectories get much longer, because the amount of decisions that are made in a trajectory uh just grow exponentially as the like long horizon abilities of agents increase.

And so, I can't prove if I If you're looking at all these distribution of uh trajectories, you can't prove every one of them is correct. You don't have a ground truth for every trajectory. But you can potentially look at the trajectories to decide if the behavior, the opinion that you have, is actually happening.

And you can then infer that if it's actually happening, it's more likely to generalize to production. It's not perfect. You don't know for sure, but at least you are having an opinion.

But, what you don't want is a customer getting one way one time and another way the other time.

And so, what would you do? Well, first, let's understand what governs the behavior. Right? The behavior's not just you write the two sentences into your system prompt and it just works. That might work for very simple narrow agents. But, when you're building these big agent systems, the behavior's actually a combination of the system prompt, your progressive disclosures, uh potentially tool descriptions, obviously the training of the model. There's a lot of things that govern the behavior.

And one tip, by the way, I have for when you think about building production agents is really think of the context the agent is going to see as it's working as runtime training data. The word prompt, I think, trivializes it a bit, right? At the end of the day, this is the data that the agent is being trained on at runtime. Not literally trained on, but effectively trained on. And so, you want to care about every single token and understand how that data causes the agent to behave in certain ways.

And one of the things that we developed at Basis was this concept of a behavior spec. And the idea of a behavior spec is essentially saying before we update the context or write the context, uh what do we actually want? What is our intent? You can kind of think of this a little bit as like a product spec for the agent era.

And you can't write You shouldn't be writing every detail down. You should be taking the most important opinions and putting it because if you put everything, you'll be duplicating a lot of state. So, you define the ones that matter the most.

And then you can use them as a way to align your team from a spec perspective, but then you can also use them as a rubric. And you can say in this particular trajectory, whether that is in any trajectory that doesn't have a ground truth, did the agent get into a situation in which this behavior was relevant? And then if so, did it actually exhibit the behavior?

And this way you can scale the amount of signal that you get on your trajectories far larger than trying to increase the amount of outcome-based evals, ground truths, and rubrics that you have. Those are really important, but you cannot scale those anywhere near as fast as you can scale the ability to supervise what the behaviors of the agent are.

Um this is so this is actually the second concept, um which is called forking, which we can combine here with behavior specs to think about. Forking, if you've ever used uh cloud code or or Codex the web apps, there's a little little fork icon uh under each message, uh where you can essentially create a copy of the agent using the same thing, which works really well on your local computer. It's hard to build a system that does this in the cloud perfectly with recreating the database environment and recreating the uh the prompts, uh all the all the different environments. But forking is another tool that we use to check the behavior.

So, a flow that you can imagine is saying we had a trajectory, could be in an eval set, it could be in testing or in production, and it failed the behavior eval. And now you're trying to understand why. Why did it fail failed the behavior eval? Why did it not exhibit the behavior? And then you can go into the trajectory, go right before the point in which the agent made the decision that was in contrast to the behavior, assuming again your behavior is good, and it's actually producing signal.

And then you can fork it. And when you fork it, you can ask the agent uh or you would fork it right after it made the decision. You could ask it why did you do that? Or you can go and update the uh context of the agent and see if that improves the behavior. And so with forking you can start to actually take the signal and start to figure out, okay, how can we then improve the harness to now uh leverage the signal?

Whereas if you're just looking at signal from an outcome-based eval, you can't do that anywhere near as easily because it failed the outcome, how do you know why? You have potentially a thousand inference calls in your 5-hour long agent trajectory run.

Uh this is going to sound silly, but I promise it's very effective, which is that you can, when working with coding agents, ask the coding agent to make a sub agent that pretends to be your production agent. And you have to tell it to not cheat, and you give it the system prompt and the skills, and you render everything perfectly. And what you can do is you can ask it what it would do in some scenario. You can give it the situation, and see if you can recreate the situation that you saw in your eval or in production. And if you can recreate it, now you can tweak your context to see if the sub agent would change its behavior based on your tweaks.

And the reason to do this is obviously far worse than forking, but you do this because this is much cheaper, much faster, and allows you as an agent builder to really easily iterate on ideas without needing to go through the expensive process of actually forking an entire environment.

And you can do this today without building anything. Um I did this for literally year year and a half plus before we uh built forking into our internal systems.

And the main idea here is understanding that if you look at the the distribution from earlier, you're trying to understand is the is the uh agent generalizing to that distribution. And so you don't know purely based on the outcome eval. So you can try to choose the best outcome evals that should represent the curve, but you don't really know. And so supervising the process through some of these methods gives you some additional signal in order to understand if it's generalizing properly.

And now if we go back to the firm, we talk about talk about supervision, we talked about how the agent uh if he's our opinionated, he can be more reliable and he actually can be simpler. What that means is the agent maybe it starts doing something narrow, but because people will work with it, they see that it's easy to use, and they see that it's reliable. As it gets better and better, they will trust it more. It's just like a co-worker. You have a co-worker day one. Imagine someone sends you a PR. You're not going to if it's you're looking at two axes whenever someone sends you a PR. It's these two axes. What's the black greatest of the PR, and what is your perception of how competent that person is?

Right? If the least competent person in your company is sending you a PR that's editing a core service, you're going to look at it. If the most competent person is sending you a PR that's editing an internal document, you may not look at it as much. And so this idea is true with humans working with agents just like it is with humans working with humans.

And the answer is they might. But that's not how you scale GDP and scale output. Nobody wants their agent to move 37 their tax return. They want it done reliably, at scale, in a way that they can trust, and in a way that their people know how to work with.

And so the thing I will leave you with is for agents to diffuse, they need to be simple. For teams to trust them, they need to be reliable. The way you get to simple and reliable is you develop opinions on how the agent behaves, and then opinions allow you to build that additional signal that helps you start to close the loop so that you can achieve self-improving agents in production.

Thank you very much.

[applause]