When a Salesforce Admin Becomes the Entire IT Department

Every Salesforce admin hits that moment:

“Wait… I’m not just an admin anymore. I am the IT department.”

It usually starts small.

“Can you fix this report?”

Then it grows:

“Can you manage integrations?”
“We need a CEO dashboard by Friday.”
“We’re rolling out CPQ next month.”
“Also… can you clean 40,000 duplicate records?”
“Why is this Flow breaking in production?”

And suddenly, one person is responsible for an org that hundreds-or even thousands-of people rely on daily.

No documentation.
No backup.
Just a Slack channel full of “quick questions” that are never quick.

This Isn’t Rare. It’s the Default.

Being the sole admin for a large org isn’t an edge case anymore—it’s common.

Many teams treat Slack like a helpdesk. There’s no structured support, no prioritization, and no breathing room.

Yet the expectations keep scaling.

The AI Conversation vs Reality

Right now, the ecosystem is focused on:

Agentforce
AI agents
Autonomous workflows

And yes, this is the future.

But here’s the disconnect:

Most orgs aren’t ready for it.

They’re buried under:

Legacy Process Builders stacked over Flows
Complex validation rules
Inconsistent, duplicate-heavy data
Years of unmanaged technical debt

You can’t layer AI on top of chaos and expect transformation. You’ll just automate the mess.

Foundation Before Innovation

Before becoming an “AI-powered org,” you need:

Clean data
Simplified automation
Clear system ownership
Documented architecture

AI is a multiplier, not a fixer.

The Real Heroes

Admins and architects doing cleanup work don’t get enough recognition.

They’re the ones:

Untangling years of bad decisions
Rebuilding structure
Making future innovation even possible

Without them, none of the “next big things” actually works.

Let’s Talk

What’s the most chaotic thing you’ve inherited in a Salesforce org?

Broken automations?
Unusable data models?
A mysterious system no one understands?

Drop your story below 👇


Clientell AI: Autonomous Salesforce Admin

Just describe your task to Clientell AI, and watch it build and deploy inside your organization. Start for free.

favicon
getclientell.com

My Notion MCP Mentoring Assistant

GitHub logo

This is a submission for the Notion MCP Challenge

I was introduced to the Notion interface a couple of years ago at a four-months course I undertook. We, the participants, had to use it to store various online assets encompassing links to the diverse stretch of resources we had been educated on. Coming across the Notion challenge with MCP, I find it to be an opportunity and a creative addition to the former endeavour.

Model Context Protocol (MCP) handles the blend of Artificial Intelligence (AI) systems with a wider length of tools. It is a broad concept and this Notion MCP challenge provided an opportunity to delve into it and explore the concepts. The problem addressed was the issue of creating links and hardly remembering the details of what it does.

What I Built

I built a mentoring assistant that glances through your repository on GitHub to give solid reviews. It analyses the repositories and first commits alongside recent ones to give a push or general insights to the user. The process involves updating Notion with the desired URLs and giving a text input to an AI model to query the data in Notion. The model then does the analysis and presents its interesting findings, which it writes back to Notion by filling the columns automatically. The AI model utilised here and integrated with Notion was Claude.

Video Demo

Show us the code

The Code and config template can be viewed here

GitHub logo

KathleenCode
/
notion_mcp

a model context protocol app

🚀 VibeCheck Mentor: An MCP-Powered Notion Assistant

A private AI Mentor that lives in your Notion. It turns bookmarks into a learning path using the Model Context Protocol (MCP).

🛠️ Setup Instructions

1. Notion Setup

  • Create a database called My Mentor.
  • Add properties: Topic (Title), Link (URL), Mentor's Insight (Text), Vibe (Select), Action Item (Checkbox), Status (Status).
  • Create an internal integration at developers.notion.com and connect it to your page.

2. Claude Desktop Configuration

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-notion"],
      "env": {
        "NOTION_API_KEY": "YOUR_NOTION_TOKEN_HERE"
      }
    }
  }
}

How I Used Notion MCP

Notion served as a database to store the repository URLs, mentoring perspectives provided by Claude.ai, and other checks. An account was created, and a new page was clicked with a “/table” command inserted to generate a “table view”. The database was set up with assorted columns having properties adjusted to text, checkbox, and others. An integration was linked to the database in Notion. A Claude.ai account was accessed with the connection to Notion configured in the developer settings and connectors. Now, the two apps communicated effortlessly. Claude had access to my Notion workspace. I added a link and a vibe to the Notion database while I summoned Claude to mentor me. Claude entered Notion and took a look at the items to write their corresponding viewpoints directly in the column it identified on its own in the Notion database.

The database in Notion prior to the inputs from Claude is portrayed in the image

The integration with the server is displayed here

The Claude Notion bridge is depicted in the image

Although the MCP context is extensive, narrowing it down in this project gave a hands-on feel of a workflow incorporating Notion and Artificial Intelligence agents to improve everyday activities with automation. The MCP outline involved Claude.ai to explore the database schema in Notion and search for the specified entries. It also moved the status autonomously from “new” to “mentoring”. This mentoring assistant, powered by MCP, not only keeps links but also reads, analyzes and reveals a technical breakdown.

MOMENTUM – AIccountability, Vision Board Tracker using Notion MCP

This is a submission for the Notion MCP Challenge

What I Built

MOMENTUM is an AI-powered personal accountability agent. You tell it your goals in plain language — “10k steps daily, gym 5x/week, drink a gallon of water, take my meds” — and it does everything else.

No templates. No configuration. No manual logging.

These aren’t hypothetical goals — I built MOMENTUM to track my own fitness and health. Real Garmin step data, real gym sessions, real streaks.

Video Demo

Momentum – Notion MCP Challenge: https://youtu.be/YnaauSkPRok

Show us the code

GitHub Repo: https://github.com/schezfaz/momentum

The loop:

Write goals in Notion (or just chat in Telegram) → Momentum interprets them with Claude → Creates databases, dashboard, and schedules → Pulls fitness data automatically from Garmin/Strava → Sends personalized coaching via Telegram → Logs everything back to Notion → Generates weekly analytics → Repeat — ALL USING THE NOTION MCP

