Scaling the enterprise harness: How to achieve AI agent controllability across an organization

Transcript

Ken Mugrage: Hello, everybody. Welcome to another edition of the Thoughtworks Technology Podcast. My name is Ken Mugrage. I'm one of your regular hosts, and I'm very pleased to be joined today by a couple, actually somewhat regular guests as well, but some leaders in our organization. I will ask them to introduce themselves. Thomas, we'll start with you.

Thomas Squeo: Thank you, Ken. Thomas Squeo, Chief Technology Officer and Head of Advisory for the Americas. Matt?

Matt Kamelman: I'm Matt Kamelman. I'm based in Barcelona, Spain. I'm the Global Innovation Choreographer for Thoughtworks, and I'm really glad to be here with both you, Thomas, and Ken, sharing the space.

Ken: Great. Thank you both for joining. What we're talking about today is a topic that is, like a lot of topics this year, very new. Thoughtworks hosted a couple of events this year, one in February and one in June, and it's interesting because there's a concept that didn't exist in the event in February. We're talking about creating AI, there's Spectacode and all these other kinds of things, but shortly after that, the term harness engineering came out, and it's taken the world by storm, and then in the event in June, not even six months later, if we do the math there, it's winter and spring, but it was actually only four or five months apart, everybody wanted to talk about it.

It was very much engineering-first, which as an engineer, I appreciate, but it didn't address some of the enterprise things and so forth. What we're going to talk about today is what our guests are calling Enterprise Harness Engineering. Regular listeners who may have heard my soapbox speech before, where I think it's important that we define terms. To that end, what I'm going to ask is for a definition here, and I just want to remind the listeners that what we're looking for here is a shared understanding, that for the next 30 or 40 minutes, when we say harness engineering, you know what we're talking about.

I encourage you, even if you don't agree with ours, to make sure you agree in your own teams, so that when you're using words, if someone says the unit tests are done, everybody knows what that means. Thomas, I'm going to put you on the spot here. What's your definition of harness engineering?

Thomas: I'll go right into it. Basically, harness engineering is the discipline of designing the controls around the AI agents so they can operate with reliability, accountability, and autonomy inside the business that is useful. You made a comment about the definitions. I think that we hear about harness engineering. We've also heard about loop engineering. It is not settled science on what the end term will be. We're using this term internally. We're using this term in front of customers, but it might come at you, and somebody might talk about loop engineering, for example, and that means pretty much the same thing. This is combining the specs, the context, the permissions, all of the elements around how an agent operates, what are the tools, the tests, its evaluations, and the feedback loops necessary for it to be able to function and deliver business value.

In short, if you think about the model, that's the intelligence layer, and the harness is what makes that intelligence layer safe and dependable at an enterprise scale. One of the things that we typically see when we are talking about moving into an agentic model is that with a solidly built and solidly understood harness, you don't always have to go to the best and most capable model.

Matt: I love metaphors, so I would encourage people to think about it, for example, like a wild animal. The harness on a powerful animal it's basically constraining the capability that the animal has. The animal's capability is real, and it's valuable, but without the harness, you can't direct it safely or reliably. That's basically what we're trying to build with a harness. The harness encodes under organization's constraints, which, by the way, was a term back in February. Constraint engineering. I think it was what I heard the first time.

It basically controls your permissions, memory, the governance into the agent, basically, and it makes sure that the organization actually does what it intends and finds boundaries from the business. In the case of enterprise AI, it would actually also build a harness on the business, on the legal side, and on the risk context it requires, which is part of what we're going to talk about.

Ken: I appreciate that, because we hear all about making it faster and talking economics and tokenomics and all that, and having that safety sounds like that's a part of that, which I'm sure we'll get into. We've all heard about prompt engineering. Is this the same, is this better? How is this different from prompt engineering?

Thomas: If you think about the agent is going to interact with a prompt. It's not uncommon for when you put an agent into motion, or there's a handoff, the prompt is the key input for it. If you think about this from our view, when we start talking about the enterprise context, it's not just is this the next generation of prompting. I think that the agents have a degree of autonomy where they're going to be solving their own and creating their own prompts on an ongoing basis.

If you think about this, not only are you dealing with what is the low-level prompt doing, but I think that more importantly, we're thinking about this as who in the enterprise is understanding and managing risk associated with these things. If you think about this, Matt uses a term that I agree with. It's called bounded autonomy. If that prompt has a set of parameters, what is the span of control or span of decision-making authority that that agent has? That's what we're suggesting and controlling in the Enterprise Harness. Matt?

