Case study · production agent system
The work that closes deals — research, qualification, proposals, follow-up timing — was all manual. The CRM I built and now run my business on has an orchestrator agent over 18 specialists that do that work and queue it. Exactly one module is allowed to send, and only after a human approves the row.
| Stack | Python, FastAPI, SQLAlchemy, APScheduler, Anthropic API, Twilio, Google Workspace APIs, Deepgram, JWT auth, pytest, Ubuntu VPS behind nginx |
|---|---|
| Size | 51 database tables, 315 API endpoints across 30+ routers, 20+ recurring jobs, an Android companion app |
| Models | Opus orchestrates; Sonnet and Haiku do the bounded specialist work |
| Status | In daily production use, running my own business. Built in about seven weeks. |
| Evaluated? | Not yet. No test set exists for the fleet, so no accuracy claim is made anywhere on this site. |
The shape of it
From the dashboard chat, from a Telegram bot, or from one of 20+ scheduled jobs. Eight agents run daily and produce automated briefings.
It holds every tool — about 25: pipeline reads and writes, contact CRUD, activity logging, Gmail read and draft, calendar create and reschedule, and agent dispatch.
18 of them: lead qualification, follow-up scheduling, proposals, pipeline analytics, lead scraping, customer health, competitor and product research, sales coaching, onboarding, support, pricing, compliance review, data hygiene, marketing calendar, social content, task automation.
Drafts queue as a PendingAction row, reviewed in the dashboard or over Telegram. One module is permitted to send email or SMS. The rule is enforced in code, not by convention.
Specialists have no database access of their own and reach data only through the orchestrator. That keeps credentials and write access in one place and makes every agent run reviewable. The approval gate covers customer-facing email, text and proposals; internal actions such as logging activity, scoring a lead or scheduling a task are not gated.
Decisions
run_agent_skill invokes a specialist for one schema-validated output: score this lead, write this proposal. ask_agent opens a persistent thread when the task needs judgment — the specialist replies with a needs list, the orchestrator fetches that data with its own tools, and the conversation continues. One is a function call; the other is a colleague who can ask a question back.
Per-agent model tiering, cost attribution per run, a daily token budget that short-circuits the fleet, a research cache, exponential-backoff retries, and every run logged to an agent_runs table. Cost is blended on a 3:1 input/output ratio, because averaging the two rates evenly overstates it by roughly 2x.
Merchant processing statements are read straight from PDF by a vision model, with no per-processor parsers. Every figure is either printed on the statement or derived from one by arithmetic. A regex classifier runs independently, and disagreements go to a human instead of being auto-resolved.
A Twilio recording becomes a speaker-separated Deepgram transcript, then a structured review — outcome, sentiment, objections, next steps, coaching tip — written back to the lead's timeline.
Ownership
Claude Code wrote most of the implementation. I wrote the specifications, the agent prompts and the decision log; chose the architecture, including the single-sender rule and the orchestrator-only data access; reviewed the diffs; ran the tests; and deployed and operate it. When something is wrong in production, it is mine to fix.
I am not claiming to have hand-written 315 endpoints, and I would not describe myself as a software engineer. What I'd claim is this: I can specify a system precisely enough that agents build the right thing, catch it when they don't, and run the result as a business depends on it.
The honest gap is measurement. This fleet has no evals. The next evaluation project is lead scoring and statement extraction, where being wrong costs money and the right answer is checkable — the same harness as the support assistant.