Evolve Agentic Tools
A Google-SSO front door on Cloudflare Workers that queues jobs to a Mac Mini-hosted FastAPI kit running 19 site-audit and content tools, with every submission logged before the…
- 19
- tools in the live catalog
- 3
- runtime dependencies (next, react, react-dom)
- 975 KiB gz
- deployed Worker bundle size

Problem
Evolve Agentic had a growing set of one-off internal utilities (site auditing, screenshots, performance checks) with no shared front door, no access control, and no record of who ran what. Anyone with the URL to the Mac Mini's tunnel could hit a tool directly, and there was no audit trail if a job silently failed. The team also needed the heavy work (headless Chromium, Playwright) to stay off Cloudflare's edge, since none of that runs in a Worker. Two of the tools that needed a front door weren't small utilities at all - RETARD and Evolve Animator are each substantial standalone builds in their own right - which meant the front door couldn't be scoped as "a form for simple scripts"; it had to be a genuine catalog able to hold a one-field auditor next to a multi-stage generation pipeline without either one looking like an afterthought. The architectural question wasn't only "how do we gate access" but "which side owns the work": rebuilding all of it Cloudflare-native was ruled out early because the tool kit already existed and worked, and a second decision point - build a new Mini API from scratch versus front an existing one - had to be made explicitly rather than assumed.
What was built
A small Next.js app that acts purely as a catalog, form, and paper trail; it does no work itself. A user signs in with a Workspace Google account restricted to one domain, picks a tool from a registry-driven catalog, and fills a form. Submitting writes one row to a Cloudflare D1 table before the job is handed off, then polls a status endpoint until the job finishes and links out to the artifacts (reports, screenshots, PDFs) which are served back through an authenticated, sandboxed proxy so nothing untrusted renders on the app's own origin. The 19 tools span five practical groups: site/QA tooling (site auditor, WebShooter, responsive matrix, visual diff, performance, pre-launch checklist, social preview, competitor snapshot, change monitor), client-delivery generators (handoff builder, site scaffolder, favicon/social-image generator, site-care report), document/data utilities (document extractor, data cleaner), business-document generators (proposal generator, SOP architect), and the two bespoke, multi-stage tools (Evolve Animator, RETARD) surfaced through the identical catalog-and-form pattern as every simpler tool rather than getting a special-cased UI. Every row in the run record captures the full lifecycle - queued at submit, job_id and status on successful handoff, the failure reason inline on the row (not a separate error table) if the Mini never accepted the job, and duration plus a result manifest on completion - so a stuck or failed run is always traceable to a specific row rather than an absence of one.
Technical approach
The interesting decision is the split: Cloudflare Workers can't run headless Chromium, so the actual tool logic (auditor, webshooter, visual diff, RETARD's build pipeline, Evolve Animator's render pipeline) lives in a separate FastAPI/HTMX repo (evolve-tools) running under launchd on the Mac Mini, reached over a private cloudflared tunnel with a bearer token that never leaves the server side of the Worker. The front door writes the D1 row and calls the Mini's job endpoint in that order deliberately: a Mini outage still leaves a queued row instead of a silent failure that never happened. File uploads are never stored as bytes in D1, only {filename, bytes, type} metadata; the actual file streams to the Mini as multipart. Auth uses Web Crypto directly rather than an auth library, and the D1 layer is plain SQL rather than an ORM, both explicit choices to stay under Cloudflare's ~3 MiB gzipped free-tier bundle cap, which fails at wrangler upload rather than at build time. The tool registry (src/lib/tools.ts) is the single source of truth for what appears in the catalog, what fields a form has, and what validation runs, so adding a tool is one array entry. A real security bug was found and fixed here: artifacts were originally served on the app's own origin, which is an XSS vector if an artifact contains attacker-influenced HTML; the fix adds a CSP sandbox directive, nosniff, and forces a download rather than inline render. As of the last handoff, the Worker-to-Mini hop for an authenticated job submission had not yet been exercised end to end (D1 showed zero runs), so the two sides were verified independently but the full chain was unproven pending Victor running one real job.
Creative approach
Craft
Dark surface with a single cyan accent (#0a0e14 background, #22d3ee accent), sentence-case headings, no decorative iconography, an ambient looping video/aurora background behind the catalog generated with Higgsfield and falling back to a static aurora when video can't load. The visual restraint mirrors the architectural one: the app is explicitly a thin shell, and the design doesn't pretend otherwise with dashboards or charts it has no data for. Results render tangibly rather than as a bare "done" state: a completed run shows an inline report, a score, and a summary through the authenticated artifact proxy, so the payoff of running a tool is visible in the same page the form lived on, not a separate download step. The form layer inherits its structure from the same registry that drives the catalog - every field, its type, and its validation come from one array - so a proposal generator's seven-field form and a one-URL site auditor share identical spacing, labeling, and error-state behavior despite being wildly different in complexity.
Reframe
The non-obvious call was refusing to let the front door do any work at all. Every other internal tool suite on the Mini could have been rebuilt as a Cloudflare-native app, but Playwright and Chromium simply cannot run there, so instead of forcing the architecture, the front door became a pure catalog-and-ledger layer over an existing FastAPI kit that already worked. The D1-write-before-submit ordering is the same instinct applied to failure modes: rather than trying to make the Mini call reliable, the design accepts it will sometimes fail and makes that failure visible instead of silent. The same reframe shows up in how a failed submission is recorded: a row that never reached the Mini isn't marked as an error, it stays queued with the reason attached, because nothing actually failed on the Mini side - the distinction between "the job failed" and "the job was never accepted" is preserved in the data rather than collapsed into one generic failure state.
Process and what failed
The XSS in the artifact proxy was found and fixed after the fact, not designed in from the start, a reminder that serving Mini-generated HTML reports on the app's own origin looked fine until someone thought about what an attacker-influenced report body could contain. The Worker-to-Mini chain remained formally unverified at the last session's end despite both halves individually passing their own tests, which is the recurring lesson across this whole cluster of tools: independently-green components are not the same claim as a proven end-to-end path. The tool count itself drifted and had to be corrected twice: an earlier handoff said 17, a separate memory record said 18, and only checking the Mini's own tool registry and its live health endpoint against the front door's registry - and finding both agreed at 19 - settled which number was actually true. An architecture decision that could have gone either way was made explicit rather than defaulted into: building a brand-new Mini API from scratch was on the table, and the call ("front an existing kit" over "build fresh") was Victor's, not an assumption baked in silently. Smaller frictions surfaced along the way: Cloudflare Worker secret changes propagate across instances with a lag, so the first request after a secret rotation returned a 503 and only the next one succeeded, no redeploy required or possible to force that faster; and the Higgsfield credential used to generate the ambient background video expired mid-project and needed re-authentication before that asset could ship.
Outcome
Live at tools.evolveagentic.ai, gating 19 internal tools behind Google Workspace sign-in with every submission recorded in D1 before it reaches the Mini. Two of the catalog's tools (RETARD and Evolve Animator, covered elsewhere in this portfolio) are themselves substantial standalone projects surfaced through this same catalog rather than duplicated as separate front doors. The frontend runs with only three runtime dependencies (next, react, react-dom) and deploys at 975 KiB gzipped against Cloudflare's roughly 3 MiB free-tier ceiling, with D1 migrations applied to the remote database ahead of every deploy rather than after. Google Workspace OAuth passed verification for internal use, and Cloudflare DNS plus the custom domain were both configured and confirmed live rather than left on the workers.dev fallback. What isn't yet proven is the one thing that matters most: a real, authenticated job submitted through the live UI and carried end-to-end to a finished artifact. As of the last handoff the D1 ledger showed zero runs, so the front door and the Mini API had each been verified independently but never together on a live request - the explicit next step was for Victor to sign in and run one tool (the site auditor, as the simplest case) so the full chain could be confirmed from submission through to a rendered result rather than inferred from two halves that separately passed their own tests.