AGI invention and innovation: beyond the feature list.

Most software is bought to do a known job. Invention is the opposite: the job does not exist yet, or exists as a problem without a product. A system built for a fixed feature list cannot help there. A general intelligence can, because the loop does not change when the task has no precedent.

Invention is not a novelty feature bolted onto the site. It is the natural consequence of a system that can research, design, code, test and iterate inside one thread. The same intelligence that rebuilds a page can build a prototype, and the same evidence discipline applies: nothing is claimed until it runs.

It is also the honest end of the capability argument. Unlimited domains are examples. Beyond them sits the work nobody has packaged yet: a tool your business needs and cannot buy, a product idea too small for a vendor to build, a process that has never been automated because it was never quite the same twice.

That is the practical case for invention as a capability rather than a slogan. The unserved work is not exotic; it is the ordinary work that falls between product categories. A general intelligence does not need a product category to start.

The edge matters too: invention is where unverified claims do the most damage. A prototype that was never run is not an invention. A concept deck is not a product. The loop only closes when something works and the evidence is attached.

The service case is simple. A business with a new idea usually has three options: hire a development team it cannot justify, buy a platform that almost fits, or leave the idea in a document. A general intelligence adds a fourth: build the smallest real version, test it, and decide on evidence whether it deserves more investment.

The same applies inside existing systems. Most teams have a list of internal tools they would build if they had a spare engineer: a reconciliation script, a small dashboard, a form that connects two systems nobody wired together. Those tools are too small for a project and too valuable to skip. They are exactly the size of an R&D loop.

Invention also changes what asking for software sounds like. Instead of specifying every field and flow before anything exists, you state the problem and the test. The first build is allowed to be rough, because the purpose of the first build is to produce information rather than to ship.

None of this needs a research department. It needs a way to turn a stated problem into a run, a run into a build, and a build into evidence. That is the loop, applied where no product exists.

Not every idea deserves a build, and part of the framing work is deciding that. The loop should be cheap enough that a bad idea dies in a day and expensive enough that a good one produces something real. Most teams never build the small tool because even starting looks like a project.

A second pattern is composition. Many products that do not exist are simply two existing tools wired together with a better interface and a check in the middle. The invention is the connection and the reliability, not a new algorithm.

Some of the most valuable work is repair. A process that breaks quietly, a page that has been wrong for a year, a deployment nobody understands, a spreadsheet that recalculates into the wrong answer. None of it is glamorous and all of it costs.

The method is the same loop with a different first question: what should this be doing, and what is it actually doing? The gap is the diagnosis. From there the fix is planned, applied, verified and documented, so the next person can see why it was done.

Repair is also where a general intelligence beats a specialist tool. Specialists are built for the system they know. Real breakage crosses boundaries: a website problem that is really a DNS problem, a reporting error that starts in a spreadsheet, an automation that fails because an upstream format changed. One intelligence can follow the failure across the boundaries.

The standard is not that it works now. The standard is that it works now, the reason is understood, and there is a check that will tell you if it breaks again. That is the difference between a patch and a repair, and it is why repair work belongs in the same loop as invention.

There is a quiet satisfaction in this work that is worth naming. The thing that was broken is now understood, and the next failure will be quicker to find. A system that is understood can be changed; a system held together by habit eventually cannot.

Repair work is often where invention begins. A fix that keeps recurring is a product waiting to exist: the script that patches a process, the check that catches a failure earlier, the small interface that removes a manual step. The loop records the pattern, and the pattern becomes the specification.

There is also a class of repair that is really an argument. A system breaks because two assumptions disagree: a format changed, a dependency moved, a process grew around a constraint that no longer exists. The fix is not to patch the symptom but to find the assumption that has stopped being true and design around its absence.

Inherited systems deserve honesty. Some are too fragile to change in one step, and the right answer is a careful containment, a documented workaround and a plan for the next attempt. A repair that is understood but partial is better than a rewrite that is ambitious but untested.

The repaired system also teaches the agent something about the next system. Patterns repeat across businesses: the same fragile integration, the same manual reconciliation, the same spreadsheet acting as a database. A repair in one place becomes a warning in the next.

Repair is also a form of respect for the work that came before. Someone built the system, made decisions under constraints you cannot see, and kept it running longer than expected. Understanding that before replacing it is part of doing the job properly.

Every claim about invention needs a boundary, and this one is simple: no guarantees of novelty, no guarantee of market fit and no guarantee that the idea is good. Those are not software problems. They are judgement, evidence and the market’s answer.

What can be promised is process: the problem is framed, the hypothesis is testable, the build is real, the test is honest and the record is kept. If the idea fails, you get an accurate failure and a faster next loop. That is worth more than a confident deck and a launch date.

There are also honest limits on reach. Invention that needs physical fabrication, regulated approval, laboratory access or clinical trials is beyond a desktop application acting alone. The intelligence can do the design, the code, the documentation and the coordination around those steps, with human specialists owning the parts that need a signature.

Most of all, invention is not magic and it should not be sold as magic. It is the systematic application of general capability to a problem that has no product yet. The loop is ordinary. The output is not, and neither is the risk of claiming more than the evidence supports.

There is a second kind of leverage that is easier to miss. Cross-domain work is not only faster; it produces better questions. A researcher looking at a data problem will ask about sources; a coder looking at the same problem will ask about reproducibility. A general intelligence carries both habits into the same run, so the frame is examined from more than one side before the build.

That is why the R&D loop belongs in this product rather than in a specialist sandbox. A prototype that needs a landing page, a data check and a deployment is not three projects; it is one goal with three domains. The hand-offs between them are where most invention dies quietly, because the idea is still fragile when the first transfer happens.

Leverage also compounds with memory. A prototype built this quarter becomes a skill next quarter: the same approach, available without a rebuild. The tenth small tool costs a fraction of the first, not because the build got easier but because the intelligence kept what it learned.

One more boundary: invention does not license invention. A prototype must not quietly become production just because it worked once. The loop ends with a test and a report; the decision to promote it to something real is a human decision, made with the risks visible.

What remains in scope is the part that matters most: the ability to attempt. Most organisations are not short of ideas. They are short of ways to try them without a quarter-long commitment. That is the gap this capability fills.

The test of an invented thing is the same as the test of a repaired thing: does it work, and can you show why?