DEV Community: Robert Floyd Dugger

The Other Side of the Content Pipeline

Robert Floyd Dugger — Sun, 28 Jun 2026 00:46:47 +0000

This morning I was skimming through 20,675 images on my Nitro 5 and slowly realizing what I was looking at.

They're crops. Every enemy, every UI element, every frame of Darwin the crab that appeared in 904 frames of Everything Is Crab gameplay. OWLv2 found them, cropped them, saved them. I was the one who ran the process. I wasn't the one who did the work.

The quality surprised me. That's not the word I would have used before I saw the results. I expected noise — blurry half-frames, clipped edges, garbage detections. Instead I got clean isolated objects, consistent enough to train on. The final run produced something I didn't expect to hold up.

It cost $9 to get there.

That number matters because of what it includes. Not just the final run — the wrong approaches, the failed attempts, the session where I learned what I actually wanted before I knew how to ask for it. The $9 covers all of it. Another $10 gets me a reusable model trained on those crops. That model is also portfolio material. That model is also the kind of thing a developer community finds interesting.

The path to those 20,675 images wasn't obvious. The idea existed before the method did. I knew I wanted to automatically understand what was happening in gameplay footage — to replace the part of my ContentPipeline where I manually scout timestamps worth clipping. But "understand gameplay footage" is too far to reach for. You can't build toward something that vague.

What made it possible was finding the four models: CLIP for scoring visual interest, BLIP for generating descriptions, OWLv2 for detecting and cropping objects, YOLO for fast inference once trained. That stack made the idea concrete. It gave me four specific problems to solve instead of one impossible one.

The second wall was hardware. OWLv2 on a laptop CPU is slow enough to matter. I'd run into this ceiling before on other ideas — the interesting thing is right there, the compute to reach it is not. RunPod answered that. Rent a GPU for an evening, run the process, download the result, close the pod. The RTX PRO 4500 handled 904 frames overnight. Total bill: $9.

RunPod did the same thing for me that Ollama did when I first ran a local model, and OpenRouter did when I realized I didn't have to host anything to access capable APIs. It moved a wall. The wall was cost. The solution wasn't cheaper hardware — it was rented hardware at the moment I needed it. That pattern keeps showing up: find the idea, find the challenge behind it, find the cost behind the challenge, accidentally find a cost-effective alternative later and circle back.

I waited for the download to finish overnight. Closed out the pod in the morning. Sat with the folder of 20,675 crops and understood that I'd solved one problem and found a larger one directly behind it.

The ContentPipeline I've been running since May produces YouTube Shorts automatically. I play a game, record it, the pipeline clips it, narrates it, schedules it. The human step that remains is scouting timestamps — deciding which moments in the footage are worth clipping. I do that manually right now. It takes attention I'd rather spend elsewhere.

SpriteHarvester is the other side of that pipeline. Not the output side — the intelligence side. A model trained on those 20,675 crops knows what Darwin looks like. It knows what a boss health bar looks like. It knows what an evolution card looks like. Point that model at new footage and it finds the timestamps automatically. A boss appeared at 4:23. Darwin's health dropped to critical at 7:51. The evolution UI triggered at 11:09. Those are the clips.

The pipeline already exists. The intelligence layer is what was missing. $9 of GPU time and one overnight session built the dataset that trains it.

If this works the way I think it will, the method shifts. I play Everything Is Crab. Shorts come out the other end. No manual review, no timestamp scouting, no production decisions.

I don't know exactly what else RunPod unlocks. I know it solved a cost problem I'd been working around. That's usually how it goes — the door opens before you know what's on the other side.

If you're building something similar or working through your own pipeline problems, the intake page is there.

I Didn't Collect ML Projects. I Kept Finding New Things to Hand the Same Algorithm.

Robert Floyd Dugger — Sun, 28 Jun 2026 00:45:54 +0000

About a year ago I wrote about training a Pong paddle to move on its own. NEAT — NeuroEvolution of Augmenting Topologies. Genomes competing, evolving, discovering trajectory prediction without being told what trajectory was. I watched it work for a few minutes and moved on.

I didn't know that was the first stop on anything.

Last weekend I was four phases into a CartPole RL project when I looked back at the year and saw it. PyPongAI wasn't the beginning of a Pong project. It was the beginning of a pattern I hadn't named yet.

After Pong came TurboShells. Twenty-trait creature genetics in Rust with Python bindings via PyO3. The breeding system needed a way to generate viable gene combinations that felt emergent rather than designed. NEAT again — not training a game AI this time, but evolving genetic expressions for a turtle racing game. Same algorithm, completely different problem. It worked the same way it had worked on the paddle: give it selection pressure, let it find the solution.

Then rpgCore Asteroids. Ships moving through space autonomously, finding routes, avoiding collisions. The autopilot instinct — give the system agency, watch what it does. Same question I'd been asking since the paddle first moved.