Matt: Let's take it from the prompt, Ken. You say you were comparing it with the prompt? The prompt basically involves that you think a lot before you actually build it. That's prompt engineering into what you exactly want the agent to do, or take it to the part of the enterprise. What Thomas was explaining is the fact that there's a lot more thinking or reasoning and the context basically of a whole enterprise that needs to be taken into account, especially if you're going to have an agent that can do things on behalf of the company.

There's a difference between an agent that is going to, I don't know, either help writing code or something like that, or an agent that is actually going to handle, for example, invoices, an agent that is going to handle clients' orders and stuff like that. At that moment, you have to have it very, very clear for your company what level of authority that agent can do to act on behalf of the company. That's something that we have seen in the news in the last six months or so that has been neglected a number of times. The span of the problem can become super heavy.

Basically what I'm trying to say is I think that everything is happening at the same time. You were saying everything is happening so fast. We have been focusing on important matters like actually deploying the agents and how do we actually do it, how do we control the expenditure, the amount of tokens that we are using. At the same time, you have a whole company that is using all of this, and it's evolving on the amount of things that it can actually offer to their clients.

The part of how we're actually building all of this and it's not just made in autonomy, it's just about the part of the kind of knowledge that we are going to retain from the actions of the agents and how that translates into the whole company's knowledge base too. I think it's another layer.

Ken: I have to admit I'm having a bit of a flashback to, "Hey, we got this thing called public cloud now, and anybody can deploy their own things and get Terraform and et cetera. Like whoa, whoa, whoa, timeout. You're putting our logo on stuff that hasn't gone through compliance checks. We're going to have a platform team." Is this a different platform?

Thomas: Yes, 100%. If you think about platform engineering, as that ultimately that goal was repeatability, this is now offering controllability. If you think about where we used to do things like paved roads, not only would you have your ALM context and your internal development platform, you would have the ability to have your CICD and common golden paths and so on. Then ultimately you would overlay your observability. What we're suggesting is now you move that up a level and now you're governing that operating environment.

I'm going to make it very clear, like, let's take this out of the abstract of widgets and things that we're talking about. We do this today in a mainframe modernization context. We work with Mechanical Orchard. We work with their Imagen platform. They have built a harness which is purpose-built only and solely for modernizing complex mainframe environments to be able to take that through and instead of thinking out as a prompt, think of it as that understanding of the code and the change, data capture and the data pipelines, all of that are the inputs for those agents to be able to work. The autonomy for those agents to work comes up with what we call behavioral equivalence, and once that behavioral equivalence is set up, we would then let the agents run a series of tests or synthetic versions of a job or real versions of a job. That autonomy to be able to ensure that what is happening is happening in a way that is human-consumable from a sociotechnical standpoint. Did it technically survive or deliver what was?

Then how do you actually promote that with the confidence of knowing that what was built by those agents is actually able to be promoted into a production environment and then taken over by a cloud-native team? That could be a microservices architecture that comes out of that, a modular monolith that comes out of that, or an agentic architecture that comes out of that.

What's happening is that you have now, hey, my goal is modernization of this origin system. The harness allows engineers, Thoughtworkers, to be able to build in that environment and do that modernization, to be able to deliver that value. Then ultimately, what goes into production has gone through this harness, and that harness has now had those controls through it. When I think about it, if you were going to roll the clock back and you were going to think about platform engineering and all the different ways that we did platform engineering of tools providers, you could roll your own, you could create your own environments and so on and so forth.

Whereas the traditional notion of platform engineering is repeatability and operating in control, this is now controllability and operating in control. You've now overlaid, now, a way of managing non-deterministic systems at scale in this regard. The reason why I think about it in the notion of mainframe modernization is that people have said, "Hey, that's not an addressable problem for a really long time." We've cracked that nut, and we're very happy about it. We also have other tools that we have built inside our own organization that allows us to be able to manage agents at scale. Some of it is basic telemetry, let's just say they are deterministic SLAs, configurations, things that you want to be able to say, "What are the ADRs that are input to these things?" Those are relatively static items, but when they flow through the system, and the agents are working on them, they're grounding themselves in that context. Matt, thoughts?

