The Agentic Contract

So a handful. Fine. I've got one argument today, and by the end of this, you can decide if I'm right, if I'm wrong. Agents are not software. They're the first thing we've ever shipped that doesn't hold still. I've got a two year old, and agents are like my two year old because it's like the agent has eaten a bag of Skittles and it's just come up for air.

They're uncontrollable. And almost everything we know about running software assumes that they and they are software, and they hold still, but holding still and they are controllable. Every artifact you've ever shipped holds still. A binary, a service, a query, you deploy it.

And on a Tuesday, what you deployed on Monday is the same thing that you deployed on Tuesday unless you or someone else changed it. But agents break in four different ways. They make their own decisions. They access systems on their own, and they get abducted by teams that you've never met. But most importantly, and this is the thing that, you know, I get I get very passionate about is that they drift.

We know that they drift because the models change from underneath you. We know they drift because tool chain tool calls change over time. And it's the one thing that breaks it all. And just as an example, over the course of a few weeks, it started on the Monday, and it passed every test.

You did your evals. You ran it a thousand times. It cost you a $100, but three weeks later, it's differed. The model suddenly changed underneath you, and the data it sees shifted. Same code, different agent. No other production system changes whilst you sleep.

And this is probably the uncomfortable thing. Right? A whole playbook of building, testing, deploying assumes the artifact holds still. And you test it, you freeze it, you deploy it, and that's dead for agents because the tests you passed no longer exist. But I come from a world of non engineering.

I'm not an engineer by trade. I should have said that at the beginning. We've come to speak to probably 250 to 300 different organizations over the past six months about how you take an agent from PAC into production. Predominantly, those organizations have been highly regulated. Most of them have been in Australia.

And actually, the thing that I wanted to talk to everyone about a bit beyond the agentic contract is, well, in the past, engineers have been the control for software in an organization. Essentially, what engineers said is what happened. Maybe you worked with product. Whereas today, people can build agents, whether you're in the BDR team, the marketing team, the sales team.

And that relationship between engineering, product, the business, GRC, security is actually more important than ever. And aside from what I'm about to show on the agentic contract side, actually what we found is that the biggest problem for taking agents into production has been that communication between the different parts of the organization and ensuring that the business is obviously kept in the loop, but the engineers ultimately hold the control.

And the standard processes that you've always built around the engineering life cycle is maintained within the agent framework. But the problem is that these frameworks have made building easy, right? And the problem is that if a BDR has built an agent and they pass it to the marketing team and they pass it to the sales team, you go from one of kind of data risk into one of operational risk.

And ultimately now, businesses are trying to grapple with the idea that if we are saving two hours a day for 15 people, we're saving tens of thousands of dollars a year, but who's the person who is waking up in the morning when the American team found out the agent that they're relying on from the Australian team is broken? And that drift just exacerbates the problem.

These are quotes from organizations that we've spoken to over the past six months or maybe closer to the last three months, which as recently as this week. And I think it goes to show that lots of organizations are still seriously unsure about what actually rolling out agents needs to look like. And it's amazing because the things that we take for granted, those authentication protocols or authorization setups, the permissions that you've been building out as different parts of your platform over the past kind of however many years, have essentially gone out the window.

And oh, sorry. I don't know where that's gone. Excuse me.

Where's my mouse? There we go.

And I mean, my personal favorite is that one word YOLO. And this is one of the biggest fintech companies out there. And I think what it says is we've moved beyond this being a building problem to being one of kind of operations. And I'm not going to label this too much, but you've seen this all before. You know, you're probably thinking this is a model card, a service manifest, and governance with a new hat.

And that's a really fair argument. You know, I'm a vendor. I'm standing up here. But ultimately, everything's describing that static thing. Once you write it, you file it, and it's true forever. That's the assumption that we've always had. And so when we think about advising organizations on how you need to think about rolling this out and this is by no means a particularly novel way of approaching this, but when we think about that relationship between engineers, product, and the rest of the organization, I think the first thing to remember is not everyone speaks off the same hymn sheet. No one not everyone is thinking in terms that you think about in terms of, you know, who does own that agent? Who is that person waking up at 2AM in the morning on a Tuesday because the agent's failed?

Why is the scope allowed? And I think this is a really interesting one because, you know, that BDR example I gave you is one that I have come up against of, you know, I've set up Clorid Code. I've integrated it with our CRM. I'm uploading a variety of different I shouldn't be saying this out loud, but a variety of different documents into that platform.

And that's just us and a team of five. But I know in big organizations, this is happening all the time, and that it's happening at scale. And so really being clear and helping the rest of the organization to understand what is in scope, what is the data that actually needs to read and write. And I know, because I've been on the other side of these conversations from you guys, I'm always going to want more.

And I think really having a system that or a structure in place that can support kind of you getting to the endpoint is really important. And this is just an example of what it actually looks like in reality. And I think what's really key is that the language that we use for this is ones that the organization understands, not in technical terms. And the clearer it is for simple people like myself to understand, the better it is for the organization to roll it into production. Because it's unlikely that the engineering team are gonna be stuck in front of that.

It was going to be the business or it's going to be GLC or it's going to be security. All of our best friends. So that's it for me in terms of where we're up to. I think the key thing from our perspective is that using an asset, like an agentic contract, to manage the way that you run your agents is a way for you to be able to ensure that the whole organization is on the same page.

And ultimately, if you don't have that, then it's going to be very, very difficult to kind of roll those agents from POC into production. And I think ultimately, the next decade is not about how easy it is to build an agent. It's how you operate it, beyond the first agent to the tenth to the hundredth. So the organizations out there that we speak to that are doing thousands, if not 20 tens of thousands of agents.

And I think the teams that work that out, that work out how to operate agents at scale are gonna be