Definitely, Maybe Agile · 2026-04-30 · 17 min
Key moments - from our scoring
Substance score
53 / 100
Five dimensions, 20 points each
The hosts explore a critical communication breakdown in how organizations hand off ideas from conception to execution. When strategic intent gets converted into PowerPoints, then summarized by AI, then passed through additional layers of tools and people, the original essence gets diluted toward bland, generic versions. Peter and Dave draw parallels to CALM (Common Architecture Language Model), a structured language framework used in financial systems architecture by Finos, which maintains a single model that generates different stakeholder views without corrupting the underlying context. The core argument is that organizations should capture intent in a stable, version-controlled context document - similar to markdown-based context files - rather than creating multiple artifacts for different audiences. This single source of truth prevents the drift that happens when a PowerPoint becomes the artifact being edited instead of the intent. Dave notes that even simple user stories diverge in interpretation across handoffs, so the challenge is building a business-context equivalent to CALM that can be interpreted consistently. The conversation applies to anyone managing product strategy, business requirements, or cross-team knowledge transfer where clarity of intent directly impacts delivery outcomes.
AI naturally pulls ideas toward a common denominator and boilerplate versions. When an original idea is converted to a PowerPoint, then summarized by AI, then passed through another AI engine, the nuance and what made the idea special gets diluted through the chain, creating a 'broken telephone' effect before the specification is even built.
CALM (Common Architecture Language Model) is a standardized language framework developed by Finos that defines systems, components, and interfaces in a single model. From that stable model, you can generate different views for different stakeholders without changing the underlying context, preventing the drift that happens when artifacts get edited for different audiences.
Maintain a single stable context document (similar to version-controlled markdown files) that captures the essential intent and context. Edit the context, not the PowerPoint - when you need a PowerPoint for a particular audience, generate it from the context as a view, not the source.
People read the same thing differently based on their own context and assumptions. Without a structured framework to articulate and share intent, multiple interpretations naturally emerge, which is why a shared taxonomy and stable source of truth is needed.
Organizations shift from making a PowerPoint that communicates what they're actually trying to do, to making a PowerPoint that meets audience expectations. These are two different things, and a single central context artifact keeps you honest by preventing that drift.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode identifies a real problem - idea dilution through repeated AI summarization and artifact passing - with some structural thinking via the CALM framework analogy. However, the core insight (that context gets lost in handoff chains) is not particularly novel, and much of the runtime is spent circling the same point rather than building on it. The conversation lacks concrete case studies or measurable examples of the damage caused by this breakdown.
AI naturally pulls things toward a common denominator. You end up with a boilerplate version of the thing, and whatever was special about the original intent gets diluted through the funnel.
There's no shared taxonomy for intent. No way to have one source of truth that different people can look at from different angles without losing something.
The framing of AI as a transmission medium that standardizes and dilutes intent is reasonably fresh, but the underlying critique of organizational handoff failures and context loss is well-established. The CALM reference is interesting but deployed as analogy rather than deep analysis. The suggestion to build a 'context document' as a single source of truth is essentially a repackaging of existing practices (project charters, design documents, specs) without substantial innovation in how to structure or enforce it.
This is basically how organizations have always operated.
That's the best case, not the typical case.
This is a two-host co-conversation with no external guest. Peter Maddison and Dave Sharrock appear to be practitioners/consultants with relevant experience in agile and context engineering, but neither is identified with a substantial operator track record, exit, or scaled company. The episode lacks the credibility that would come from interviewing someone who has actually solved this problem at a large organization or seen massive financial impact from intent loss.
We've seen play out in a lot of our work.
We've had plenty of conversations about what works there.
The episode names one concrete example (CALM/Finos) with some technical detail, but largely avoids naming real companies, failed products, or quantified costs of broken intent. The discussion of user story divergence is anecdotal ('times we've written user stories') rather than evidenced. No metrics on how often intent loss occurs, what percentage of failed features stem from this, or financial impact. The proposal to build a context structure for banking or e-commerce is speculative rather than grounded in real implementation.
There's a project within Finos, which is a financial open source organization. One of their open source initiatives is called CALM, the Common Architecture Language Model.
all those times we've written user stories, agreed we understood them, handed them off, and still come out the other end with two different interpretations of a simple feature.
The hosts ask reasonable follow-up questions and gently push back on each other (Peter needling Dave about 'context engineering is a thing'; Dave questioning how to make the structure stable across interpretations). However, the conversation lacks sharp challenge - neither host presses the other on why this hasn't been solved, what barriers exist to adoption, or how to measure success. Questions tend to be exploratory rather than investigative, and there's no disagreement that forces either party to defend their position rigorously.
So I'm not sure how you build the structure you're describing in CALM for a business context, in a way that is actually stable across multiple interpretations.
I think we're starting to agree that capturing and sharing context as a stable, underlying artifact is genuinely valuable.
Computed from the transcript - who did the talking, and the words that came up most.
It doesn't happen all at once. A great idea comes out of a strategy session. Someone turns it into a PowerPoint. Another person summarizes that PowerPoint with AI. By the time it reaches the team building it, the sharp edges are gone and nobody quite remembers what made the idea worth pursuing in the first place. Peter and Dave dig into a problem that's older than AI but getting harder to ignore. How does intent get lost as it travels through layers of people, tools, and artifacts? What does a shared context document do that a business case can't? And what can the architectural world teach the product world about keeping the thread from unraveling? Key takeaways: Moving artifacts backwards and forwards through an organization strips out nuance at every step. A single central context document is a more honest way to carry intent from strategy to delivery. AI is being actively encouraged in most organizations right now, and in using it, teams may be quietly eroding the ideas behind what they're building without realizing it. If your outcomes don't match your original intent, the handoff chain is usually where things went wrong. That's worth looking at before blaming the team.
Transcribed and scored by The B2B Podcast Index.
Welcome And Why This Matters Peter 0:05 Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Dave 0:13 Peter, great to catch up with you. We're following on from a conversation we started a few weeks ago, sparked by something we found online. The Broken Telephone Of Ideas Peter 0:22 Yeah, there was an article that came through my LinkedIn feed and it caught my attention because of a conversation we'd had on the podcast about context engineering and how roles are shifting.
This article was more about where some of the fundamental problems are with the system as it stands today. AI plays a part in that, but honestly, the underlying issue is older than AI. How do we articulate and capture ideas, and then hand them off to the person who's going to build them? That question applies to AI too.
Dave 1:04 And this touches on something we've seen play out in a lot of our work. The business has ideas, or whoever is close to the customer has ideas. There's a communication pathway, whether that's specs, BRDs, user stories, jobs to be done, or just working directly with a team. You start with an idea, figure out what you want to do with it, and get it to the people who build it.
We've gone from tightly defined specs to much more fluid approaches, and we've had plenty of conversations about what works there. But as you accelerate ideas through that chain, you start hitting edge cases and real messiness. The article we're talking about describes a scenario where an idea gets generated, someone uses AI to turn it into a PowerPoint, that PowerPoint gets fed into another AI engine, it gets summarized again, and somewhere along the way you lose the essence of what you were originally trying to do.
Peter 2:28 Right, because AI naturally pulls things toward a common denominator. We've all seen enough examples of it. You end up with a boilerplate version of the thing, and whatever was special about the original intent gets diluted through the funnel. This is happening right at the point where you're trying to define something, before you've even written a proper spec.
If the specification is being built from an intent that's passed through a chain of AI-generated summaries, you can end up with a classic broken telephone situation by the time it reaches the builder. Dave 3:29 The best strategy sessions I've been part of have people in the room who have a very clear idea of where they're trying to get. They defend it, argue for it, make a case for it. And they constantly pull the conversation back from that tendency toward the diluted, normalized version of an idea.
They hold the thread. That's the best case, not the typical case. But when someone really understands what they're trying to achieve and can articulate it well, you get something stronger out of the whole process. If you rely on AI to do that work instead, you might never narrow down to the sharp, specific intent that can actually get delivered.
Would that be fair? Peter 4:36 I think it depends on how AI is being used in that context. Always does, yes. But if it's being used to summarize and standardize, the nuance gets lost.
You have a great strategy session, everyone's aligned, you've got a genuinely good idea, and then it goes into a PowerPoint, gets sent to someone, and they run it through AI to summarize it. Whatever made the idea interesting often doesn't survive that. And this isn't a new problem. This is basically how organizations have always operated.
Dave 5:28 It's how we end up with bland strategic vision statements that don't mean anything to anybody. The connection to the original intent just quietly disappears. Peter 5:48 Or you tried to keep everyone happy in the room, and as a consequence, you ended up with nothing at all. Dave 5:55 There are plenty of ways to arrive at that.
And getting back to the article, the argument is essentially this: stop moving artifacts backwards and forwards. Don't pass PowerPoints and business cases through layers of people and tools. Capture the intent as a single, stable thing, and edit that. Not the PowerPoint.
Not the business case. The context. A Structured Model For Shared Context Peter 6:39 Exactly. I have a good technical example of this, if you'll bear with me.
There's a project within Finos, which is a financial open source organization. One of their open source initiatives is called CALM, the Common Architecture Language Model. What CALM gives you is a standardized language for defining a system and how its components and interfaces relate to each other. It's great material for an LLM, but more interestingly, it lets you define actors, interfaces, and flows in a single model.
From that model, you can generate all the different views that different stakeholders need, without changing the underlying context. You can see how that connects to what we're talking about here. Dave 7:51 Yeah. Peter 7:52 So you use that language to come to a shared agreement about the shape of the thing you're trying to build.
That's in the architectural space, but the principle holds more broadly. Dave 8:05 It actually helps clarify something we were circling around before we started recording. In our last conversation, we talked about context engineering and the idea of capturing context in markdown files, things like where the business is trying to go, what they're trying to achieve, that kind of thing. These context documents become a stable foundation under which products get built.
They're version-controlled and they don't change dramatically as the work progresses. And the article is making essentially the same argument. Don't create a PowerPoint. Don't write a business case.
Create a single context that moves between the people contributing to it. Edit the context, not the artifacts you've generated from it. The challenge I keep coming back to is that in an architectural space, you have CALM giving you structure. I'm not sure we have an equivalent in the business context.
Something well-formed enough that the next person who picks it up interprets it the same way you did. Why Even Simple Stories Diverge Peter 9:26 And that's actually what the article was pointing at. We have this kind of structured context in other domains, but not really in the product space. There's no shared taxonomy for intent.
No way to have one source of truth that different people can look at from different angles without losing something. I find it interesting. There are various approaches, but the gap is real. And yes, I'm still trying to convince you that context engineering is a thing, so I'm hoping this is nudging you in that direction.
Dave 10:18 I think we're starting to agree that capturing and sharing context as a stable, underlying artifact is genuinely valuable. What it reminds me of is all those times we've written user stories, agreed we understood them, handed them off, and still come out the other end with two different interpretations of a simple feature. Not a complex strategic challenge. Just one feature that does X.
Even then, people can read the same thing differently. So I'm not sure how you build the structure you're describing in CALM for a business context, in a way that is actually stable across multiple interpretations. Peter 11:23 It's a real challenge. Maybe there are lessons to take from CALM.
Maybe we should go away and try to build something that starts from that thinking. What are the attributes of language that actually describe intent? And can we use those deliberately? Dave 11:40 If you think about something like banking or e-commerce, you could probably put together a pretty useful context structure fairly quickly.
There would be edge cases it doesn't cover, but you could get something meaningful. That could be a good experiment. Peter 12:06 Yeah. And I think there's something valuable in here for our listeners around how you create the context that drives the systems you're building, and how you manage the transfer of that context without it getting diluted along the way.
The idea itself becomes something everyone contributes to, rather than a series of separate views that get generated for different audiences and slowly drift apart. Dave 12:59 I really like the idea of a single artifact, a context document that holds the essential things. And you can absolutely use it to generate a PowerPoint for a particular audience when you need one. But the PowerPoint is a view, not the source.
One thing you and I have talked about before is how quickly you shift from making a PowerPoint that communicates what you're trying to do, to making a PowerPoint that meets the expectations of the audience receiving it. Those are two different things. A single central artifact keeps you honest. You could argue this is what the project charter was supposed to be in traditional project management.
And if you keep it current, it becomes the raw material for everything else. That consistency is actually quite powerful. Three Takeaways And How To Reach Us Peter 14:26 With that in mind, we should wrap up and go build it. So what are the three takeaways from this conversation?
Dave 14:38 The first is recognizing that passing artifacts backwards and forwards, PowerPoints, business cases, summaries for different audiences, adds noise and loses information at every step. And seeing a single context document as the alternative is a meaningful shift. The second is watching closely how ideas actually move through your organization. People are busy, AI is being actively encouraged, and in using it, they may be quietly diluting the intent behind what they're building.
That matters, because you might not end up with the outcomes you were aiming for. Peter 15:24 Which leads to the third, which we don't quite have time for today: validation. Did I actually get the outcome I was expecting from the intent I started with? If your intent is being eroded through multiple summaries and handoffs, that might explain why the output doesn't match what you had in mind.
That's a whole other conversation. Dave 16:27 I think we've got three things there. Peter 16:29 I think so. To all our listeners, don't forget to subscribe.
And if you'd like to come on the show or just want to chat about any of this, reach out at feedback@definitelymaybeagile.com. Until next time. Dave Until next time.
Peter You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and David Sharrock focus on the art and science of digital, agile, and DevOps at scale.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Why Your PE AI Program Is Already FailingPrivate Equity Data Guy · on Context engineering95 / 100
Orion at Gravity: Trustworthy AI Analysts for the EnterpriseData Engineering Podcast · on Context engineering92 / 100
221: You need Minimum Viable Readiness for AI because perfect data doesn't exist with Jason DobbsHumans of Martech · on Context engineering89 / 100
Why Scott Brinker Says AI Can't Pick Your Tech StackMaking Sense of Martech · on Context engineering87 / 100
178: Activation Is Broken: Why Most SaaS Teams Get It Wrong (and How to Fix It)Move The Needle · on Jobs to be Done framework87 / 100
How to Hire Salespeople in 2025The Revenue Formula · on Jobs to be Done framework87 / 100Organizational Honesty in Agile Teams66 / 100AI Is Speeding Up Delivery. Are You Building the Right Thing?51 / 100Data, AI, and Knowing When to Let Go - with Tommy Cotter81 / 100AI Adoption Starts With How People Think, Not Which Tools They Pick - with Royce Sin81 / 100What Organizations Get Wrong About Junior Engineers and AI55 / 100