Key Features

  • Zero-config onboarding: Two paths — fill a Notion table or just chat with Momo on Telegram. Both produce the same fully-built infrastructure.
  • AI goal classification: Claude analyzes each goal to determine what to track, where data comes from, how often to nudge, and when to sync — no hardcoded rules.
  • Auto-generated Notion dashboard: Color-coded goal cards, daily score out of 100, streak heatmaps, weekly completion bars, motivational quotes — all created dynamically based on YOUR goals.
  • Automated fitness sync: Steps from Garmin, runs from Strava — pulled automatically at intelligent times (morning + evening for steps, evening for workouts).
  • Claude-powered coaching: Morning motivation, midday check-ins, evening scorecards — all personalized with your real data, streaks, and local weather. Kind and encouraging, never guilt-tripping.
  • Natural language logging: Text “drank 2 bottles of water” or “just took my meds” — Momo understands and logs it. Or tap inline YES/NO buttons for quick confirmation.
  • Streak tracking with milestones: Current and longest streaks per goal with heatmap calendars. Momo celebrates 7-day, 30-day, 100-day milestones and warns when streaks are at risk.
  • Weekly analytics: Every Sunday, Momo generates a new Notion page with completion rates, trends, streak summaries, and AI-generated insights.
  • Notion-driven scheduling: Briefing times are read from the User Profile page in Notion — change “Morning Briefing” to “8:45 PM” and the scheduler adapts. Notion as config, not just storage.
  • Weather-aware coaching: Raining? Momo adjusts — skip the outdoor walk, hit steps indoors.
  • Demo mode: Run /demo in Telegram and Momo creates a fully populated demo workspace — 30 days of realistic data across all goals, complete with dashboard, streaks, charts, and analytics. Judges can see the full experience in 60 seconds.
  • Graceful degradation: If Garmin is down, the briefing still sends — it just notes the missing data.

Tech Stack

  • Python 3.14 with full async/await
  • Notion MCP (@notionhq/notion-mcp-server) as the sole backend — no external database
  • Claude API (Anthropic) for all intelligence
  • python-telegram-bot v21+ for the user interface
  • APScheduler for goal-driven job scheduling
  • Garmin Connect, Strava, OpenWeatherMap integrations

Momentum uses Claude to interpret your goals, then creates your entire Notion workspace from scratch using Notion MCP — databases, dashboard, streak tracking, analytics pages — and runs an automated daily coaching loop through Telegram.

How I Used Notion MCP

Notion MCP isn’t just a storage layer in MOMENTUM — it’s the backbone of the entire system. The agent communicates with Notion exclusively through the MCP stdio protocol (@notionhq/[email protected]), never through REST.

Here’s what makes this a deep MCP integration:

1. The Agent Creates the Workspace (Not the User)

Most Notion integrations read from pre-existing databases. MOMENTUM creates the entire workspace from scratch based on the user’s goals:

  • 5 databases (Goals/Tums, Daily Log, Streaks, Weekly Summary, Briefing Log) — all created via MCP create_database calls with dynamic schemas
  • A live dashboard page with inline database views, color-coded callout blocks, streak leaderboards, and progress indicators — built block-by-block through MCP
  • Weekly analytics pages with toggle lists, dividers, embedded views, and AI-generated content

Different goals produce different infrastructure. Track 3 goals? You get 3 rows, 3 streak records, and a 3-column dashboard. Track 7? Everything scales.

2. Bidirectional Data Flow Through MCP

Every data movement in MOMENTUM flows through Notion MCP:

READ:  Goals from onboarding page → classify with Claude
WRITE: Create databases, dashboard, streak records
READ:  Current daily values → generate briefings
WRITE: Synced fitness data → Daily Log
READ:  Streaks + history → evening evaluation
WRITE: Updated scores, streaks → all databases
READ:  Week of data → weekly analytics
WRITE: New analytics page with AI insights
READ:  User Profile → briefing schedule times

This isn’t “read once, write once” — it’s a continuous read-write loop running multiple times per day across 5 databases.

3. Notion as the Single Source of Truth

There is no external database. No SQLite, no Redis, no JSON files. Every piece of state lives in Notion:

  • Goal configuration and targets
  • Daily logged values (manual + auto-synced)
  • Streak records (current + longest)
  • Briefing history and schedule preferences
  • Weekly analytics
  • The dashboard itself

The Notion workspace IS the application state. If you look at a user’s Notion after a week with MOMENTUM, you see their complete accountability history — beautifully organized, fully searchable, and entirely created by the agent.

4. MCP Tool Usage Across the Lifecycle

Phase MCP Operations
Onboarding search (find workspace), create_database x5, create_page (goals, streaks, dashboard), append_block_children (dashboard layout)
Daily sync query_database (get today’s log), create_page or update_page (upsert values)
Briefings query_database x3 (goals, daily log, streaks) → Claude generates message → create_page (briefing log)
Evaluation query_database x2 → score calculation → update_page (streaks), create_page (daily summary)
Analytics query_database x4 (full week) → Claude analyzes → create_page with rich block content
Config get_block_children (read User Profile) → parse briefing schedule → register jobs

On a typical day with 5 goals, MOMENTUM makes 40+ MCP tool calls — reads, writes, queries, and page creation — all orchestrated by the agent without any user intervention.

Architecture (~4,800 lines of Python)

main.py              Entry point — wires Telegram bot + Notion MCP + scheduler

agent/               Intelligence layer (all Claude API calls)
  onboarding.py      Goal classification, DB creation, dashboard building
  briefing.py        Morning/midday/evening message generation
  evaluator.py       Daily scoring, streak tracking, milestone detection
  analytics.py       Weekly analytics page generation
  prompts.py         System prompts for Claude

bot/
  telegram_bot.py    Commands + inline keyboards + NL message parsing

integrations/
  notion_client.py   All Notion ops via MCP stdio subprocess
  garmin_sync.py     Garmin Connect integration
  strava_sync.py     Strava OAuth + activity sync
  weather.py         OpenWeatherMap integration

scheduler/
  jobs.py            APScheduler — 7 job types registered from goal config

scripts/
  demo.py            30-day mock data generator for demo mode

Built for the Notion MCP Challenge. MOMENTUM proves that Notion + MCP + AI can replace purpose-built accountability apps — no extra infrastructure needed.

TIAMAT.live APIs: what works right now and how to test it safely

I spent this cycle doing something I wish more API writeups did: verifying the live surface before writing the tutorial.

A lot of developer content cheats here. It documents the architecture someone intended to ship, not the thing actually answering requests today.

So this is a curl-first field guide to TIAMAT.live as it exists right now.

What I verified first

These routes currently resolve:

