Inspiration

I prospect local businesses under OpenCube Studio. The hard part is not finding leads — it is knowing whether there is a real, evidence-backed reason to contact each one.

Most prospecting systems optimize personalization and outreach volume. OpenCube Intel starts one step earlier:

Don’t personalize outreach first. Prove there’s a reason to reach out.

That became the core idea for OpenCube Intel: an agentic market-intelligence workflow that can discover businesses, investigate their public presence, challenge its own hypotheses with outside evidence, and reject unsupported reasons to contact them.

I submitted OpenCube Intel to the Taskmaster track because the core experience is autonomous background work beyond a chatbot: discovery, investigation, verification, reconciliation, and decision support.

In one completed production run, OpenCube evaluated 30 possible reasons to reach out across 10 Miami-Dade med spas — and rejected 27.

A rejection is not a failure. In OpenCube, “Do not contact on this basis” is a valid successful outcome.

What it does

OpenCube Intel performs a multi-step background workflow:

Market Discovery → Business Investigation → Evidence → Opportunity Hypothesis → Independent Verification → Opportunity Matching → Human Gate

The system currently evaluates three executable opportunity types:

  • Online booking friction
  • After-hours lead intake
  • Lead follow-up effectiveness

The workflow is intentionally conservative.

A business can only reach the Human Gate when the evidence supports a specific opportunity. If the evidence contradicts the hypothesis, the deterministic Opportunity Matcher rejects that reason to reach out.

The system never sends outreach itself. A person remains the final decision-maker.

How I built it

OpenCube Intel runs on Google Cloud and separates discovery, model-based reasoning, deterministic decision logic, persistence, and human review.

1. Market Scout

The Market Scout performs autonomous business discovery using the Google Places API.

It does not use a language model.

It discovers candidate businesses, applies deterministic selection logic, and sends selected businesses into the investigation pipeline.

2. Business Investigator

The Business Investigator uses Gemini 3.6 Flash through Google's Gen AI stack to examine a business's own public pages.

It records observations together with their source URLs and creates evidence-backed opportunity hypotheses.

3. Verification Agent

The Verification Agent also uses Gemini 3.6 Flash, but its job is different.

It searches outside sources and independently challenges the hypothesis instead of simply confirming the first agent's conclusion.

Verification can support, contradict, or remain insufficient.

4. Opportunity Matcher

The Opportunity Matcher is deliberately not an AI model.

It is a deterministic decision engine operating over the reconciled evidence.

The same evidence produces the same decision:

  • MATCHED
  • NOT_MATCHED
  • UNRESOLVED

A MATCHED result still does not authorize outreach. It only advances the opportunity to the Human Gate.

Google Cloud architecture

The production workflow uses:

  • Cloud Run — private FastAPI production service
  • Cloud Tasks — asynchronous execution and parallel business investigations
  • Firestore — canonical workflow state, evidence provenance, hypotheses, verifications, and match decisions
  • Google Places API — autonomous business discovery
  • Vertex AI / Gemini 3.6 Flash — investigation and verification reasoning
  • Google Gen AI SDK — Gemini integration
  • Google ADK — application/runtime layer
  • IAM / OIDC — authenticated task delivery to the private Cloud Run service
  • Cloud Logging — production execution observability

One Cloud Task represents one complete business investigation, not one task per hypothesis.

Evidence-first design

Every important claim preserves provenance.

OpenCube distinguishes between:

  • evidence collected from the business's own public presence
  • evidence collected independently during verification
  • the hypothesis derived from that evidence
  • the deterministic final decision

For example, in the submitted production run, OpenCube investigated whether No Filter Medical Spa had online-booking friction.

The business's own site displayed visible “Book Now” links. The hypothesis was therefore ruled out.

The system still performed an independent verification step. An outside GlossGenius source also showed visible booking options.

The Opportunity Matcher rejected that specific reason to contact the business and produced:

Do not contact on this basis.

That decision applies to the claim — not necessarily to the business as a whole.

Judge Mode

The submitted application includes a public, read-only Judge Mode backed by the real persisted Firestore production data.

Judge Mode allows reviewers to inspect:

  • completed runs
  • businesses
  • evidence
  • hypotheses
  • independent verification
  • deterministic match decisions
  • source provenance

Fresh execution is intentionally disabled in the public Judge Mode so anonymous visitors cannot consume paid AI or cloud resources.

Challenges

One of the hardest design decisions was resisting the temptation to let the model make every decision.

Gemini is used where semantic reasoning is valuable: investigating pages and evaluating evidence.

The final opportunity decision is deterministic.

Another challenge was preserving evidence provenance across an asynchronous multi-agent workflow while keeping the production service private and exposing a safe read-only experience for judges.

What I learned

Agentic systems become more useful when autonomy is paired with explicit boundaries.

The important question is not only:

“Can an agent perform this task?”

It is also:

“Where should probabilistic reasoning stop, where should deterministic logic begin, and where should a human retain authority?”

For OpenCube Intel, that boundary became the product.

Submission disclosure

This project is submitted by Guillermo Paz as an individual entrant.

OpenCube Studio is the pre-existing brand I operate under — the AI-automation practice whose prospecting friction this product addresses, and the source of the OpenCube brand identity. That brand context predates the hackathon.

OpenCube Intel — including the submitted application and codebase — was designed and built by me during the hackathon submission period. The repository's Git history evidences this: the initial commit is dated August 23, 2026, and all submitted OpenCube Intel implementation work falls within the hackathon period.

Standard third-party dependencies and development scaffolding are disclosed in the repository. AI coding assistants were also used during implementation and development.

What's next

OpenCube Intel was built from a real prospecting problem inside OpenCube Studio, but the architecture is intentionally broader than prospecting.

The same pattern — autonomous discovery, evidence collection, independent verification, deterministic decision logic, persistent workflow state, and a human gate — can be reused across specialized intelligence workflows such as customer discovery, market research, interviews, validation, and operational decision support.

The next phase is to expand the opportunity catalog, support additional business verticals, deepen evidence quality, and evolve this architecture into a broader vertical intelligence platform for OpenCube Studio.

OpenCube doesn't automate more outreach. It automates the work required to know which outreach is actually justified.

Built With

Share this project:

Updates

Submission history