InventorOS

InventorOS is a governed, evidence-first patent-intelligence workflow for R&D teams.

Comment

InventorOS — Project Story

Inspiration

R&D teams often have no shortage of ideas; the harder problem is deciding which ideas deserve engineering time. Patent evidence, technical papers, internal context, and design intuition are usually spread across systems and people. A promising concept can be lost because nobody has the time to search, compare, remember, and explain the evidence trail.

InventorOS started from a long-standing personal ambition: make invention exploration feel creative without making it ungrounded. Instead of treating a language model as an oracle, we designed a system that turns an invention brief into a governed, inspectable research process. The result is an evidence-backed invention opportunity for human discussion—not a patentability decision or legal advice.

We built it for the Fortified Enterprise Fleet track because this problem needs more than a single agent. It needs approved roles, durable context, asynchronous execution, security boundaries, a human decision, and a trace that an enterprise can inspect.

What it does

InventorOS is a governed patent-intelligence workflow for R&D teams.

  1. A researcher frames a technical opportunity.
  2. A versioned agent fleet retrieves and normalizes bounded public patent evidence through parallel source lanes.
  3. If the initial brief is too vague, a Technical Query Refiner proposes patent-searchable formulations based on component, mechanism, operating condition, failure mode, and measurable target.
  4. The system builds a project-specific evidence map and a dossier with source provenance, limitations, conflicts, and an engineering hypothesis.
  5. A human reviewer approves, rejects, or returns the dossier for more work.
  6. The final Concept Vision presents three separate visual artifacts: the complete concept direction, a functional mechanical/fluids assembly, and a lean MVP assembly.

The live dashboard makes the workflow visible: reviewers can see persisted agent handoffs, parallel fan-out, control-plane boundaries, audit events, evidence, the final dossier, and the Concept Vision. The public deployment is intentionally read-only so judges can inspect historical runs without creating new jobs or modifying review records.

How we built it

InventorOS is a three-service Google Cloud architecture:

  • Dashboard: React + Express on Cloud Run, publicly available only in read-only showcase mode.
  • Control plane: Rails 8 + AgentKit on private Cloud Run. It owns the versioned Enterprise Agent Registry, project lifecycle, durable workflow barriers, and human-review promotion rules.
  • Agent runtime: Python + Google ADK on private Cloud Run. It receives authenticated Pub/Sub work, claims idempotent execution leases, runs the research fleet, calls Vertex AI Gemini, and records durable state.

The runtime begins with a small curated public-patent index in BigQuery, then uses Vertex AI Google Search grounding when the governed index is insufficient. It does not perform a live scan of the raw multi-terabyte Google Patents BigQuery table. Gemini 2.5 Flash synthesizes evidence-bound output, while Gemini 2.5 Flash Image produces the Concept Vision artifacts. Firestore stores project-scoped run state, handoffs, event history, and execution leases; Cloud SQL stores AgentKit flows, registry records, HITL/audit data, and human-approved reusable RAG knowledge. Generated artifacts live under private, organization/project/run-scoped Cloud Storage paths.

The Fortified control plane is explicit rather than decorative:

  • A Cloud SQL-backed InventorOS Enterprise Agent Registry snapshots approved roles, versions, risk, preconditions, and tool scope at dispatch.
  • Pub/Sub + Cloud Run + AgentKit provide asynchronous, retry-safe work and durable parallel fan-out.
  • Firestore + AgentKit/Cloud SQL RAG retain project-scoped context across sessions; only human-approved knowledge is promoted for reuse.
  • Service-to-service OIDC, dedicated service accounts, and least-privilege IAM enforce agent identity.
  • An application-level, deny-by-default Policy Gateway authorizes named agent-to-tool routes by organization, project, classification, and trace.
  • Regional Model Armor is configured fail-closed for protected model and public-source routes.
  • Firestore event ledgers, AgentKit records, Cloud Logging, and correlated run IDs provide the observability trail.