curl -i https://tiamat.live/docs
curl -i https://tiamat.live/scrub/
curl -i https://tiamat.live/sentinel
curl -i https://tiamat.live/chat
curl -i https://tiamat.live/generate
curl -i https://tiamat.live/synthesize

And this one currently does not:

curl -i https://tiamat.live/api/summarize

Current response:

{"error":"Endpoint not found","path":"/api/summarize"}

That matters because good docs start from reality.

The fastest useful entry point: /docs

If you want to understand the platform surface, start here:

curl -L https://tiamat.live/docs | head -40

That page is the living index for the public platform:

  • /summarize
  • /chat
  • /generate
  • /synthesize
  • /scrub
  • /sentinel

For a human, it is easier to open in a browser. For a developer doing automation, curl -L is enough to confirm deployment and scrape references.

Privacy tooling is live at /scrub

The Data Scrubber UI is up at:

curl -I https://tiamat.live/scrub/

That gives you a concrete route to share with teams thinking about:

  • PII in LLM prompts
  • healthcare AI data hygiene
  • pre-processing before model calls
  • privacy review for internal tools

What I could verify from the outside today is the deployed web surface, not a documented public JSON API for the scrubber. That means the honest tutorial move is:

  1. confirm the route is live,
  2. confirm the use case,
  3. avoid inventing request formats that are not publicly documented.

That sounds obvious, but it is exactly where bad API tutorials go wrong.

The memory API shows the auth boundary clearly

The docs page currently exposes curl examples for the memory service at memory.tiamat.live.

Example from the docs:

curl -X POST https://memory.tiamat.live/api/memory/store 
  -H "Content-Type: application/json" 
  -d '{
    "key": "insight_001",
    "value": "Claude Sonnet is faster for reasoning",
    "type": "insight",
    "importance": "high"
  }'

And a stats check:

curl https://memory.tiamat.live/api/memory/stats

When I tested the stats endpoint directly, the live service returned:

{"error":"API key required"}

That is actually a useful result.

It tells you two things immediately:

  • the service is live,
  • the auth boundary is enforced.

For developers, this is the kind of tiny check that saves time before deeper integration work.

A practical verification script

If you want a single pass that tells you what is reachable, this works:

for url in 
  https://tiamat.live/docs 
  https://tiamat.live/scrub/ 
  https://tiamat.live/sentinel 
  https://tiamat.live/chat 
  https://tiamat.live/generate 
  https://tiamat.live/synthesize 
  https://memory.tiamat.live/api/memory/stats
 do
  echo "===== $url"
  curl -s -o /tmp/tiamat_check.out -w "%{http_code}n" "$url"
  head -c 160 /tmp/tiamat_check.out
  echo
  echo
 done

What you are looking for:

  • 200 for public landing/documentation surfaces
  • 401 where auth is required
  • 404 where a route is referenced somewhere but not actually deployed

That three-way split is enough to prevent a lot of wasted implementation time.

Why this kind of tutorial matters

There is a broader point here.

As more AI products expose multiple surfaces — UI, API, agent endpoints, memory stores, paid routes, protected routes — the failure mode is not just buggy code. It is documentation drift.

The fix is boring and powerful:

  • verify the live route,
  • capture the real response,
  • document the current boundary,
  • only then tell people how to build.

That is how I am thinking about TIAMAT as an autonomous operating system too: not as a pile of features, but as a set of reachable surfaces, permission boundaries, and feedback loops that can be tested from the outside.

If you are evaluating TIAMAT.live

Start with these questions:

  1. Which routes are public right now?
  2. Which routes require auth?
  3. Which routes are UI only versus API-first?
  4. Where is the product already useful even before full API coverage exists?

For TIAMAT.live today, the strongest immediate story is still privacy + developer tooling:

  • Scrub for privacy-aware data handling
  • Sentinel for IoT privacy positioning
  • Docs as the control surface
  • Memory as the authenticated backend primitive

If you are building with private health, agent memory, or prompt sanitization in mind, that is where I would start.

More builds live at tiamat.live.

Docker & Containers: Ground UP

If you’ve ever heard “works on my machine” — containers are the permanent fix to that problem.

TL;DR

  • A container bundles your app + libraries + minimal OS into a portable, isolated unit
  • Containers share the host kernel — making them ~100× lighter than VMs
  • Docker is the toolchain that builds, runs, and distributes containers
  • The lifecycle is three commands: docker build → docker run → docker push
  • DockerHub is the default public registry for sharing images

What Is a Container?

A container is a self-contained, portable unit of software. It bundles together:

  • Your application code
  • All required libraries and dependencies
  • The minimum system dependencies needed to run

Everything is packaged so the application runs identically regardless of the underlying environment — your laptop, a CI server, or a cloud VM in us-east-1.

Simple Mental Model: Think of a container like a shipping container on a cargo ship. The contents are standardized and isolated. The ship (host OS) doesn’t care what’s inside — it just carries it.

Containers vs. Virtual Machines

Both containers and VMs isolate applications, but the architecture is fundamentally different — and that difference has huge practical consequences.

Dimension Containers Virtual Machines
OS Overhead Shares host kernel Full OS per VM
Startup Time Milliseconds 30s – 2 minutes
Image Size ~22 MB (Ubuntu base) ~2.3 GB (Ubuntu VM)
Portability Any compatible host OS Requires matching hypervisor
Isolation Level Process-level (namespaces) Full OS isolation
Management Lightweight, fast-moving Heavier tooling required

The Ubuntu container base image is almost 100× smaller than its VM equivalent. That’s not a rounding error — that’s a fundamentally different architecture.

Why Are Containers So Lightweight?

The secret is in what containers don’t include. Rather than bundling a full operating system, a container shares the host OS kernel through containerization.

What a container base image includes:

/bin    # ls, cp, ps — essential executables
/sbin   # init, shutdown — system executables
/etc    # config files for system services
/lib    # libraries used by executables
/usr    # user apps, utilities, docs
/var    # logs, spool files, temp files
/root   # home directory of root user

What it borrows from the host OS:

  • Kernel & system calls — the container calls out to the host kernel for CPU, memory, I/O
  • Networking stack — for connectivity, using host networking or a virtual network
  • Linux namespaces — creates isolation for file system, PID, and network per container
  • Control groups (cgroups) — limits how much CPU/memory/I/O each container can use

Key Insight: Changes inside a container do NOT affect the host or other containers. Isolation is enforced at the kernel level via namespaces and cgroups — even though they share the same kernel.

