# Enterprise Harness Engineering for AI Agents

**Podcast:** Thoughtworks Technology Podcast
**Published:** 2026-08-06

## Transcript

Hello, everybody.
Welcome to another edition of the ThoughtWorks Technology Podcast.
My name is Ken McGrange.
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.
So, Thomas, we'll start with you.
Thank you, Ken.
Thomas Swayo, Chief Technology Officer and Head of Advisory for the Americas.
Matt?
I'm Matt Camelman, 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.
Great.
So thank you both for joining.
So 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.
You know, we talk about creating AI, there's spec to code 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.
It was everybody wanted to talk about it.
And it was very much an engineering first, which as an engineer I appreciate, but it didn't address some of the enterprise things and so forth.
So what we want to talk about today is what our guests are calling enterprise harness engineering.
And so regular listeners who may have heard my soapbox speech before, where I think it's important that we define terms.
So 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 engine, you know what we're talking about.
And 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.
So, Thomas, I'm going to put you on the spot here.
What's your definition of harness engineering?
I'll go right into it.
So 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.
I think about, you know, you made a comment about the definitions.
I think that we hear about harness engineering.
We've also heard about loop engineering.
You know, 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 does an agent operate?
What are the tools, the tests, its evaluations and the feedback loops necessary for it to be able to to function and deliver business value?
So in short, like 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.
So one of the things that we typically see when we 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.
You know, I love metaphors.
So I would encourage people to think about it like, for example, like a wild animal.
So the harness.
on a powerful animal it's basically constraining the capability that the animal has the the animal's capability is real and it's valuable but without the harness you can't direct it safely or reliably so that's basically what we're trying to to build right with a harness the harness and codes and organizations constraints which by the way was was the term back in February, right?
Constrained 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 defines boundaries from the business.
And 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 our work alone.
talk about.
I appreciate that because we hear it all about making it faster and token economics and tokenomics and all that.
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?
If you think about the agent is going to interact with a prompt, so it's not uncommon for when you put an agent into motion or there's a handoff, the prompt is kind of the key input for it.
So if you think about this from our view, when we start talking about the enterprise context, it's not just the, 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.
So if you think about this, not only are you dealing with you know, what is the low level prompt doing?
But I think that more importantly, we're thinking about this as who is who in the enterprise is understanding and managing risk associated with these things.
So if you think about this, you know, Matt uses a term that I agree with.
It's called bounded autonomy.
What is the what is the degree if that prompt has a set of, you know, kind of parameters?
What is the span of control or span of?
of decision-making authority that that agent has and that's what we're suggesting and controlling in the uh enter the uh the enterprise uh harness so matt let's take it from the prompt right can you say you were comparing it with the prompt the prompt basically involves that you think a lot before you actually build it, right?
That's prompt engineering into what you exactly want the agent to do, right?
When we take it to the part of the enterprise and 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, right?
I mean, 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 uh invoices an agent that is going to handle clients orders and stuff like that in that moment you have to have it very very clear for your company what little of authority that agent can do to act on behalf of the company and that's something that we have seen in the news in the last six months or so that has been neglected in a number of times and the span of the problem can become super heavy.
So basically what I'm trying to say is like, I think that everything is happening at the same time.
You were saying everything is happening so fast and 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?
And 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 and the part of how that we actually build all of this.
And it's not just bounded 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 it translates into the whole company's knowledge base too, right?
So I think it's another layer.
So 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, time out.
You're putting our logo on stuff that hasn't gone through compliance checks.
And so we're going to have a platform team.
Is this a different kind of platform?
Yes, yes, 100%.
So if you think about platform engineering is that ultimately that goal was repeatability.
Now this is now offering controllability.
So if you think about, you know, where we used to do things like paved roads, you used to have kind of, not only would you have your ALM context and your internal development platform, you would have the ability to have your CICD and your common golden paths and so on.
And 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 a very clear, like, let's take this out of the abstract of like, you know, 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 Imogen 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 that understanding of the the code and the.
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.
And that autonomy to be able to ensure that what is happening is happening in a way that is human consumable from a socio-technical standpoint?
Did it technically survive or deliver what was?
And then how do you actually promote that with the confidence of knowing that what was built is actually being engineered, 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.
And 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.
But what's happening is that you have now, hey, my goal is modernization of this origin system.
The harness allows engineers, thought workers to be able to build in that environment and do that modernization to be able to deliver that value.
And 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...
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 kind of environments and so on and so forth.
But whereas the traditional notion of platform engineering is repeatability and operating and control, this is now controllability and operating and control.
So you've now overlaid now a way of managing.
non-deterministic systems at scale in this regard.
The reason why I kind of 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 tooling that we have built inside our own organization that allows us to be able to manage agents at scale.
And some of it is kind of basic telemetry, things that are not Let's just say they are deterministic SLAs, configurations, things that you want to be able to set.
What is 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.
So Matt, thoughts?
I think that's always super, super accurate.
I would just add that I'm always thinking of 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, right?
And I know this, 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, right?
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, right?
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, right?
If it escalated to something legal.
An agent, you cannot do anything against an agent, right?
You need to define how this is going to work.
for the whole enterprise and it's something that most of the times it's just being done reactively instead of proactively and we believe with thomas that 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 that the company is going to perform right one of the pushbacks that we often get whenever we talk about standardization whether we want to call it harness or a platform or anything else is like team autonomy and taking advantage of the latest thing and so forth.
And speaking of the latest thing, it seems like every week there's a new model from somebody.
And this one's 5% better than that one.
And this one's better at coding.
And that one's better at reasoning.
Although none of them are actually reasoned, but that's a different rat hole.
So, I mean.
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 five.
And the teams are like, no, I need that 4% improvement.
How do we balance that on the enterprise?
So this is a great question.
And 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.
So, for example, we have an AIOps or an AISRE team that has built a set of harnesses that are purpose built for the thing that they're they're willing to deliver.
Stability, scalability, security, understanding kind of what is the.
What are the perimeters that are important to them to operate and control?
And then also demonstrate that out to customers when they need to be able to do that.
So, you know, is it on?
Is it scaling?
Is it producing risk for the organization?
I think that when you think about kind of this from the question you just asked, I think, is it workflow first or autonomy first?
I would say that if in that regard, you know, 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.
So for that set of agents to work together is essentially what's being managed.
And that blast radius is control.
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 can actually interact with documents and knowledge stores and so on and so forth.
And what ends up happening is that we're looking at like 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 context, the enterprise context that we deliver over top of it.
There is a significant movement to be able to disaggregate your knowledge, your enterprise knowledge and context from the underpinning model so that model is fungible.
So as you see, you know, kind of 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.
So 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.
So 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 AI ops, like what does it mean to run?
operations and an SRE model or mindset with agents as a part of that team.
And then the other one I gave was that mainframe modernization harness as well.
You know, it's funny, there's a movie came out several years ago, Ford versus Ferrari, and 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.
And he felt that power and he was literally crying at the end, having never been in.
And he's like, he had no idea.
I had no idea.
You know, and Thomas, you talk about this in an aircraft thing.
You know, a metaphor there.
Is more power, is the biggest, greatest engine all it's supposed to be?
Is that all I need?
Great movie.
Love that scene.
It's actually rewatchable on its own.
I think that the thing about it is this, is that the engine needs to be purpose built for the job that it's going to be doing.
So 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.
So it's kind of like 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.
So just like with...
kind of 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.
And 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.
So, you know, if you think about kind of 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 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?
But it's not just an engine.
So I think about this as if I think about the mental model that I have around this is that the model is the engine and the tokens are the fuel.
And 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 costs in a way that it was material to the enterprise.
And what our suggestion is that harness engineering and agentic delivery platforms, those in concert, have the ability to manage your fuel costs, the token costs, with a correlation to the unit of value.
Does it, you know, instead of just saying, hey, I'm going to cap my token costs, say.
What is the value you're going to realize by spending that fuel in that engine to drive that outcome?
If it's, you know, you know, sending people from one side of the country to the other, you have a different set of requirements around what you what you need to accomplish than as possible.
So so if you think about, you know, if I'm flying from here to, you know, you know, 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, you know, 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.
So I can mix metaphors all day, but I'm going to hand it off to Matt for any kind of thoughts there.
I was enjoying it.
I'm just going to add that I think that again, one of the parts that needs to come in now is like.
Well, the engine without the rest of the plane, it's worthless.
You need a whole plane built around that engine to actually be able to either carry passengers or carry yourself from an airport to the other airport.
And provided that you're not a private owner of an airplane and you're an airplane company, like if I had airlines, well, the cost of fuel, if it changes so drastically as it did with tokens, it's definitely going to affect my business, right?
So 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 it because there's the only way that we can actually address it.
But, and perhaps Thomas, this is like the right moment to bring in, like when we started talking about this, we already saw that there are four layers of harness that we are actually trying to address.
And Ken, when you're talking about the LLM, it's not that we're not taking care of it.
It's the first layer, right?
The model, it's the substrate.
It's important for cost, latency, selection, but it's downstream of the architecture.
It's not really the driver, right?
I mean, you need the engine to fly, of course.
If you don't have an engine, then you don't fly.
But 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, right?
The first layer, it's a natural thing that everyone understands.
It's what we've been discussing and Thomas so greatly just...
turn into this metaphor of the airplane right but just if you want to keep it with the airplane then there comes the second layer which would be the builder harness right it's it's the different platforms that we build around that using that model and how we're actually going to build the whole uh standardized infrastructure the tool access memory orchestration frameworks so basically the developer teams don't reinvent the wheel right that's 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 feedforward, like rules, project, context, skill files that shape agentic actions before execution, and sensors, which is super important.
Thomas was mentioning it before, right?
It's automated tests, linter security checks that evaluate agent output after execution.
What we're bringing new is this.
fourth layer, which is the organizational harness.
It's the governance layer.
It's a critical gap.
It's the missing layer that defines the policy, the ownership, the identity, and the accountability, which going back to the whole airplanes thing, it's like 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.
And at the same time, we want to remain profitable.
We want to make business out of this.
So how do we actually make all of this converge, right?
So it's the harness engineer for the enterprise is the fourth layer.
But as you see, there are other three layers that are easily identified by anyone.
Yeah, and I think it's important to note for the 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'll get a lot of the detail there as well.
So don't feel like you have to get all the layers correct from here.
I know I just did a query to the document to bring them back up, and I only read the document yesterday.
And so we are creating other reference material there, so just as an FYI.
Well, what's interesting about that, Ken, is we wrote that document about 45 days ago, and our thinking has evolved since.
I mean, 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.
you know, as we kind of bring like, what do you actually want to accomplish?
And that spec is, is, is supplemented by not only that context, but all the documents and things that you could bring through.
I'm thinking in a, in a, in a software development context now.
And then, you know, platform engineering, as, as we've talked about before is still relevant.
It's a, 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, they're running on their own kind of product life cycle, if you will.
And then if you think about harness engineering, now we're introducing that non-deterministic that makes autonomy governable.
And then, you know, the example that I gave around AI and Asian ops is that where you now look at what is, is the system operable to Matt's point?
Is it economically accountable?
And then my ultimate position on this is that we think we should think of our use of AI is value.
aligned to govern outcome.
And 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.
So we've touched on this several times and you just did it again, but 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, you know, 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, right?
I mean, how do we give them enough freedom to do what we need them to do while providing this enterprise part of the harness?
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, and it has to do with the part of how actually, We normally think about the company as all of the problems that we have.
And I have felt that there's little conversation about how does a client or another party that works with us perceive the company, right?
And that's when the concept with talking to Jeremy came up of what's the perceived authority that this actual agents will have, right?
And 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, right?
And not that it happened just because we actually incited 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.
And 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.
So 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.
And it's a very kind of thin-ass 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 this kind of agents.
I think from the quality dimension is you need to be able to...
understand like what's happening with it.
I think the guardrail and the valuations come that much more, become that much more part of your quality dimensions as you kind of bring them forward, because you want to make sure that is to Matt's point, is the agent doing what you want?
Is it operating as expected?
You know, in the, in the mainframe example, we have that, that, you know, behavioral back testing to be able to ensure that, you know, it is actually operating exactly as it was.
But then in the strategy example, It's much more broad.
And I think that there's now the, you know, the human in the loop in a strategy conversation is that much more important because, you know, if you think about, you know, the work that we do, we need to be able to, you know, synthesize it and represent it.
You know, ultimately that these tools are bringing this, you know, information together in a way that we're going to now use to make decisions.
You know, the example that Matt just gave was a legal example where you have, you know, agents decomposing contracts to be able to understand where.
They are where risk is for the organization and so on.
So 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 kind of a pat answer.
in that regard.
Yeah.
I would just add that besides the part of the legal part, which is exactly what I was trying to bring up, Thomas, it's a part of, I remember, 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, right?
But the company that already delivered the goods was saying, okay, but what do we do now?
Whoever bought that from us had the level of autonomy and authority to actually carry the purchase, right?
And the shipment is already done.
And I'm not going to take on an oops, we didn't mean to for an answer.
So this is, for example, an example to illustrate this part of the level of autonomy.
that you're going to give to your agents.
It's 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.
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.
So 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.
you know, your risk exposure.
Almost every conversation, Ken, that I have about agents at some point comes back to security.
And I think the reason why we 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, you know, 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 does it mean to be able to operate these in control as team members, as we start to see like, you know, the pyramids shift into more diamond shape and their team is working with many agents.
What does it mean for an enterprise from controlling the blast radius around those activities?
And, you know, 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.
So any of those traditional markets where healthcare, military, public safety, injustice, or finance, the agent did it is not a good answer.
Exactly.
Yeah, we do the old joke about if you're creating cat widgets versus whatever.
You know, 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.
And Matt's actually running one right now around a bunch of AI experiments.
And 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 mean, I don't want to overload the term, but it's just we'd be self-hunting with a really wide thing here.
So, I mean, 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?
Like, I think you're literally doing it this week in Barcelona that people can apply towards this thing.
I mean, is self-healing real?
Is self-awareness real?
Well, I would say that it's...
It's a common worry.
I mean, if you're talking about 66 entries out of the 270 that we got, it's definitely not a small amount.
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 would be probably 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 headlifting of work that we actually do, it's something that it's at least desirable.
Are we actually measuring all the consequences?
Are we actually conscious about everything that this means?
We're probably not.
I mean, it's a blast radius in itself, the whole power that AI can actually have.
But I remember one of the entries from the hackathon that started their...
Brief summary of, imagine it's 2 a.m.
and you got a notice that your whole system just shut down and you need to pull it back up, right?
Wouldn't it be great if AI could do that for me, right?
You would wake up the next day at 8 o'clock in the morning to find a Jira ticket that has already been solved about a problem that occurred at 2 a.m.
and it just gave you the briefing and tells you everything is okay, everything is under control, the system is on go.
right so the term self-healing i think it's it's wide it just covers for a number of different aspects of the sdlc so there's there's a lot of of points and layers in which the self-healing can actually happen actually out of the 66 teams i haven't gone through all of them but I have gone through some of them and they go into different actually parts of the software development lifecycle, right?
And of course, the part of AIOps that I think Thomas knows about that and it's already something that's happening, for example, ThoughtWorks.
We have a number of projects that are already trying to solve this before the hackathon.
And actually now with the hackathon, we're just putting them in contact to see what can they seize at this new proposal that the participants of the hackathon had actually.
But I definitely think that it's something that, and from reading the news, which you know, it's something that I do regularly on 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.
And 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.
So understanding that you're not done there, is your gut feeling that a good enterprise harness, I don't know what we call it.
Do we call it, is that what it's called, an enterprise harness?
Or is it enterprise harnessing design?
But is it your feeling that this topic we're talking about today helps, hurts, or is it agnostic in that self-healing loop?
I think it helps.
But I think that, as I mentioned earlier, you might have different harnesses for different things.
you know, kind of capabilities.
In the document that Matt and I wrote, we also had Z from our AISRE team give us a couple of examples of where he's seen it working.
And we cited one example where the harness was directly influenced the reduction of latency in the system.
It was essentially a key aspect of that.
It was 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.
But the latency reduction came directly from the harness, not from selecting a different wall.
So 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 rules to justice.
But it definitely could involve the part of self-healing on the different layers that we already we already talked about, right?
And 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, it goes a lot more into actually having the framework and how do you actually build, what are the pieces that you need to bear in mind to build this than actually trying to find a harness to rule them all, like Thomas says, right?
I mean, that's probably impossible.
You know, like a lot of things in AI, this sounds great in theory, it looks great in a blog.
You know, what proof points do we have that this is the right path to go down?
I mean, have we done this on clients?
Have we done this internally?
I know we have some platforms that we've built internally.
Yeah, without a doubt, Ken.
I mean, we cited examples that our customers have authorized us to talk about at Parloa, at Morgan Stanley.
So we actually cite those examples and we are seeing that kind of...
that proof point on the projects that we're on the ground on.
I mean, 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, you know, in, you know, press releases and, and cited as examples.
Those are the ones that we're talking about in the documents that we're writing on the, on the, on the site.
So, but those are two examples that we cited in the article as well.
Yeah.
And, and, and as Thomas was saying, we're, we're.
hoping to gather a lot more of this.
The article, it's just the front page of what we're trying to build as a white paper and we're trying to get more people involved.
And of course, if someone in the audience is actually willing to share their experience or feels related to the topic, we'll 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, right?
Of what's the way to do it.
So I normally end these with a call to action where I ask the guests, you know, what would you do Monday morning?
I'm going to interject my own and allow you to disagree if you'd like.
But I think the best thing our listeners can do is with understanding this stuff changes so fast, as Thomas just said, take a look at their article on ThoughtWorks.com that talks about this.
Also, take a look at MartinFowler.com.
where Brigitte Buckler and others have written, mainly Brigitte, 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.
So I think, unlike most of our episodes, this edition's...
call to action isn't go write this code.
It's go learn more.
So do y'all agree with that?
And if so, what other resources should our listeners be looking at?
Well, obviously, Brigitte's articles on martinfoller.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.
So I think that there's going to be different approaches and techniques to be able to solve for this.
Anthropics got a point of view.
OpenAI's got a point of view.
Microsoft's got a point of view.
AWS is a point of view.
But I think that if I was going to distill it down to one thing, I think about enterprise harness engineering is just the next progression from platform engineering.
So, you know, 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.
And agentic as an operating pattern is just a way it's being realized today.
And I think that our mental models need to think differently for how we manage enterprise risk as well.
Yeah.
And if I had to bring one more thing in, I would just bring in the Agile Manifesto.
Just embrace change.
I mean, this is going to change.
technology has always gone super fast.
It's a light speed now, right?
I mean, Alderaan is the next stop probably, so we should be prepared for that.
And 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, right?
Which is not bounded to just a model or just a platform or just the use that you're using.
But 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, right?
Because we're definitely living to the next industrial revolution and things are going to be reshaped.
And I think that the part where we can actually serve the great wave is to actually bear in mind, okay, who are we?
What do we want to accomplish?
And how do we actually maintain that through this?
through the storm.
Right.
And yeah, that that's why I called 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.
Great.
So again, thank you, Thomas.
Thank you, Matt.
Really appreciate your time as always.
And for the listeners, we'll be talking more about this.
So watch this space.
Thank you, Ken.
Thank you, Thomas.
Thank you.