Presentation: Beyond the Harness: Canvas for AI Agents

InfoQ Homepage Presentations Beyond the Harness: Canvas for AI Agents

Nimisha Asthagiri shares how applying proven product engineering and architecture principles creates a bounded canvas for AI agents. She explains how this model provides agents with bounded autonomy, continuous drift detection, and decision records to scale software development resiliently.

Nimisha Asthagiri is a Technical Advisor at Thoughtworks where she leads client digital transformations using design thinking, change management, and platform architecture. Her current focus is architecting agentic enterprises with systems thinking for responsible AI.

QCon AI is a practitioner-led event focused entirely on the engineering discipline required to scale these workloads safely. It provides direct access to the architectural playbooks and failure metrics that peer organizations use in production.

Presented by: David Iparraguirre - Senior Product Marketing Manager at Datadog, and Jessica Yang - Product Manager at Datadog

Nimisha Asthagiri: Today, I'm going to talk about, "Beyond the Harness: Canvas for AI Agents." I want to start with a story. I don't know about you, but for me, it feels like deja vu. Why it is, is because many moons ago, I used to be heading up architecture for an open-source community.

In that community, we had a codebase that had grown organically. We had to worry about decay of the codebase. There were feature toggles that were not being garbage collected.

There was code that people didn't know whether or not who owns it, what is the purpose of it, things like that. There was also drift. We had a modular monolith that we were going towards, but it was becoming a big ball of mud.

Actually, it was, and we're trying to disentangle it. There was architecture drift that we were facing against. Then all of these things, we needed to have, therefore, a way to support the growth of that codebase and our community.

In order to do that, we needed guardrails. We needed context to everybody. We needed to be able to provide guidance and a digital strategy that everyone was rowing towards.

For me, this feels like deja vu. We were also talking about, at that time, it was leading humans. It's open-source community, so there was teams across the world distributed, not necessarily, some in Australia, some in Boston.

We didn't talk to each other synchronously. We needed ways to be able to communicate asynchronously, leave traces around, leave decision records around. While this concept of cognitive debt is at the rise right now with AI agents and work concerns, in 2021 and so forth, these were things that I needed to deal with even earlier.

Why that is, is because we had humans that couldn't connect with each other. We had people who would leave the open-source community or leave the organization maintaining it. These were things that we had to deal with.

We had humans who wanted the autonomy to innovate. I'm going to talk about that today, and how that might actually apply some of these architectural thinkings and principles to then us providing a bounded autonomy for AI agents.

I'm Nimisha Asthagiri. I work at Thoughtworks. I'm currently a technical advisor. I had my upbringings in software engineering and algorithmic work and so forth. Eventually leading to being chief architect at edX, which was a startup based in the Boston area before I joined Thoughtworks. I do want to caveat with saying we're all learning. The industry is changing rapidly. Some of the things that I'll talk about today please take that with a grain of salt because now applying it to a new paradigm shift that we're all going towards is something that we're all experiencing. However, some best practices, and this is why it feels deja vu, might be applicable here. That's why I want to share with you today.

Here are some main takeaways. Hopefully this resonates with you as a conversation to have together right now, so really some of the mental model shifts. What I'm going to do is I'm going to talk through some of this paradigm we're talking about, which is harness engineering.

I do want to also put forth a proposal of maybe shifting our mental model from not just a controlled harness and what that might lead us to when we're talking about managing agentic topologies, but to thinking about a bounded canvas. We'll talk more about that. In addition to that, I mentioned about cognitive debt, and that is a huge concern.

What might be our mental model if we don't necessarily question it but more so accept it and think about what are those traces, what are those decision records, not just architecture decision records, organization decision records, product decision records that are needed to leave as stigmergy or traces or pheromones essentially for whoever inherits the codebase and works on it.

We'll talk about some of these mental model shifts. I also want to be able to propose thinking a little bit more holistically, not just a particular coding task at hand, but let's leverage some of the things that we've been doing with operating models for product engineering overall and see how that could be applicable here, and think about this as a much more longer life cycle. Designing for change.

