Solo Founder Agent Orchestrator

As a solo founder, keep your mental sanity intact with this Solo Founder Agent Orchestrator and Workflows.

Comment

Inspiration

I originally built ScoreFluent for the Gemini XPrize hackathon. Running the product mostly alone, I discovered that operational work—not feature development—was consuming the most time.

Every Sentry alert, support email, sales enquiry, and feedback question required me to investigate multiple systems and decide what should happen next. I wanted a second operator that could complete this work, not another chatbot that only generated text.

For the Taskmaster category, I turned those repetitive processes into real, multi-step agent workflows with scoped tools, persistent feedback, and clear approval boundaries. This is something which easily can help every Solo Founder out there, especially non technical ones. Something which I am thinking to open source as templates.

Required Google Technology

ScoreFluent uses all three mandatory technologies:

  • Gemini 3.5: Every operational agent runs on gemini-3.5-flash through Vertex AI.
  • Google Agent Framework: The fleet is built with the Google ADK for TypeScript.
  • Google Cloud infrastructure: The agents and multimodal service run on Cloud Run, while Firestore stores feedback, learned preferences, and evaluation metrics.

The separately listed Gemini 3.1 Flash Image, Veo, and Lyria models are additional multimodal integrations. They do not replace the Gemini 3.5 model powering the operational agent fleet.

What It Does

ScoreFluent combines an operational agent fleet with a multimodal generation service.

Agent Fleet managed by Gemini Orchestrator

Orchestrator: Classifies inbound requests and delegates them to the appropriate specialist. These are not separate products. They are specialized workers inside one Taskmaster workflow, which are:

  • OPS-1 — Sales: Reviews B2B trial usage, manages prospects of cold outreach from the mailbox, and drafts personalized outreach.
  • OPS-2 — Support and Incidents: Investigates failed attempts, correlates logs, handles support tickets, and deduplicates bug reports.
  • OPS-3 — Community: Analyzes feedback both in-app and in the support mailbox, drafts community content, and routes disguised support complaints. Generates personalized replies for the author relevant to their sessions and mail content.
  • OPS-Analyst: Answers operational questions about user activity, conversion funnels, natural language activity queries etc using strictly read-only tools.
  • Media-Agent: Explained in Multimodal Generation Service

These agents gather evidence, call scoped tools, create operational artifacts, and coordinate next steps. Human approval is reserved for consequential external actions.

A representative OPS-2, incident workflow can:-

  1. Classify and route an alert.
  2. Correlate the affected accounts, attempt, Sentry event, and Railway logs.
  3. Distinguish user error from a product or provider failure.
  4. Search for duplicate GitHub issues, if none found create one, which triggers Claude integration with the repo to raise a fix PR. (In demo video I forgot to show the PR, but at 3:21 of the video you can see the mail from Claude bot, thats the Fix PR raised)
  5. Identify affected users and draft personalized apology emails relevant to the section of the app where they saw the error. Also in certain cases add free credits.
  6. Prepare a single customer-notification action for approval on Slack for a given incident. Once approved all affected users are sent their contextual personal email

Other flows are explained in the architecture diagram

Multimodal Generation Service

I get a periodic dump of trending content in the domain, which today I manually feed into the media agent i.e. a separate service deployed on Google Cloud Run which gives me one interface for generating supporting marketing and communication assets:

  • Images: Gemini 3.1 Flash Image generates promotional and education-focused visuals.
  • Video: Veo 3.1 generates videos through an asynchronous submit-and-poll workflow.
  • Music: Lyria generates instrumental music from mood, style, and instrumentation prompts.
  • Text: Gemini 3.5 Flash generates product and marketing copy.
  • Speech: Google Cloud Text-to-Speech converts exact scripts into playable audio.

Gemini 3.1 Flash Image, Veo, and Lyria are additional Google AI model integrations submitted for bonus consideration. Some of these assets have been widely shared on the social-media handles of ScoreFluent.

How I Built It

The five agents run inside a single Google Cloud Run service using the Google ADK for TypeScript and Gemini 3.5 Flash through Vertex AI.

Agents access product systems through 28 scoped HTTP tools. They do not hold database, payment-provider, analytics, or incident-management credentials directly.

The wider workflow integrates:

  • Vertex AI Search: Grounding over product documentation and runbooks.
  • Vertex AI Agent Engine: Persistent founder preferences.
  • Firestore: Judge-facing feedback and learning loop.
  • PostgreSQL & PostHog: Operational and product data.
  • Sentry & Railway: Incident investigation.
  • GitHub & Slack: Issues, approvals, and notifications.
  • Multimodal Cloud Run pipeline: has additional Google AI integrations with Imagen, Veo, Lyria, Gemini, and Google Cloud Text-to-Speech.

Safety and Reliability

ScoreFluent uses layered safeguards rather than relying on prompt instructions alone.

Least-Privilege Tool Access

Each specialist receives only the tools required for its role:

  • OPS-Analyst is strictly read-only.
  • OPS-1 is limited to sales and prospect workflows.
  • OPS-2 owns support and incident tools.
  • OPS-3 owns community workflows and support handoffs.
  • Orchestrator routes work but does not directly perform specialist actions.

