The engine itself is a collaborative multi-agent pipeline stitched together mostly in Python. At a high level:

Problem hunting agents are given domain/subdomain pairs and are tasked with identifying the most impactful problems humanity faces in each area. Challenges are expanded into structured problem statements.

Domain agents (energy, digital systems, life-sciences-adjacent, etc.) work collaboratively to propose and refine seed candidate mechanisms and architectures - working from first principles within gaps discovered during systematic searches of patent archives, academic papers, and the open internet.

Refinement loops force agent interaction to resolve contradictions, tighten constraints, and generate something physically, economically, and organizationally plausible.

Report agents turn that graph into three separate documents: main report, implementation guide, and societal/industry impact report.

A guardian layer tries to filter out obvious garbage and anything in categories we simply do not want to publish (biohazards, weapons, high-risk surveillance, etc.).

Right now it runs on a mixture of frontier models behind an abstraction layer so we can swap individual agent models without rewriting the pipeline. Model selection is important, but perhaps less so than the framework and choreography: prompt schemas, roles, collisions, constraints, and consistency checks contribute most to the end result.

Every published innovation is a shared vision between at least 18 individual ai agents.

We render PDFs with consistent front-matter, metadata, and internal IDs.

Hashes and PDFs are anchored on Arweave for timestamping and persistence.

A WordPress front end and some custom templates serve the human-readable library.

Throughput is currently set at ~4 innovations per day, mainly constrained by API cost and some deliberately conservative safety checks. There is a scheduler that manages queues, retries, and backpressure so the thing can run 24/7 without me babysitting it.

Happy to go deeper on any of the above if there is interest.

A few clarifications from the IP side, since this always comes up.

This is not legal advice.

“Prior Art” is messy in practice. What counts, and how heavily it weighs, varies by jurisdiction and fact pattern.

What we can control is: novelty, public availability, timestamps, persistence, and how closely the disclosures resemble things examiners actually read.

For the AI-generated innovations, I worked with a patent lawyer to make each package look like a reasonably “enabling” disclosure: a clear statement of the problem, the core idea, constraints, and at least a sketched path to implementation. Some will inevitably be too hand-wavy to block a very narrow claim, others will be overly broad. The goal is to increase the probability that examiners and litigators have something concrete to point at.

Separately from the lab, the Unpatent tool exists for humans who already have their own write-ups and want to publish them as prior art:

You upload a document or paste text, add some metadata, pay a flat fee.

The system publishes to a prior-art archive that is explicitly consumed by the USPTO, and anchors the same content on Arweave for timestamping.

Result is a public, timestamped disclosure that can be cited as a printed publication equivalent.

That path is meant for cases where someone has a real, specific invention and wants a cleaner, more obvious defensive disclosure than hoping a blog post gets indexed and noticed.

I am very interested in hearing from more patent practitioners on how this is perceived, and how to make both the AI-generated disclosures and the Unpatent tool more useful in the real world.

A few people have asked why I am not just offering this as “GPT for inventions”. A product that anyone can prompt.

Three reasons (this is my current reasoning, subject to change):

Safety and incentives. If the engine was exposed as a generic invention API, there would be strong incentives to push it into areas I do not want to automate or publish (offense-heavy domains, surveillance optimizations, etc.). Keeping it as a one-way lab allows steering towards domains with positive human impact.

Mission alignment. The point of this project is to create a massive public library of prior art that is hard to appropriate and easy to build on. Charging per-generation access to the engine pushes in the opposite direction. I would rather keep the core engine pointed at “public good” domains and let people use the outputs freely.

Funding reality. There are real running costs (models, infra, time), so it cannot be self funded forever. Demand for an ai invention tools that gives away the secret sauce is generally low among the public sector. The model we are exploring is domain sponsorship:

A sponsor funds a track (or tracks), for example “wildfire resilience” or “low-cost diagnostics”.

We configure and run cohorts of the engine focused on that track.

The output still goes into the public library and through all disclosure channels with clear notice that the track was sponsored; there are no exclusive rights.

That feels like a better fit for what this is trying to be: infrastructure for open innovation rather than another IP-wrapping startup.

If you have opinions on better funding structures for this kind of thing, I would genuinely like to hear them. I am trying to avoid the failure mode where something starts as “for the commons” and drifts into enclosure because of financial pressure.

People have asked about ai hallucinations, so here’s the honest version.

TLDR; Hallucinations sometimes happen. But they don’t break the usefulness or validity of the disclosures, and the system is designed so that incorrect details don’t invalidate the core idea. Modern models hallucinate less than they used to, and the disclosure format is resilient to the remaining noise.

More detail:

Hallucination rates are dropping over time Across the last two model generations, we’ve seen a very noticeable decline in fabrications when using structured, constrained, multi-agent prompting. It’s not perfect, but the trend is clearly improving.

We don’t treat the AI as an oracle The engine is more like a tireless research assistant than a truth machine. The supervisor + refinement loop forces internal consistency, so the output tends to be coherent even if some details aren’t experimentally validated.

Incorrect details don’t invalidate prior art Prior art doesn’t have to be flawless to count. In practice, examiners and courts often rely on the portions that are correct, even in papers or disclosures that contain errors. What matters is that the idea, mechanism, and implementation pathway are publicly taught. A disclosure can be partially wrong and still function fully as prior art.

We run internal filters to catch the worst issues There are consistency checks, cross-agent critiques, domain sanity filters, and safety blocklists. These reduce (but don’t 100% eliminate) hallucinations. The goal is to keep the output in a usable, conceptually solid range.

The point isn’t to assert truth; it’s to make ideas public These aren’t meant to be validated research papers. They’re structured disclosures designed to teach a concept clearly enough that a practitioner can understand and build on it. This is the bar for defensive publication, not empirical proof.

Valid portions still create value Even if a paragraph is off, the rest of the disclosure still stands. And if anything truly incorrect is identified, we treat that as feedback for improving the filtering and refinement loops.

So yes, hallucinations exist. But they don’t undermine the purpose of making ideas public, timestamped, findable, and structurally useful as prior art. And as the models improve, the signal to noise ratio keeps improving too.

Happy to dig deeper into how we evaluate or mitigate this if anyone wants specifics.