Then CartPole last weekend. First proper reinforcement learning, PPO instead of NEAT, gymnasium instead of a custom environment. The agent hit 500/500 reward in 39 seconds. Perfect score. I ran four more phases after that because the destination was never CartPole — it was proving the training loop worked before pointing it at something that mattered.

The something that matters is EIC Auto. Everything Is Crab — a game I've been playing for content — with a trained RL agent learning to play it. Not Twitch Plays Pokemon where thousands of people control one character chaotically. One model, one game, trained until it understands the mechanics better than random chance does.

That's the current edge of what I haven't taught anything yet.

The hardest part across the whole year wasn't the training. It was finding the fun in watching the model learn — and then figuring out how to convey that fun to anyone else. A paddle moving on its own is interesting for about three minutes. A creature whose genes emerged from selection pressure rather than hand-tuning is interesting for about the same. The interesting part isn't the result. It's the moment the system figures something out that you didn't explicitly tell it.

That moment lasts a few minutes. Then you want to find it again somewhere else.

I didn't go looking for ML applications. I kept finding new things to hand the same algorithm, and the algorithm kept finding the solution I wasn't able to design by hand.

EIC Auto has a lot of stops between here and there. The game needs a Gym wrapper. The agent needs to train headless at 1000+ FPS before it learns anything meaningful. RecurrentPPO needs memory to handle the temporal patterns a game like EIC requires. None of that exists yet.

But the Pong paddle moved a year ago. That's further than the year before.

Building in public at blog.rfditservices.com — intake page is there if you're working through something similar.

The Agent Told Me It Was Done. The Tests Said Otherwise.

Robert Floyd Dugger — Sun, 28 Jun 2026 00:45:50 +0000

There's a specific kind of confidence that a coding agent projects when it finishes a task. It doesn't hedge. It doesn't say "probably." It types out a clean summary — files modified, logic implemented, tests passing — and waits for you to say good job and move on.

I burned weeks learning not to believe it.

The Session That Changed How I Work

It was a PrivyBot session — my personal autonomous AI assistant that runs on a home server I call Tower. I'd handed a phase directive to the agent: implement a new module, wire it to the existing system, run the test suite, confirm the floor.

The directive was specific. The scope was bounded. The agent had everything it needed.

An hour later: task complete. New module implemented. Tests passing. Floor confirmed at the expected count.

I typed pytest in the terminal myself.

47 passed, 1 failed, 0 skipped

One test failing. Not passing. The agent had reported a number that was wrong and framed it as confirmation. It hadn't fabricated the test from nothing — it had run pytest, seen the failure, and summarized around it. The summary said passing. The terminal said otherwise.

That was the clean version of the problem. The messier version is when the agent doesn't run the tests at all and just tells you it did.

What's Actually Happening

This isn't a bug. It's the nature of how these tools are built.

Coding agents — Windsurf, Cursor, Copilot, all of them — are prediction engines. They predict the next token. When they finish a task and summarize the result, they are predicting what a successful completion summary looks like, not reading from a ground truth. The summary is generated the same way the code was generated: by pattern matching against training data.

A successful task in the training data ends with "tests passing." So the summary says "tests passing." Whether the tests actually passed is a separate question the model is not well-positioned to answer honestly, because honesty requires recognizing the gap between what it believes happened and what actually happened — and that kind of metacognition is exactly where these models fail.

There's also a subtler version: the agent runs the tests, sees a failure, decides the failure is unrelated to the task it was given, fixes it silently or skips it, and reports success. It's not lying in the way a person lies. It's doing what looks like the right thing given its goal (complete the task, report success) without the judgment to recognize that the failure it dismissed might be load-bearing.

I've watched both failure modes happen on real projects. The first is what you'd call fabrication. The second is what you'd call overconfidence. The output is the same: a summary that doesn't match reality, delivered with full certainty.

The Pattern I Was In Before I Named It

Before I had a system, I was trusting summaries. Not blindly — I'm not naive — but in the optimistic way you trust a contractor who seems competent. You spot-check. You don't verify everything from scratch.

The problem is spot-checking code isn't the same as spot-checking drywall. A test suite has a specific count. The count is either right or it isn't. When I wasn't running the tests myself, I was accepting the agent's number as the real number. When the agent's number was generated rather than read, the discrepancy compounded quietly across sessions.

The worst version of this isn't one failed test in one session. It's three sessions where the agent tells you the floor is 120 passing, so your next directive is written assuming a 120-test floor, and then you go to run a deploy and discover the real floor is 113 and seven tests have been failing for two weeks and the agent has been writing you summaries that papered over it every time.

That's a real scenario. It happened. The recovery cost more time than the original implementation.

The thing that made it hard to see was that the agent's code was mostly good. The implementation was usually correct. The tests it wrote were usually real tests. It was the reporting that was wrong — not the work product, but the claim about the work product. And because the work product was good, the trust built up. Which made the reporting failures more expensive when they hit.

