Day 1: I wanted to build a better AI agent.
Day 5: I accidentally designed an operating system.
In Part 1, I shared how the 5-Day AI Agents Intensive with Google and Kaggle pushed me to see agents not as scripts, but as architectures.
In Part 2, I’ll walk through:
How my understanding of agents evolved again
How my original 6-repo MindsEye system turned into a 7-repo MindsEye OS
Why I introduced LAW-T (Law of Time) and LAW-N (Law of Network)
And how Google Workspace + Gemini + Node.js now fit into one coherent ecosystem
Key Learnings That Stayed With Me
The course kept circling back to a few big principles that changed how I design systems:
🎯 Agents are event-driven, not always-on
Agents shouldn’t run 24/7 “just in case.”
They should wake up when something meaningful happens: an email label, a file change, a user action.
🧠 Memory is the center, not an optional add-on
A stateless agent is a toy.
An agent with structured, queryable memory becomes a system that can actually evolve.
🔧 Tools are capabilities, not cages
It’s not “this is a Docs bot.”
It’s: “this agent has Docs capability when it needs it.”
👥 Multi-agent ecosystems beat single-agent monoliths
Small, focused components that share state will always scale better than one giant “do everything” agent.
Those ideas started as theory in the course.
Then they became the backbone of what I built.
Generation 1 — The Original 6 MindsEye Repos
Right after (and during) the intensive, I built a Google-native agentic system across six repos. These are still live and still important:
mindseye-workspace-automation → Perception & ingestion
🔗 https://github.com/PEACEBINFLOW/mindseye-workspace-automation
Captures events from Gmail, Docs, Drive, Forms using Apps Script and normalizes them into a unified shape.
mindseye-google-ledger → The prompt & run ledger
🔗 https://github.com/PEACEBINFLOW/mindseye-google-ledger
A time-labeled “soft blockchain” of nodes (ideas/prompts) and runs (executions/results) built on Google Sheets.
mindseye-gemini-orchestrator → Reasoning kernel (planned)
🔗 https://github.com/PEACEBINFLOW/mindseye-gemini-orchestrator
A Node.js orchestrator designed to route nodes + context into Gemini and log outputs back into the ledger.
mindseye-google-devlog → Narrative reflection
🔗 https://github.com/PEACEBINFLOW/mindseye-google-devlog
Generates weekly devlogs from the ledger — converting raw runs into narrative, human-readable updates.
mindseye-google-analytics → Insight & metrics
🔗 https://github.com/PEACEBINFLOW/mindseye-google-analytics
Exports data to Looker / analytics flows: run frequencies, success rates, surface usage, etc.
mindseye-google-workflows → Architecture as YAML
🔗 https://github.com/PEACEBINFLOW/mindseye-google-workflows
Describes portal flows and multi-step workflows as YAML — so the system’s behavior is documented, inspectable, and reproducible.
These six repos were my first generation:
A Google Workspace-native “agentic stack” where everything lived inside Google’s ecosystem.
But something was missing: a deeper structure for time and network behavior.
That’s where Generation 2 comes in.
Generation 2 — A Networked MindsEye OS (7 Repos)
To move from “cool Google stack” to “actual OS”, I added a second layer of repos — focused on laws and infrastructure:
Mind’s Eye LAW-N Network
🔗 https://github.com/PEACEBINFLOW/minds-eye-law-n-network
Mind’s Eye Core (LAW-T + Event Model)
🔗 https://github.com/PEACEBINFLOW/minds-eye-core
Mind’s Eye Search Engine
🔗 https://github.com/PEACEBINFLOW/minds-eye-search-engine
Mind’s Eye Google Workspace Connectors
🔗 https://github.com/PEACEBINFLOW/minds-eye-gworkspace-connectors
Mind’s Eye Dashboard (Next.js UI)
🔗 https://github.com/PEACEBINFLOW/minds-eye-dashboard
Mind’s Eye Automations (Schedulers + Triggers)
🔗 https://github.com/PEACEBINFLOW/minds-eye-automations
Mind’s Eye Playground (Experiments)
🔗 https://github.com/PEACEBINFLOW/minds-eye-playground
You can think of it like this:
The original 6 repos = Google-native application & workflow layer
The new 7 repos = event, time, network, and OS layer underneath
Together they form a MindsEye OS that is:
Google-native
Event-driven
Time-aware
Network-aware
Multi-repo, multi-agent-friendly
The Two Laws — LAW-T and LAW-N
The course kept emphasizing:
perception → memory → reasoning → action → feedback
I wanted to put two more “laws” underneath all of that:
LAW-T (Law of Time) → How events are labeled, grouped, and reasoned over in time
LAW-N (Law of Network) → How events travel across clients, devices, and clouds
LAW-T vs LAW-N at a glance
| Without LAW-T | With LAW-T |
|-------------------------------------------|----------------------------------------------------|
| “This happened… sometime today.” | blockId = daily_2025-11-17, segmentId = 2025-11-17T09 |
| Hard to trend, compare, or aggregate | Automatically bucketed into time blocks & segments |
| Without LAW-N | With LAW-N |
|---|---|
| “Send everything immediately.” | Route via channel, priority, reliability
|
| Overloads devices / bandwidth | Smart batching, critical-first delivery |
Those laws are implemented through the new repos.
🛰️ 1. minds-eye-law-n-network — The Traffic Controller
🔗 Repo: https://github.com/PEACEBINFLOW/minds-eye-law-n-network
🎯 Role: Decide how data moves through the system.
Every outgoing payload (event, update, notification) carries network intent:
channel: realtime | timeline | bulk
priority: critical | high | normal | low
reliability: must_deliver | best_effort
source: android | web | server | drone | system
A policy engine can then:
send now
queue
batch
or drop
Connection to Gen 1:
This layer controls how data from mindseye-workspace-automation, ledger, and analytics actually travels through the network.
🧠 2. minds-eye-core — LAW-T & the Universal Event Model
🔗 Repo: https://github.com/PEACEBINFLOW/minds-eye-core
🎯 Role: Define the event language and the time law for MindsEye.
Core is responsible for:
MindEyeEvent → the universal event type
LAW-T logic:
blockId (e.g. daily_2025-11-17)
segmentId (e.g. 2025-11-17T09)
Shared TypeScript types used across other repos
A typical event looks like:
{
"eventId": "gmail-abc123",
"source": "gmail",
"blockId": "daily_2025-11-17",
"segmentId": "2025-11-17T09",
"channel": "realtime",
"priority": "normal",
"reliability": "must_deliver",
"subject": "Project update from team",
"timestamp": "2025-11-17T09:23:15Z"
}
Connection to Gen 1:
The ledger, devlog, and analytics repos all benefit from LAW-T — they can operate over blocks and segments instead of raw timestamps.
🔍 3. minds-eye-search-engine — The Hunting Brain
🔗 Repo: https://github.com/PEACEBINFLOW/minds-eye-search-engine
🎯 Role: Help MindsEye “hunt” through its own memory.
This service exposes:
/events/search → full-text and filtered search over events
/events/stats → time-series and counts per source / type
It’s used to answer questions like:
“What did Gmail + Calendar do in the last 7 days?”
“Which events relate to this person, project, or keyword?”
“How does this week’s activity compare to last week?”
Connection to Gen 1:
The devlog and analytics repos can query this engine to generate summaries and insights over time-labeled event data.
👂 4. minds-eye-gworkspace-connectors — Google as the Senses
🔗 Repo: https://github.com/PEACEBINFLOW/minds-eye-gworkspace-connectors
🎯 Role: Convert Google Workspace activity into MindEyeEvents.
This repo ingests:
Gmail → messages, labels, threads
Calendar → events aligned with LAW-T blocks
Drive & Docs → long-term memory artifacts
Meet → transcripts
Everything is normalized into the MindEyeEvent schema and handed to Core.
Connection to Gen 1:
This essentially replaces and upgrades parts of mindseye-workspace-automation, making perception more standardized and reusable across both generations.
📊 5. minds-eye-dashboard — The Face of MindsEye
🔗 Repo: https://github.com/PEACEBINFLOW/minds-eye-dashboard
🎯 Role: Make the whole architecture observable and usable.
Built with Next.js + React + Tailwind, the dashboard gives:
Timeline view (LAW-T blocks & segments)
Unified event feed (Gmail, Calendar, Drive, Docs, Meet)
Search UI backed by minds-eye-search-engine
Cognitive views and weekly snapshots
Connection to Gen 1:
This acts as the visual counterpart to devlog and analytics — the same data, but presented interactively instead of just in Sheets / Looker / Docs.
⏰ 6. minds-eye-automations — The Heartbeat
🔗 Repo: https://github.com/PEACEBINFLOW/minds-eye-automations
🎯 Role: Orchestrate all recurring and triggered actions.
It coordinates:
Daily event syncs
Weekly summaries
LAW-T block generation
Cognitive pool refresh
Search snapshots
Google Workspace triggers (Gmail, Drive, Calendar, Meet)
Backed by:
Cloud Scheduler
Cloud Run
Pub/Sub
(optionally) Apps Script webhooks
Connection to Gen 1:
This is the runtime backbone that keeps both the ledger and devlog evolving over time — and will eventually schedule Gemini runs via mindseye-gemini-orchestrator.
🧪 7. minds-eye-playground — The Lab
🔗 Repo: https://github.com/PEACEBINFLOW/minds-eye-playground
🎯 Role: Safely experiment with new ideas.
This playground contains:
Mock event generators
LAW-T labeling experiments
Simple search prototypes
Scripts and notebooks for analysis
Connection to Gen 1:
It’s where I prototype flows that will eventually feed into or enhance the ledger, workflows, and Gemini orchestrator repos.
One Gmail Label, Thirteen Repos
Let’s walk one concrete example through the system.
Scenario: I apply a label in Gmail called "Send to MindsEye".
Perception & Ingestion
📬 Gmail event fires with the new label.
🔌 GWorkspace Connectors capture it and convert it into a MindEyeEvent.
🌐 LAW-N Network decides how to send it (e.g. realtime, normal, must_deliver).
⏰ Core (LAW-T) stamps blockId and segmentId.
💾 The event is stored in the event store and optionally logged into the Google Ledger.
Memory, Reasoning & Reflection
🔍 Search Engine indexes it for /events/search and /events/stats.
📓 Google Devlog later uses those events to write narrative summaries.
📈 Google Analytics aggregates this activity into dashboards and KPIs.
Orchestration & OS Behavior
🤖 Automations run daily and weekly jobs:
refresh snapshots
roll up LAW-T blocks
plan reasoning runs via Gemini Orchestrator
🧠 Gemini Orchestrator (once wired to the API) can:
pick relevant events
generate insights / decisions
log runs back to the Ledger
User Experience
📊 Dashboard shows:
the Gmail event in the unified feed
a spike on the timeline for that period
source breakdowns (Gmail vs Calendar vs others)
🗺️ Google Workflows define how this whole flow is described as YAML portal maps.
🌐 Workspace Automation continues to act as the glue for legacy / direct Workspace logic.
The result is not “an agent replied to an email.”
It’s an OS that:
perceives
routes
time-labels
logs
reasons
summarizes
visualizes
…off a single user action.
The Big Takeaway
If I had to compress everything from the course and this build into one sentence:
The future of AI isn’t one clever agent — it’s an ecosystem of small, focused subsystems that share structured memory, respect time and network constraints, and cooperate over a common event model.
For me, that ecosystem now looks like:
6 Google-native repos (ledger, workflows, devlogs, analytics…)
7 OS repos (laws of time & network, core events, search, automation, UI, playground)
All stitched together by the architecture patterns I learned during the intensive.
What’s Next
The challenge ends on December 7, 2025, but this architecture is just getting started.
Planned next steps:
Plug Gemini into mindseye-gemini-orchestrator as the reasoning core
Push more real-world event sources through LAW-N (mobile, web, maybe hardware)
Turn MindsEye into a template other teams can fork and adapt
Use Google Ledger + Devlog + Analytics as a full “self-analytics” layer for the OS itself
The most surprising part?
I built all of this with almost no cloud budget — just architecture, Google Workspace, and stubborn iteration.
I entered the course wanting to “build an agent.”
I walked out with:
A Law of Time (LAW-T)
A Law of Network (LAW-N)
A Google-native MindsEye OS spread across 13 repos
And a completely upgraded mental model for agentic systems.
And honestly?
This still feels like Level 1.
Top comments (0)