We're talking about evolutionary architecture, but what might be some specific ideas and main takeaways I want to be able to share with you today as well as how might we be deliberate about actually deliberately disturbing our codebases and our products. We've talked about chaos engineering over the years, but I think it's so applicable right now, especially if we're not the ones actually writing the code directly. That's the takeaways.

How might we do this? Let's go through these three acts together. We'll start with the what, the why, and then the how as we talk through this.

Let's start with the what. I'm talking about this as a semantic diffusion because, as you know, there's concepts that are coming forth so quickly, like prompt engineering was 2023, 2024. 2025 we have context engineering, and now in 2026 we're hearing about harness engineering.

Really when prompt engineering, the need of the day at that time was to just be able to optimize that instruction, optimize that one communication that you're having with the agent. That's what we were talking about and how do we be more efficient with our tokens and so forth. Then context engineering, now you're talking about across interactions, and now a context where you're able to provide to these agents.

What are they able to see?

Once again, token optimization for one thing, but also the quality of the output, those types of things come into play. There you're then managing the information exchange between yourself and the agents. Then finally you have harness engineering and this has been a big buzz starting February and so forth, and we'll talk through that. Now we're talking about no longer one task across sessions. We're talking about actually for an entire lifetime. Not just one interaction, but across a lifetime of what you might be developing as a product and so forth. In order to do that, you want to build a world. You want to build a system. Now systems engineering and those perspectives come into play.

Let's start with February 5th, earlier this year. We had Mitchell Hashimoto from HashiCorp who had published this in one of his blogs. I don't know if there's a broad industry term.

Remember we're all making up terms as we're trying to figure some of these things out. For him he was like, this feels like harness engineering. What is he talking about?

He's talking about whenever I find a mistake and I need to then solution for that mistake, then I'm going to update the harness so that that never happens again. This harness methodology, we were talking about harnesses, so like Cursor, for instance, as a technology which a human through the harness communicates to the coding agent. There's a lot of capabilities that are forming there.

This harness engineering is now as a user you're updating that harness. That's what Mitchell is talking about here. You'll see that this is something that we're talking about now having a user updating of that harness as we're going forth.

We took that, and from that OpenAI started doing additional experimentation. Within five months they had a team at OpenAI build a million lines of code, and they were experimenting with this. The way that Ryan coined this was, humans steer and agents execute. Once again, this concept of harness. When Mitchell mentioned it a week before, he, I think, may have also been thinking about test harnesses. Our best practices are like, when something breaks, make sure that there's a regression test to make sure it doesn't happen again, hence his statement. Now we're starting to shift towards, there are these humans in control and humans steering so that agents can execute. This is interesting, but definitely a lot of learnings from OpenAI has worked with this, and we'll go through them in a bit.

Then now you have Kyle from HumanLayer, and he's also trying to make sense of this new terminology coming forth, harness engineering. He's thinking, how does that apply to context engineering? This was his mental model in March.

He's thinking, maybe harness engineering is a subset of context engineering because context engineering is what you feed to the agents, and now with harnesses you're also establishing hooks and sub-agents and commands. He was thinking from a Venn diagram, is this how one might think about it? You can see how our mental model is evolving, February, March.

Then another one with Vivek. Vivek from LangChain, he made it very simple. This has been quoted a lot now.

He's like, really an agent is just essentially a model plus the harness. Anything that is not the model is the harness. When you think about a coding agent, you think about this very simple formula, and this is one way to think about this.

This now has been quoted, like I said, and cited in many different ways, and this is starting to then think about, ok, this is how we might think about it. It's essentially the white space that had been there. When we were having all these issues with unreliability with coding agents and the coding models, rather than waiting for the model developers to update their models, how might we as a consumer and a developer update the harness around it so that becomes more reliable?

That's what this was talking about. You can see in Vivek's blog post, this is how he thinks about this. Overall, the entire thing is a coding agent and the harness, you have the model, but then you have things like the observability that we put, any persistence, across sessions, any controls, things like that.

Those would all become part of the entire agent.

Everything in the white space in between, the agent and the model is a harness. That's Vivek's mental model in March. In that, he's also yes-ending, essentially, Hashimoto's statement earlier about this continuous upgrade, and whenever you discover something, whenever there's an improvement that's needed, there's this, therefore, a loop to continue to improve the models and continue to update the harness.