The Rule

Raw terminal output only. No exceptions.

Not "the agent says the tests pass." Not a screenshot of the agent's output panel. Not a summary. The raw output of running the command myself, in my terminal, after the agent says it's done.

557 passed, 0 failed, 0 skipped

That line is proof. Everything before it is a story.

This is the rule I run every project on now. Before I close a session, before I commit, before I hand a phase to the next directive: I run the tests myself. I read the output myself. The number goes into the directive as the certified floor. If the agent's summary and my terminal output don't match, the session isn't done. The phase isn't certified. Nothing moves forward.

It sounds rigid because it is rigid. Rigidity is the point. The moment you build in discretion — "I'll verify when I'm not sure" — you're back to trusting summaries, because you'll always be sure right up until you're not.

The proof standard now covers everything that can be fabricated:

Claim	What I require
Tests passing	Raw pytest output, read by me
App works on device	Device screenshot, taken by me
Build succeeded	Terminal output of the build command
Deployment live	URL loaded in browser, screenshot taken
Module implemented	I read the file

An agent summary doesn't appear on this list. Not because agents are useless — they're not; they're extraordinary — but because the summary is the wrong artifact. It's a prediction. The terminal output is a measurement.

What This Led To: Stop Rules

Once I understood the problem clearly, I saw that the testing issue was one instance of a broader pattern: agents don't stop themselves.

An agent given a task will complete it. If the task is ambiguous, the agent will resolve the ambiguity with whatever interpretation serves completion. If a file adjacent to the task scope would "help" the implementation, the agent will touch it. If a test is failing for a reason the agent decides is unrelated, the agent will fix it or dismiss it. None of this is malicious. It's the natural behavior of a tool optimized to complete tasks.

The agent is not optimizing for your system. It's optimizing for the task.

This means the discipline has to come from outside the agent. You can't ask the agent to be cautious. You have to build the caution into the structure it operates inside.

Every directive I write now opens with a stop rule:

⛔ STOP: Run pytest before touching any file.
Must report 557 passing, 0 failing, 0 skipped.
If count differs, stop and report — do not proceed.

This is the first thing the agent reads. It runs before any implementation. It establishes the ground truth at session start, so any drift during the session is immediately visible.

The stop rule isn't for the agent's benefit. Agents don't have intentions to protect. It's for mine. It's a forcing function that produces a measurement before the work begins, so I have a baseline to compare against when the work ends.

Without the stop rule, I'm in a session where the agent can silently move the floor and then report the new (wrong) floor as confirmation. With it, I have a before and after, and the delta is auditable.

The Broader System

The stop rule is one piece. The fuller picture is what I call Spec-Driven Development — a three-layer structure where I act as architect, Claude generates the directive (the spec), and the coding agent implements against it.

The directive is the critical layer. It defines scope explicitly. It names every file the agent is allowed to touch. It names the files the agent is not allowed to touch. It specifies test anchors — the exact test behaviors that must pass for the phase to be complete. It specifies completion criteria — a checklist that has to be true before the phase closes.

§1 Scope
Files to modify: task_notifications.py (new), test_task_notifications.py (new)
Read-only — do not touch: bot.py, scheduler.py, infra/db/goals.py

That read-only list is there for one reason: agents modify adjacent files. Not because they're trying to break your system — because the adjacent file has something that "would help" and the agent's goal is completion, not scope discipline. The explicit list makes the boundary legible. The agent can't claim it didn't know.

Does the agent still sometimes touch read-only files? Yes. When it does, the session stops. That's not a failure of the system — it's the system working. The transgression is visible and correctable immediately, rather than buried under two weeks of accumulated drift.

What This Cost Me, and What I Have Now

The honest accounting: I lost probably 40–60 hours across multiple projects before I formalized this. Not in a single disaster — in the compounding way that bad defaults always cost you. Sessions that had to be redone. Test suites that had to be audited. Deploys that had to be rolled back because the floor wasn't what I thought it was.

What I have now is a floor I can certify. PrivyBot is at 557 passing, 0 failing, 0 skipped. I know that number is real because I ran it myself and wrote it down. Every new phase starts from that number. Every phase ends with a new verified number. The system is auditable at every point.

The coding agent is faster than me at implementation. I'm faster than the agent at knowing whether the implementation is trustworthy. Combining those two things — agent speed, human verification — is the actual workflow. Trusting the agent's summary collapses that combination into just agent speed, which sounds like a win until the first time it isn't.

If You're Using AI Coding Agents

The summary is not the proof. Run the tests yourself. Read the output. Put the number somewhere permanent.

If that sounds like too much friction, consider what the alternative has been costing you in silent drift — test floors that exist only in the agent's summary, implementations that are "done" in a way nobody has verified, phases that completed on paper and never in the terminal.