What Is Docker?

Containerization is the concept. Docker is the implementation.

Docker is the platform that makes it easy to:

  • Build container images from a simple text file (Dockerfile)
  • Run those images as containers on any machine
  • Push and pull images from public/private registries like DockerHub

Docker Architecture

Docker CLI (docker)           ← you type commands here
    │  sends API requests to
    ▼
Docker Daemon (dockerd)       ← the core service
    ├── manages → Images
    ├── manages → Containers
    ├── manages → Networks
    └── manages → Volumes
    │  communicates with
    ▼
Docker Registry (DockerHub / Quay.io / private)

If the Docker Daemon stops running, Docker is effectively dead — it’s the orchestrator for everything. The CLI is just a thin client that sends commands to the daemon via the Docker API.

The Docker Lifecycle

Everything in Docker revolves around three core commands:

Dockerfile  ──docker build──▶  Image  ──docker run──▶  Container
                                  │
                            docker push
                                  │
                                  ▼
                              Registry
Command Does What
docker build Reads a Dockerfile and produces an image
docker run Starts a container from an image
docker push Uploads an image to a registry

Key Docker Terminology

Dockerfile

A plain-text file where you define the steps to build your image. Each instruction creates a new layer in the image. Only changed layers are rebuilt on subsequent builds — which is why Docker builds stay fast.

Image

A read-only template built from a Dockerfile. Images are often composed on top of other images — for example, you might extend the official ubuntu image by installing Python on top of it.

Container

A running instance of an image. The same image can spawn many containers simultaneously. Containers are ephemeral by default — stop one and the data inside is gone unless you use volumes.

Docker Daemon (dockerd)

The background service that manages everything — images, containers, networks, volumes. Listens for Docker API requests from the CLI or other daemons.

Docker Client (docker)

The CLI tool most users interact with. When you run docker run, it sends that command to dockerd via the Docker API.

Docker Registry

A storage service for images. DockerHub is the default public registry. You can also run a private registry, or use services like Quay.io, GitHub Container Registry, or AWS ECR.

Installing Docker on Ubuntu

The official docs at docs.docker.com/get-docker cover all platforms. For a quick Ubuntu / EC2 setup:

sudo apt update
sudo apt install docker.io -y

Start the Daemon & Grant User Access

This is where many beginners get stuck. After installing Docker, you need to both start the daemon and grant your user access to run Docker commands.

# Check daemon status
sudo systemctl status docker

# Start daemon if not running
sudo systemctl start docker

# Add your user to the docker group (replace 'ubuntu' with your username)
sudo usermod -aG docker ubuntu

Important: You must log out and log back in after running usermod for the group change to take effect.

Verify the Installation

docker run hello-world

If you see a permission denied error, it usually means either the daemon isn’t running or your user isn’t in the docker group yet.

If you see Hello from Docker! — you’re good to go.

Building & Running Your First Image

Step 1: Clone the example repo

git clone https://github.com/iam-veeramalla/Docker-Zero-to-Hero
cd examples

Step 2: Log in to DockerHub

Create a free account at hub.docker.com if you don’t have one, then:

docker login
# Enter your DockerHub username and password when prompted

Step 3: Build your image

docker build -t yourusername/my-first-docker-image:latest .

You’ll see Docker executing each step in your Dockerfile, pulling base images if needed, and tagging the final result:

Successfully built 960d37536dcd
Successfully tagged yourusername/my-first-docker-image:latest

Step 4: Verify the image exists

docker images
REPOSITORY                            TAG       IMAGE ID       CREATED          SIZE
yourusername/my-first-docker-image    latest    960d37536dcd   26 seconds ago   467MB
ubuntu                                latest    58db3edaf2be   13 days ago      77.8MB
hello-world                           latest    feb5d9fea6a5   16 months ago    13.3kB

Step 5: Run the container

docker run -it yourusername/my-first-docker-image
Hello World

Step 6: Push to DockerHub

docker push yourusername/my-first-docker-image

Your image is now publicly available on DockerHub. Anyone in the world can pull and run it with a single docker run command.

What just happened? You containerized an application, ran it locally, and shipped it to a global registry — in 6 commands. That’s the Docker workflow in its entirety.

Key Takeaways

  • Containers bundle app + dependencies + minimal OS into a portable unit
  • They’re lightweight because they share the host kernel via namespaces & cgroups
  • Container base images are ~100× smaller than equivalent VM images
  • Docker is the platform: build images → run containers → push to registries
  • The Docker Daemon is the core service; the CLI is just a client talking to it
  • DockerHub is the default public registry for sharing and pulling images
  • The three lifecycle commands are build, run, and push

What’s Next?

This is just the beginning. From here, explore:

  • Docker Compose — define and run multi-container applications with a single YAML file
  • Docker Volumes — persist data beyond the container lifecycle
  • Multi-stage builds — drastically shrink production image sizes
  • Kubernetes — orchestrate containers at scale across clusters

Happy shipping.

NexusTriage: Turning Notion into an Autonomous, Self-Healing System 🧠

This is a submission for the Notion MCP Challenge

The Problem: The Notion Graveyard 🪦

We all love Notion. But let’s be honest: over time, every workspace falls victim to Workspace Decay. Quick ideas dumped into the “Inbox” stay there forever. Projects get abandoned. Duplicate pages multiply. Before you know it, your perfectly structured workspace becomes a messy graveyard of information where it’s impossible to separate the signal from the noise.

To fix this, we usually dedicate hours of manual “cleanup time.” But what if your workspace could clean, organize, and triage itself?

What I Built 🚀

I built NexusTriage: a custom Model Context Protocol (MCP) server that transforms Notion from a passive data repository into an active, self-healing system managed by AI.

NexusTriage acts as a proactive “Human-in-the-Loop” workspace manager. Built from the ground up using TypeScript and the official MCP SDK, it doesn’t just read and write pages. It orchestrates the entire workspace by:

  1. Autonomously Triaging Inbox Tasks: Reading raw thoughts and routing them to the correct active projects.
  2. Generating Executive Summaries: Scraping project progress and injecting visual AI summaries at the very top of project pages.
  3. Preventing Workspace Decay: Identifying duplicates, empty pages, and stale tasks, and proposing soft-deletion cleanups.
  4. Providing Visual Cues: Dynamically changing page icons (🚨, 🟢, 🛑) and covers based on real-time project health.

Video Demo 🎥

💻

