@Tom_Hagen, Thank you for your thoughtful and passionate take. I put more thoughts into this thread as I agree with you, we can do better — I think many of us have wrestled with similar tensions when trying to reconcile the philosophy of GTD with the realities of implementation, whether on paper or in software.
I’d like to offer a few reflections that might help bridge the gap.
First, I believe when David Allen refers to GTD as “holistic,” he’s pointing to the fact that GTD is not just a productivity method, but a
behavioral system. It's about how we
think,
review,
make decisions, and
engage with our commitments — not just how we store them. Paper or software are simply containers. A brilliant container won’t work without clear habits and regular engagement. So yes, you
can implement GTD on paper or in software — but
doing GTD well requires more than just having the right fields or filters. That might be what Allen was hinting at, even if it didn’t land well.
Second, I completely agree with you that creativity and iteration are often hard to box into a “next action.” GTD doesn’t try to eliminate ambiguity — it helps us
frame it. In your example, maybe the next action is “open editor and sketch first attempt” — not because that defines the whole solution, but because it moves you forward without friction. Creative work often unfolds
because you’ve lowered the barrier to starting.
Third, I’m with you on the power of digital tools. Filtering, context-switching, and even reviewing at scale are significantly easier with smart software — especially when your system gets complex. So yes, software
can absolutely
enhance GTD — provided we don’t rely on it to
do GTD for us. A tool might be smart, but it can’t reflect for you, clarify your intentions, or decide what matters most right now. That’s still on us.
It’s quite possible that when David Allen says GTD can’t be “implemented” in software, he’s not claiming it’s technically impossible, but rather emphasizing that GTD is first and foremost a
thinking framework. But I agree with you — if we
do treat his “blueprint” seriously (especially the model he shared at the 2019 Amsterdam Summit), then from a
systems design perspective, it is absolutely possible to build software that supports the entire GTD flow, possibly even in a more integrated and elegant way than he originally proposed.
In fact, companies like SAP, Microsoft, or Oracle and many more routinely build digital ecosystems that map to incredibly complex operational flows — we’re talking global ERPs, multinational CRMs, compliance systems, etc. In comparison, a robust GTD platform — complete with inbox capture, thinking support, context filtering, and trusted review loops — is, while not trivial, certainly not out of reach. So I’ve always wondered:
why haven’t any of the tech mastodons attempted it seriously?
The closest serious attempt I’ve seen was probably IQTell — which tried to merge email, tasks, projects, and reference into one actionable hub. And it got surprisingly close before it shut down.
Now, speaking from my own experience, I’ve applied Lean Six Sigma principles to my GTD setup and reached something quite close to what I’d call a
personal airtight system. I use Outlook desktop (O365), Todoist, and OneNote — with automation handling things like delegation directly from email into Todoist tasks, and dynamic linking of notes and project references. My dashboard gives me not only visibility over my horizons of focus but also seamless control over handoffs, outcomes, and waiting-fors.
This system might look like an “ideal GTD app” to someone juggling a fragmented setup full of what I call
waste generators — frictions, double entries, or breakdowns in trust. But — and this is crucial — as soon as I step outside my bubble and start coaching or collaborating with someone else, I’m reminded of a key GTD reality:
the tool is only as good as the behavior driving it. Most teams I encounter aren’t “GTD-native,” and their tools reflect that — reactive, siloed, and often built on unclear commitments.
Just to highlight what I mean: recently, I partnered with a startup that operates entirely on an IMAP email infrastructure. My entire ecosystem — from delegation flows to meeting follow-ups — is built around Exchange and the Microsoft Graph API. So suddenly, all the background automation I’ve developed over years — code that seamlessly links Outlook emails to Todoist, OneNote, and project metadata — became unusable in that environment.
That small technical incompatibility was incredibly humbling. And honestly, a bit infuriating. Overnight, my trusted system was no longer airtight. I wasn’t just adjusting my edges — I had to question the
backbone of my entire automation. It raised a bigger question for me:
how can I build a GTD ecosystem that’s robust enough for my needs, but flexible enough not to break when collaborating with others in a completely different digital reality?
This challenge went far beyond APIs and platforms. It brought me face to face with something described in
TEAM, the book David Allen co-authored — the idea that effective collaboration requires aligned systems and mutual clarity on purpose and outcomes. My system, as refined as it was, was designed primarily for
me. But the moment I needed to work deeply with others outside my “bubble,” it became apparent that a personal system — no matter how advanced — doesn’t automatically scale into a
shared system.
That meant letting go. I had to relinquish parts of my finely tuned setup and co-create new standards with my collaborators. For instance, we collectively agreed to use Microsoft Teams, including Planner and Lists, to align our shared project visibility, reviews, and accountability. This created a kind of “GTD for teams” environment, where even those unfamiliar with the methodology could engage productively without friction.
But even once that was in place, we kept facing new layers of friction. Let’s say we invite an outside expert into a key conversation — and they use Zoom instead of Teams. Suddenly, all the meeting automation we rely on — automatic transcription, AI-generated minutes, structured extraction of next actions — falls apart. We’re back to friction, duplication, and lost information. It’s a constant reminder that
our most trusted systems often depend on assumptions about the environment — and those assumptions break quickly across organizational boundaries.
So the real lesson for me has been:
adaptability trumps control. GTD at its core is about clarity, not rigidity. And as much as we strive for airtight systems, we need to design with permeability in mind — systems that flex across contexts, tools, and human variables, without collapsing. That’s not easy. But it’s probably the next frontier for GTD practitioners who are not just thinking about personal effectiveness, but collective flow.
Building on all this, I’ve recently started exploring how AI — especially large language models — could help boost and stabilize the digital GTD ecosystem. I’m currently prototyping an AI-driven GTD app, where I assign specialized digital agents to each key corner of the GTD workflow: capture, clarify, organize, reflect, and engage. The idea is to have these agents proactively support each phase, not just passively store information. Early results are promising — I’m confident that LLMs can eventually handle 80% of my flows with surprising nuance, from parsing inboxes to drafting next actions, preparing weekly review prompts, and even nudging me based on shifting priorities.
But that brings me full circle to the challenge I keep encountering:
how effective will these AI flows be when I step outside my controlled ecosystem and have to work with others? An AI agent that knows my context can be brilliant — but drop it into a shared space where roles, norms, and tools vary wildly, and its intelligence can become noise. So again, it’s not just about building smarter systems. It’s about designing them to
collaborate — with people, across platforms, and in real-world messiness.
That’s where I think the future lies: not in building a perfect solo cockpit, but in creating digital GTD ecosystems that are smart enough to adapt, humble enough to yield, and fluid enough to support both personal flow and team alignment — even when those two worlds clash.