Matt: I think that's always super, super accurate. I would just add that I'm always thinking on the part of the company, let's say the client or whatever company or enterprise. It's still trying to sell their products or deliver value in whichever way. That didn't change. We now have a new tool or a new set of tools that are able to do a number of new things, and those tools do not necessarily understand or hold the amount of knowledge and context of the company to know exactly what they can or should do. I know sometimes it looks like a kind of far-out comparison, but every time you onboard a new worker into a company, the worker goes through an onboarding that teaches the worker a number of rules that are not implicit, that are actually very explicit of what the company is, what the company can do, and what the company cannot do.

Part of the harness on the enterprise would be, how do we actually translate all of this, and we actually keep it alive in a new kind of worker that is an agent? The difference with the worker is always capable and actually liable for his behavior. A worker does something wrong, you're going to go and talk to the worker, and probably if it's something punishable, then you will take action if it escalates to something legal. An agent, you cannot do anything against an agent. You need to define how this is going to work for the whole enterprise. It's something that most of the time it's just being done reactively instead of proactively. We believe with Thomas, the more that you actually build this up and you actually think about it, and you build a harness for your whole company to actually be able to operate safely within this new environment, the better the company's going to perform.

Ken: One of the pushbacks that we often get whenever we talk about standardization, whether you want to call it harness or a platform or anything else, is team autonomy and taking advantage of the latest thing and so forth. Speaking of the latest thing, it seems like every week there's a new model from somebody, and this one is 5% better than that one, and this one is better at coding, or that one is better at reasoning. Although none of them actually reason, but that's a different rabbit hole. How do we deal with that? Is this just yet another thing where, "Hey, we're saying use our harness, but then Opus 6.0 comes out?' I think they just launched 5. The teams are like, "No, I need that 4 % improvement." How do we balance that on the enterprise?

Matt: This is a great question. Actually, I think it's important to know that if it's workflow first versus autonomy first. We're landing on an item that I want to make sure that we disabuse right now. We're not suggesting that there's one harness to rule them all for every enterprise. If you have this notion of, think about it, is that your harness is bounded by the domain context that you're operating in.

For example, we have an AIOps or an AI SRE team that has built a set of harnesses that are purpose-built for the thing that they're wanting to deliver: stability, scalability, security, understanding what are the parameters that are important to them to operate and control. Then also demonstrate that out to customers when they need to be able to do that.

Is it on? Is it scaling? Is it producing risk for the organization? I think that when you think about this from the question you just asked, I think is workflow first or autonomy first? I would say that in that regard, I would say workflow first should be the enterprise default, but autonomy should expand where the outcome is actually measurable. You want to be able to have that, whatever the units of truth that need to be. For that set of agents to work together is essentially what's being managed, and that blast radius is controlled.

We have created a set of tooling for strategy work, and that strategy work takes outside-in analysis. It has a bunch of work that couldn't actually interact with documents and knowledge stores and so on and so forth. What ends up happening is that we're looking at one of the measures that for that harness is: how long is the runtime to be able to solve for that problem? What is the token spend associated with that problem?

That is less to get to your actual question. It is less about the model that is actually working on and the enterprise context that we deliver over top of it. There is a significant movement to be able to disaggregate your enterprise knowledge and context from the underpinning model, so that model is fungible. As you see advancements in each model that go out there, you're not necessarily like, "Hey, I've completely coupled myself when I don't have the ability to move my context between them."

I think that one of the things we see, and this is where you start to get into things like agentic delivery platforms, is where now you're managing a control plane that is managing things like token spend, token routing, things of that nature to be able to deliver enterprise value. The examples that I've given you now are one very much in a strategy context, what that harness would look like in that regard.

One of those examples was an AIOps. What does it mean to run operations and an SRE model or a mindset with agents as a part of that team? Then the other one I gave was that mainframe modernization harness as well.

Ken: It's funny, there's a movie that came out several years ago, Ford v Ferrari. There's a scene, and I don't know if it's real, but they take the CEO of the Ford Motor Company, sticks him in a race car for the first time, he felt that power, and he was literally crying at the end, having never been in, and then he's like, he had no idea, "I had no idea." Thomas, you're talking about this in an aircraft thing. You have a metaphor there. Is more power, is the biggest, greatest engine, all it's supposed to be? Is that all I need?

Thomas: Great movie, love that scene. It's actually rewatchable on its own. I think that the thing about it is that the engine needs to be purpose-built for the job that it's going to be doing. For example, if you're going to fly a 747, you have different engine requirements than if you're in a Cessna or a small single-person plane. It's the right tool for the job. You don't want to necessarily laden your organization with enough complexity that's not able to actually take advantage of it.

