On December 9, 1968, a 43-year-old engineer named Doug Engelbart walked onto a stage at the Joint Computer Conference in San Francisco. He had a mouse in his right hand, a chord keyboard in his left, and a five-camera live video feed to the SRI lab thirty miles away in Menlo Park. For ninety minutes, in a presentation now known as "The Mother of All Demos," he showed a thousand engineers something none of them had seen: two cursors blinking on the same document.
Fifty-eight years later, billions of people open Google Docs every day and expect that exact thing to just work.
This is the story of how it got there — through Lotus Notes, Xerox PARC, Etherpad, Google Wave, Figma, and Taskade Genesis. And why AI agents are about to become the next class of cursor on that same stream.
TL;DR: Real-time collaboration runs in one unbroken line from Engelbart's 1968 NLS demo to today's AI-agent workspaces. The substrate is Operational Transformation (Ellis-Gibbs 1989 → Jupiter 1995 → Wave 2009 → ot-json0 → Taskade Projects 2017+). The receipt is Aaron Iba — Etherpad co-founder, Google Wave engineer, now a Taskade angel investor. AI agents are the new co-editor class on the OT wire. Try Taskade Genesis →
🗺️ 58 Years of Real-Time Collaboration in One Diagram
Six eras. One unbroken line. The next section walks through each.
🎤 1968: Engelbart's Mother of All Demos
The earliest "we should build collaborative real-time editors" memo in computing history is a 1962 SRI proposal by Douglas Engelbart titled "Augmenting Human Intellect: A Conceptual Framework." The thesis was unfashionable in 1962 and stayed unfashionable for decades: the point of computers is not to automate humans away. The point is to make humans collectively smarter.
By 1968 Engelbart and 17 researchers at SRI's Augmentation Research Center (ARC) had built NLS ("oN-Line System") — a hypertext, outline-editing, mouse-driven, video-conferencing, shared-screen workstation. None of those words were in industry vocabulary yet. NLS invented all of them.
On December 9, 1968, Engelbart gave the live demo at Brooks Hall, San Francisco — to approximately 1,000 attendees of the Joint Computer Conference. Two collaborators back at SRI joined over a video feed. They edited the same document. Two cursors. One screen.
┌─────────────────────────────────────────────┐
│ Brooks Hall · San Francisco · Dec 9 1968 │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ Engelbart's NLS screen │ │
│ │ │ │
│ │ Outline: agenda for the demo ▍ │ │
│ │ - Mouse │ │
│ │ - Chord keyboard │ │
│ │ - Hypertext links ▍ │ │
│ │ │ │
│ │ ▍ = Engelbart's cursor │ │
│ │ ▍ = remote SRI cursor (30 mi away) │ │
│ └─────────────────────────────────────┘ │
│ │
│ Audience: ~1000 engineers, 0 prepared │
└─────────────────────────────────────────────┘
The crowd gave a standing ovation. Almost none of them built on what they had seen. It would take twenty years for groupware to ship commercially, and forty years for real-time editing to reach the open web.
Why? Because everything Engelbart built required custom hardware, mainframes the size of refrigerators, and SRI-grade research dollars. The personal computer didn't exist yet. Neither did the local-area network. Neither did the web. Engelbart had seen the destination from the runway.
The unfinished part of the NLS vision — real-time co-editing as the default state of every working document — sat in academic papers for two decades.
📨 1989: Lotus Notes and GROVE — The Year Groupware Split in Two
Two products and one paper appeared in 1989 that would define the next thirty years.
Lotus Notes 1.0 (December 1989)
Ray Ozzie, the engineer who would later become Microsoft's CTO, founded Iris Associates in 1984 specifically to build the kind of integrated workspace Engelbart had demoed. Iris built what became Lotus Notes, which shipped on December 7, 1989. Notes was the first commercial groupware platform — integrated email, threaded discussion, document database, and workflow automation, with replication as the killer feature.
Notes did not use Operational Transformation. It used replicated document databases — your local replica had a full copy; the server reconciled changes overnight or on-demand. This was the right call for 1989: networks were slow, intermittent, and expensive. Replication accepted eventual consistency in exchange for working offline.
The replication camp would become the conceptual ancestor of today's CRDT / local-first lineage. Ozzie himself went on to found Groove Networks (P2P groupware acquired by Microsoft in 2005) and remained an evangelist for replicated, offline-first collaboration into the 2020s.
GROVE and the Birth of OT (1989)
Five months earlier, in May 1989, Clarence Ellis and Simon Gibbs at MCC (Microelectronics and Computer Technology) published a SIGMOD paper called "Concurrency Control in Groupware Systems." The paper defined the dOPT algorithm — the first formal Operational Transformation — alongside a research prototype called GROVE (GRoup OutlinE Viewer, a multi-user outline editor).
The Ellis-Gibbs insight: don't replicate the document, replicate the operations. When two users edit the same document concurrently, instead of waiting for sync, transform each incoming operation against the operations already applied locally so its indices stay correct against the now-current state. Math instead of timing.
OT was the conceptual ancestor of today's Google Docs / Etherpad / Taskade Projects lineage.
1989 quietly forked the river:
This split is still the central choice every real-time collaboration product makes in 2026. We come back to it in the OT-vs-CRDT section.
🧪 1995: Jupiter at Xerox PARC — OT Goes From Paper to Production
The Ellis-Gibbs OT paper was a research curiosity for six years. Then in 1995, David Nichols, Pavel Curtis, Michael Dixon, and John Lamping at Xerox PARC published "High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System" (UIST 1995). Jupiter was the first production-grade OT engine — a working collaborative environment used by the PARC research community.
Three Jupiter contributions are still load-bearing today:
- Central-server linearization. Every client sends ops to a single server; the server orders them globally, transforms each one against the already-applied set, and broadcasts the canonical sequence back. This sidesteps the notoriously hard TP2 problem (correctness under three-way concurrent transforms without a central arbiter) — the same shortcut Google Docs, Etherpad, and Taskade Projects take today.
- OT on structured documents, not just plain text. Jupiter showed OT could be defined for tree-structured documents with attributes, not just character streams. This is what makes rich-text OT possible.
- Lossy networks are fine. OT handles delivery delay, packet loss, and reorder transparently as long as the server is the linearizer. This was the realization that made OT web-compatible before the web was ready.
Three years later, in 1998, Chengzheng Sun and Clarence Ellis published a follow-up that formalized the TP1 and TP2 transformation properties every OT implementation must satisfy. TP1 (transposition over concurrent ops) is essential and provable. TP2 (transposition convergence under three-way concurrency) is what every decentralized OT algorithm gets wrong — and what every academic CRDT paper since has used as motivation for switching paradigms.
The OT lineage was now technically complete. Just nobody had built a consumer product on it.
🌐 2005–2008: Writely, Google Docs, and the First Wave of Web Editors
By the early 2000s the web was finally fast enough for OT. A three-person startup called Upstartle built Writely, a browser-based collaborative editor, in early 2005. Writely's editor wasn't using full OT — it used a coarser "diff and merge on save" approach — but it was the first time most users had seen multiple cursors in a web document.
Google acquired Writely in October 2006 and rebranded it as Google Docs. Concurrent editing — the full OT version, on a central server linearizer — landed publicly in April 2010. Once Google Docs was real-time, the rest of the web had to catch up.
Meanwhile in Boston, a different team was racing Google to the same finish line.
✍️ 2008: Etherpad — The Editor That Taught Google How to Collaborate
In November 2007, three engineers in Boston — Aaron Iba (MIT '05, Mathematics), David Greenspan, and J.D. Zamfirescu — founded AppJet, a JavaScript developer-tooling startup. As the side-project demo for AppJet's serverless JS runtime, they built a real-time collaborative pad.
On November 19, 2008, that pad launched publicly as Etherpad — and immediately ate Google Docs' lunch on a single dimension: character-by-character live sync. Google Docs at the time had a ~15-second sync lag. Etherpad's lag was unmeasurable to the naked eye. Each character keystroke arrived at every collaborator's screen as fast as the network could carry it.
Etherpad's OT engine — internally called Easysync / Changeset library — was the third production OT engine in industry history (after Wave's predecessor work at Google and Jupiter at PARC). Three operators (= retain, - delete, + insert), an interned attribute pool for rich-text spans, central-server linearization. Conceptually simple, ruthlessly fast.
Etherpad keystroke flow · 2008
===================================== Alice types "h" Bob types "s"
│ │
▼ ▼
insert("h", 1) insert("s", 3)
│ │
▼ ▼
┌──────────────────────────────────┐
│ Etherpad central server │
│ 1. Apply Alice op first │
│ 2. Transform Bob op │
│ → insert("s", 4) │
│ 3. Broadcast canonical sequence │
└──────────────────────────────────┘
│ │
▼ ▼
"chats" shown "chats" shown
Etherpad's reception was rapturous. Journalists, programmers, Wikipedia editors, and student study groups adopted it within months. By mid-2009 it was a real category — the "real-time Google Docs killer."
Then Google bought it.
On December 4, 2009, Google announced the acquisition of AppJet. Aaron Iba, David Greenspan, and J.D. Zamfirescu joined the Google Wave team in Sydney. Etherpad was scheduled for shutdown. The community erupted. Google reversed course, open-sourced Etherpad under Apache 2.0 on December 17, 2009, and ran the hosted service through March 2010.
The open-source release birthed Etherpad Lite — a Node.js rewrite by Peter Martischka beginning in 2011 — which eventually became the canonical Etherpad. The project lives today at github.com/ether/etherpad-lite with roughly 18.3K stars, 290+ community plugins, deployed at Wikimedia, Mozilla, the European Commission, and thousands of universities and newsrooms.
Aaron Iba's other career chapters:
- 2011: One of six full-time Y Combinator partners
- 2013: Left YC to found PayGarden (alternative payments)
- Later: Co-founder of Matrix Operations (high-frequency trading infrastructure, NYC/London)
- Today: Angel investor — including in Taskade, where his fingerprints are visible in the OT-driven Project editor
We come back to Iba in the lineage-receipt section. First, Wave.
🌊 2009–2010: Google Wave's Rise and Fall — and the OT Diaspora
When Google acquired Etherpad in December 2009, the Etherpad team was added to a much larger Google product: Google Wave, which had previewed at Google I/O on May 28, 2009 to a ten-minute standing ovation. Wave was an even more ambitious bet than Etherpad — email + chat + wikis + social + embedded "robots" + federation across servers, all on a much richer OT engine.
The Wave team had been led inside Google by brothers Lars and Jens Rasmussen (the Google Maps founders). The OT engine itself had been built up over multiple years and inherited Jupiter's lineage. Adding the Etherpad team poured the open-web Easysync expertise into Wave's enterprise-Google-scale platform.
Then the product failed.
Wave shut down in August 2010 after fifteen months — the canonical post-mortem is covered in detail in our Google Wave Lessons post. Four reasons:
- No focused use case. Wave tried to replace email, chat, wikis, and social all at once.
- Invite-only rollout fragmented the network. Group features arrived seven months late.
- Empty-Wave onboarding. Users opened Wave and didn't know what to type.
- Per-keystroke performance felt slow on 2009 home internet.
The product died. The technology diaspora-ed throughout the industry:
| Wave engineer | Where they went | What they built |
|---|---|---|
| Joseph Gentle | Independent | ShareJS → ShareDB → ot-json0 → Diamond Types |
| David Greenspan | Meteor | Meteor JS framework |
| Aaron Iba | Y Combinator → PayGarden → Matrix Operations → angel investing including Taskade | Lineage carrier |
| Lars Rasmussen | Facebook Search | |
| Stephanie Hammond | Quip | Quip (acquired by Salesforce 2016) |
Joseph Gentle's path matters most for this story. He extracted Wave's OT primitives into open source and published a series of blog posts ("Implementing OT sucks" in 2011; "I was wrong. CRDTs are the future" in 2020) that became the definitive practitioner literature on collaborative editing. Gentle's ot-json0 is the JSON OT type Taskade's Project editor runs on today.
The Apache Software Foundation took over Wave's federation protocol as Apache Wave in 2010 and retired it in 2018 after little community uptake. Wave's threaded reply model influenced Slack threads and Quip; Wave's "playback" timeline became Google Docs version history; Wave's "gadgets" became Slack apps, Notion blocks, and Taskade Genesis Apps.
📐 2011: CRDTs Become Real — The Other Side of the River
While Joseph Gentle was extracting Wave's OT into ShareJS, a different research thread was reaching the production stage on the other side of the 1989 fork. In May 2011, Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski at INRIA published "Conflict-free Replicated Data Types" (technical report RR-7687, then SSS 2011 conference paper). The paper coined the term CRDT and proved that a class of data types could converge under arbitrary network delivery without a central arbiter — solving the TP2 problem OT had been wrestling with since 1998.
CRDTs were the academic fulfillment of Ray Ozzie's 1989 Lotus Notes replication thesis — formally proved correct, generalized to arbitrary data types, designed for peer-to-peer operation.
A different practitioner thread spun up immediately:
- 2006: Oster et al. publish WOOT (the first text CRDT, from INRIA)
- 2009: Logoot algorithm (Weiss/Urso/Molli) — fractional position IDs
- 2011: Shapiro CRDT paper + RGA algorithm (Roh et al.)
- 2016: YATA (Yet Another Transformation Approach) — Kevin Jahns; basis for Yjs, the most-deployed text CRDT today
- 2017: Automerge — Martin Kleppmann's JSON CRDT
- 2022: Peritext — Ink & Switch / Kleppmann; rich-text CRDT with inline-formatting intent preservation
- 2023: Diamond Types — Joseph Gentle's ~5,000× speedup over earlier CRDTs
CRDTs unlocked a new category: local-first software. The 2019 Ink & Switch essay "Local-first software: You own your data, in spite of the cloud" by Kleppmann et al. crystallized the design principles — keep data on the user's device, work offline, sync when networks are present, preserve user ownership and longevity.
By 2026, CRDT-powered products include Yjs (running in Tiptap, Hocuspocus, thousands of editors), Automerge-based apps, Figma multiplayer (custom tree-CRDT-ish), Linear sync engine, Obsidian Sync, and Apple Notes.
OT and CRDT both deliver eventual consistency. They differ in where the correctness lives. We do the engineering deep-dive in our OT vs CRDT sister post.
🎨 2015–2019: Figma Forks the Road; Sync Becomes Infrastructure
If 2009-2014 was the OT-vs-CRDT split going from academic to practical, 2015-2019 was the sync-engine era — the years when real-time collaboration moved from being a product feature to being infrastructure.
Figma: The Custom Tree-CRDT (2015-2019)
Figma publicly launched its design tool in October 2016. Internally it had been operating since 2015. CTO Evan Wallace published a now-canonical engineering post in October 2019 explaining Figma's multiplayer architecture.
Wallace's key design decision: Figma did not use Operational Transformation. A design document is a tree of objects (frames, layers, components, styles) — not a text document. Figma chose a custom Last-Writer-Wins-Register (LWW) system where each object property gets the latest update keyed by a client clock. Effectively a tree-CRDT shaped to a design tool's workload.
Figma's trade-off: simpler implementation, no OT transform-pair combinatorics, but LWW can "lose" concurrent edits to the same property. For design files this is acceptable because designers rarely fight over the same exact pixel-level property at the same exact moment. For text, LWW would be unusable.
Figma's choice is still cited as the counterexample whenever someone claims OT or CRDT is universally superior. It's workload-shaped.
Notion, Linear, Liveblocks (2018-2022)
In the same window, three other notable systems emerged:
- Notion: Hybrid OT-for-text + LWW-for-property approach. Live cursors became visible in 2019.
- Linear: Custom sync engine that pulls deltas from a server with offline support. Closer to CRDT semantics; the Liveblocks teardown covers it well.
- Liveblocks: Real-time collaboration as a service — sync infrastructure that other products embed. Both OT and CRDT primitives in the same SDK.
Sync was no longer a feature. It was a substrate every product was expected to ship.
🧬 2017–2025: Taskade Projects — The OT Substrate, Built For Workspaces
Taskade entered this lineage in 2017, founded by John Xie, Dionis Loire, and Stan Chang. The thesis was different from Figma's design-tool angle and different from Notion's block-document angle: the outline is the foundational primitive of work, and the outline needs seven views (List, Board, Calendar, Table, Mind Map, Gantt, Org Chart) on one collaborative substrate.
The substrate choice mattered. Taskade Projects is built on ot-json0 — Joseph Gentle's open-source JSON OT type, the direct descendant of the Wave OT engine. Two custom subtypes are registered on top:
Delta— Quill's rich-text format, used for any rich-text leaf in a Project node (card descriptions, doc blocks)Text0— the simpler plain-text OT subtype, used for short fields like titles
The Taskade OT engine adds custom changeset compose/transform/invert machinery and a randomized TP1 fuzzer for correctness testing on top of the public ot-json0 library. The engine has been running in production since 2017, transforming hundreds of millions of operations per month inside Taskade Projects.
The architectural payoff is what makes the next chapter possible: because the engine is OT-driven and clients are just "things that send operations into the stream," AI agents become a new class of client without changing the substrate.
🤖 2025–2026: AI Agents Join the OT Stream — Taskade Genesis
In October 2025, Taskade launched Genesis — a Workspace DNA-based system that turns one prompt into a live dashboard, portal, form, or app. Under the hood, Genesis is the substrate completing Engelbart's 1968 vision: multiple intelligences (human and AI) editing the same document in real time, with the document itself being a runnable system.
Genesis Capability Map — From the May 2026 Newsletters
The full Taskade Genesis surface was rolled out chapter by chapter across the recent Taskade newsletters. Six surfaces, every one of them a thing every prior generation of collaborative software wanted to ship:
| Newsletter chapter | What Taskade ships | Engelbart 1968 → 2026 analogue |
|---|---|---|
| Workspace Memory · Mind Graph | Workspace-scoped knowledge graph visualizing how Memory, Intelligence, and Execution interconnect | NLS hypertext outline, finally with a brain |
| Agent Workflows · Tools Wired | Agents with 22+ built-in tools (web search · file editing · image generation · web fetch · agent-to-agent · slash commands · MCP) + 100+ integrations | Engelbart's "augmenting human intellect" with non-human collaborators |
| App Payments · Stripe Live | Native Stripe Checkout actions inside Genesis Apps | Wave's "gadgets" with native commerce |
| Frontier Models · Auto-Routed | Frontier models from OpenAI, Anthropic, Google plus open-weight providers, auto-routed by plan tier | The AI half no prior workspace shipped |
| Embed Apps · Anywhere | Every Genesis App embeds as a responsive widget on any site with per-app permissions | Wave's federation, finally working |
| Clone Apps · Instantly | 150,000+ apps in the Community Gallery; clone any in 60 seconds and remix | HyperCard's stack-swap, AI-native |
Plus the five vibe surfaces — Vibe Coding · Vibe Payments · Vibe Workflows · Vibe Marketing · Vibe Tracking — and MCP both sides (Taskade-as-Server for Claude Desktop / Cursor / VS Code, Taskade-as-Client for external Notion / Linear / Salesforce). MIT Technology Review named vibe coding a "breakthrough technology of 2026." Genesis shipped 198 platform releases in 2026 alone.
Humans, AI Agents, the meta-agent EVE, and 100+ external integrations all submit OT changesets to one stream. Every keystroke (human or agent) is auditable, undoable, and ordered. There is one document, one history, one OT engine — and four classes of co-editor.
Workspace DNA: Memory → Intelligence → Execution
Taskade Genesis frames the runtime as Workspace DNA: a self-reinforcing loop where Memory (Projects) feeds Intelligence (Agents), Intelligence triggers Execution (Automations), Execution writes back to Memory.
- Memory — every project is a living context: data + relationships + history. The OT engine guarantees every edit (human or agent) is captured in causal order.
- Intelligence — AI Agents v2 with 22+ built-in tools (web search, file editing, image generation, slash commands, web fetch, project read/write, agent-to-agent, MCP tool calling), persistent memory that accumulates expertise across sessions, custom tools via the Model Context Protocol.
- Execution — Automations across 100+ bidirectional integrations (Slack, Stripe, Notion, GitHub, Shopify, Salesforce, Calendar, Linear, Monday, Airtable, Telegram, RSS, Webhooks). Triggers pull external events in; Actions push data out. Durable execution so workflows automatically retry and never silently fail.
EVE: The Meta-Agent on the Wire
EVE ("Entity of Vision & Execution") is Taskade's meta-agent — reading the entire workspace DNA, orchestrating work across all four DNA strands (Memory, Intelligence, Execution, Media). EVE itself stores its persistent memory as Taskade Projects in a projects/memories folder — the platform eats its own dogfood. EVE writes through the same OT engine humans and agents use; her edits are interleaved in causal order with everyone else's.
Genesis Apps: One Prompt, One App, Seven Minutes
Where Wave's "gadgets" needed Java developers and Notion's blocks need template builders, Genesis takes a sentence:
| You say... | Genesis builds (in ~7 minutes) |
|---|---|
| "Customer feedback app with sentiment analysis and Slack alerts" | Ratings DB + photo uploads + AI sentiment + manager Slack alerts + follow-up workflows |
| "Booking system for my coaching practice with Stripe checkout" | Real-time scheduling + payments + confirmations + customer history |
| "CRM for inbound leads with AI qualification" | Multi-source capture + AI scoring + automated nurturing + pipeline tracking |
| "Onboarding portal for new hires" | Forms + equipment provisioning + training checklists + document collection |
| "Help desk with AI routing and SLA tracking" | Ticket submission + AI categorization + KB integration + SLA timers |
| "Team Knowledge Base with mind-map visualization" | Wiki database + ask-the-wiki agent + Mind Graph visualization |
150,000+ apps have been built since Genesis launched. 3 million automations have been executed. MIT Technology Review recognized vibe coding — building applications through natural language — as a "breakthrough technology of 2026."
Real-Time Workspace Workflows
Recent Taskade newsletters laid out the full feature surface. The 2026 capabilities map:
- Workspace Memory · Mind Graph — workspace-scoped knowledge graph visualizing how Memory, Intelligence, and Execution interlink
- Agent Workflows · Tools Wired — agents call 22+ built-in tools + 100+ integrations via slash commands and natural language
- Frontier Models · Auto-Routed — frontier models from OpenAI, Anthropic, and Google plus open-weight providers, auto-routed by plan tier
- App Payments · Stripe Live — native Stripe Checkout actions in Genesis Apps
- Embed Apps · Anywhere — every Genesis App embeds as a responsive widget on any site
- Clone Apps · Instantly — 150K+ apps in the Community Gallery; clone any in 60 seconds
- Vibe Coding — describe apps in plain language → instant builds
- Vibe Payments — Stripe-powered flows triggering automations
- Vibe Workflows — forms and requests creating automated processes
- Vibe Marketing — content aggregation and cross-platform publishing
- Vibe Tracking — leads and data synced across tools via webhooks
- MCP both sides — Taskade-as-Server (Claude Desktop, Cursor, VS Code can drive your workspace) and Taskade-as-Client (your agents call external Notion/Linear/Salesforce MCP servers)
📊 How Taskade Genesis Compares to Today's Real-Time Editors
Every product in this lineage made a substrate bet. Here is the 2026 scorecard across the four most-deployed real-time workspaces:
| Capability | Taskade Genesis | Google Docs | Notion | Etherpad |
|---|---|---|---|---|
| Sync engine | OT (ot-json0 + Quill Delta + Text0 subtypes) |
OT (proprietary, Wave-derived) | Hybrid OT-for-text + LWW-for-property | OT (Easysync / Changeset library) |
| Lineage receipt | Aaron Iba on cap table · ot-json0 from Joseph Gentle (ex-Wave) |
Built by ex-Wave engineers internally | No public OT lineage | Aaron Iba co-founded the codebase |
| AI agents as co-editors | Custom Agents v2 + meta-agent EVE editing the same OT stream | Gemini sidebar (assistive, not a co-editor) | Notion AI block (one-shot completion) | None (community plugins only) |
| Built-in automations | 100+ bidirectional integrations · Temporal durable execution · triggers pull events in, actions push data out | None native (third-party Apps Script) | Limited (Buttons, basic triggers) | None |
| Memory persistence | Workspace DNA · Memory → Intelligence → Execution loop · agents accumulate expertise across sessions | Per-doc only; no agent memory | Per-page; no agent memory | Per-pad only |
| Embed / clone the app | Genesis Apps embed anywhere · 150K+ in Community Gallery · clone in 60 seconds | Docs embed read-only | Public pages embed; templates clone | Pads embed read/write |
| Project views | 7: List · Board · Calendar · Table · Mind Map · Gantt · Org Chart (Timeline lives inside Gantt) | 1 (document) | Many database views | 1 (pad) |
| RBAC | 7 tiers: Owner · Maintainer · Editor · Commenter · Collaborator · Participant · Viewer | 3 (Editor / Commenter / Viewer) | 4 (Full / Edit / Comment / Read) | Plugin-dependent |
| MCP both sides | Yes — Taskade-as-Server (Claude Desktop / Cursor / VS Code) + Taskade-as-Client (external Notion / Linear) | No | No | No |
| Models | 15+ frontier models from OpenAI, Anthropic, Google plus open-weight providers, auto-routed by plan | Gemini only | Anthropic + OpenAI (chat only) | None |
| Annual pricing (paid entry) | $6/mo Starter · $16/mo Pro · $40/mo Business | $7/mo Workspace Business Starter | $10/mo Plus · $15/mo Business | Free self-host · hosted varies |
The takeaway: only one of these four ships agents, automations, and the OT lineage receipt on the same substrate. Google Docs has the OT engine but not the agents-as-co-editors model. Notion has the workspace but not the OT pedigree or the cloneable-app surface. Etherpad has the open-source receipt but not the AI layer. Taskade Genesis carries all four.
🧾 The Lineage Receipt: Aaron Iba on the Taskade Cap Table
Most lineage claims in tech writing are metaphors. The Etherpad → Google Wave → Taskade lineage is a cap-table receipt.
One person carried the same architectural conviction across three companies and eighteen years:
- Etherpad (2008) — co-founder. Shipped the first character-by-character real-time web editor.
- Google Wave (2009-2010) — engineer. Joined Google in the AppJet acquisition. Helped extend OT to richer document semantics.
- Taskade (2017-2025+) — angel investor. Taskade Projects runs on
ot-json0, the open-source descendant of the Wave OT engine. The Genesis launch pitch deck (slides 04 and 12) lists Iba explicitly as the workspace-lineage angel.
If you ask "who else has built three generations of real-time collaboration substrate?" the list is small. Iba is on it. Ray Ozzie is on it. Joseph Gentle is on it. Engelbart, who started everything, didn't live long enough to see his vision shipped on AI agents (he passed in 2013) — but his actual fingerprints are in the outline model NLS demoed, which is the same outline model Taskade ships today.
🪞 What Engelbart Was Actually Asking For — and What We've Finally Shipped
Engelbart's 1962 SRI paper titled "Augmenting Human Intellect: A Conceptual Framework" is worth rereading in 2026. The thesis wasn't "build a multi-user text editor." The thesis was much bigger:
"By 'augmenting human intellect' we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. ... We do not speak of isolated clever tricks that help in particular situations. We refer to a way of life in an integrated domain where hunches, cut-and-try, intangibles, and the human 'feel for a situation' usefully co-exist with powerful concepts, streamlined terminology and notation, sophisticated methods, and high-powered electronic aids." — Doug Engelbart, 1962
He was describing a workspace where humans and machines collaborate as peers on complex thinking, with the workspace itself remembering, reasoning, and acting.
What he was missing:
- The web. Real-time collaboration needs a network everyone is on.
- Cheap compute. OT engines on 1968 mainframes were research curiosities; OT on 2009 networks barely worked; OT on 2026 cloud is invisible.
- AI as the second class of collaborator. Engelbart imagined the augmentation as software amplifying humans. He didn't imagine the augmentation could be a coworker.
Taskade Genesis ships all three. Humans, AI agents, and EVE the meta-agent edit one OT-driven workspace, with memory and execution closing the loop back into more memory. The 58-year vision is shipping.
🔮 What's Next: 2026–2030
The next chapter of real-time collaboration:
| Trend | What it means | Where it shows up |
|---|---|---|
| Agents-on-OT-wire | AI agents as first-class co-editors with the same OT primitives humans use | Taskade Genesis · ServiceNow Action Fabric · GitHub Copilot Workspace |
| MCP everywhere | One protocol for any agent to call any tool / data source | Anthropic Claude · OpenAI · Taskade MCP both sides · ServiceNow AI Agent Fabric |
| Hybrid OT+CRDT | OT for structure, CRDT for offline / local-first features, on one substrate | Linear · Notion · likely Taskade roadmap |
| Workspace DNA as standard | Memory + Intelligence + Execution loop on every productivity surface | Taskade · ServiceNow Otto · OpenAI personalization |
| Rich-text CRDT matures | Peritext-style algorithms become production-grade | Yjs ecosystem · Automerge 3.x · Tiptap |
| Live cursors on AI agent edits | You see EVE typing in real time, not just outputs | Taskade Genesis demo · GitHub Copilot Workspace |
| One prompt → embedded app | The Wave "gadget" thesis ships at consumer scale | Taskade Genesis Apps · Notion AI Blocks |
The pattern is consistent: the substrate hasn't changed since 1968. The participants have multiplied.
🔗 Further Reading
- Google Wave Lessons: OT Internals + Aaron Iba Lineage — the failed product whose engine survived
- OT vs CRDT: The Two Algorithms Behind Every Real-Time App — engineering deep-dive
- History of Etherpad: How Aaron Iba's Open-Source Editor Shaped the Modern Web — the pre-Wave story
- History of ServiceNow: From Fred Luddy's $35M Comeback to AI Control Tower — enterprise workflow lineage
- History of Mermaid.js: Diagrams as Code — sister piece on developer tooling lineage
- What is OpenAI? Complete History — the AI side of the lineage
- History of Computing: From Binary to AI Agents — the hardware-side parallel
- Outlining Software: Past, Present, and Future — the data-structure lineage
❓ Frequently Asked Questions
When did real-time collaboration start?
December 9, 1968 — Doug Engelbart's "Mother of All Demos" at the Joint Computer Conference in San Francisco. Two cursors editing the same document, live over a 30-mile video link. Most of the rest of the history is execution.
Why are Google Docs, Etherpad, and Taskade Projects all built on OT?
Because all three are server-mediated, online-first, rich-text products where a central server is acceptable (and useful for auth, permissioning, and audit). Operational Transformation works extremely well for that workload — the rich-text semantics are 15 years more battle-tested than CRDT rich-text, the wire format is smaller, and TP2 (the hard decentralized-OT problem) is sidestepped by central linearization.
Why are Figma, Linear, and Yjs apps built on CRDT?
Because they need peer-to-peer or offline-first behavior, or because their document is a tree of structured objects (Figma) rather than a stream of text. CRDTs make eventual consistency mathematical rather than coordination-based, which is exactly what local-first software needs.
Is Taskade local-first?
No. Taskade is server-mediated by design. AI agents are server-side participants who need a central authority for permissioning, audit trails, and durable execution. Local-first is the right answer for some product categories (notes, design files, certain dev tools); workspace + AI-agent collaboration is not one of them.
What is EVE in Taskade Genesis?
EVE ("Entity of Vision & Execution") is the Taskade meta-agent — the central AI system that reads your entire Workspace DNA (Projects, Agents, Automations, Files) and orchestrates work across all of them. EVE writes through the same OT engine humans and agents use; her edits are interleaved with everyone else's in causal order. EVE stores her own persistent memory as Taskade Projects — the platform dogfoods itself.
Can I read the original Engelbart demo?
Yes. The full 1968 video is on YouTube and the Doug Engelbart Institute's site preserves transcripts, source documents, and the "Augmenting Human Intellect" paper. It remains, sixty years later, the single most important read in the history of collaborative software.
What is MCP and how does it relate to this?
The Model Context Protocol (MCP) is a 2024 open standard for AI agents to call external tools and data sources — Anthropic's protocol that has been adopted by OpenAI, Google, ServiceNow, and Taskade among others. MCP is the substrate that lets agents become first-class participants in real-time workspaces. Taskade plays both sides — Taskade-as-Server (Claude Desktop, Cursor, VS Code can drive your Taskade workspace) and Taskade-as-Client (your Taskade agents call external Notion / Linear / Salesforce MCP servers). MCP is the API equivalent of Wave's federation protocol — fifteen years later and actually working.
What is Workspace DNA?
Taskade's framing for the runtime loop: Memory (Projects) feeds Intelligence (Agents), Intelligence triggers Execution (Automations), Execution writes back to Memory. A self-reinforcing loop that distinguishes "living software" (Taskade Genesis Apps) from static templates and one-shot AI outputs.
What is the "lineage receipt"?
The verifiable evidence that Taskade is a direct continuation of the Engelbart → Etherpad → Wave OT lineage, not a marketing claim. The receipt has three components: (1) the Taskade Project editor runs on ot-json0, the open-source descendant of the Wave OT engine; (2) ot-json0 was extracted by Joseph Gentle, a Wave engineer; (3) Aaron Iba (Etherpad co-founder, ex-Wave) is an angel investor in Taskade. Three engineering and capital primary sources, not a metaphor.
Where can I try Taskade Genesis?
Taskade Genesis is free to start at /create. Free tier includes Genesis apps and live agents; paid tiers (Starter $6/mo, Pro $16/mo, Business $40/mo) unlock more credits, more agents, MCP support, and additional integrations. 150,000+ apps have been built since launch.
