Working Notes from the Edge of Practice
In the past few years, most of what we'd consider our most interesting work — certainly where we're stretching our own strategic foresight practice — has stayed invisible. Clients keep telling us the value isn't the tools and methods on the page; it's how we thought through their questions to get there. We've mostly let that stay unsaid. That's lost value, for us and for anyone trying to see what foresight practice actually looks like from inside a working consultancy.
R&D is an attempt to change that.
What gets built here doesn't always reach a deliverable. A database structure, developed for a scenario planning engagement. A simulation engine, rebuilt for a different risk domain, to see whether the architecture held. A prompt system for turning development threads into publishable pieces. A positioning framework, contributed to a global forecasting consortium. A small foresight operation, run almost entirely by AI — more on that below. These get built, tested, iterated, pinned for later, and returned to, months on. The thinking behind them has mostly stayed invisible until now. The work spans several years; documenting it openly is newer.
"The thinking behind them has mostly stayed invisible until now."
One thread running through much of this work is testing generative AI tools — not as a productivity layer, but as a real research question. Where does it fit inside a foresight process, and where doesn't it? What does it change about how we design simulations, structure research, build frameworks? What does it reveal when it gets things wrong? We've tested this across audio, generative media, game engines — formats we're pushing at the edges of what foresight and futures design can do right now. The answers keep shifting as the tools do, which is itself part of what we're tracking.
Running alongside this are the work logs themselves. Much of what we build gets developed through extended sessions — in AI tools, in notebooks, across conversations that span weeks or months. We've started treating those logs as primary material: mining them for the moments when something gets learned, prototyped, discarded, refined. When a design decision gets made, then reversed. When a tool answers in a way that changes the direction of the work. When something built for one purpose turns out to matter more somewhere else. R&D catches those turns close to when they happen, before the learning gets smoothed into a method, or just forgotten.
The clearest example of what this is for is APE — a small autonomous foresight operation, run with minimal human editorial direction, built to show what a foresight agency actually does once its judgment, selection logic, and framing choices are taken out of the loop. It's an adversarial model of the practice: what does the role look like challenged, replaced, or simply made to explain itself? The question isn't whether AI can do foresight. It's whether the practice can say what it does that AI doesn't. That's not a comfortable question. We think it's a necessary one.
What that gap comes down to, in practice: the questions we're willing to ask about the edges of our own work, the tools we test before there's a clear use case yet, the assumptions about the practice we're willing to hold up and challenge — including our own. None of that shows up in a deliverable. It shows up in how we think, how we build, and what we're willing to throw out when something better turns up.
R&D pieces are short, artifact-first — captured close to the work, before the thinking hardens into method.