This becomes now a training loop between model and harness and you as the developer, as a consumer of this. You can see this evolving. Then there was a publication.

This is coming from a team in China, and they're starting to think also about, what is the overall system here? You have the model, yes, and then, ok, fine, the white space of the harness, which is then interacting with the environment over a period of time. Let's step back here and think of this now as an overall system.

Then now, if you think about this as an overall system, you're starting to now think about the behavior of the system and anything that now, as a software engineer, you want things to be auditable. You now want things to be able to be manageable and observable in that way. This was also a very interesting paper, I think, recommended. It's a good read. It has other concepts in there as well, and we'll come back to it in a bit.

Then Birgitta, who is a colleague of mine at Thoughtworks, she had a blog post in April on the Martin Fowler site, and her mental model, actually after some discussion amongst a few of us, she had published this and she was bringing forth this idea from cybernetics. We've been talking about feedback loops all the time, but there's feedforward and feedback. These are concepts from cybernetics, nothing new, but now applying it and putting a mental model for us.

Maybe that's one way of thinking about it. Then the harness, therefore, encompasses all the guides and things that we might provide, the context, the best practices, decision records, whatever, as feedforward to the agent. Then feedback would be sensors, things that we might put in our CI pipelines or linting, and things like that.

You can see that also being there. One thing that I found was there was something, going back to my architect days, I'm like, this sounds a lot like we're trying to control, and there's some maybe fear.

Of course, there is fear. We have to acknowledge it. Harness engineering definitely made sense even thinking about it as a right step in the evolution from prompt to context to harness.

Actually, a colleague of ours, Mark, from Boston, he had this thing that he had put on LinkedIn, and I was like, yes, this actually resonates with me as well. He's saying, harness, guard rails, sandboxes, these are all when we're thinking about constraints from the outside, and externally we need to constrain these agents. He's like, the whole power of agents, the whole autonomy and self-learning, we want them to be able to self-learn, so there must be some things from within the system that also needs to be applied, not just externally.

He was saying even our mental model, so I completely agreed with him, this mental model and mindset of harness is that limiting on how we might approach and look at this. He's also advocating for new metaphorical vocabulary.

Hence, I'm here with you today, and I'm proposing us thinking about it maybe as a canvas and not as a harness. I want to explain why. I found this poem, The Unfinished Canvas, by Mira Midha, and I found this to be actually very applicable here.

The Unfinished Canvas, beautiful poem, and it talks about the artist's experience with painting and doing this on a canvas. It's a canvas that is only half filled, the other remains empty, and on one half of a canvas, but the other one has invisible words. This very much, I feel like as developers and whatnot, we have this creativity, and even when we're using and leveraging machine agents, there is this creativity where we're thinking about it's never done, but also there's incomplete, there's a backlog of items.

There's a vision of where this product's going to go. It always might feel unfinished, and that's what we tell ourselves as well when we're developing products.

I think that is very applicable. Then the other one is, the mind did not play, the tune his hands wanted to. This is us, of course.

We have these intentions. We want to have the intentional architecture, but then it's emergent design. We want to have these intentions on satisfying user requirements or improving our usability or whatnot, but users actually didn't use it in the way that we expected.

There's a lot of that uncertainty, even in an artistic canvas as well as in our own work. Then brushes, clumsy, the bristles stiff as rigor mortis had set in. This is also the painter's experience where over time you keep using that paintbrush, and then there's some legacy there, and then there's a brittleness from the dried paint.

This is our experience as well, where we see maybe some things that became overly constrained or overly defined over time, we kept adding to it, now became brittle, so our code becomes brittle, or we have the legacy, we have things like that that are lying around that we're unaware of, or really need to be able to address and detect that arises.

Then tin cans flung in disarray, anarchy from side to side. This is part of it, this is part of creation, is the messiness. In this poem, Mira's embracing it.