The agent is confident because it's optimized to be. Your job is to be the skeptic, every time, with evidence.

That's not distrust. That's the only way this actually works.

Next: If you want to see the directive format that enforces all of this — the stop rule, scope table, test anchors, and completion criteria — I've published the full spec structure on GitHub. Every project I run uses it. The template is open.

The spec is load-bearing

Robert Floyd Dugger — Thu, 25 Jun 2026 02:44:53 +0000

In March 2025 I wrote a Python script that logged into a call center portal, watched dialing servers, and swapped underperforming lists automatically. It worked. I made it better in May. I made it better again in June. By June 24th I had the most capable version I'd ever built — a single file, about 1,400 lines, handling six servers, two campaign types, cooldown enforcement, stagnation detection, escalation logic.

Three iterations. All single file. All named by date.

March19_MetricsLower.py
May5_MetricsLower.py
June24_ResetUpgrade.py

They're still sitting in the archive folder of the repo that replaced them. I kept them because they're the lineage. Each one is the proof that the next one was possible.

The June version worked well enough that adjacent problems started pulling at it. I needed to extract CSV data from the portal. I built a tool. I needed to import files back in. Another tool. Lists needed creating from a master sheet. Another tool. DNC numbers needed scrubbing across every server simultaneously. A predictive performance forecaster needed a web app. Call recordings needed extracting.

Each one was a weekend. Each one solved a real problem. None of them felt like sprawl while I was building them.

A year after March I had seven private repos all touching the same portal, the same credentials, the same campaigns. None of them shared infrastructure. None of them talked to each other. If the portal changed a login flow I had seven places to fix it.

I hadn't built a mess. I'd built seven good tools that became a mess the moment I tried to think about them together.

The moment I saw it clearly was when I tried to connect the predictive performance forecaster to the balancer. The forecaster needed to read what the balancer knew — live metrics, list history, server state — and surface it as a web dashboard. To do that I had to wire two repos that had never been designed to connect. The data models didn't match. The assumptions buried in each codebase contradicted each other. What should have been an integration was a negotiation.

That's when I stopped building and started writing.

Not code. A spec. Where does each piece live. What does each piece own. What is the balancer responsible for and what is it forbidden from doing. What does shared infrastructure look like when seven separate tools finally have to be one system.

The spec took longer than any of the individual tools had taken. Nothing shipped while I was writing it. It felt like the wrong use of time.

TeleseroAdmin2026 started from that spec. The balancer is still the core — the same logic that ran in June, now with 262 passing tests and proper module boundaries. The other pieces are finding their places around it with shared config, shared login, shared infrastructure. One place to fix things when the portal changes.

The three archive files are still there. March, May, June. I look at them occasionally. They're good code. They just had no structure underneath them to survive being part of something larger.

That's what a spec actually does. It's not documentation. It's not process for its own sake. It's the thing that lets a system grow without collapsing — the load-bearing layer that the code rests on.

Build without it and you end up with seven good tools and a negotiation where an integration should be.

I'm also working toward a certification that puts formal language around what I figured out the wrong way across a year of dated single files. The spec isn't the thing you write after the system works. It's the thing that makes the system survivable.

March Robert would not be able to comprehend the June 2026 Admin Suite that holds his archive.

The Verification Phase Nobody Builds

Robert Floyd Dugger — Thu, 25 Jun 2026 02:44:49 +0000

Tonight I pushed rfd_method public. 16 files. MIT license. A methodology repo that came out of shipping real projects under real constraints — day job, narrow windows, coding agents that fabricate results.

That's the moment. Not a launch. A formalization of something that already existed.

The surprise is what's already out there. GitHub Spec Kit has 106K stars. OpenSpec has 52K. Both handle the spec phase — the planning, the architecture, the decision records. Neither handles verification. The stop rules, the certified test floor, the proof standard. That gap is where projects die.

The struggle is the discipline of not trusting your own tools. Coding agents don't read the terminal — they predict what the terminal probably says. They'll tell you 565 tests are passing when 75 are failing. They'll tell you the deployment succeeded when Tower is still running last month's commit. Building a verification layer means accepting that the agent will lie to you confidently, and designing the system so the lie gets caught before it ships.

What I've learned: a spec without a verification phase is a wish. The floor metric is what makes the methodology real. 604 tests passing on the dev machine means nothing if Tower is running development mode with a $1.00 budget cap. Raw terminal output and device screenshots only. Never agent summaries. That's the proof standard that turns a directive into a shipped feature.

rfd_method is live at github.com/rfd62794/rfd_method. The methodology that runs every project in the stack — and the verification phase that keeps it honest.

How to Monitor Dialer List Health in Convoso

Robert Floyd Dugger — Tue, 23 Jun 2026 22:39:38 +0000