Just like with the DevOps to platform engineering journey that we've seen in the past, very small teams don't benefit from a platform engineering context at the same scale as large engineering teams. What you want to be able to do is have the ability to meet the moment with the scale of the tooling that is going to drive the problem. If you think about this centralization versus federation, if you think about this federation, you want to push that decision about what model and how it's being used and how that harness is created as close to the team as possible, but you have it be able to-- its natural exhaust or natural telemetry and observability-- be able to be understood and managed from an enterprise context. Whether that be a product manager that's making those decisions about what is important, but if there's a guardrail strike, what happens? How do you manage it? How do you present that up to the organization? It's not just an engine.

The mental model that I have around this is that the model is the engine, and the tokens are the fuel. The reason why we have this tokenomics conversation is that, as the model providers move from a subscription-based revenue to a token-based revenue stream, what happened was all of a sudden now we were impacted by our fuel cost in a way that it was material to the enterprise. Our suggestion is that harness engineering and agentic delivery platforms, those in concert, have the ability to manage your fuel cost, the token cost, with a correlation to the unit of value.

Instead of just saying, "Hey, I'm going to cap my token cost," say, "What is the value you're going to realize by spending that fuel in that engine to drive that outcome?" If it's sending people from one side of the country to the other, you have a different set of requirements around what you need to accomplish as possible.

If I'm flying from here to an hour away in a single-person Cessna, I have a completely different set of requirements. However, when you think about what the rules of the road are, and what happens here is that the rules around how you land, how you actually interact with an airport, all those kind of things, that's the governance of the enterprise in this context. I can mix metaphors all day, but I'm going to hand it off to Matt for any thoughts there.

Matt: I was enjoying it. I'm just going to add that I think that became one of the parts that needs to come in now. It's like the engine without the rest of the plane is worthless. You need a whole plane built around that engine to actually be able to either carry passengers or carry yourself from one airport to the other airport. Provided that you're not a private owner of an airplane and you're an airplane company, like if I had met airlines, well, the cost of fuel, if it changes so drastically as it did with tokens, it's definitely going to affect my business. This is what I told you before. Everything is happening at the same time. It's not that it's something that we need to isolate because the only way that we can actually address it.

Perhaps this is the right moment to bring in: when we started talking about this, we already saw that there are four layers of harness that we are actually trying to address. Ken, when you were talking about the LLM, it's not that we're not taking care of it. It's the first layer, the model. It's the substrate. It's important for cost, latencies, selection, but it's downstream of the architecture. It's not really the driver. You need the engine to fly, of course. If you don't have an engine, then you don't fly. As I was saying before, you need to build the whole airplane around it, and you need to actually build a model of business of what you want to do with the airplane.

The first layer it's the natural thing that everyone understands. It's what we've been discussing, and Thomas so greatly just turned into this metaphor of the airplane. If you want to keep it with the airplane, then there comes the second layer, which would be the builder harness. It's the different platforms that we build around that using that model and how we're actually going to build the whole standardized infrastructure: the tool access, memory, orchestration, frameworks. Basically, the developer teams don't reinvent the wheel. That's something that we normally want to happen. That's a harness in itself too.

Then the third layer is the user harness, the practitioner layer. It regulates the day-to-day developer and team interactions using two essential controls: guides, which is feed-forward, like rules, project context, skill files that shape agentic actions before execution, and sensors, which is super important. Thomas was mentioning it before. It's automated tests, linters, security checks that evaluate agent output after execution. Bringing new is this fourth layer, which is the organizational harness. It's the governance layer. It's the critical gap.

It's the missing layer that defines the policy, the ownership, the identity, and then the accountability, which, going back to the whole airplanes thing, it's basically the one thing that acknowledges that, okay, we have an airline. We want to operate in an air control traffic space. We need to know the rules. We need to abide by the rules, and we need to apply those rules to everything that we have built. At the same time, we want to remain profitable. We want to make business out of this. How do we actually make all of this converge? It's the harness engineer for the enterprise is the fourth layer, but as you see, there are other three layers that are easily identifiable by anyone.

Ken: It's important to note for listeners here that unless you're taking notes, and if you're driving down the freeway, please don't be taking notes. Thomas and Matt have written about this. It is on the website, so you get a lot of the detail there as well. Don't feel like you have to get all of the layers correct from here. I know. I just did a query to have the document to bring them back up to, and I only read the document yesterday. We are creating other reference material there, so just as an FYI.

