Context Engineering and the Roles AI Is Rewriting

Welcome And The AI Shift

Peter 0:04 Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello, Dave. Good to see you again.

Dave 0:15 Peter, great to catch up. I'm looking forward to this conversation. We've been going back and forth on it, and there's a lot more to dig into. Today we're talking about these context and prompt engineering roles that are starting to pop up in organizations.

Peter 0:34 Right, and I think this is part of a larger conversation. AI has significantly changed how things get done. Building technical systems, managing them, building products, designing products - all of it is being thrown into upheaval. And if you start to drill down, what happens to the people doing this work? What happens to their skills? Where do they fit in the broader system of building a product? So let's get into it.

Dave 1:12 Let me put some context around this. We've had guests on the podcast and talked a lot about different areas where AI is helping organizations do things differently. What we're really focused on here is: you're building a product and you're starting to use AI tools to do a lot of the heavy lifting in that process. It's really about how to build code and product using these AI tools.

Peter 1:49 Yes. And where this conversation started was around the question of where product owners and product managers fit in that new world. I threw out the idea of context engineering, which everyone's talking about. And you pushed back on that - product managers don't do engineering - and that led us somewhere interesting.

Dave 2:18 Words matter. We've had this conversation before about roles where the name is too generic, not descriptive enough, and it just creates misalignment. As soon as you say context engineer, my mind goes to the technical side. If you're trying to bring product and customer-centric people into that conversation, there's already a barrier between what an engineer does and what the business and customer need.

Peter 3:25 Well, haven't you heard? There are no more engineers. Everyone's an engineer now.

Dave 3:29 Fair point. Because that drives us pretty quickly to prompt engineering, where a lot of the conversations I've been part of treat prompt engineers as essentially synonymous with developers. The recognition is that developers are spending more and more time crafting prompts and making sure they're asking the right things of the coding agents they use - which is what we used to call development.

Peter 4:10 That's so 2025. I think we've moved beyond that now.

Dave 4:14 Fair. Just to anchor this - we're talking about the end of Q1 2026. So let's dig into context engineering in a bit more detail.

Peter 4:33 Here's the concept. For agents to operate well, they need context. They need intent. And they work best when that's well-structured, put together in a way that's consistent and repeatable. So you need well-defined context fed into the system. To create good context for agents - especially at the level where you're guiding a product or a whole system - you need to define that context from a product perspective. What do we want this product to do? Who is it going to serve? What does it look like? That's what helps guide the agents in what they're trying to build.

Dave 5:25 If I put my product management hat on - that feels like defining the value stream the product is built to serve. Clear boundaries. What it will and won't do. What needs you're meeting on the customer side, what objectives the company is trying to achieve. These are functional boundaries within which that value stream delivers product.

Peter 5:54 Yes. And the wonderful thing about agents is that we can also have them learn from the delivery and feed that back into the system.

Dave 6:02 That's worth touching on. We often think of value stream definition as semi-permanent - we've identified the target market, we know what we're delivering. But what you're describing is a recognition that there's continuous room for improvement and refinement of that context. It's not going to shift sprint by sprint, but assuming Q1's context is fixed through the rest of the year isn't right either. You want to continually re-evaluate and optimize, which is where that context engineering mindset comes in - continuous review, learning, small modifications to get better results.

Ownership And Version Control Of Intent

Peter 7:06 Right. Your context needs to be captured and structured. That's where a product-type role comes in - going out and pulling context from all the right places, building that understanding, and then articulating it to guide the product forward. The engineering part is structuring that context into a form that agents can consistently consume. At the product side, it might essentially be a well-organized text document. But someone then needs to have the agent pick that up and consume it into the orchestration system. So there's a technical layer to it too.

Dave 8:10 And simple things like version controlling that context. I'm imagining every stakeholder going to whoever is labeled the context engineer and explaining how they want to change things. That becomes whoever shouts loudest gets to tweak the context.

Peter 8:31 Somebody has to be accountable and own it.

Dave 8:34 Exactly. And the way you're describing it, the product manager or product owner - that value stream owner, whatever you call them in your organization - feels like a natural fit for the context engineer role.

Peter 8:50 You could argue that. Who fills that role may also vary depending on the organization and who currently does what. One organization's product owner is another's product manager or business lead. The underlying point is the same though: you need a written, articulated description of what the product is going to do so agents can go build it. And most organizations don't have that. It lives in people's heads.

Dave 9:48 That might be the key statement of this conversation so far - because very few organizations actually have that documented. This is really about taking strategic intent and cascading it down to the operational level. We've talked before about how hard that is to do. We're now creating cascading contexts that drive what's happening across the business - and that's very rarely been done in any organization bigger than a garage.

Peter 10:33 And part of the irony here is that this is exactly what tech teams have been asking for all along. They've always wanted clear guidance on what the business actually wants to build. That's never been clearly articulated. Well, now it kind of has to be. And your tech teams - if you haven't let them all go yet - may have some capacity to help translate that into terms the agents can work with.

