Google Files Patent for an AI That Turns a Sketch Into a Cloud App Plan
Sketch the app you want on paper, hand it to an AI, and get back a plan a computer can actually deploy. A new Google patent application describes that pipeline for the hidden wiring behind big apps and websites.
What Google's app-blueprint AI actually does
Imagine you're launching an online store and you sketch the setup on paper: a front door for visitors, a place that tracks orders, a database for products. Turning that sketch into something a computer can run usually takes a specialist a lot of careful, fiddly work.
Google's patent describes an AI that writes the first draft. You describe what you want in words, or hand over a picture of the sketch, and the AI draws a rough blueprint made of boxes and arrows. Then it checks which Google cloud services you are allowed to use, picks one for each box, and fills in settings such as where it runs and how much traffic it should handle.
The last step converts the finished plan into a standard file format engineers use to set up cloud systems (Terraform is one example), so your team can put it to work.
… generating, by a machine-learned model implemented by the computing system, an initial design specification with a plurality of components for a structure of an application based on the application request …
Translation: An artificial intelligence builds a blueprint for the app using your request.
How Google's draft design gets real services
Claim 1 covers a pipeline with a clear order. A user sends an application request. A machine-learned model (an AI trained on large amounts of example data) produces an initial design specification: a draft built as an intermediate representation of a design graph. In plain terms, that is a neutral map of boxes (components, each with a job) and arrows (connections) that is not tied to any one vendor's tools.
From there the system works through these steps:
- It reads a list of services available to that user, drawn from the user's profile and permissions.
- For each box, it picks a service from that list that can do the box's job.
- It sets that service's parameters (things like region, machine type or scaling rules) based on the request.
- It produces a final specification and converts it to a destination format.
The description adds optional extras. A "design agent" (an AI helper that reviews the draft) can add protections, such as attaching a Cloud Armor firewall policy if you mention defending against floods of fake traffic. Big requests can be split into application, component and resource tasks. Components can be configured in parallel. The system can also pull from a library of pre-approved building blocks, and translate AWS or Azure templates into Google equivalents, such as swapping a Lambda function and DynamoDB table for Cloud Run and Cloud SQL.
The computing system accesses a list of services available to the user and determines, for a respective component, a first service from the list to perform an associated task.
Translation: The system matches each part of the app blueprint to available cloud tools.
Why this matters for anyone building on Google Cloud
If you have ever wondered why launching an app takes whole teams, part of the answer is the wiring. A single online store can need a front door for visitors, several separate services, multiple databases, and rules tying them together. This patent describes a tool that drafts that wiring from a description, so people can review and adjust instead of starting from a blank page.
The filing points to practical places this could live: a chat window, a coding assistant, or a design canvas where a person reviews each change before accepting it. It also describes moving a setup from AWS or Azure over to Google's equivalents, and sticking to pre-approved building blocks so protections like encryption are on by default. For Google, a tool like that could make its cloud easier to adopt. For you, it could mean the app behind a favorite service gets built, and changed, faster.
Google's 57th filing we've tracked in our AI agents acting for you watch since May builds on earlier applications like the custom screen builder and the plain-English robot coder.
Claim 1 is short on specifics and long on steps. It never names a kind of AI model, a particular cloud, or what the output file must look like. Text and images only appear in the narrower dependent claims, so the main claim reaches any kind of request.
Two requirements give it shape. The AI's first draft has to be a graph of components, and the services it picks have to come from a list of what that particular user can access. A tool that writes deployment code straight from a prompt, with no draft plan and no permissions check, would sit outside the claim's wording as written.
That makes the claim wide on inputs and outputs, with the ordered pipeline as its fence. The permissions check is the most useful piece: a draft built only from services you can actually reach is a draft you can act on.
Get our take in your Top Stories
Liked this breakdown? Add Patentlyze as a preferred source on Google, and our plain-English take shows up more often in your Top Stories the next time Google patent news breaks.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
20 drawing sheets from US 2026/0329545 A1 · click any drawing to enlarge
Show the other 12 sheets
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →
Be the first to weigh in