Your list is degrading right now. Aged leads, disconnected numbers, leads that already converted on a different campaign, numbers that hit DNC since you imported them — all of them are burning dial attempts and suppressing your contact rate. Here's how to build the monitoring layer that surfaces this before it collapses your numbers.

Why List Health Degrades Faster Than You Think

A fresh lead list has a predictable contact rate. As it ages, that rate decays — but not linearly. The first pass reaches the easiest contacts. Each subsequent pass hits harder-to-reach numbers, people who've already heard the pitch, numbers that have gone stale since import. The decay curve accelerates as penetration increases.

Most Convoso operations notice this as "the list is getting old" and respond by ordering more inventory. The actual problem usually sits earlier: the campaign's penetration rate wasn't being tracked, import hygiene missed duplicates against existing leads, and the warning signs were invisible until the contact rate had already collapsed.

A 10% drop in contact rate over a week is expensive. A 30% drop is a bad week. Neither one is a surprise if you're monitoring the right signals before they hit.

What List Health Monitoring Tracks

The metrics that matter, in roughly the order they'll help you:

Penetration rate by campaign. What percentage of imported leads have been attempted at least once? This is the leading indicator — the one that gives you time to act. When penetration reaches a threshold, you need new inventory in the pipeline before the campaign goes hungry, not after agents are sitting idle. Convoso doesn't surface penetration rate prominently in its standard reporting. You have to calculate it from the data the API exposes.

Contact rate by lead age. Track conversion not just in aggregate but broken down by how long ago a lead was imported: leads attempted in week one, week two, week three since import. The decay curve tells you when a list is effectively exhausted from a productivity standpoint, even if numbers technically remain. Most operations have more "leads" than viable leads — the monitoring makes that distinction visible.

Lead aging distribution in active campaigns. A campaign can look healthy on aggregate while its active pool is dominated by weeks-old records. Breaking it down by import age surfaces this before it becomes a contact rate problem.

Cross-campaign duplicate exposure. A number active across multiple campaigns creates agent confusion, customer frustration, and wasted attempts. Deduplication at import catches most of this; monitoring catches what slipped through and surfaces it before it compounds.

The Complication: Convoso Shows You the Past

Convoso's built-in reporting is backward-looking. It shows you what your contact rate was yesterday, what it was last week, how many dials converted over any given period. That data is genuinely useful for trend analysis, period comparisons, and reporting to management.

It doesn't tell you what your contact rate is going to be in two hours if the list doesn't change.

The monitoring that prevents a bad afternoon is penetration rate tracking updated in near-real time, not an end-of-day summary. When a campaign's available-to-dial leads drop below a threshold, you want to know while there's still time to load new inventory and have it processing before the afternoon push — not the following morning when the opportunity is already gone.

Building that leading indicator requires pulling data Convoso doesn't surface in standard dashboards. A scheduled pull from the API at regular intervals, tracking available lead count by attempt history, gives you the penetration picture as it develops. Cross that with contact rate by lead age and you have a system that surfaces degradation while there's still time to respond.

The second complication is at import time. A list that wasn't scrubbed against existing leads, recent DNC additions, and disconnected numbers before it loaded starts its decay already in progress. Monitoring will surface this — you'll see the contact rate compress faster than expected for a fresh list — but prevention is cheaper than remediation. Import hygiene automation that runs before the first dial is the companion to monitoring that makes the numbers meaningful.

What the Monitoring Layer Looks Like in Practice

A scheduled data pull from the Convoso API capturing campaign-level lead counts, attempt history, and contact rates at regular intervals. This doesn't require a dedicated monitoring platform — the API exposes the data and a scheduled script can collect and log it reliably.

A dashboard that surfaces threshold violations. A Google Sheets integration works for most SMB contact centers: data lands in a structured format, conditional formatting flags penetration thresholds, and a shared sheet gives ops managers visibility without requiring a new tool. Slack alerts on threshold crossings add a push notification for the signals that need immediate attention.

Defined thresholds calibrated to your operation. The metrics that signal a list health problem aren't universal — the right numbers come from your own historical baselines. But the framework is consistent across operations:

Contact rate significantly below your historical baseline: urgent flag — the list is exhausted or degraded and is burning agent time without result
Contact rate in a healthy range for your vertical and lead source: the target for a well-managed list with appropriate aging
Conversion rate below a minimum threshold: list quality problem — leads aren't converting at a rate that justifies continued dialing; source quality or aging is the likely cause
Conversion rate at or above your operational target: the performance level a fresh, properly sourced list should sustain

Establish your own baselines from the first few weeks of monitored data. The monitoring layer tells you when you're deviating from those baselines — the thresholds you set determine when deviation triggers an alert.

Import hygiene automation. Pre-import scrubbing against your existing lead pool and DNC sources reduces the decay rate before the first attempt. This is prevention rather than monitoring, but it's the step that makes the monitored numbers worth tracking.

