grant-pilot — federal-grants agent with sub-agent orchestration

Repo: github.com/midimurphdesigns/grant-pilot

Live demo: grant-pilot.kevinmurphywebdev.com

Read the full story: Building grant-pilot

A multi-turn agent that helps a small business or nonprofit find federal grants they qualify for and drafts the skeleton of an application. A planner dispatches three specialist sub-agents — discovery, eligibility, drafter — over public grants.gov and SAM.gov data. 3 sub-agents, 3 tools, ~$0.05 per run, hosted with a daily budget cap and per-IP rate limit so strangers can run it without burning the bill.

How it's built

Bun + TypeScript strict, Anthropic SDK, Zod-validated tool boundaries, real grants.gov + SAM.gov integrations. The planner runs a bounded multi-turn loop: discovery derives a keyword query and ranks 5 candidates 0–100; eligibility fetches full grant detail + an optional SAM check and returns a verdict grounded in the eligibility text; drafter produces a structured application skeleton (sections + applicant prompts + watch-outs, never prose). Each sub-agent has its own fallback ladder (Sonnet 4.6 → Haiku 4.5, ported from fedbench). The hosted demo is hardened with a $3/day budget cap, a 5-runs/hour-per-IP rate limit (Upstash Redis), and bounded enum + regex inputs that neutralize the prompt-injection surface.

Artifacts worth reading

• The planner that decomposes intent and dispatches sub-agents — never throws, structured failures route as values
• The SAM-registration hard gate — the only place a deterministic check overrides the LLM verdict
• The streaming /api/run route handler with NDJSON streaming, budget cap, and rate-limit guardrails

The trade-offs

Sub-agent orchestration is more code to maintain than a single agent with a long prompt. It's also the thing that makes a multi-turn agent debuggable, observable, and cost-bounded in production. Three sub-agents was deliberate — adding a fourth would be framework creep without commensurate user value at v0.1. The cap itself is the signal.