Thomas: What's interesting about that, Ken, is we wrote that document about 45 days ago, and our thinking has evolved since. If you think about what we see is that this notion of context engineering has emerged as what makes the enterprise knowable to agents for their context. We obviously have a point of view around spec engineering that makes intent explicit as we bring, what do you actually want to accomplish?

That spec is supplemented by not only that context but all the documents and things that you could bring through. I'm thinking in a software development context now. Then platform engineering, as we've talked about before, is still relevant. That makes those capabilities usable. It makes those things that you want to see hardened as enterprise capabilities that much more valuable because they're running on their own product lifecycle, if you will.

Then if you think about harness engineering, now we're introducing that nondeterministic that makes autonomy governable. Then the example that I gave around AI and agent ops is that where you now look at, is the system operable? To Matt's point, is it economically accountable? Then my ultimate position on this is that we should think of our use of AI as value-aligned to govern the outcome. This is the reason why we believe Enterprise Harness Engineering is a way forward for organizations to implement these at scale while operating in control.

Ken: We've touched on this several times, and you just did it again. I want to get a little bit more explicit. If we talk about autonomy, and I think there's this concept authority envelope and others. It's like if all these things are to control and make agents safe, how do we know that they still can do good work? How do we give them enough freedom to do what we need them to do while providing this enterprise part of the harness?

Matt: I think that part of that is a real challenge, Ken, is a part of, and I was talking about this with Jeremy a lot, and we actually wrote an article about that too. It has to do with the part of how actually we normally think about the company as all the problems that we have. I have felt that there's little conversation about how does the client or another party that works with us perceives the company. That's why, when the concept with talking to Jeremy came out, of what's the perceived authority that these actual agents will have? This is very much linked to the part of bounded autonomy that we were talking before.

If you deploy an agent and the agent is going to act on behalf of the company, and it has a certain level of autonomy that provided that we have an Enterprise Harness Engineering, we have decided that the agent can do, and not that it happened just because we actually decided it. Sometimes it's complicated to understand the difference between what you, as a company, think that the agent is capable or able to do, and there might be a different interpretation from a client or from a third party of what the agent can actually do.

When this happens, it's a problem because you can have a person that actually has signed a contract with you thinking that the agent that you actually deployed had that level of autonomy and that level of authority, and you might not have foreseen this or have not actually ruled this. The actual part of understanding the level of autonomy that the agents or that the company is going to have while using AI and the different potentiality of how people can perceive what your company is capable of doing with AI might be different. It's a very kind of finite place to walk. You need to define that. You need to be very certain, very clear about this level of autonomy and the level of authority that you're going to give to these kind of agents.

Thomas: I did get from the quality dimension as you need to be able to understand what's happening with it. I think the guardrail and the valuations become that much more part of your quality dimensions as you bring them forward because you want to make sure that, to Matt's point, is the agent doing what you want? Is it operating as expected? In the mainframe example, we have that behavioral backtesting to be able to ensure that it is actually operating exactly as it was, but then in the strategy example, it's much more broad.

The human in the loop in a strategy conversation is that much more important because if you think about the work that we do, we need to be able to synthesize it and represent it ultimately that these tools are bringing this information together in a way that we're going to now use to make decisions. The example that Matt just gave was a legal example where you have agents decomposing contracts to be able to understand where they are, where risk is for the organization, and so on. I think that that's where we have a very human element in this process that hasn't gone away.

We have talked about things like LLM as judge in the past, where you're using two agents adversarially or two models adversarially against each other to be able to drive a consensus, but I think that that is just another tool in your quiver or tool chest as opposed to a pat answer in that regard.

Matt: I would just add that besides the legal part, which is exactly what I was trying to bring up, Thomas is the part of. I can't remember the name of the company, and probably I shouldn't mention it even if I did, but there was an incident a couple of months ago in which a company's agent actually bought a lot of, I don't know why, for an X amount of money to another company, and the company didn't want to buy that. It was just the agent acting on its own basically.

The company that already delivered the goods was saying, "It's okay, but what do we do now?" Whoever bought that from us had the level of autonomy and authority to actually carry the purchase, and the shipment is already done. I'm not going to take an "Oops, we didn't mean to," for an answer. This is an example to illustrate this part of the level of autonomy that you're going to give to your agents is something that needs to be completely stressed, governed, traceable, and you need to have it very clear of what the capability that agent has to act on your behalf, for example.