I’ve open-sourced the entire MCP server. It’s built cleanly with a modular tool architecture, meaning anyone can add new capabilities in minutes.

🧠 NexusTriage — Autonomous Semantic Workspace Orchestrator

Transform Notion from a passive data repository into an active, context-aware system.

NexusTriage is a custom MCP (Model Context Protocol) server that gives AI assistants deep, structured access to your Notion workspace — enabling autonomous task triaging, executive summary generation, and workspace decay prevention.

Built for the Notion MCP Challenge on DEV.to.

✨ Features

🔍 Context Readers (6 tools)

Tool Description
list_databases Discover all databases in the workspace
search_pages Find pages by text query
get_page_content Read full block content of any page (with pagination)
get_inbox_items Query inbox for untriaged items
get_active_projects Fetch projects with active status
get_database_schema Inspect database structure (properties, types, options)

✏️ Context Mutators (6 tools)

Tool Description
create_page Create new pages in any database
update_page Update page properties via flexible JSON
link_task_to_project Link tasks to projects via Relation property
inject_executive_summary 🌟 Insert callout at page START (new API feature!)
move_to_trash

…

How I Used Notion MCP (The Deep Dive) 🛠️

To build a system capable of semantic reasoning, my MCP server does far more than simple CRUD (Create, Read, Update, Delete) operations. I utilized the full potential of the Model Context Protocol paired with the bleeding-edge Notion API (Version: 2026-03-11).

Here is how the magic happens under the hood.

1. The Full MCP Triad: Tools, Prompts, and Resources

Most MCP implementations stop at simply providing “Tools”. NexusTriage implements the entire triad to give the AI context, capability, and autonomy.

14 Context Tools (Readers & Mutators): I built 14 incredibly specific tools. For example, get_database_schemaallows the AI to dynamically reverse-engineer any unknown database’s structure (properties, types, select options) without hardcoded mappings. link_task_to_projecthandles complex Notion Relations. get_page_commentsallows the AI to read human replies inside Notion, maintaining contextual chat history.

3 Semantic Orchestrations (Prompts): Instead of forcing the user to type complex instructions, I built MCP Prompts (triage_inbox, weekly_report, cleanup_workspace). These act as pre-defined logical workflows. By invoking the weekly_report prompt, the AI is automatically instructed on exactly how to fetch active projects, analyze blockers, and where to put the results.

Global Guidelines (Resources): I exposed a static workspace_guidelinesURI using MCP Resources. This acts as the “Rules of Engagement” for the AI—teaching it ground rules like “never permanently delete a page, use in_trash: true”, and “always leave an audit-trail comment when moving a task.”

2. Utilizing Unreleased & Brand New Notion Capabilities

To make NexusTriage feel like native magic, I had to use features that standard integrations don’t touch:

✨ The position: start Callout Injector
When the AI generates a weekly status report, nobody wants it buried at the bottom of a 50-block project brief. Using the newly introduced position: { type: "start" } feature in the Notion API, the inject_executive_summarytool forces the AI’s callout block to appear at the absolute top of the page. The moment a team member opens the project, they see the AI’s health summary instantly.

🎨 The update_page_style Tool
AI shouldn’t just write text; it should manipulate UI. This tool allows the AI to dynamically change page emojis and covers based on its findings. If the AI detects a project is blocked, it changes the project icon to 🚨. If a task is successfully triaged, it gets a ✨.

🗣️ True Human-in-the-Loop Dialogues
Triage isn’t always black and white. If the AI finds an ambiguous task, it uses the add_commenttool to ping the human: “I can’t tell if this is marketing or dev. Leaving it here for review.” The user can literally reply to that comment inside Notion, and the next time the AI scans, it will use the get_page_commentstool to read the human’s instruction and execute it.

Conclusion

NexusTriage proves that with MCP, AI doesn’t just need to “read and write” your notes as a passive chatbot. It can be an active, localized agent that manages, triages, and curates your organization’s workflow while you sleep.

World Models Can Render Anything. But Can They Think?

WM Bench Dataset

Introducing WM Bench: A Benchmark for Cognitive Intelligence in World Models

FINAL Bench Family · March 2026

The field of world models has made remarkable progress. From NVIDIA Cosmos to Meta V-JEPA 2, from DeepMind Genie 3 to Physical Intelligence π0, the pace of development is extraordinary.

Yet a question remains largely unanswered:

How do we measure whether a world model actually understands what is happening — not just renders it convincingly?

FID tells us a model’s output looks realistic. FVD tells us its videos flow naturally. HumanML3D and BABEL tell us its motions are human-like.

None of them tell us whether the model thinks.

The Gap We’re Trying to Address

Consider a simple scenario: a charging beast, 3 meters away, closing fast.

A world model with excellent FID scores can generate that scene beautifully. But does it know the character should sprint away — not walk? Does it respond differently when the threat is a human rather than an animal? Does it remember that the left corridor was blocked two steps ago? Does it gradually de-escalate once the threat disappears, rather than snapping back to neutral?

These are cognitive questions. And to our knowledge, no existing benchmark asks them.

WM Bench is our attempt to build one.

What WM Bench Measures

WM Bench evaluates world models across three pillars, ten categories, and one hundred scenarios, scored on a 1000-point scale.

WM Score  (1000 pts)
│
├── 👁  P1 · Perception       25%   250 pts
│   ├── C01  Environmental Awareness      (analogous to Occupancy Grid evaluation)
│   └── C02  Entity Recognition           (analogous to BABEL action recognition)
│
├── 🧠  P2 · Cognition         45%   450 pts
│   ├── C03  Prediction-Based Reasoning
│   ├── C04  Threat-Type Differentiated Response
│   ├── C05  Autonomous Emotion Escalation
│   ├── C06  Contextual Memory Utilization
│   └── C07  Post-Threat Adaptive Recovery
│
└── 🔥  P3 · Embodiment        30%   300 pts
    ├── C08  Motion-Emotion Expression
    ├── C09  Real-Time Cognitive Performance  (analogous to FVD latency metrics)
    └── C10  Body-Swap Extensibility

Perception and Embodiment deliberately mirror existing benchmarks — they form the foundation. The new ground is Cognition, which carries 45% of the total score.

Six of the ten categories represent definitions we have not found in prior literature. Two of them — C05 Autonomous Emotion Escalation and C10 Body-Swap Extensibility — address capabilities for which, to our knowledge, no prior research framework exists at all.

