What it is
My own working pipeline for handling inbound work requests. One big prompt kept doing everything badly, so I split it into five agents that each do one job and hand over a checked result. A person stays in charge of the only step that matters: sending.
The five agents
- Scout. Looks at new requests every few minutes and keeps only the ones that fit: the right region, a client with a track record, and little competition so far. It reads and never writes.
- Writer. Drafts two different replies for each request, using a catalog of real past work as its only source, so nothing is invented. Both drafts open with the client's own problem, not with a greeting.
- Reviewer. A separate agent that checks each draft before a person sees it. Plain code catches contact details and dead or unknown links; a model checks the opening, the claims against the catalog, and whether the draft answers what the client asked. If something fails it fixes the draft and says what it changed.
- Approver. Ordinary code, not a model. It builds a preview with the bid, the cost and the attachments, posts it to the owner's phone, and waits. It sends only after a tap on Confirm. Cancel does nothing.
- Editor. Changes a draft or the price when the owner asks in the chat thread, for example "shorter" or "add the map project". Changes to something already sent also show a preview first.
Example use case: quote requests
The poster shows the same pipeline on a home-services company. A homeowner asks about a second floor that will not cool. The scout keeps it because it is inside the service area. The writer drafts two replies from the price book and past jobs. The reviewer catches a quote below the price book, a promise of same-day service the calendar cannot keep and a dead financing link, and fixes them. The owner sees a preview on the phone and taps Confirm before anything reaches the customer.
Why five and not one
A writer that also checks its own work approves its own mistakes. Keeping the reviewer separate means it looks at the draft cold. Keeping the approver as code means the step that spends money and speaks for me cannot be talked into anything by the text of a request. Each agent gets only the tools it needs, and the ones that prepare work cannot confirm anything.
A real catch
In a test on a live draft, the writer had linked to a page that returned 404. The reviewer's link check found it, picked the closest live case study from the list of real pages, and swapped it in, along with two smaller fixes to the closing line. That is the kind of slip that is easy to miss when you paste drafts by hand.
Stack
Python, a scheduler on the host machine, Claude and OpenAI Codex driven from the command line with MCP connectors, a chat bot on Discord for the phone side, and a link checker built on HTTP requests. The writer runs on one model and the scout and reviewer on another, so the work is spread across two subscriptions.
What it does not claim
It is new, so there are no win rates to quote yet. The reviewer reduces bad drafts; it does not guarantee good ones. It runs on a machine that has to be on, and every send still depends on a person's tap by design.
Message me on the platform where you found this and I will answer there.