My Team of Twenty Bots

How I use small, specialized AI assistants alongside my work as a software engineer.

I'm Michael Neeley (@redreceipt), a software engineer at Differential working on Apollos, software for churches. The work isn't just writing code. There are pull requests to review, issues to triage, support questions to investigate, and a steady stream of notifications to sort through.

I use twenty Grok bots for recurring jobs: watching projects, sorting notifications, keeping PRs moving, and investigating bugs. Here's how I've split up that work, as of October 2026.

How I organize the work

Switchboard gathers reports from the specialists and prepares my weekday briefing. I use it to bring updates together and pass new instructions to the bots they affect, instead of repeating myself in every chat.

The daily rhythm

Before the weekday briefing, the coordination bots gather project status, scope concerns, and PRs waiting on a decision. Switchboard brings those reports together so I don't have to read each one separately.

Through the day, Sieve checks inbox noise hourly, Nanny watches my PRs, and Semver keeps up with dependency updates. The code-improvement bots look for work without filling the review queue with competing PRs.

Weekly and monthly passes cover Foreman's stale-ticket sweep, Bottleneck's constraint brief, and Keystone's technical proposal in Linear.

The roster

Coordination

Switchboard: Executive Assistant. Coordinates the other bots, gathers their digests, and prepares the briefing. When I change a standing rule, I can ask Switchboard to relay it to the bots it affects.

Foreman: Project Manager. Watches the Linear projects I'm responsible for and posts updates when something changes. Its weekly sweep catches my assigned issues that have gone quiet, even if they aren't in a project.

Trawler: Linear Projects. Takes a wider view across engineering projects and reports material status, blockers, and drift. Foreman focuses on moving my work forward; Trawler supplies a broader picture.

Chisel: Engineering Manager. The scope critic. It compares planned work with active issues and PRs, then gives me concrete suggestions about what to cut, defer, or combine.

Bottleneck: Constraints Advisor. Looks across the available business and project tools and proposes one top constraint, with evidence and concrete recommendations. I want a priority to act on, not another long status list.

Inbox & PRs

Sieve: Email & Linear Triage. Owns the rules for clearing skippable work Gmail and Linear notifications while keeping real asks and blockers. For GitHub email, it checks the current PR or issue state rather than trusting the subject line. Archiving is a whole-thread operation, not deleting individual messages. It also looks for noise that can be turned off at the source, so it doesn't have to keep cleaning up the same notifications.

Nanny: PR Monitor. Watches my PRs for CI, reviews, comments, and work that needs attention. Drafts are included: it summarizes their state and asks whether I want them marked ready, closed, or kept. It shouldn't make that decision for me or ask the same unchanged question every hour.

Stamp: PR Reviews. Handles mechanical reviews and prepares briefs for changes that need my judgment. For in-scope simple changes, a clean automated review can lead to an approval through my account. It follows up on review feedback and conflicts so I don't have to chase every author myself. It doesn't merge PRs. In repos that don't require approvals, it tells authors they don't need to wait for mine.

Semver: Dependency Updates. Works through Dependabot PRs and gets dependency branches into shape. It can approve and merge certain low-risk updates; major or uncertain changes come back to me for a decision. It also handles a limited slice of dependency-related email alongside Sieve.

Code improvement

I give these bots a one-open-PR rule: if their workstream already has an open PR, wait rather than start another. That keeps the review queue manageable.

Keystone: Software Architect. Looks for unclear boundaries and handoffs between services and apps, then proposes concrete structural improvements. It also has a monthly technical-proposal routine that files a recommendation in Linear Triage, with evidence, tradeoffs, and a migration plan.

Codemod: TypeScript Migration. Converts JavaScript to TypeScript in small, mechanical steps. The brief is to improve type safety without quietly changing behavior.

Pruner: Code Cleanup. Looks for dead code, redundant tests, and code that can be simplified.

Smoke: E2E Testing. Looks for critical flows without useful end-to-end coverage and adds tests for those gaps.

Hotpath: Performance. Looks for repeated queries, unnecessary rendering, wasted work, and expensive synchronous paths, then proposes improvements with evidence.

Intruder: Security. Does defensive security work within the repositories it's authorized to inspect. Its brief calls for demonstrable issues and root-cause fixes, not speculative scanner noise or work outside that scope.

Onramp: Agent DX. Improves the setup instructions, tooling, debug access, and QA paths that coding agents use. A reliable development path helps every bot that touches the repository.

Production & support

Triager: Error Triage. Uses Sentry to find a high-impact unresolved error, investigates it, and delegates a root-cause fix through a draft PR.

Pipeline: Data Pipelines. Uses Astronomer/Airflow to investigate a failing active DAG and work toward a fix with tests.

Medic: Support Triage. Investigates actionable Linear support issues one at a time, records findings, and can open a fix. It uses its own Linear app and GitHub bot identity, so its work isn't presented as mine.

Compass: Product Guide. Answers product and code questions for teammates in Slack, plus analytics questions through Metabase. It gives non-engineering teammates a place to ask how a feature works without waiting for me to dig through the code.

What I've learned

Stop noise at the source. I expanded Sieve's job from archiving notifications to finding subscriptions and settings we can turn off. That's better than cleaning up the same noise every hour.

I need decisions, not status dumps. Twenty assistants could easily give me twenty more places to check. I use Switchboard to bring the reports together, ask Bottleneck for one top priority, and work through Stamp's review list one decision at a time. The useful output isn't everything they've found. It's what needs my attention, why it matters, and the call I need to make.

Sometimes the useful answer is to do less. When a couple of my projects got caught in the weeds, I asked Chisel to cut them back to what was absolutely critical—including questioning whether any of it was. I don't just want help getting through a larger task list faster. I want the assistants to challenge what belongs on the list in the first place.

That's what I'm trying to get out of Grok Bot: fewer loose ends to chase, and more attention left for the coding and decisions that need me.

And yes, Switchboard wrote this article