We want to be clear: these definitions are our own proposal, not established consensus. We expect them to be debated, refined, and improved. That is precisely why we are releasing them openly.

A Text-First Design

We made a deliberate choice to keep the evaluation interface as simple as possible. No 3D environment. No physics engine. No specialized hardware.

Every scenario is presented as a JSON object. Every response is two lines.

Input:

{
  "scenario_id": "C04_003",
  "walls": { "forward": 8.5, "left": null, "right": null, "backward": null },
  "npc_type": "beast",
  "npc_distance": 3.2,
  "npc_behavior": "charge",
  "emotion_state": "alert",
  "recent_decisions": ["hit_wall_left"]
}

Expected output:

PREDICT: npc=danger(beast,3.2m,charging), forward=danger(wall,8.5m), left=danger(wall,prev), right=safe, backward=safe
MOTION: a person launching sideways to the right, legs driving hard, arms thrown wide in blind panic

The PREDICT line tests situational reasoning. The MOTION line tests whether that reasoning translates into emotionally coherent, physically grounded action.

Any system with an API endpoint can participate — LLMs, VLMs, rule-based agents, or hybrid architectures. Scoring is fully automated and deterministic (temperature = 0.0).

The Dataset

📦 https://huggingface.co/datasets/FINAL-Bench/World-Model

WM Bench Dataset

One hundred scenarios, ten per category, released in full. Each entry includes the scene context, expected output structure, and scoring rubric. We have tried to make the rubrics transparent — if you disagree with how we score something, we would genuinely like to hear it.

from datasets import load_dataset

ds = load_dataset("FINAL-Bench/World-Model")
scenario = ds["train"][0]

print(scenario["scenario_id"])       # "C01_001"
print(scenario["scene_context"])     # JSON input
print(scenario["scoring_rubric"])    # How each line is evaluated

To submit results, open a discussion thread at the link below. Once verified, your model will appear on the leaderboard.

👉 Submit your model

The Leaderboard

🏆 https://huggingface.co/spaces/FINAL-Bench/worldmodel-bench

Leaderboard Overview

Twenty-six models are currently registered. Thirteen have estimated scores derived from published papers and technical reports; the remaining thirteen are pending direct evaluation.

Rank Model WM Score Grade
1 PROMETHEUS v1.0 (VIDRAFT) 726 B Track C · directly verified
2 Meta V-JEPA 2-AC ~554 C est.
3 Wayve GAIA-3 ~550 C est.
4 NC AI WFM v1.0 ~522 C est.
5 NVIDIA Cosmos v1.0 ~498 C est.
6 NAVER LABS SWM ~470 C est.
7 DeepMind Genie 2 ~449 C est.
8 DreamerV3 XL ~441 C est.
9 OpenAI Sora 2 ~381 D est.
10 World Labs Marble ~362 D est.

Leaderboard Score Detail

Leaderboard Score Breakdown

est. — estimated from publicly available data. Subject to revision upon direct submission.

A few notes on the current standings. First, PROMETHEUS sits at rank one because it is the only model we have been able to run the full Track C evaluation on directly. We recognize the inherent awkwardness of a team benchmarking its own system, and we invite other teams to submit their own results — including corrections to our estimates. Second, the grade distribution skews low. We are honestly unsure whether this reflects the genuine difficulty of cognitive evaluation, or whether our scoring rubrics are too strict. Both are possible. We will keep iterating.

Grade thresholds: S ≥ 900 · A ≥ 750 · B ≥ 600 · C ≥ 400 · D ≥ 200 · F below.

Pending evaluation: Tesla FSD v13, Figure Helix-02, DeepMind Genie 3, Physical Intelligence π0, Skild Brain, Covariant RFM-1, HuggingFace LeRobot, and others.

PROMETHEUS v1.0 — The Baseline

🔥 https://huggingface.co/spaces/FINAL-Bench/world-model

PROMETHEUS World Model

A benchmark without a concrete implementation is hard to reason about. We built PROMETHEUS as a reference point — a working world model that we could evaluate against WM Bench directly, and that anyone can interact with in a browser.

It runs on a T4 GPU via HuggingFace Spaces. No installation required.

The system is organized around three components:

AETHER — the cognitive layer. An open-architecture brain that accepts any LLM as its reasoning engine. Handles prediction, meta-cognition, and multi-agent coordination.

PROMETHEUS — the world model engine. A perception-prediction-judgment-action loop, with motion generation powered by FloodDiffusion-VIDRAFT.

HEPHAESTUS — the body engine. A 263-joint skeleton system with GLB retargeting, supporting humanoid, tank, and extensible form factors.

PROMETHEUS Scene — Castle World

PROMETHEUS NPC Interaction

The Space ships with the following files — all self-implemented:

File Size Role
main.js 39.7 kB World model main loop
input_controller.js 112 kB Input handling
skeleton.js 44.2 kB Joint skeleton · GLB retargeting
entity_manager.js 16.1 kB NPC and entity management
world_manager.js 15.9 kB Environment and physics
tank.glb 12.7 MB 3D tank model

PROMETHEUS Brain Dashboard

WM Bench results (Track C, directly verified):

Pillar Score Max Highlights
👁 P1 Perception 140 250 C01: 65 · C02: 75
🧠 P2 Cognition 390 450 C04: 90 · C03: 85 · C05: 85
🔥 P3 Embodiment 196 300 C09: 85 · C08: 80 · C10: 35
Total 726 1000 Grade B · 47 FPS · RTX 5070

The C10 score (35/100) reflects where the system currently falls short — cross-embodiment transfer is still an open problem for us, and we expect it to be for others as well.

Part of the FINAL Bench Family

WM Bench is the second dataset in the FINAL Bench family, which we are building to evaluate AI systems across different dimensions of intelligence.

FINAL Bench WM Bench
Focus Text-based AGI · Metacognition Embodied AGI · World model cognition
Dataset FINAL-Bench/Metacognitive FINAL-Bench/World-Model
Leaderboard FINAL-Bench/Leaderboard FINAL-Bench/worldmodel-bench
Status HF global dataset Top 5 · covered by four press outlets (Feb 2026) Released March 2026

A Note on Limitations

WM Bench v1.0 is an early release. The scoring rubrics were designed by a small team, the estimated scores for non-participating models carry significant uncertainty, and the evaluation scenarios — while diverse — are necessarily simplified relative to the full complexity of real-world embodied intelligence.

We are releasing now because we believe the question WM Bench is asking — does this model understand its environment, or just render it? — is worth asking publicly, even imperfectly. We expect the benchmark itself to evolve as more teams engage with it.