I think we when we're developing and working with our teams, there is that messiness, and there is failures that come along to our successes. I think similarly, why cheat ourselves just because we're having machine agents part of our team now. Then, finally, view this mental storm from the out, to see not the unfinished canvas, not an end or a start, but a beautiful masterpiece that has become your art. Essentially, what this is saying is, step back, look at what you've created, and yes, it is unfinished, just like our products are unfinished, and over time, we collectively work on it, it becomes a piece of art. We've experienced this over the years, especially when we're working with our development teams, and not always, I know we have moments where we're so frustrated, it doesn't feel delightful, and our experiences aren't as delightful, but the potential of it being delightful is there.

Let's not cheat ourselves away from that, nor the machine agents who are helping us through this. That's the mental model I'm proposing with this canvas model. If we want to call it canvas engineering, I'm not here to actually coin the word as much as I am about guessing, being skeptical about the harness engineering term and its effect on what we might be, how we might approach it.

How might we then apply this? I don't want to overkill the metaphor here, but let's just go with it just a little bit more. Feedforward with this canvas way of thinking.

You have a canvas. You have boundaries on the canvas. Artists, they might put tape around it to make sure you don't go beyond those boundaries, just like we might do that for our agents.

You might scaffold it. Artists, before they actually start drawing and painting, they might sketch it to say, this is the architectural structure and modularity and things and subdomains and whatnot that we may want to have before we might jump in. Not always.

Depends on the size of the project, of course. Many at times, if it's something that you've already prototyped and you know where you're going to go, that might be useful. They prep the environment.

They put primers on the canvas.

For us anything that we may need to do to be able to establish any sort of scaffolding, or starter kits, or whatnot to help prime the environment, we would do that as well, even with machine agents. Then, any constraints. There's a palette of paint, colors that are already chosen beyond which you would not want to go to other color schemes.

These are types of constraints that we may also have for when we're establishing any structural type of constraints for our agents as well. Then, finally, validations. What might be some things that we've already learned along the way, any prototyping and small experimental forms and things like that that then lead and become context to the paint and the canvas that we're about to put together.

Then we have feedforward and feedback, a simple way of thinking about the system from a cybernetic standpoint. You have the structures.

Structurally there might be our type systems. We might have sandboxes for our agents, things like that. That still allowed bounded autonomy for the agents, but we're providing these types of boundaries.

Reactive, we might have backpressure. We might have rate limits, things like that, and linters, and so forth that we also have our agents leverage. Then you have dynamism.

You have some dynamic feedback guardrails as well. Those might be things that you want to be able to assess from a guardrail standpoint. Like, what are those drifts?

What are those architecture drifts? What are those drifts from, the spec said this, but you're actually implementing this, things like that. If there's any budget runs, if there's any cost optimizations, things like that that we're going beyond.

We have to be able to step back and see that. Finally, reflective, some reflective feedback. This is where you step back away from the canvas, look at it from the door and whatnot, and you're looking at strategically, where are we?

We dive deep and we're going in the rabbit hole and working through this. Wait, let's step back. Is this where we want it to be? Let's do any postmortems and retrospectives on how things are and so forth. This is all part of that experience, and hence the canvas experiences that we have. That was the what. That was talking about harness engineering, the evolution towards that, the verbiage, the taxonomy for that, and now also starting to think, what if we think about it as a system? What if we think about it as a canvas for creativity, but still with bounded autonomy?

Now let's go a little bit into the why. Why bother with this and why are we doing this? Some of this, I think we're all experiencing.

The first thing, of course, is just the industrial pressures that exist in our own organizations. It's like, whether you want to or not, if you are in this industry, it is coming to us and has already entered our own goals and requirements coming from leadership. This is coming from McKinsey, of course, is one of the consulting firms, also consulting leaders in organizations on this whole AI movement.

It starts with where we were, let's say, status quo. Then once GitHub Copilot, for instance, came in, and now you have developers always using AIs as an assistant or pairing with AI, maybe you might result in 1.2x if things are good, improvements in productivity. Then when you start having coding agents, so beyond just GitHub Copilot's assistant mechanism, but a coding agent with that harness and things like that, then maybe you might see 2x improvement.

Then, really, where people are looking to go, and this is where leadership are seeing this type of slide. They're saying, we can do even more because we can have a whole swarm of coding agents, and now everybody as developers, we elevate, and each of us become architects and so forth. That might be a 20x improvement.

