Most agent demos work until they meet real data, a usage limit or a wrong answer. This page shows what I built, the problems that came up and how each one was solved. The systems are my own products and tools, so I can explain every decision in them.
Which one do you need?
| Your situation | What fits | Where I built it |
|---|---|---|
| One assistant should use your product or data | MCP server | Receptionist server |
| One repeating job with a clear finish | Single agent with tools | Job agent scan step |
| Quality suffers when one prompt writes and checks | Multiple agents with one job each | Proposal pipeline, Baydot Company |
| Many requests need sending to the right feature | Coordinator and specialists | FaceSearch |
Plain code is my first choice whenever a rule is enough. A model only gets the steps that need judgment.
What I built
1. Baydot Company: a CEO agent that runs a small team
A local workspace where one person talks to a CEO agent, in English or Roman Urdu. For real work it delegates.
- Each role is a separate model call with a validated structured contract.
- On a GitHub repo, the team works on its own branch and runs the tests. The app can open a draft PR, and it never merges.
- Runs, evidence, token usage and task history are stored in SQLite. Documents can be searched with local retrieval, and inference can stay local through Ollama.
Stack: Python, Codex CLI, SQLite, GitHub CLI, Ollama. The repo is private and it is a single-owner tool, so I can walk you through it on a call.
2. Product Factory: research to live product
A pipeline of Claude Code agents that finds real problems and builds small, free browser tools. Nothing gets built until I approve the GitHub issue.
Fourteen live tools came through it, including an AI agent cost calculator. They are free tools, so they prove the pipeline works, not that they earn revenue.
3. Proposal pipeline: five agents and a tap
It reads jobs through an official MCP connector, drafts from a catalog of real work and waits on my phone. Read the full case study.
4. MCP server and the FaceSearch agent layer
I wrote a TypeScript MCP server with the official SDK. Its 8 tools cover availability, booking and lead qualification, with validated inputs. See the MCP details.
FaceSearch has a coordinator and 10 specialists, with model routes for Claude, Gemini, OpenAI, OpenRouter and custom endpoints. Its specialists currently report on system data and route requests. It uses provider APIs, not MCP.
Problems I hit and how I solved them
One prompt did everything badly
Why: a writer that checks its own work approves its own mistakes.
Fix: split it into agents with one job each, and a reviewer that reads the draft cold.
A draft linked to a dead page
Found by: the reviewer's link check, on a live draft. The page returned 404.
Fix: links are checked by code and only known pages are allowed, before anyone sees the draft.
A usage limit stopped the work
Why: one provider's limit would stall the whole pipeline.
Fix: limit errors are detected, the provider's cooldown is recorded, and each step moves to the other model.
A model should not press send
Why: text from a web page or job post can try to talk a model into things.
Fix: sending is plain code behind a preview and a Confirm tap. Scan steps have write tools blocked.
The same project in every draft
Why: the writer kept reaching for its favourite example.
Fix: code ranks catalog entries by fit to the job, with a small penalty for recent use.
Agents can loop and burn money
Risk: a reviewer and builder can argue forever.
Fix: at most two revision rounds and nine calls per run, plus timeouts. A failed review stays marked needs attention, not done.
Code could change after review
Risk: the reviewed diff is not what gets published.
Fix: before a draft PR, the app verifies that the checkout, branch, remote and reviewed diff are unchanged.
A tool read 1/2 as 1
Found by: the UX audit agent, using the recipe tool as a person would.
Fix: the fixer agent rewrote the parser for fractions and ranges, then a separate agent reviewed it.
A model writing SQL on real data
Risk: one bad query changes or leaks data.
Fix: a guard allows only one SELECT or WITH, in a read-only transaction with a timeout and row cap. See SupaQuery.
A crash could pay for a GPU job twice
Risk: a worker dies right after submitting.
Fix: leases, checkpoints and idempotent submit. Tests crash it on purpose and see one submit. See genflow.
How I decide what an agent may do
- Write down the finish line. If nobody can check the result, it isn't ready for an agent.
- Use code for rules and a model only for judgment.
- Give the fewest tools possible, read-only by default.
- Put a person before anything risky: sending, spending or changing real data.
- Set limits and keep records: call caps, timeouts, and a stored trail of each run.
- Test on real failures, then add each one to the checks.