Thomas: Last December I was at a conference where I learned that insurers will no longer indemnify agentic or AI-driven decision-making if there is not a human in the loop. Think about that when you're saying, "Hey, I'm going to make an agent, and it's going to be doing everything for me." It's your risk exposure. Almost every conversation, Ken, that I have about agents at some point comes back to security risk. I think the reason why we've talked about the Enterprise Harness is the notion of controlling for that risk.

We want to be able to bring a discipline that the low-level technical ways in which you're able to build and govern and deploy agents, is being solved on the technical dimension. I think that what we see is that there's a gap around what it means to be able to operate these in control as team members. As we start to see the pyramids shift into more diamond shape and their team is working with many agents, what does it mean for an enterprise to control the blast radius around those activities?

One thing that happens when you develop software is you have a quality process around it. It's entirely different when you're saying, "Hey, I'm going to allow it to make fraud determinations or credit issuance or things like that." Any of those traditional markets where healthcare, military, public safety, and justice, or finance, the agent did it is not a good answer.

Matt: Exactly. [chuckles]

Ken: Here, we do the old joke about if you're creating cat widgets versus whatever. I have an eight-week-old puppy, and so buying puppy stuff would be-- except for they have my credit card, so I am worried about their compliance. Shifting gears just a tad. One of the things that we do sometimes inside Thoughtworks to learn things and share is something called a "hackathon," which I think most of our listeners are familiar with. Matt is actually running one right now around a bunch of AI experiments.

As I understand it, some 50 or 60 of the entries had something to do with self-healing or software that can either repair itself or address issues or make itself better. I don't want to overload the term, but we'd be self-funding with a really wide thing here. I guess, Matt, what are you learning there? In some of the writing, y'all have talked about the self-healing steering loops and temporal constraints and those types of things. What are we learning? I think you're literally doing it this week in Barcelona that people can apply towards this thing. Is that self-healing real? Is self-awareness real? [laughs]

Matt: I would say that it's a common worry. If you're talking about 66 entries out of the 270 that we got, it's definitely not a small number. It means that there's a lot of people that are actually either thinking about it, trying to solve it, or at least think that it's interesting enough to solve a problem that we already have and that could be solved.

I think that my take on this, Ken, would probably be that what we're learning from AI it's basically that the craving that we have as humans to get a third party, like an AI, to be able to do a lot of the heavy lifting of work that we actually do. It's something that 's at least desirable. Are we actually measuring all the consequences? Are we actually conscious about everything that this means? We're probably not. It's a blast radius in itself, the whole power that AI can actually have.

I remember one of the entries from the hackathon that started their brief summary of, imagine it's 2:00 AM, and you got a notice that your whole system just shut down and you need to pull it back up. Wouldn't it be great if AI could do that for me? You would wake up the next day at eight o'clock in the morning to find a Jira ticket that has already been solved about a problem that occurred at 2:00 AM, and it just gave you the briefing and tells you everything is okay, everything is under control, the system is on call. The term self-healing, I think it's wide. It just covers for a number of different aspects of the SDLC. There's a lot of points and layers in which the self-healing can actually happen.

Actually, out of 66 teams, I haven't gone through all of them, but I have gone through some of them, and they go into different parts of the software development life cycle. Of course, the part of AIOps that I think Thomas knows about and it's already something that's happening, for example, at Thoughtworks we have a number of projects that are already trying to solve this before the hackathon. Actually, now with the hackathon, we're just putting them in contact to see what they can seize at this new proposal that the participants on the hackathon had actually brought.

I definitely think that it's something that, from reading the news, which you know, Ken, it's something that I do regularly as part of my work. It's something that a lot of people are trying to solve. It's something that would actually help software to be more self-dependent and not so much dependent on humans. I don't think it can go to everything, but there are a number of things that can be easily solved with a self-healing system.

Ken: Understanding that you're not done there, is your gut feeling that a good Enterprise Harness-- I don't know what we call it, or do I call it. Is that what it's called, an Enterprise Harness, or is it enterprise harnessing design? Is it your feeling that this topic we're talking about today helps, hurts, or is agnostic in that self-healing loop?