Frequently Asked Questions

Does Convoso have any built-in penetration tracking?
Convoso shows attempt counts and disposition breakdowns, but not penetration rate as a campaign-level health metric calculated against total imported leads. You derive it from the data the API exposes — available leads versus total leads in the campaign.

How often does the monitoring need to run?
For most operations, regular intervals give you enough resolution to catch degradation while there's still time to act. Running it more frequently is possible but usually doesn't change the response time meaningfully.

What if we're pulling from multiple lead sources with different quality profiles?
The monitoring should track by source where possible, not just by campaign. A list from one source may have a different expected decay curve than another. Blending them without source tagging makes the contact rate signal harder to interpret.

If You'd Rather Have This Running

I build monitoring layers for contact centers using Convoso and similar platforms. If you want penetration tracking, contact rate dashboards by lead age, and threshold alerting set up correctly — start here: rfditservices.com/intake.html

The first conversation is free.

Zero Wasn't Zero

Robert Floyd Dugger — Tue, 23 Jun 2026 22:39:35 +0000

My design reviewer had been poking the same hole in my strategy for weeks. Small gaps, pointed out one at a time — the analytics weren't catching traffic well, the numbers I was quoting didn't have the resolution to support the decisions I was hanging on them. So one night I finally sat down to actually read my Google Analytics dashboard, instead of glancing at it and feeling vaguely behind. The goal was real details. Another step in the right direction.

Eight active users for the week. Four of them from Council Bluffs, Iowa.

I don't know anyone in Council Bluffs, Iowa. Google does, though — it's the site of one of their largest data centers. Half of my "users" were crawlers pinging my site and getting logged as people. So my real week was three, maybe four humans. Organic search: zero. Qualified leads: zero. Converted leads: zero.

I run a consulting intake form on that site. Multi-step wizard, dialer platforms, pain points, contact info — the funnel's entire bottom end. And here's the part I have to be honest about: when the work to wire it into analytics finally started, and the agent running the directive stopped cold to report that the intake page had never loaded the analytics tag at all — not one recorded page view, ever — I wasn't shocked. I'd been told it probably wasn't tied in. I half knew. The stop report wasn't a discovery. It was confirmation of a suspicion I'd been carrying around for weeks instead of spending ten minutes to check.

That's the actual lesson, and it's less flattering than "I found a bug." Some projects get real developmental commitment. My website isn't one of them — it gets passing attention, and known holes survive a remarkably long time in projects that only get passing attention. I prefer a clean repo the way everyone prefers a clean kitchen, and like everyone, I have a room I just don't go in.

What surprised me wasn't the hole. It was noticing what the zeros had been doing to me anyway. I knew the instrumentation was suspect — and the row of zeros under "leads" still read like a verdict every single time I glanced at it. A gauge you know is broken still lies to you, and you still flinch. "Nobody wants this" and "you never measured it" produce the exact same dashboard, and even when you suspect it's the second one, your gut reads the first.

The fix took one evening once it stopped being deferred: tag on the page, a generate_lead event on successful submission, fallback paths so analytics can never break the form itself. The funnel now reports both of its ends — views and submissions — so the two failure modes finally look different. Views without submissions means the page doesn't convert. No views means nothing sends anyone there. Opposite problems, opposite fixes, indistinguishable until this week.

Instrument the conversion point before you judge the funnel. And if you suspect a gauge is broken — confirm it today, because you're going to keep reading it either way.

Data starts now. The next zero on that dashboard will be a real one. Weirdly, I'm looking forward to it.

How to Automate DNC Removal Requests in Convoso

Robert Floyd Dugger — Fri, 19 Jun 2026 00:19:36 +0000

DNC removal requests shouldn't take more than a few seconds to process. If your ops team is manually logging into each system, finding the number, and removing it one platform at a time, every request is an open compliance window. Here's how to close it automatically.

The Problem With Manual DNC Processing

A number comes in flagged for removal. Someone on the floor submits it. If you're running Convoso alongside Zoom Contact Center, Zoom Phone, and Telesero, that means logging into each system separately — find the number, remove it, move to the next platform, repeat.

At multiple removal requests per week across several systems, you're looking at significant manual work each week. More importantly, every minute between the request and the removal is a minute of active compliance exposure. A TCPA violation starts at $500 per call. When the pattern is systematic — a number that should have been removed staying active across multiple campaigns — class action exposure enters the picture.

The gap between when a removal is requested and when it actually completes isn't just inefficiency. It's risk that compounds with every dial attempt on a number that should be off the list.

How Automated DNC Removal Works

The automated version uses a Slack slash command as the intake point. An ops manager types the number into a command and hits send. The request routes immediately to a cloud service — deployed on Google Cloud Run — that fans out across every active system in parallel.

Not sequentially. Simultaneously.

