Google Patents a Way to Train Chatbots on Plain-English Task Descriptions
Every business task a chatbot handles today usually requires engineers to hard-code the rules. Google is patenting a way to skip that by letting the AI read plain-English descriptions of what a task needs, then figure out the rest from the conversation itself.
How Google's chatbot learns new tasks without custom code
Every time you call a company's support line and an automated system asks 'what city are you flying from?' it is following a rigid script someone had to build by hand. Google's new patent describes a way to train a chatbot that can pick up those kinds of tasks just by reading a plain-English explanation of what information it needs to collect.
Instead of a programmer writing explicit rules like 'if the user mentions a city, store it as the departure field,' the system reads a description of the task written in ordinary language. It then watches the back-and-forth of a conversation and figures out which pieces of what the user said belong in which fields, all on its own.
The practical payoff is that you could theoretically describe a new business task, hotel bookings, tech support, prescription refills, in plain text, and the AI would know how to handle it without anyone writing new code around it.
obtaining a schema for a target task, wherein the schema includes a plurality of slot definitions, and wherein each of the plurality of slot definitions include a corresponding natural language description of corresponding values for a respective one of the plurality of slot definitions …
Translation: The system creates a list of categories for a task by using plain language to explain what kind of information goes in each.
How the model maps conversation turns to numbered task slots
The patent describes training a sequence-to-sequence language model (a type of AI that reads a chunk of text and outputs another chunk of text, like a translation engine) to track the state of a conversation as it moves through a structured task.
Here is the core loop:
- The system receives a schema for a task. A schema is basically a list of the information the task needs, like departure city, date, and passenger count for a flight search, each described in plain English.
- Each field in that list gets a numbered index, a simple pointer so the AI can refer to it precisely.
- The AI then reads the full conversation history between a user and an agent, combined with the schema, and predicts a dialog state, meaning it outputs a list of which fields have been filled in and what values belong in them, based purely on what the user has said so far.
The indexed approach is what makes this different from earlier methods. Instead of copying the user's exact words into a field, the model maps those words to a numbered slot definition. That keeps outputs clean and structured even when the user phrases things in unexpected ways.
The training process feeds the model many examples of conversations paired with their correct final states, so it learns to generalize to new tasks described in the same plain-English format.
The methods include determining a contextual representation comprising a concatenation of a history of dialog sequences exchanged between a user and a service agent, wherein the dialog sequences describe a context for the task.
Translation: The AI combines the entire history of the conversation into a single data stream to understand the current situation.
What this means for AI-powered customer service tools
Right now, building a virtual assistant that handles a specific task, like booking a restaurant or troubleshooting a router, requires a team to write explicit logic for every possible conversation path. This patent aims to collapse that work into writing a description, which is a much lower bar. It would let companies spin up new automated workflows without deep engineering investment each time.
The AI-powered customer service space is one of the more active areas in this week's Big Tech patents, and Google's approach here reflects a broader bet that general-purpose language models can absorb task-specific knowledge from text alone rather than from hand-crafted rules.
The core trade this design makes is legibility for fragility. Describing task requirements in natural language is dramatically easier than writing code, but natural language is also ambiguous, and the model's ability to correctly interpret a loosely written schema description is only as good as its training data. If a business writes a slot description that is slightly off or uses phrasing the model has not seen before, the predicted dialog state could map values to the wrong fields with no obvious error signal. That is a real cost in production environments where a misunderstood task field can mean a wrong order, a missed appointment, or a frustrated customer. The trade reads as reasonable for well-resourced deployments where teams can write careful descriptions and monitor outputs, but it likely undersells the editing discipline the approach actually requires.
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
8 drawing sheets from US 2026/0236708 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →