AI Agent Project Scoping Tool Development

Scoping an AI agent engagement usually takes a vague inbound email, two calls and a proposal written by hand, and that is before anyone has checked whether the prospect is a fit. Research on the company happens in browser tabs and gets lost; proposals go out as PDFs and nobody knows if they were opened. For a small studio this means days between first contact and a real conversation, and hours of founder time spent on leads that were never going to close.

A prospect answers six plain questions on the home page: what kind of company, what repetitive work the agent should take over, where that information lives, daily volume, response time, and when a person should approve. A price band is pinned above the questions and moves on every answer, from the widest possible range down to a committed band. They enter their name, work email and company, pick a 20-minute call slot shown in Pakistan time, and tap “Send my proposal”. Within a couple of minutes they receive a written scoping brief, the price band, a 30-day milestone plan and a calendar invite, and the proposal opens as a web page laid out like an engineering drawing. Meanwhile the studio owner gets an email with the company researched, scored for fit and one-click approve and decline buttons, and the lead appears on a public read-only board at /demo where the prospect can watch it land.

Agent-written proposals from a locked price engine. A workflow on every new Scope (and every revision) runs a backend function that recomputes complexity points server-side from the answers, clamps the band to a RateBand table, then calls InvokeLLM (Claude Sonnet) for a six-section brief under a contract that forbids prices, timelines other than 30 days, and any system the prospect didn’t name. The brief is never given a price, so it cannot echo one. A 90-second timeout falls back to “Brief to follow before the call” and still sends.

Research and fit scoring with the AI confined to classification. A second workflow on every new Lead calls InvokeLLM with internet access to research the website (60-second cap), then a typed evaluation at temperature 0 that answers a fixed rubric: workflow evidence, scope clarity, headcount bucket, budget signals and three red-flag questions. Points for industry, size and budget are tables in code; the AI only picks levels. Output is a 0–100 breakdown, a three-line summary, red flags, and a recommendation chosen in code. An unreachable site scores from the answers alone and never auto-qualifies.

Gmail and Google Calendar as the delivery layer. Proposal emails go from a dedicated hello@trontra.com account through the Gmail connector; the call is created, and moved on revision, through the Google Calendar connector. Operator alerts and the “send cap hit” notice use SendEmail templates. A 30-per-hour send cap queues overflow proposals, and a scheduled workflow every ten minutes drains the queue, oldest first.

Nothing public touches the database. Access rules restrict every business entity to the operator and admin roles; the signing-key and submission-log entities are unreadable by any user. The scope form, slot picker, proposal page and public board all go through backend functions: submitScope validates every field, enforces a ten-minute duplicate rule and five submissions per hashed IP per hour; getProposal resolves one proposal by token; getDemoBoard returns seeded leads in full and live leads as company, score, band and stage only.

Revisions that re-run the pipeline. “Adjust scope” on the proposal page reopens the flow pre-filled; resubmitting increments the Scope’s revision, re-runs the proposal workflow, supersedes the old proposal (its page shows a banner to the new REV), releases the old slot, moves the calendar event, and re-triggers lead research. The proposal’s title block shows the REV, and a REV HISTORY lists what changed.

Signed one-click decisions. The operator’s email carries HMAC-signed approve and decline links backed by a key stored in an entity no user can read; they expire after 14 days, a tampered signature is refused, and once either is used both return “Already decided”.

Two spotlight tours and a read-only board. A 220-line tour component dims the page, cuts out the target and docks a card above the bottom tabs on phones; the home tour ends by opening the scope flow, the /demo tour ends on “Scope a project yourself”. The board is the same six-stage layout as the operator console, with write controls disabled and a “Reset demo data” function that restores the seed without touching live leads.

12 entities with role-based access rules, 18 backend functions, 6 workflows (3 entity-triggered, 3 scheduled), Gmail and Google Calendar connectors, InvokeLLM in 5 functions plus a typed evaluation model for scoring, 3 SendEmail templates, 3 user roles.

Live app: https://trontra.base44.app Public operator board: https://trontra.base44.app/demo