Agents cannot access the database or external providers directly. All product access passes through 28 scoped HTTP tools with validated inputs.

Credential Isolation

Agents hold no database, payment-provider, analytics, GitHub, Slack, Sentry, or Railway credentials. The Cloud Run runtime uses a dedicated Google Cloud service account and one scoped internal gateway credential.

Production dispatch and memory endpoints verify Google OIDC identity tokens. Judge-demo endpoints use separate credentials.

Human Approval Boundaries

Drafts, customer communication, and other consequential external actions stop at an approval gate. Agents cannot independently:

  • Issue refunds
  • Mutate Stripe
  • Merge pull requests
  • Deploy code
  • Publish social content
  • Send mass communication
  • Delete production data

Human approval is reserved for financial, reputational, or irreversible actions.

Code-Gated Financial Decisions

An automatic 20-credit compensation is granted only when application code confirms:

$$ \text{grant} = \text{attemptErrored} \land \text{creditsSpent} \land (\text{age} \le 30\text{d}) \land \lnot\text{priorComp} $$

The model does not choose the amount or determine final eligibility. A database uniqueness constraint prevents the same event from receiving compensation twice.

Idempotency and Deduplication

Repeated Sentry alerts for the same incident create one GitHub issue rather than one issue per alert. Incident notifications and compensation paths also use persistent deduplication safeguards.

Database constraints—not model memory or “search first” prompts—provide the final concurrency guarantee.

Evidence Before Action

OPS-2 must gather evidence from relevant systems before acting:

  • User and attempt history
  • Credit ledger
  • Sentry events
  • Railway request logs
  • Existing GitHub issues
  • Support-ticket history
  • Scoring rubrics and question reviews

If evidence is unavailable, the agent must state what could not be verified instead of inventing a diagnosis.

Structured Input Validation

Every tool uses a Zod schema to validate arguments before execution. IDs, action types, status changes, numeric ranges, and enumerated values are constrained at the tool boundary.

Execution Limits

Judge runs have both:

  • A 45-second wall-clock limit
  • A 40-event limit

These limits prevent runaway tool use, stalled workflows, and agent-transfer loops.

Output Validation

Completed runs are checked for agent-specific requirements, including:

  • Correct specialist routing
  • Required evidence-gathering tools
  • Expected draft or terminal action
  • Read-only compliance
  • Correct artifact type
  • Prohibited claims such as saying a message was sent or published

Validation results are displayed in the judge UI.

PII Protection

Judge-facing answers and execution summaries apply best-effort redaction for:

  • Email addresses
  • Phone numbers
  • UUIDs
  • IP addresses

The UI shows summarized tool activity rather than exposing raw tool responses.

Failure Isolation

Memory, metrics, Slack callbacks, and optional integrations are designed to fail softly where appropriate. For example, a Memory Bank or Firestore interruption does not prevent the core agent from completing its operational task.

Domain state remains in PostgreSQL and is read fresh during each run. Memory stores founder preferences—not duplicate copies of tickets, users, or financial state.

Emergency Controls

The wider ScoreFluent platform includes an AGENTS_DISABLED kill switch for stopping agent execution without removing the deployment.

Challenges

Recording all this in one take was extremely difficult, but I was really happy at the end. So thanks for this hackathon

I was new to Google ADK and initially found the number of possible agent architectures overwhelming. I chose a deliberately small stack: ADK, Gemini, Cloud Run, Vertex AI, and Firestore.

The hardest workflow problem was distinguishing user error from genuine product or third-party service failures. Acting without sufficient evidence could create incorrect tickets, compensation, or customer communication, so OPS-2 gathers evidence across attempts, logs, Sentry, and support history before taking the next step.

Idempotency was another important lesson. “Search before creating” was not a strong enough guarantee when several alerts could arrive simultaneously. Database constraints became the final safeguard against duplicate issues, compensation, and notifications.

What I Learned

Memory materially improves agent output. A technically correct generic support reply still feels generic; a reply informed by my previous edits and rework instructions sounds like ScoreFluent and requires much less correction.

I also learned that useful autonomy does not mean removing humans from every decision. I made choices to keep a human review and chose Slack as the surface, which has allowed me to also debug and fix the system before I leave it on auto pilot as the product ScoreFluent itself is quite new and I can't risk losing customer trust due to an obvious mistake.

Most importantly, the system now saves me approximately 5–8 hours each week. That gives me more time to improve the product—and more time away from work on weekends.

Disclosures

  • Pre-existing product: ScoreFluent is a pre-existing product originally created for the Gemini XPrize hackathon. It is not claimed as new work for this event.
  • Pre-existing tools: A small number of analytics and B2B outreach tools existed before this contest and were previously invoked manually. Their private implementations are not included in this repository.
  • New hackathon work: During the final week of the submission period, I built the Google ADK and Gemini agent layer, Cloud Run deployment, specialist routing and orchestration, memory integrations, approval workflows, feedback loop, and automated execution systems that coordinate the existing tools.

Built With

  • adk
  • claude
  • cloudrun
  • firestore
  • gemini
  • kimi
Share this project:

Updates

Submission history