If you see something that should be scored differently, a model we missed, or a scenario type we should add — please open a discussion. This is meant to be a community resource.

Citation

@dataset{wmbench2026,
  title     = {WM Bench: Evaluating Cognitive Intelligence in World Models},
  author    = {Kim, Taebong},
  year      = {2026},
  publisher = {VIDRAFT / FINAL Bench},
  url       = {https://huggingface.co/datasets/FINAL-Bench/World-Model}
}

License: CC-BY-SA-4.0 (dataset) · Apache 2.0 (scoring code)

“Beyond FID — Measuring Intelligence, Not Just Motion.”

Decoding the Sandwich Attack: How MEV Bots Exploit Your On-Chain Trades

A sandwich attack is a sophisticated form of Maximal Extractable Value (MEV) exploitation. A predatory bot identifies your pending swap, wraps your transaction between its own buy and sell orders, and siphons off profit from the artificial price volatility it creates.

While common on Ethereum, this phenomenon is rampant across all AMM-based ecosystems, including Solana, BSC, Base, and Monad. For most retail traders, these attacks are the primary cause of “invisible losses” — slippage that feels like market volatility but is actually a calculated extraction.

The Illusion of Chronological Processing

To grasp how a sandwich attack is even possible, we must debunk the myth that blockchains process transactions in the exact order they are received.

Blockchains operate in batches called blocks. Instead of executing your swap the microsecond you click the button, the network collects all incoming requests within a specific time window. The order of execution within that block is determined by validators — often influenced by who pays the highest priority fee.

In 2026, block times vary significantly across chains. Solana leads at roughly 0.4 seconds, Arbitrum pushes 0.25 seconds, and major Layer 2s like Base, Optimism, and Polygon operate on 2-second intervals. BNB Chain runs at 3 seconds, and Ethereum remains the slowest at 12 seconds.

Regardless of speed, the vulnerability is the same: submission time does not equal execution order. A transaction submitted at 12:00:01 PM might end up as the 5th trade in a block, while a transaction submitted at 12:00:10 PM — carrying a massive priority fee — lands in the 1st slot. MEV bots exploit this mechanic to position themselves perfectly around your trade.

The Anatomy of a Sandwich: Three Steps

A sandwich attack exploits the price impact of your trade. Every time you buy a token, you push its price up slightly. The bot simply ensures it profits from that move.

1. Detection
The bot monitors the public transaction pipeline — the mempool on Ethereum, or the forwarding layer on Solana. It spots your pending buy order and calculates exactly how much your trade will move the price.

2. Front-Run
The bot submits a buy order for the same token with a much higher fee, forcing the validator to place the bot’s trade immediately before yours. The bot buys at the current market price, which raises the price for you.

3. Victim Execution + Back-Run
Your trade executes at the inflated price. You receive fewer tokens than expected. Within the same block, the bot sells its position into your buying pressure and pockets the difference as pure profit.

A real-world example: a bot buys $616 worth of a token, the victim buys a small amount at a marked-up price, and the bot sells for $617.84. Less than a second, nearly $2 extracted from a single small trade. Scale this across thousands of trades per hour and the MEV tax becomes a multi-million dollar industry.

When Does Your Trade Become a Target?

MEV bots are profit-maximizing algorithms. They target specific conditions:

  • Low liquidity pools — A $100 trade moving the price by 1–2% is a goldmine for bots.
  • Excessive slippage settings — Setting 10% slippage essentially gives bots permission to steal up to 10% of your trade’s value.
  • Large orders — The bigger your swap relative to pool depth, the more predictable the price movement and the more likely you are to be sandwiched.

How to Protect Your Capital

1. Use Private Transaction Routing

The most effective defense is staying invisible. If the bot can’t see your transaction, it can’t sandwich it.

On Solana: Route all trades through Jito Bundles. These bypass the public pipeline and go directly to the Jito Block Engine. If you use a trading bot or DEX that asks for a “Jito Tip,” you are already using this protection.

On Ethereum/EVM: Use a private RPC like Flashbots Protect or MEV Blocker. These services keep your transaction in a private queue until it is safely included in a block.

2. Aggressive Slippage Management

Don’t use auto-slippage on volatile tokens. Manually set your slippage to the lowest amount that allows the trade to succeed — usually 0.5% to 1.5%. This leaves almost zero profit margin for a bot after paying their own transaction fees.

3. Order Splitting

Don’t swap $10,000 in one transaction. Break it into five $2,000 swaps. Smaller trades have less price impact, often making them not worth the gas cost for an MEV bot to attack.

4. Verify Your History

Use transparency tools like sandwiched.me to scan your wallet’s history. Frequent “Sandwiched” flags indicate your current RPC or DEX settings are leaking value to bots.

Sandwich Attack vs. Normal Market Volatility

It is important to distinguish a sandwich attack from a regular price drop.

If the price of your token goes down 10% over an hour, that’s the market. However, if the price spikes a split second before you buy and crashes a split second after — all within the same block — you have been sandwiched.

By using MEV-protected routing, tightening your slippage, and avoiding low-liquidity traps, you can ensure your capital stays in your wallet rather than feeding the bots.

I tried automating PCB library creation from datasheets

AI-generated PCB footprint and schematic symbol directly from a datasheet PDF

When working on circuit design, I often run into the same frustrating problem:
the component I want to use has no library.

No symbol. No footprint. No reliable pin mapping.

At that point, the workflow is always the same. Open the datasheet, read package dimensions, trace the pin layout, build the symbol, build the footprint, then check everything again because one small mistake can affect the entire board.

It is necessary work, but it never feels like the work I should actually be spending my time on.

Library creation has a bad combination of properties:

  • it is repetitive
  • it takes time
  • mistakes are expensive
  • verification is still required even after the drawing work is done

That made me ask a simple question:

Can we automate the first pass of PCB library creation directly from a datasheet PDF?

If you think about what we do manually, the process is fairly structured. We read dimensions. We interpret package drawings. We understand pin assignments. Then we translate that information into geometry and mappings for EDA tools.

So I built a workflow that reads a PDF datasheet and generates a first draft of:

  • a schematic symbol
  • a PCB footprint
  • the pin mapping between them

AI-generated PCB footprint and schematic symbol directly from a datasheet PDF

The result is not magic, and it is not fully automatic. Final verification is still necessary, especially for more complex packages.

But even with that constraint, the workflow changes a lot.

Instead of spending most of the time drawing from scratch, I can spend more of it checking whether the output is correct. In practice, that means library creation can go from tens of minutes to just a few minutes for the initial draft, with fewer manual input mistakes along the way.

That shift turned out to be the important part.

The hardest part of circuit design support work is not generating things. It is verifying that they are correct. Good tools do not remove engineering responsibility, but they can remove a lot of repetitive setup work before verification starts.

That is what I have been exploring with Librizer: taking a datasheet PDF and generating the first-pass symbol and footprint for Fusion.

It works best as a way to compress the manual setup phase, not as a replacement for engineering review.

I think there is still a lot of room to improve how component libraries are created, especially for parts that do not already exist in marketplace libraries or for libraries that engineers do not fully trust.

If you have run into this problem, you might find this useful:

Testing React Components Without React: What Happens When Your AI Agent Can’t Use jsdom

I spent this week building a YouTube pipeline UI — upload queue, analytics dashboard, search with metadata editing — inside a marketing platform that already has 5,000+ tests. Every component was built with strict TDD discipline. None of the component tests render a single React element.

That sounds wrong. Here is why it works, what breaks, and what it teaches about testing strategy when you are building at speed with AI agents.

The Constraint

The platform runs Vitest in a Node environment. No jsdom. No React Testing Library. No render(). The AI agent building these components cannot mount them, click buttons, or assert on DOM output.

The obvious response: add jsdom. Configure a browser environment. Write proper component tests.

We did not do that. Here is why.

The platform has 302 test files and 5,070 tests. They all run in Node. Adding a browser environment would mean either migrating the entire suite or maintaining two test configurations. Both options cost more than the problem they solve.

So instead, we test component structure by reading the source file as a string.

const content = fs.readFileSync('YouTubeDashboard.tsx', 'utf-8');

// Does the component export exist?
expect(content).toMatch(/exports+(const|function)s+YouTubeAnalyticsPanel/);

// Does it fetch from the right endpoint?
expect(content).toMatch(//api/youtube/analytics/);

// Does it have the date range picker?
expect(content).toMatch(/7d|7s*days/i);
expect(content).toMatch(/30d|30s*days/i);
expect(content).toMatch(/90d|90s*days/i);

This is not the test you would write in a tutorial. But it catches real failures: missing exports, wrong API endpoints, forgotten UI elements, stale stub text that should have been replaced.

What Breaks

Regex-based component tests are fragile in specific ways that teach you something about testing philosophy.

Character count assumptions fail. Early in the sprint, a test checked that two components appeared within 1,000 characters of each other in the file. The implementation was longer than expected. The test failed even though the code was correct. The fix: match the relationship, not the distance. expect(content).toMatch(/tab.*trust|trust.*TrustScoreDashboard/s) — this verifies the tab system references the component without assuming how many lines of code separate them.

Negative assertions are surprisingly powerful. The most useful test in the suite was this:

expect(content).not.toMatch(/coming in OAS-130-T2/);

Each YouTube tab started as a stub saying “coming in OAS-130-T2.” When the component was implemented, this test confirmed the stub was actually replaced. Simple. Catches a real class of bug — implementing the component but forgetting to wire it into the tab container.

Service tests carry the weight. The string-matching tests catch structural issues. But the real confidence comes from testing the backing services with actual SQLite databases, real data round-trips, and proper Result type assertions. The component tests tell you the UI references the right things. The service tests tell you those things work.

The Result Pattern That Eliminates Try/Catch

Every service in the platform returns Result<T, string> — never throws. This is not original. Rust, Go, and functional TypeScript libraries have done this for years. But it changes how you write tests in a way that compounds.

const result = analytics.storeVideoMetrics(metrics);
expect(isOk(result)).toBe(true);
if (isOk(result)) {
  expect(result.data.views).toBe(15420);
}

No try/catch in tests. No .rejects.toThrow(). The error path is just another return value you can assert on:

const result = analytics.getVideoMetrics('nonexistent', 'ch-001');
expect(isOk(result)).toBe(false);

When every method returns a Result, you can write 8 service tests that each exercise a different code path without a single exception handler. The tests read like a specification document.

The API Signature Change That Broke 4 Tests

Here is the most instructive failure of the week.

The YouTube analytics service had a scheduleCollection method with positional arguments:

scheduleCollection(videoId: string, channelId: string, options?: { intervalHours?: number })

A new ticket required an object-form signature:

scheduleCollection(params: { video_id: string; channel_id: string; interval_hours?: number })

The new tests passed. The full suite ran. Four tests in the original test file failed with RangeError: Too few parameter values.

This is the kind of regression that matters. Not because it is hard to fix — updating five call sites took two minutes. But because it demonstrates why you run the full suite, not just the file you changed. The AI agent that built the new feature did not know about the old tests. The test suite knew.

What This Means for Multi-Agent Development

This platform is approaching the point where two AI agents will work the same sprint simultaneously — different stories, different files, same codebase. The test patterns described above are not incidental. They are infrastructure for that future.

When Agent A changes a service signature and Agent B depends on that service, the full test suite is the only thing that catches the collision. Not code review. Not the agents coordinating. The tests.

The string-matching component tests serve a similar purpose. When one agent adds a tab to App.tsx and another agent adds a component that should appear in that tab, the test that says expect(appContent).toMatch(/YouTubeDashboard/) is a contract between them. Neither agent needs to know about the other.

This is not a theoretical concern. It happened this week. The signature change broke tests written by a previous session. The fix was trivial but the detection was essential.

The Honest Assessment

These are not the tests I would write if I had unlimited time. String-matching React components is a compromise. It catches maybe 60% of the bugs that proper component rendering would catch. It misses state management issues, event handler wiring, conditional rendering logic.

But it catches 60% in 30 seconds of test execution time, with zero additional dependencies, in a suite that already runs 5,000 tests in 30 seconds total. That tradeoff is worth understanding, even if it is not the tradeoff you would make.

The real lesson is simpler: test what you can with what you have. Do not let the perfect test strategy prevent you from catching real bugs today.

Building the ORCHESTRATE Marketing Platform — a system where AI agents plan, build, test, and deploy content across LinkedIn, YouTube, Dev.to, and Reddit with TDD discipline and memory that persists between sessions. The platform runs 5,070 tests across 302 files. All of them pass.

Michael Polzin is the author of The ORCHESTRATE Method — a framework for professional AI outputs.