Meet the Minions: Building an AI Workforce and Making It Earn Its Keep

We didn't set out to build an AI workforce. We set out to build products. But when you're running a small operation with several ambitious projects, research, development, QA, sales, and infrastructure all compete for the same hours. So we started experimenting with a different way of working.

Not one chatbot pretending to be a company. Different AI systems with different responsibilities, connected by tools, a relay, email, and a persistent Chief of Staff. Some research. Some monitor. Some verify. Some fix things. And one very busy owl tries to make sure the work actually gets finished.

The goal isn't more AI activity. It's more completed, verified work per dollar.

First, why Benny's Lab exists

Benny's Lab is our proving ground. Our commercial business is Bikefit.cc, where we're building technology for bicycle retailers. Real customers and commercial relationships aren't the place to discover that a new agent can't reliably finish a task.

So we build useful projects in the Lab, test the technology on genuine problems, and only move proven capabilities into the business. The projects aren't disposable demos. They're products and experiments with their own value.

Sports Intelligence: engineering under pressure

Sports Intelligence combines sports data, market signals, model outputs, scheduled refreshes, and user-facing software. When odds move or games finish, the system needs fresh data and accurate results. It's an excellent place to test monitoring, debugging, automated repairs, deployment discipline, and independent verification.

Coach Atlas: research and data quality

Coach Atlas is a cycling coach directory that tests automated sourcing, enrichment, deduplication, profile management, and database workflows. Those are exactly the sorts of capabilities we can later reuse for Bikefit's commercial research.

Benny's Race Audits: evidence and verification

Benny's Race Audits explores AI-assisted investigation of race results and licensing eligibility using public records. The challenge is not merely finding a suspicious entry: it's distinguishing a lead from a verified finding, preserving evidence, and avoiding unsupported conclusions.

Our AI staff has to earn trust, too. An agent that can't reliably maintain a sports dashboard shouldn't be trusted to make unsupervised changes to a customer-facing application. Competence is demonstrated through results, not impressive promises.

Grok, ChatGPT, and the first automated workers

ChatGPT became a product, engineering, and coordination partner. Grok became a major research engine. Instead of having two powerful systems duplicate every task, we started assigning them different work.

Then came the GrokBots. The Sports Intelligence monitoring bot checks data freshness, refresh failures, anomalies, and API usage, with monitoring more active around football weekends. The Leads bot researches bicycle retailers and contacts, helping feed the commercial prospecting pipeline. They gather evidence and report; they don't automatically get authority to change everything they inspect.

The relay and the emails

Independent AI systems don't magically share conversations or task states. So we built the Benny's Lab Grok Relay to exchange bounded requests, project context, messages, and results between systems. That beats manually copying entire conversations back and forth, and it avoids paying to reprocess irrelevant history.

Email became another practical coordination channel. GrokBots can send monitoring reports, research findings, and exceptions into Gmail. The messages provide a durable record and a familiar way to move information between systems with different integrations.

But an email describing a broken pipeline doesn't fix it. A relay message saying “assigned” doesn't mean “done.” Communication was solved before execution was solved.

Enter Woutson and the specialist team

Woutson, our persistent AI Chief of Staff, owns recurring oversight, follow-through, and coordination. Rather than having a founder babysit every handoff, Woutson is responsible for getting work to the right specialist and checking that something useful comes back.

Our new specialists have distinct roles: Scout handles bounded discovery and research; Sales Operations qualifies leads and prepares campaigns; Research & QA independently investigates and verifies; and Release Manager performs authorized engineering, testing, and deployment work.

Custom MCP: the breakthrough we should have tried sooner

Connecting agents to their tools was one of the most frustrating parts of the experiment. We spent hours wrestling with preconfigured integrations, OAuth errors, and repeated authorization attempts. A Supabase connection even returned Unrecognized client_id.

Eventually we switched to purpose-built MCP connectors. That let us define the operations exposed to each agent and separate development from QA. Release Manager could perform authorized read/write work; QA could inspect through a read-only interface. We kept working integrations intact and verified the new connections.

Custom MCP doesn't magically bypass platform authorization, and effective permissions still depend on the credentials and server-side enforcement. But it gave us a more appropriate architecture. Our new rule: try the standard connector, and if it fails without an obvious fix, evaluate custom MCP before spending the whole day fighting the same pipe.

How the systems connect

Sports Intelligence: from detection to a verified fix

The intended closed loop starts with a GrokBot alert. Woutson routes the report to QA, which verifies the issue independently. Release Manager implements an authorized repair and runs tests. QA checks the outcome, and Woutson reports the evidence or keeps the issue open.

The same philosophy governs sales. GrokBot and Scout research prospects; Sales Operations prepares and checks them; Woutson handles authorized client-facing execution and CRM updates. We prefer one accountable operator for customer communications rather than letting every research worker send messages independently.

Don't use a bazooka for a mosquito

We use scripts, tests, direct database queries, and existing automation where they can reliably do the job. Lightweight models handle routine extraction and classification. Stronger models are reserved for difficult engineering, conflicting evidence, and decisions that genuinely need more reasoning. Multiple agents shouldn't independently repeat the same work unless verification adds real value.

The point isn't to run as many AI workers as possible. It's to finish useful work at a sustainable cost.

Where we stand

As of October 14, the core team is assembled. Development and QA have reported verified GitHub, Gmail, and Supabase access, with distinct Supabase permissions. Sales Operations has verified Lemlist read access, while Woutson uses existing connections for authorized sales execution; independent HubSpot access for Sales Operations remains a follow-up item.

That's an infrastructure milestone, not proof of perfect unattended autonomy. The next test is whether the agents consistently complete scheduled work, recover from failures, and provide independent evidence without requiring repeated human intervention.

The Lab is where we learn what these systems can do. Bikefit is where they have to deliver real commercial value.

Some experiments will become products. Some will become internal tools. Some will fail. All can be worthwhile if they teach us something and prevent expensive mistakes in the business.

We're not building an AI workforce just to say we have one. We're building useful tools, proving them under real conditions, and giving a small team the leverage to accomplish much more.

The staff is assembled. The tools are connected. Now the minions have to earn their keep.

— Benny's Lab · Building, testing, improving, repeating.