This is one of the whys. We've been learning as we've been experimenting with these coding agents. This one is coming from LangChain, Viv's blog post that I mentioned earlier.

Here, what they found was that, if they take a model and all they do is change the harness and improve on the harness, they were able to have real improvements. They went from top 30 to top 5 on the Terminal-Bench 2.0's benchmarking. There is credibility around this way of thinking about leveraging harnesses.

I'm curious, have any of you experimented with harnesses? There are some starter kits and things like that on GitHub. This just came out in February.

Still, this is something that we're experiencing. When we hear from people like LangChain, OpenAI, and these bigger companies, allows us to learn from them. This is definitely interesting, worth looking at their blog post on some of their learnings.

OpenAI, as I mentioned, a million lines of code in five months. One of their lessons was just that we need to have continuous garbage collection, because now that we are going faster we can't wait to have that maybe a sprint zero or a sprint just for cleaning. Sometimes teams do that.

We need to have continuous garbage collection. What they did was they launched separate agents where their role just was to do garbage collection. That garbage collection could be anything from code that's not used or detecting drift, feature toggles unused, anything like that as well.

This one, there's quite a few industry learnings here about not constraining agents. If we constrain the agents too much, then you get context bloat because you're saying all of these things, and then there's cognitive misunderstanding and communication interaction failures with the agent because it doesn't know what to follow. Those issues arise. Then, also, what we might be creating as agent skills, they might become brittle because there's too much complexity. We're saying do this and do that and do that. It's such micro-optimizations that any little change, the agent is not able to self-heal and recover because it's been told too many things. I think those are some learnings for us to consider.

In the article that I mentioned earlier by the team in China, they had a whole taxonomy of failures from their experiences. They talk about, for instance, it's possible that the context itself, the agent doesn't have the context that it needs. Maybe the tool that it's trying to fetch doesn't have access to it.

There's any access issues to the tool, or it doesn't know which tool to discover, things like that. Maybe the feedback mechanism that we may have put into play becomes unavailable or is not accessible for any reason, or the agent doesn't understand it. The models themselves might have some failures that were unexpected.

Then on the bottom row we have things that agents may not be able to verify for whatever reason. Entropy is going to continue to be there. That's just part of law of thermodynamics.

Regardless of what we do, there's always going to be entropy.

When it comes to architecture, we're always managing entropy. That's going to be part of whatever we build. Even today without machine agents or in the past without machine agents, these were things that we would run into.

Recovery, so maybe there is an issue in production or issue with some tests and whatever, and agents not able to recover from that. These are different types of agentic issues. Sometimes we don't really know the root cause.

I do want to say while, for instance, models will continue to improve and the harnesses provided by our coding agent providers, they might focus more on the top and be able to bridge the gap between what they provide and what we're able to do today. However, the things on the bottom, like they're always going to be there. They always have been there even without machine agents.

Just want to share that these types of failures, we're not here to control and prevent.

Instead, the alternative model is, how do we make ourselves resilient? Like the DevOps model, if something's going to fail and has failed, try to make it happen more often so that you have a much more resilient system so you know how to recover from those failures. Then, finally, another industry learning also comes from Birgitta, and she was sharing that a lot of the work today up to now has been more on the coding tasks related stuff and maintainability of code and things like that. What's a gap right now is behavioral stuff. Like, what about the product standpoint? What are those behavioral, functional requirements? How do we work with our coding agents to support those?

That's what I'm going to talk about actually in this next section, because we've been doing this. We have been working on functional requirements. Right now, our focus is on all the non-functional requirements.

How do we now apply functional requirements to the coding agent world? Where I would like to start, this is actually coming from 2020, this is coming from my architecture experience earlier. I looked back at this, remember I said it feels very deja vu-ish, to like say, this is the product engineering operating model that we used at edX.

Can this now be applied here where we're thinking about agents? I'm working with some life science clients right now, and we're trying to put together an operating model as we're working with agentic code and stuff like that. I looked back at this to see how might we do this.

Then, whatever canvas we might develop for the agents, how might we leverage from here?