Infrastructure is defined in Terraform. The reproducible setup instructions, including local spin-up, Artifact Registry, Cloud Build, secrets, migration, Model Armor, and Cloud Run deployment, are in the repository README.

Challenges we ran into

The most difficult part was not making agents appear active; it was making the dashboard tell the truth about asynchronous work. We had to separate a queued run from a running run, prevent duplicate Pub/Sub deliveries, retain progress after a page refresh, and avoid celebrating before a dossier actually existed.

We also had to draw hard lines between three things that are easy to confuse: historical demonstrations, saved research, and the active project. A run can only render its own evidence, graph, dossier, memory, and visuals. Historical data is never used as a fallback for a new run.

Generating useful visual output was another challenge. A product render, a mechanical architecture, and an MVP assembly answer different questions, so we made them independent, run-scoped image-generation lanes instead of reusing one image for every view. We also learned to keep model calls regional and make their failure explicit rather than silently substituting static assets.

Finally, enterprise safety cannot be just a slide. We needed the public judge experience to be easy to open while keeping the runtime, control plane, database, artifact bucket, and mutation endpoints private. The public dashboard therefore has read-only API enforcement in addition to disabled UI actions.

Accomplishments that we're proud of

  • Built a real, deployed multi-agent research workflow rather than a scripted chat demo.
  • Made parallel source retrieval and parallel Concept Vision generation visible in the live agent dashboard.
  • Added a versioned agent registry and immutable dispatch snapshots so a run can be interpreted against the fleet contract that actually executed it.
  • Preserved durable, project-scoped state across asynchronous handoffs and refreshes with Firestore leases and AgentKit/Cloud SQL workflow records.
  • Implemented a clear human-review gate: approval, rejection, reviewer notes, and promotion decisions are auditable and survive retries.
  • Kept the system evidence-first. Every dossier is tied to public-source evidence and clearly states limitations; InventorOS does not claim to decide patentability.
  • Connected the final engineering story to three distinct visual outputs: complete concept, functional assembly, and MVP assembly.
  • Published a judge-friendly dashboard without exposing the private execution fleet or allowing anonymous visitors to mutate research data.

What we learned

We learned that a fleet becomes credible when its boundaries are as visible as its intelligence. A sophisticated agent diagram is not enough: reviewers need to see what was persisted, which role acted, which source route was used, what was blocked, and when a human made the decision.

We also learned that long-term memory must be governed, not merely stored. Run memory is useful for continuity, but only reviewed knowledge should become reusable organizational context. This distinction protects both quality and tenant boundaries.

On the product side, the most valuable output is not an elaborate invention for its own sake. It is a traceable explanation of why a proposed mechanism fits the returned evidence, followed by a simpler MVP that identifies the smallest experiment worth building. The Feynman-style simplification layer and the separate mechanical assembly view made that idea much clearer.

What's next for InventorOS

  1. Enterprise data connectors: add ERP, PLM, laboratory notebook, and document connectors only after each one has delegated identity, classification, regional residency, and policy contracts.
  2. Stronger agent evaluations: create simulation suites for tool poisoning, prompt injection, stale-memory recovery, retry behavior, and evidence quality before a role version is promoted in the registry.
  3. Richer review workflows: add reviewer groups, configurable approval thresholds, comments on specific evidence claims, and an exportable audit package.
  4. Monitoring across weeks: use approved project baselines to trigger governed landscape-monitoring runs when relevant public evidence changes.
  5. Prototype collaboration: connect the approved functional assembly and MVP visual artifacts to structured experiment plans, bill-of-materials hypotheses, and engineering feedback—while preserving the distinction between a design hypothesis and a validated product.

InventorOS is designed to grow from a public-patent research fleet into a trusted R&D operating system: one where creative exploration, institutional memory, security controls, and human judgment reinforce each other.

Built With

Share this project:

Updates

Submission history