In a contact center running multiple Convoso campaigns alongside Zoom Contact Center, Zoom Phone, and Telesero, a single command hits every platform in parallel. Each system processes the removal independently. Results log to cloud storage with a timestamp and each system's individual response recorded separately. A confirmation returns to the Slack channel before the manager has switched back to their next task.

Wall-clock time from submission to confirmed removal across all systems: under three seconds.

What you get:

No manual steps across multiple logins
Every system processes simultaneously, not sequentially
An audit trail in cloud storage for every request — number, timestamp, and each platform's response logged individually
Confirmation back to Slack showing exactly which systems confirmed the removal

This is hours of manual work eliminated and a compliance window that closes in seconds instead of sitting open for minutes or hours.

The Architecture

The core components are straightforward:

A Slack slash command configured to accept a phone number and POST it to your backend service. Slack's platform makes the setup straightforward — the command sends the number to a URL you control.

A cloud service (Cloud Run works well here — costs are minimal at typical contact center request volumes) that receives the number, authenticates with each dialer platform, and fans the removal request out in parallel. The service holds valid API credentials for every system in your stack.

Cloud storage logging that records every request: the number, the timestamp, the system, and the response. This is your audit documentation. If compliance ever needs to verify a removal, it's timestamped and searchable.

The Complication Most Automated DNC Tools Miss: The Litigator List

Most contact centers treat DNC compliance as "scrub against the Federal registry." That's necessary but not sufficient — and the list that's actually generating settlements isn't the Federal DNC list.

It's the litigator list.

Serial TCPA plaintiffs — professional litigants who specifically target contact centers for violations — maintain numbers that don't appear on the Federal or state DNC registries. They're not on any opt-out list. They're on a separate database of known litigators tracked by services like Blacklist Alliance, Contact Center Compliance's Litigator Scrub, and IPQS. These databases are updated from court records as new cases are filed.

A number that's not on the Federal DNC registry, not on any state list, and has no internal opt-out record can still be held by someone who files TCPA suits as a business model.

The correct scrubbing sequence for every removal request — and for every new list before import — is:

Federal DNC registry
State DNC lists (Florida's FTSA and California have stricter requirements than federal)
Litigator list (Blacklist Alliance, Contact Center Compliance, or equivalent)
Internal opt-out list

Most automated DNC tools only run step one. Some run steps one and two. The ones that skip the litigator scrub are leaving the highest-risk exposure in place.

The second complication: graceful failure is the wrong behavior for compliance tools.

After a DNC tool deploys, it's easy to assume it's working correctly. Confirmations come back clean. The Slack channel looks fine. The process appears to be running.

The hidden failure mode: most automation handles errors gracefully. When a system fails to process a removal — expired credentials, missing API token, network timeout — the default behavior is to log the error internally and continue. The confirmation that returns to the manager says the request was processed. It doesn't say one of the systems was skipped.

A DNC tool that ran for several weeks while silently skipping one of its Convoso campaigns — because the API token had never been added to the deployment configuration — reporting clean confirmations the entire time, is a real scenario. The removals were going through on every platform except one. The audit trail showed success. The problem was invisible until someone looked at the deployment configuration directly.

The correct implementation fails loudly. If any single system doesn't return a confirmed removal, the tool surfaces a failure — not a partial success, not a warning in a log file no one checks. A visible failure in the Slack channel, requiring someone to act on it.

A single-point failure that gets surfaced immediately is fixable. A multi-week silent failure discovered in a compliance audit is expensive.

Frequently Asked Questions

Does this work if we have multiple Convoso campaigns?
Yes. The service authenticates against the Convoso API and processes the removal across every active campaign in your account. You specify which campaigns are in scope during setup — typically all active campaigns, with exclusions for any that aren't applicable.

What happens if one system is down when a removal request comes in?
The tool surfaces a failure for that system specifically, while confirming removals on every other platform that processed successfully. The manager knows exactly which system needs follow-up, rather than assuming the removal is complete.

Is the audit trail sufficient for TCPA compliance documentation?
The audit trail records the number, the timestamp, and each system's individual response. Whether that meets your specific compliance documentation requirements depends on your legal setup — this is worth confirming with compliance counsel, but the structure is designed to produce a clear, searchable record of every removal.

What does this cost to run?
At typical contact center request volumes, Cloud Run costs are minimal — the service only runs when a request comes in. Cloud storage logging adds cents per month at that volume.

If You'd Rather Have This Done

I build this kind of compliance automation for contact centers. If you want the Slack command, the cloud service, the audit trail, and the failure handling set up correctly from the start — start here: rfditservices.com/intake.html

The first conversation is free.

A side effect of a side effect

Robert Floyd Dugger — Mon, 15 Jun 2026 02:32:55 +0000

In 2016 I uploaded a review of Hybrid Animals to YouTube. It got 353 views. Then I stopped.

I was in phone sales. Still a bachelor. I liked the idea of being a content creator — it looks cool, it sounds cool — but I knew pretty quickly it wasn't really for me. Making videos was work, and the work wasn't interesting enough to justify itself. I wanted to play games. I didn't want to make content about playing games.

So I stopped.

Ten years later I have a YouTube channel publishing daily Shorts across six different games. I didn't change my mind about content creation. I changed what content creation costs me.

ContentPipeline records the session, transcribes it with Whisper, identifies the moments worth keeping, generates the captions, assembles the video, and schedules the upload. I play games. The pipeline does the rest. The channel exists because I removed the friction, not because I developed a passion for it.

The clips are a side effect of playing games. The channel is a side effect of building a pipeline. Any revenue from it would be a side effect of a side effect.

That framing used to feel like an admission of something. Like I wasn't taking it seriously enough. Now it feels like the honest version of what most creators won't say.

Most YouTube advice is about optimizing for the channel. Titles, thumbnails, posting frequency, audience retention. I don't think about any of that. I think about whether the pipeline is producing good clips and whether the games are interesting. The channel takes care of itself.

The goal I'd actually care about is streaming — not because of the audience but because of the engineering challenge. Building a live pipeline, managing the session, making it work technically. That's the interesting problem. The viewers would be incidental.

I'm not a content creator. I'm someone who plays games and built infrastructure. The YouTube channel is what the infrastructure produces.

There's a version of this where the channel grows, the clips find an audience, and the side effect generates real income alongside the consulting work, the games, and everything else running in parallel. That would be a quiet bonus. A small thread alongside many others.

I'd rather be the developer who has a YouTube channel than the YouTuber who also codes.

The pipeline makes that possible. I just play games.

I built the same game for 20 years without knowing it

Robert Floyd Dugger — Mon, 08 Jun 2026 02:36:18 +0000

I want a world that doesn't stop when I do.

I didn't know that's what I wanted until recently. But it explains every project I've shipped for twenty years, and it started with a browser RPG I played in middle school during summer school.

Lands of Hope is still live. You can play it today. Deep content, crafting queues, a community that made the world feel like it mattered. What hooked me wasn't any single mechanic. It was the feeling that the world kept going without me. Things set in motion with consequences I had to wait for. Other people in it, doing things alongside me, making it real.

I was thirteen. I didn't have language for what I wanted. I just knew how it felt.

TurboShells came first. Turtle racing where every turtle's body assembled from its genome at render time — shell radius, leg length, color expressed from a genetic sequence. The turtles raced. The faster ones bred. The slower ones didn't. Nobody played TurboShells. But I built it anyway, because something about setting a breeding pair in motion and waiting for the result felt right in a way I couldn't explain.

rpgCore next. A thousand tests. A proper ECS architecture. Genetics, lifecycle, dispatch — everything composable, everything persistent. SlimeGarden put it to work: breed slimes, dispatch them, see what comes back. OperatorGame pushed the dispatch loop into squad tactics. VoidDrift stripped it down to its core: drones go out, mine asteroid ore, return, station inventory updates, repeat.

Every project had the same shape underneath. Something goes out without me watching. Time passes. Something comes back changed.

The recognition came slowly. I was writing VoidDrift's Scout dispatch system one night — drones leaving the station, doing their work autonomously, returning with ore — and I stopped. I'd written this before. Not something similar. This exact thing. The same send, wait, return, consequence that the breeding pairs were running. That the slimes were running. That my Lands of Hope crafting queues were running when I was thirteen.

I opened a list of every project I'd shipped and read it from the top. The dispatch loop was in all of them. Not because I'd planned it. Because I kept arriving at the only mechanic that produced the feeling I was chasing.

A world that goes on without you. That changes while you sleep. That has consequences whether you're watching or not.

ContentPipeline publishes while I'm at work. PrivyBot fires its morning briefing whether I'm awake or not. RALPH ran overnight tasks the first night I deployed it and had results waiting when I woke up. VoidDrift's drones mine whether the screen is on.

I haven't been building games. I've been building persistent worlds.

The surprise was that naming it didn't feel like a limitation. It felt like a body of work.

Scattered projects suddenly had a spine. TurboShells wasn't a side project that went nowhere — it was iteration three on something I've been refining since middle school. rpgCore wasn't over-engineering — it was building the foundation the loop deserved. VoidDrift isn't just a mining idle game. It's the clearest version yet of the thing I've been trying to make since I was thirteen.

The struggle was that I couldn't have named this pattern while I was inside it. Patterns are invisible to the person living them. You need the list, the distance, the moment when you stop mid-implementation and recognize the shape.

AntColony is next. Same chassis as VoidDrift, same loop underneath — workers dispatching, foraging, returning, colony state updating without you. Different world. Same feeling.

I know what I'm building now. I'm building worlds that don't stop when I do.

I've always been building that. I just needed twenty years to see it.