Let's take this one by one of what we're talking about. You'll see overall, even then, we were thinking about, and this is just the human world, the define phase, the build phase, and review phase. As a product organization, when we're defining, we're thinking about what's the overall strategy, product strategy, what are the opportunities, what are those hypotheses that we might want to test and experiment with.

We might do things like Lean Value Trees. We might do some opportunity mapping and so forth. Then the output of that could be things like the opportunity trees, the strategy documents, and so forth.

Then when we're building and we're iterating, continuous iteration, lean startup type of style, we might experiment as we do this, so continuous discovery as we're building. Then there, those outputs are specifications as well as any other compliance reports and things like that that we generate from our CI/CD pipelines and so forth.

That was always something that we also did. Then there's the review aspect. This part is interesting.

I did want to call it out. I don't think the visual does it justice. There is a time aspect to reviews.

Then there's the people or the who aspect to reviews as well. Who is doing which reviews, and then when? Because not everything needs to happen all the time.

There's microfeedback loops as well as macrofeedback loops. Then the team themselves would do reviews of their builds and do that in their own sprint demos and so forth. Maybe with their stakeholders and the customers.

Then there might be some opportunity reviews that we might do with the product leader or the product organization that requested the change in the first place. Then there might be some strategic reviews. Those strategic reviews are not just with the business organization, but also the engineering leaders.

Your VP of engineering, your CTO, whatnot, may want to be able to see, we said that we want to have these metrics, everything for value, flow, quality of our work. Where are we on those? Those are reports that we would generate along the way.

I wanted to share that.

The other thing that comes in the build phase are decision records. You're also generating architecture decision records. Proposal here is to also generate product decision records as you go along the way.

Those then become artifacts. Those are the traces or the pheromones that we leave behind. Then it doesn't matter which agent is there.

It doesn't matter if we have cognitive gaps. We can pick it up as we go, depending on the quality of those decisions. Then the other aspect I want to share, this is also coming from past work, not even in the agentic era, but where we were thinking about, strategically, what are all the different ways that we think about providing context to our teams?

Going from right to left, so at the organization level, we have our mission and our values and our vision. These don't change as frequently, so there's less volatile.

Then, as you go from right to left, it becomes more volatile. The context is also handed down from right to left. Then information is forwarded from left to right.

You'll see goals and outcomes and key results and problem statements and all of that providing the why as well as what are we trying to do, any guidelines about the how we do it, but then also very valuably is how we're going to measure. How we measure, I know right now, I think there were other talks around metrics and stuff too, and it comes up a lot. I wasn't going to go into it too detail in this talk.

I think that's a whole other talk and a whole other exploration of what measures are most impactful and don't constrain us and don't become vanity metrics or have unintended consequences, but also thinking about metrics as also evolving.

It's not just a one-time thing but things that would evolve. Here too, if you go right to left, the metrics that are more on the right-hand side may not change as frequently, like KPIs, key performance indicators for your organization don't change as much, because those are ongoing observations. It might be your customer satisfaction. It might also be your code quality, things like that. The key results are things that you're going to do for a particular initiative, for a particular moment in time for a product. Going from the organization to a product to initiative to a task.

How does this apply to agentic coding? The organization here is essentially your agentic team topology, however you may choose to design that. Could be 100 agents working together.

It could be five or one. That's something that you would design for yourself, depending on the size of your problem space. I wanted to bring this because I'm not seeing this applied so far as much right now in our conversations because we're talking a lot more about coding.

The point is how might we apply things from product engineering there. You'll see here, for instance, the example that we were working with from the life science company. This is just a screenshot coming from basically providing as context to the agent about what we just talked about.

Then, actually leveraging the agent to define what is the mission, what are the goals, and so forth. Providing the agent basically the overall structure here and how we want to go about it.

Then you still use the agent to assist you with whatever context you have to accelerate this. Then the agent themselves are creating these documents, these are all Markdown files, for this type of thing. What is going to be the product's KPIs, goals, and so forth?

Then you'll see here, it's also developing those decision records, architecture ones, and product decision records. It's part of its now its process as it's working through this canvas that we designed. There's an example decision record around designing a control port for human in the loop.