Dave 11:07 So as we work around the context engineer role, what I'm hearing is there's definitely an engineering component - consistency, structure, well-understood patterns. That's engineering in a disciplined sense. The reason I'm calling that out is that a lot of brilliant product owners live in ambiguity. They're wired to navigate client needs, customer behavior, the messy human stuff. It doesn't naturally lend itself to rigid structure. Do you see that as a problem when you bring context engineering responsibilities to product owners?

Peter 12:09 What it really comes down to is that software engineers aren't the only ones significantly affected by AI. When you look at the end-to-end system, it affects far more than just the engineering team. A lot more roles are implicated in what it takes to actually drive an agentic system to build a solution.

Dave 12:29 And I keep coming back to making decisions under uncertainty - one side of the conversation wants clear, well-defined rules. The other isn't used to pinning things down like that.

Security Rules And Hard Constraints

Peter 12:45 That's actually part of it too. These systems can help with decision-making. They can help work through ambiguity and definition. But you still need to produce something - context that's good enough to work from. There are good tools out there to help with that. Brainstorming frameworks, structured approaches to help turn ambiguity into the next most feasible step.

Dave 13:26 Revisiting the context engineering piece - we don't just have business and product context. We also have what we'd call non-functional technical constraints. And some context is fixed - security guidelines like NIST, data governance rules that are hard limits. You can't have ambiguity around whether a birthdate gets released. And then on the other side, there's that intentional ambiguity you want to support within boundaries. Can you talk more about the context side of context engineering?

Deterministic Checks And Controls Layer

Peter 14:11 There's a lot of context flowing into the system depending on where you are in it. The key piece from the product side is largely the business and customer context - what's happening around the system. But if you have a system with clearly defined metrics you want to drive from a particular change or feature, you can tell the system to monitor for those, feed the telemetry back in, and have it make decisions about what to adjust. At the same time, you still need deterministic wrappers around the things that are non-negotiable. PII is the classic example. Relying entirely on an agent to follow what's been told to it in a markdown file buried in a hundred thousand lines of context - that's a recipe for problems. You need systems to validate that the actual outcome matches what you expected, and that nothing's happening that shouldn't.

Dave 15:44 That's effectively a controls layer. And in a sense, this is a solved problem - organizations already architect systems with some policing in place. Penetration testing, data governance automation, that kind of thing. What you're saying, as I understand it, is by all means define it in the context documentation - but then you have to police for it to make sure the behavior actually matches what you intended.

Peter 16:33 Exactly. And one of the key things is - because you've defined it in the intent layer, you can check for it on the other end. If you've said "PII should be treated this way, no birthdates should go out unmasked," then you can deterministically check whether that's true in the output. The context and the control connect.

Dave 17:02 That's where context engineering starts to sound like it requires pretty heavy technical expertise. If I define something in the context, I then need to go to the other end of the pipeline and make sure those things are being watched for. Is that part of what a context engineer is responsible for?

Peter 17:29 I don't think validating the output is the context engineer's responsibility. That probably lives elsewhere in the system. If we're going with the idea that it's a product role filling the context engineer space, they're doing the work of pulling context together, creating the understanding around it, and feeding it into the front end of the system. You probably don't want that same person validating what comes out the other end.

Dave 18:04 Separation of responsibilities.

Separation Of Duties And Takeaways

Peter 18:06 So with that - are there any points you'd like our listeners to take away?

Dave 18:13 A few things. The clarification of context as something we've always wanted written down - something organizations have tried to capture in various ways over the years - I find it genuinely exciting to see organizations actually think carefully about what they're trying to build and deliver. So much of that lives only in strategic conversations that shift over time and never really get pinned down. What strikes me is there's a real push now toward something that's been a desired outcome for decades but has very rarely been achieved in most organizations.

Peter 19:04 Yes. It's almost like the structuring of intent that's now required for all of this to work. And we've talked about this before - a lot of what we're seeing with these tools is an acceleration of transformations that organizations have been trying to make for years, but found very hard to adopt.

Dave 19:24 Anything else you'd add?

Peter 19:26 I think exploring where that division of responsibility lands is valuable, and it will vary by organization. Some product owners are more technical and have a broader view of how the pieces fit together. Some contexts make more sense to handle up front. The main thing to take away is this: if you haven't already, start thinking about what context needs to be captured to guide your products, where it's stored, who creates it, and who picks it up and moves it through the system. Good context drives better outcomes. That's always been true. We're just now giving it a name.

Dave 20:16 And I'd add - the conversation between your business and technical teams, pulling those two spheres of knowledge and experience closer together, matters more now than ever.

Subscribe And Contact The Show

Peter 20:34 You really can't afford to operate as "the business" and "IT" anymore. You can't just throw things over the wall. The two groups have to work closely together. And if you're enjoying this conversation and want to hear more, hit subscribe. It makes the graph go up, which always makes Dave happy. If you'd like to be on the show, reach out at feedback@definitelymaybeagile.com. Looking forward to next time.

Dave 21:08 Until next time. Thanks again.

Peter 21:10 You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale.