MindsEye x Google AI Stack, Part 2 — 200 Users, Ledgers as “Soft Blockchain”, and the OS Vision

In Part 1
, I walked through the six repositories that make up my MindsEye x Google AI stack:

Workspace automation

Ledger (Prompt Evolution Tree + runs)

Gemini orchestrator

Devlog generator

Analytics

Workflow atlas

All of that was basically:

“Here’s the skeleton. Here’s how each bone connects.”

In this post, I want to zoom out and talk about how this behaves when it’s not just me using it, but ~200 people, each with their own prompts, workflows, and experiments.

Specifically:

How the ledger behaves like a soft blockchain

How users stay isolated but still learn from each other

How Gemini (Jimin) becomes the orchestrator/kernel

Why this starts to look suspiciously like an Android-style OS built on Google Workspace

From “My Stack” to “200-User MindsEye OS”

Part 1 was written from a solo-builder perspective.

But the design isn’t actually single-user. It’s intentionally structured so it can scale to something like:

200 people

across multiple teams

all using the same six-repo stack

all sharing the same Google Workspace surfaces

The key shift:

It stops being “my scripts” and becomes a shared operating system:

MindsEye OS running on Google Workspace + Gemini.

Everyone still has their own flows, but they all land in a shared ledger that knows:

who did what

with which node

in which context

at what time

And that’s where the “soft blockchain” idea comes in.

1. The Ledger as a Soft Blockchain (Without Crypto, With Memory)

The mindseye-google-ledger repo defines:

a nodes sheet (Prompt Evolution Tree)

a runs sheet (every execution of those nodes)

When 200 people use it:

Each person effectively grows their own subtree of the PET.

Each run is append-only: you don’t edit history, you add new facts.

Node ownership is tracked (owner, team, created_by).

Runs are timestamped and tied to nodes via node_id.

You can start to think about it like this:

Nodes = blocks of intent / design

Runs = transactions / state updates

Ledger = chain of decisions and experiments over time

It’s not a blockchain in the crypto sense (no consensus algorithm, no miners), but it is:

immutable in practice (you don’t rewrite past runs)

multi-tenant (200 people writing to the same structure)

auditable (Sheets history + Git history)

pattern-rich (you can learn from the whole thing)

The important part:

People never overwrite each other’s data.
They write next to each other in time, and MindsEye learns over that timeline.

1. How 200 Users Actually Interact With the Ledger

Here’s the mental model I’m designing for:

3.1 Personal Branches, Shared Universe

Each user:

submits ideas via Forms

labels emails in Gmail

uses Docs menus like “Send to MindsEye”

triggers runs against specific PET nodes

Those actions:

create nodes with owner = that user

append runs scoped to that node

generate linked Docs per node (prompt docs, notes, etc.)

So each person effectively has:

their own PET branch (or several)

their own run history

their own Docs attached to nodes

But all of those live in the same global ledger, with:

owner, team, tags, status

protected columns vs editable ones

per-team views and filters

This gives you:

a single source of truth

multiple personal “worlds” inside it.

3.2 Cross-User Interaction: Patterns, Not Raw Data

The interesting part isn’t “user A can see user B’s cells.”

It’s that Gemini / analytics can see everyone’s patterns, and then:

recommend structure

highlight similar nodes

surface “this pattern worked well in team X”

suggest merges or variants

So instead of:

“Here, use Bob’s exact prompt.”

you get:

“Other users who had a node like this tried three variations – here’s the pattern and the metrics. Want to branch from that?”

Data stays owned and scoped, but intelligence is shared.

Jimin (Gemini) as Kernel: Orchestrating the Whole Mesh

Right now, the orchestrator is “mostly skeleton” because I don’t have paid Gemini access yet. But architecturally, its role is clear:

4.1 What Jimin Does in the Stack

Inside mindseye-gemini-orchestrator, Jimin is meant to:

Listen to the ledger

pull candidate nodes to run (e.g. status = ready_for_run)

read node metadata, linked docs, past runs

Execute

call Gemini (or other Google AI)

generate outputs, scores, notes

Write Back

append new runs to runs

update aggregate fields (avg_score, last_run, etc.) in nodes

Suggest

propose new child nodes (“this looks like it needs a variation”)

flag underperforming branches

cluster similar prompts across users/teams

Once API & cloud access are in place, this becomes the kernel of MindsEye OS:

it sits between Workspace and the ledger

enforces structure

drives experimentation

maintains the time-labeled memory.

1. How This Looks in Practice (Very Concrete)

For a 200-user environment, the UX I’m aiming at looks something like this:

5.1 For Devs / Data People

GitHub access to all 6 repos

Clear Typescript/Sheets schema for Node and Run

Workflow YAMLs in mindseye-google-workflows that describe the full graph

Read/write access to ledger Sheets (with protected ranges)

They use MindsEye OS like:

an integration + experimentation framework

a time-aware datastore

a playground for Gemini orchestration

5.2 For Product / Ops / Biz Folks

Google Form to create new nodes (“New experiment” / “New AI flow idea”)

Google Sheets filtered to:

their team’s nodes

their active experiments

Google Docs per node:

prompt text

expectations

notes

Devlogs auto-generated weekly:

“what happened with your prompts this week?”

They use MindsEye OS like:

a living experiment ledger

a source of weekly narrative (“what did we try?”)

a way to see impact via analytics dashboards

5.3 For Leadership / Stakeholders

Looker Studio dashboards:

total nodes, total runs

active vs inactive branches

success rate per team

most active workspaces (Gmail/Docs/Forms/etc.)

Optional rollup Docs:

“MindsEye OS sprint summary”

“Prompt evolution in Q4”

They use MindsEye OS like:

instrumentation for the org’s AI efforts

a way to see which teams are really experimenting vs talking about AI.

1. The OS Analogy: Android, But Built on Workspace

This is the part I’m honestly most excited about.

The more I sketch this, the more it feels like a small, weird operating system:

6.1 Layers (Very Roughly)

Hardware Layer → Google Workspace surfaces

Gmail, Docs, Sheets, Forms, Drive, Calendar

Kernel Layer → Jimin (Gemini orchestrator)

handles events, scheduling, execution, writes to ledger

System Services → the 6 repos

automation, ledger, orchestrator, devlog, analytics, workflows

Application Framework → team-specific PET branches & workflows

how each team uses prompts + flows

Apps / UI →

Sheets views

Docs menus

Forms

Looker dashboards

future MindsEye Android / AppSheet apps

Android coordinates hardware + apps.
MindsEye OS coordinates Workspace + users + Gemini.

1. A Rough Architecture Diagram (Mermaid)

For visual thinkers, here’s a sketch of the MindsEye OS stack in Mermaid.
You can plug this into GitHub / Dev.to if you enable Mermaid support:

flowchart TB
subgraph Users[200 Users / Teams]
U1[User A
PET branch]
U2[User B
PET branch]
U3[User C
...]
end

subgraph Workspace[Google Workspace]
  GMail[Gmail]
  GDocs[Docs]
  GSheets[Sheets<br/>Ledger]
  GForms[Forms]
  GDrive[Drive]
  GCal[Calendar]
end

subgraph OS[MindsEye OS (6 Repos)]
  subgraph WA[mindseye-workspace-automation]
    WA1[Apps Script listeners]
    WA2[Event normalizer]
  end

  subgraph LEDGER[mindseye-google-ledger]
    Nodes[(nodes sheet)]
    Runs[(runs sheet)]
  end

  subgraph ORCH[mindseye-gemini-orchestrator]
    OR1[Selector]
    OR2[Gemini / Jimin]
    OR3[Run logger]
  end

  subgraph DEVLOG[mindseye-google-devlog]
    D1[Devlog generator]
  end

  subgraph ANALYTICS[mindseye-google-analytics]
    A1[Stats engine]
    A2[Dashboards]
  end

  subgraph WF[mindseye-google-workflows]
    WF1[Workflow YAML]
    WF2[Portal maps]
  end
end

%% Users → Workspace
U1 --> GMail
U1 --> GDocs
U1 --> GForms
U2 --> GMail
U3 --> GDocs

%% Workspace → Automation
GMail --> WA1
GDocs --> WA1
GForms --> WA1
GDrive --> WA1
GCal --> WA1

WA1 --> WA2 --> Nodes
WA2 --> Runs

%% Orchestrator loop
OR1 --> Nodes
OR1 --> Runs
OR1 --> OR2
OR2 --> OR3 --> Runs

%% Devlog / Analytics
D1 --> Nodes
D1 --> Runs

A1 --> Nodes
A1 --> Runs
A1 --> A2

WF1 -. describes .- WA
WF1 -. describes .- ORCH
WF1 -. describes .- DEVLOG
WF1 -. describes .- ANALYTICS

This is the “200 users on one OS” picture in my head.

1. What’s Next?

I see three main directions from here:

Make it more real for teams

better Sheets views & protected ranges

role/permission patterns for org use

workspace templates for “plug-and-play” teams

Wire in Gemini properly

Jimin as a real orchestrator

configurable models per node

auto-summarization and branch suggestions

Ship a MindsEye Android / AppSheet frontend

mobile UI for nodes, runs, devlogs

notifications on key events

one-tap “run this node again” actions

1. Closing

Part 1 was the what.
This Part 2 is more about the how it behaves when people actually live in it.

The ledger becomes a soft blockchain of experiments.

Gemini (Jimin) becomes the kernel.

The six repos form the system services.

Google Workspace becomes the hardware and window system.

200 people can work inside it without stepping on each other, while still learning from the shared patterns.

If you want to fork it, adapt it to your team, or co-build parts of this, I’m super open to collaboration.

Drop a comment or ping me — happy to go deeper into any part of the stack.