You'll see things like, I've asked it to really think about decay and drift and think about panels, control panels, where I can look at the measures and the metrics and so forth. Then also number five, there is adversarial input. I want to be able to, as a human, actually go ahead and destroy things, remove things, take away things, take away code, or take away a tool that it expected and make sure that it's resilient and recovering.

You'll see some of this output from a dashboard that we had created. It's able to show the decay, the staleness, and so forth. Any drifts that it's able to find. Even adversarial probes, for instance being able to make sure that what we expected, if we do go ahead, and this is talking about patient keys and stuff like that because this is from the life science example I was talking about. You'll see that some of these outcomes are therefore reviewable.

In summary, some of the takeaways that we talked about. These mental model shifts, consider those. How might they actually enable us evolve our thinking as the industry changes, as we change.

Let's not over-constrain ourselves, but at the same time, of course, be responsible with the right bounded context. We talked about a bounded canvas, how you still want to do boundaries but still provide the autonomy so that agents and the generative capabilities of agents can be leveraged. Then, when it comes to stigmergy, leaving traces behind.

Whether it's a human agent or a machine agent or whoever changes hands. We're able to also do traceability, be able to understand what it did. In terms of product engineering models, a lot of that work that we did for our own human topologies, how might we leverage that to our machine topologies?

Let's think back to it so that the behavioral outcomes are also there, not just the cross-functional ones. Let's design for change and design for failures.

Does this resonate, whether you're a lead architect or a senior leader or a manager or a technologist, this type of way of thinking about bounded autonomy, these are things that we've experienced in many different ways.

Participant 1: It definitely resonated with me, a lot of what you had to say. I have two thoughts. One is more of a comment, but it's an insight from a friend.

You showed this picture of a dog weighed down by 100 rules. One of the things my friend has been drilling into me is this idea of the model captures all the possibilities that it's been trained on. That when you imagine, like if you were in a situation and someone gave you 100 rules, what kind of response you would have?

It's not to be creative and capable. You're asking for a mindless automaton, and that's what you get. A not very skilled junior engineer, where you're treating it like a junior engineer, and that's what you get.

If you want a senior engineer, you have to treat it like a senior engineer, and show respect. It just makes sense. Then you're putting yourself more in the probability space of the conversations it's seen with senior engineers where they're very capable, and that's what you're more likely to get out.

I thought that was a really interesting way of thinking about it.

One of the things that really has been troubling me is how to keep a view of the architecture as I'm lifting up. You mentioned decision records. I have similar things where it's like, ok, I've got a lot of documents describing things I did and the way I thought about it at the time. The integral of that over time is the architecture, and that is much more challenging to keep up to date, I find.

Nimisha Asthagiri: One of the things maybe I went through is maps. Maps are as critical, I think. Once again, let's take our learnings from architecture and things like that and how it might be applied here.

Decision records is very key, and they're too, not all decisions are equal. One of the other guidelines I had provided the agents were also which decisions require human review, which ones don't, which ones require decision records, which ones maybe, so the reversibility of the decisions are there. The other guideline is about drawing maps and keeping those maps up to date.

Those maps, we have to be very intentional about which ones matter, and which ones are ok to drift, which ones do we want to keep up to date. By maps there, I'm talking about, it could be the C4 diagrams and the simplicity of that, but don't go all the way down to level 4, not needed anymore. Just level 0, level 1 of C4 diagrams might be sufficient.

There might also be maps that sometimes we create from a product standpoint as well. The product strategic maps, lean value tree maps, Wardley mapping, so those things. Just for that context sharing.

Another thing here is that before, people used to put a lot of things in README files, or even in like CLAUDE.md and things like that. The recommendation now is don't, like that's too much, because those CLAUDE.md type files go into the agent's context every single time. It gets too noisy for them. Why do I have to keep hearing that over and over again? It's not applicable for what I need to do now. Really just keep a map of the folder structure. That's enough. Things like that.

One other comment I wanted to make, which I forgot, which is important too, is one of my learnings is also I had all of those strategy docs and all of that. I think I may have overengineered it, because I think there was a little bit of feedback when I was working with the agent about where to start. I do think that's another recommendation here too from the field as well is, don't over-constrain it. You want to be able to build up that. Then over time your harness or your canvas will get better.