An alarming amount of organisational memory lives only inside PowerPoint: captured for a moment, then buried in a format that makes it difficult to find, reuse or evolve.
Not just presentations, but also decisions, processes, strategies, operating models, project histories, explanations of how things work and why they work that way. Important organisational context gets assembled for a meeting, presented to a particular group of people, perhaps emailed around afterwards, and then gradually disappears into SharePoint, Teams or someone’s hard drive.
Six months later, somebody needs it again - they find three versions of the deck. Nobody is quite sure which one was final, the person who created it has moved roles. Some of what it says is still true, some isn’t, and much of the context that made the slides intelligible existed only in the room when they were presented.
So somebody starts reconstructing it. This is one reason I’ve become increasingly interested in organisations moving from documents towards wikis and other forms of shared, persistent context. It isn’t because documents are inherently bad. A document is good at being a document. The problem is that we’ve asked documents to do rather more than that.
We’ve used them as containers for organisational knowledge, as proxies for processes, records of decisions, instructions for work and like databases with better typography. Sometimes even as the interface through which an organisation tries to understand itself.
And now something interesting is happening to these artefacts of knowledge work themselves.
The file has had a very long reign
Microsoft made a rather consequential and long overdue statement in its latest Copilot announcement:
“Until now, the basic unit of knowledge work has been the file — document, spreadsheet or presentation.”
It is one of those statements that seems obvious until you think about how much organisational design sits behind it. For several decades, producing knowledge work has largely meant producing artefacts for another human to consume:
We write a document explaining something.
We build a spreadsheet to model or track something.
We create a presentation to communicate something.
Even when the work being described is highly dynamic, the artefact itself is usually relatively passive. It captures information about the work, while a human supplies the interpretation, judgement and action required to turn that information back into work.
Think about something as ordinary as a quarterly review. There might be a PowerPoint explaining the process, an Excel template for collecting numbers, emails reminding people to submit them, another deck containing the final analysis, and several experienced people who know all the undocumented rules required to make the whole thing function.
Collectively, those artefacts contain a surprising amount of organisational knowledge.
But they don’t do the quarterly review - people do.
Microsoft’s interesting proposition is that another kind of artefact is now becoming accessible to the ordinary knowledge worker. Its new Code capability allows someone to describe what they need in natural language and create a small application (a tracker, dashboard, workflow, automation or other purpose-built piece of software) running inside a managed enterprise environment.
That sounds superficially like another iteration of “everyone can become a developer”, but if we reframe it, everyday output of knowledge work can begin to move from:
From information describing work → something that performs work.
Instead of creating a spreadsheet that tracks a process, I can create the tracker, instead of documenting how to assemble a report, I can create the workflow that assembles it and instead of writing instructions explaining a repeatable method, I can encode some of that method into a reusable skill.
The boundary between knowledge work and software creation is blurring. And that potentially changes far more than who gets to write code.
From shared context to executable context
There is already an intermediate step between the document and the executable artefact: shared context. This is why the difference between an organisation that runs on PowerPoint and one that makes serious use of wikis can feel much bigger than a change of publishing tool.
A presentation usually captures knowledge for a particular moment and audience. A good wiki attempts something different. Knowledge is expected to persist beyond the meeting that produced it. Other people can find it, link to it, correct it and build upon it. Decisions can sit alongside the context that produced them. Understanding accumulates rather than repeatedly being reconstructed.
The shift is roughly from:
Here is what we know right now → Here is what we currently understand, and here is where that understanding lives.
If organisational knowledge is fragmented across old presentations, email threads, spreadsheets and people’s heads, an AI system inherits much the same problem as a new employee. It has to find the right information, work out which version matters, establish whether it is still current, and reconstruct relationships that were obvious to the people involved but never explicitly captured.
Shared context makes organisational knowledge more accessible to humans. Increasingly, it also makes it more accessible to machines.
There is an interesting tension here for Microsoft itself. Copilot’s early strength was its ability to work across the documents and files already sitting inside Microsoft 365, but that document-centric view of organisational context may also have constrained its early agentic ambitions. Documents contain only a partial representation of how an organisation actually works: decisions live in conversations and meetings, operational state in systems and data, and much of the work itself in workflows and relationships. Microsoft’s more recent move towards richer context through Work IQ suggests it increasingly recognises that distinction: agents need to understand not just the organisation’s content, but its work.
But we may now be approaching another transition. Once a machine can reliably access that context, some of it no longer has to sit there waiting to be read.
A description of how to perform a task can become part of a skill that performs it.
A set of rules can become part of a workflow that applies them.
A collection of data sources and analytical steps can become something that continuously produces an assessment rather than a spreadsheet somebody has to rebuild each month.
The progression starts to look something like:
Document → shared context → executable context
These aren’t necessarily replacements for one another. Each is useful for different things, and an organisation will need all three. But executable context introduces an important new possibility: we can externalise not only what the organisation knows, but some of what the organisation knows how to do.
The capability hidden inside the artefacts
Consider what is required to produce a monthly management report. There might be a spreadsheet containing the numbers, another showing how they are calculated, a PowerPoint template for presenting them, a document explaining the reporting process, emails requesting contributions, and perhaps a checklist maintained by the person who actually knows how everything fits together.
Then, of course, there is everything that isn’t written down. Which numbers normally need investigating. Which anomalies can safely be ignored. Who needs to be chased. Which source is trusted when two systems disagree. What the leadership team usually asks about. Which commentary is useful and which simply generates more questions.
Taken together, these things represent much more than a collection of files. They are a partial representation of an organisational capability.
Until recently, digitising that capability properly would probably have meant turning it into a software project. Someone would gather requirements, translate the work into specifications, commission or configure a system and maintain it afterwards. But, if an employee can create a small application through conversation, connect it to existing enterprise capabilities, and give it instructions and context that allow it to perform parts of the work, the distance between understanding how something works and building something that does it becomes dramatically shorter.
The management report might gradually become something that collects its own inputs, identifies missing information, applies the agreed calculations, flags unusual results and assembles a first version of the commentary for review.
The human hasn’t disappeared. Neither has the underlying knowledge, what has changed is where some of that knowledge resides. Instead of being distributed entirely across documents, systems and people’s heads, some of it has been encoded into an artefact that can act. This is why I think describing the shift as democratising software development undersells it.
The more consequential change may be that the people closest to the work gain a new way to externalise what they know about how that work gets done.
The infrastructure is beginning to catch up
Of course, being able to generate a small piece of software is not the same as being able to use it safely inside an organisation.
This is where many earlier waves of low-code and no-code technology eventually ran into reality. Creating the thing was only part of the problem. It also needed access to data and systems, somewhere to run, appropriate permissions, security and governance, an owner, and some way of understanding what had been created in the first place. Make creation dramatically easier without addressing any of those things and you don’t necessarily get a more programmable organisation. You may simply get a much larger shadow IT problem.
Microsoft’s announcement is a good example of the wider shift that is actually possible - code isn’t simply being positioned as a way for Copilot to produce an application on someone’s laptop. Microsoft is providing a managed runtime in which those applications can operate, bringing identity, security and governance with them. That is an important part of the proposition because it begins to answer the question of what happens after somebody says, “I wish I had a little tool that did this.”
Elsewhere, a different part of the same picture is emerging. Google recently announced that existing REST APIs can be exposed directly as MCP tools through its API Gateway. It sounds like plumbing (and it is) but plumbing matters. Organisations already have enormous amounts of useful capability sitting behind APIs: retrieving information, updating systems, initiating transactions and invoking established business services. Making those capabilities easier for agents to call reduces the distance between an AI system understanding what needs to happen and actually being able to do something about it.
This is also where Gartner’s prediction about disposable software that we wrote about a few weeks ago starts to make more sense. Its suggestion that 80% of new applications could eventually be deliberately short-lived sounds extraordinary if we imagine every application going through the economics and machinery of traditional enterprise software development. It becomes considerably less strange if some applications can be created by the people doing the work, assembled from governed organisational capabilities, used for as long as the need exists and then allowed to disappear.
Put these developments together and a different model of enterprise technology begins to emerge.
Don’t recreate the PowerPoint problem in software
There is an obvious danger lurking in all of this. We could solve the problem of organisational knowledge being trapped in documents by trapping it somewhere even harder to see.
The spreadsheet maintained by one person and understood by nobody else is already a familiar organisational hazard. The same is true of the PowerPoint deck whose meaning depends on someone remembering the conversation that accompanied slide 17. Neither problem disappears simply because the new artefact happens to be executable.
Imagine an organisation in which thousands of employees can create small applications, workflows and agents as easily as they currently create spreadsheets. Some will be genuinely disposable: built for a particular task, useful for a week and then discarded. Others will quietly become part of how work gets done. People will begin to depend on them. New colleagues will inherit them. Decisions will be shaped by them. Other applications and agents may start calling them. At that point, what began as a convenient personal tool has become a small piece of organisational infrastructure.
This is where the analogy with documents becomes useful again. One of the reasons organisations struggle with PowerPoint as organisational memory isn’t that PowerPoint is a bad product. It is that the surrounding practices rarely require us to make the knowledge inside it durable. We don’t consistently record provenance, connect related ideas, retire outdated versions or preserve the context in which decisions were made. The artefact survives, but much of its meaning doesn’t.
Executable artefacts create a similar problem with higher stakes. If a workflow contains assumptions about how a decision should be made, or an agent encodes a particular interpretation of a policy, that knowledge needs to remain visible somehow. We need to know where it came from, who owns it, when it was last reviewed and what other parts of the organisation have come to depend upon it.
This doesn’t mean every tiny application needs to be treated like a traditional enterprise system. Doing so would rather defeat the point. Part of the opportunity is precisely that software can become more provisional: something we can create, adapt and discard as the work changes.
But disposable cannot mean unknowable. Perhaps this is where the real organisational challenge begins. As the cost of creating executable artefacts falls, the scarce capability shifts away from simply being able to build them. Organisations need ways to make what they create visible, understandable and appropriately governed without removing the speed and local autonomy that made them useful in the first place.
Choosing what knowledge should become
For a long time, we haven’t had to think particularly hard about the form organisational knowledge takes.
If we needed to explain something, we wrote a document. If there were numbers involved, we reached for a spreadsheet. If other people needed convincing, sooner or later it became a presentation. These formats became so embedded in knowledge work that the choice of artefact barely felt like a choice at all.
Some knowledge needs to be read and understood. Some needs to remain shared, connected and continually updated. Some describes a repeatable method that could become a reusable skill. Some coordinates activity and might be better expressed as a workflow. Increasingly, some can become part of an application or agent that actually participates in the work.
Often the same organisational knowledge will need to exist in several of these forms at once. A policy, for example, still needs to explain its intent to people, while parts of it might also become structured knowledge that machines can retrieve or rules that an executable workflow can apply.
So perhaps the new literacy isn’t simply learning how to create these new artefacts. It is learning to make better choices about what form our knowledge should take, and why.
Start with the knowledge, not the application
For leaders, I don’t think the immediate response to any of this should be to encourage everyone to start building applications. There is a more useful place to begin.
Choose one piece of recurring knowledge work in your organisation: preparing a forecast, onboarding somebody, approving an investment, responding to a customer issue, reviewing a project. Then look at what somebody actually needs to know in order to do it well.
Where does that knowledge live today? Some of it will be in systems and structured data. Some will be buried in presentations, spreadsheets and old documents. There may be policies and definitions somewhere else, conversations that provide important context, and experienced people who know the exceptions, shortcuts and unwritten rules.
That is the knowledge architecture of the work, whether you have deliberately designed it or not.
Before asking what could be automated, ask what needs to be made easier to find, share and maintain. Look for the knowledge that needs to remain human-readable because people need to understand, question or reinterpret it. Then look for the more repeatable parts: the rules, methods, calculations, checks and hand-offs that might increasingly become executable.
You might discover that the immediate answer is not an agent or an application at all. It might be a better wiki page, a common definition, a cleaner data source or simply getting an important decision out of somebody’s PowerPoint and into shared organisational context.
That is still progress, because making knowledge executable raises the stakes on something organisations have struggled with for decades: knowing what they know, where it lives, who owns it and whether it can be trusted.
The organisations that benefit most from this shift may therefore not be those that generate the most software. They may be the ones that become much more deliberate about the relationship between their knowledge and their work, what should be documented, what should be shared, what should remain open to human interpretation, and what can safely be turned into something that acts.
The file isn’t disappearing, but for the first time in a long time, it may no longer be the automatic answer to the question: what should we make?