Thomas: I think it helps, but I think that, as I mentioned earlier, you might have different harnesses for different capabilities. In the document that Matt and I wrote, we also had Z from our AI SRE team give us a couple examples of where he's seen it working, and we cited one example where the harness directly influenced the reduction of latency in the system. It was essentially a key aspect of that. It actually had a material effect on ticket resolution, so on and so forth.

Now, I think it's on the journey to self-healing. We're not there entirely today. The latency reduction came directly from the harness, not from selecting a different model. That was essentially a capability that now I think that it's definitely not one harness to rule them all. That's definitely not the largest adjustment.

Matt: It definitely could involve the part of self-healing on the different layers that we already talked about. As Thomas was saying, on the different harnesses that the company, or the product, or the project decide to apply. I think that what we're trying to propose here goes a lot more into actually having the framework and how do you actually build what pieces that you need to bear in mind to build this than actually trying to find a harness to rule them all, like Tomas says. That's probably impossible.

Ken: Like a lot of things in AI, this sounds great in theory. It looks great in a blog. What proof points do we have that this is the right path to go down? Have we done this on clients? Have we done this internally? I know we have some platforms that we've built internally.

Thomas: Yes, without a doubt, Ken. We cited examples that our customers have authorized us to talk about at Parloa, at Morgan Stanley. We actually cite those examples, and we are seeing that proof point on the projects that we're on the ground on. We're in about 850 active projects every day across Thoughtworks, and all of that information is coming up. Those that are willing to allow us to put it in press releases and cite it as examples, those are the ones that we're talking about in the documents that we're writing on the site. Those are two examples that we cited in the article as well.

Matt: Yes. As Tomas was saying, we're hoping to gather a lot more of this. The article is the front page of what we're trying to build as a white paper, and we're trying to get more people involved. Of course, if someone in the audience is actually willing to share their experience or feels related to the topic, we would be welcoming them to join their experience and, of course, expand this view. We believe it's a view that needs to actually be settled as a framework, basically, of what's the way to do it.

Ken: I normally end these with a call to action where I ask the guests, what would you do Monday morning? I'm going to interject my own and allow you to disagree if you'd like. I think the best thing our listeners can do is, with understanding this stuff changes so fast, as Tomas just said, take a look at their article on thoughtworks.com that talks about this. Also, take a look at martinFowler.com, where Birgitta Bockler and others have written, mainly Birgitta, about the engineering concept, harness engineering, and really trying to take a look at where you think this might help you in your enterprise.

Like anything, I don't think it's all or nothing. I don't think you can go in Monday morning and build a harness. I think you have to understand where you're going. I think, unlike most of our episodes, this edition's call to action isn't go write this code. It's go learn more. Do you all agree with that? If so, what other resources should our listeners be looking at?

Thomas: Obviously, Birgitta's articles on martinFowler.com, a lot of the work that we're doing across the articles being written at thoughtworks.com. I think that there's a groundswell of activity around this that demonstrates that this is not settled science in my view. I think that there's going to be different approaches and techniques to be able to solve for this. Anthropic's got a point of view. OpenAI's got a point of view. Microsoft's got a point of view. AWS has a point of view.

I think that if I was going to distill it down to one thing, I think about Enterprise Harness Engineering as just the next progression from platform engineering. The things that we've evangelized around as being brilliant at the basics, this is the next stage up as we introduce AI as a key part of our enterprise foundation. Agentic as an operating pattern is just a way it's being realized today. I think that our mental models need to think differently for how we manage enterprise risk as well.

Matt: Yes. If I had to bring one more thing in, I would just bring in the Agile Manifesto. Just embrace change. This is going to change. Technology has always gone super fast. It's light speed now, right? I think that the part of the harness that we're trying to talk about mainly is the part that will remain probably for the longest time, which is not bound to just the model or just the platform or just the use that you're using of LLMs.

It actually calls for the part of what's your company? What are you doing? What are you expecting? How do you want to survive through this incredible change because we're definitely living through the next industrial revolution, and things are going to be reshaped. I think that the part where we can actually surf that great wave is to actually bear in mind, "Okay, who are we? What do we want to accomplish? How do we actually maintain that through this storm?" That's why I quote the Agile Manifesto. I think it was the second one that says something like that, just embrace change. We embrace change. You cannot fight this. You need to be resilient. That's the word.

Ken: Great. Again, thank you, Thomas. Thank you, Matt. I really appreciate your time as always. For the listeners, we'll be talking more about this, so watch this space.

Matt: Thank you, Ken. Thank you, Thomas.

Thomas: Thank you.