How I’m Using Google Opal for Even More AI Automations

Google Labs shipped an agent step for its no-code Opal tool in February 2026, letting the system choose which model or tool to run at execution time instead of requiring builders to wire fixed models such as Gemini, Imagen, or Veo into each Generate step. Opal, built on Google's internal Breadboard framework created by engineer Dimitri Glazkov, now has an official home on Google for Developers rather than only in the Google Labs experimental catalog where it launched in July 2025. According to reporting on the rollout, Google described the shift as moving away from fixed, manually configured processes toward agent-driven automation that needs less setup from the person building it.

How I’m Using Google Opal for Even More AI Automations Opal is Google Labs' no-code tool for turning natural language into working AI mini-apps, built on top of an internal framework called Breadboard. Here's how I learned to use it best. The last time I opened Opal to start a new build, something in the interface had quietly changed. The Generate step, the one I'd used a dozen times to pick Gemini or Imagen or Veo, now had a new option sitting right above the familiar model list, simply labeled "Agent." No blog post had landed in my inbox announcing it. It was just there, waiting to be clicked. That small addition turned out to be a genuinely different way of building with this tool, and it's the reason this article exists. If you haven't built anything with Opal yet, go read Building AI Automations with Google Opal https://www.kdnuggets.com/building-ai-automations-with-google-opal first; it walks through the Editor, the three original step types, sharing your app, and debugging with the Console in full, and everything here assumes you've got that foundation already. This piece picks up exactly where that one left off: what's changed since, and a full second build that specifically puts the new pieces to work. A Fast Recap, for Anyone Catching Up Opal https://opal.google/landing/ is Google Labs' no-code tool for turning natural language into working AI mini-apps, built on top of an internal framework called Breadboard, created by Google engineer Dimitri Glazkov. You describe what you want in plain English, Opal turns that description into a visual, editable workflow of connected steps, and you can share the finished app with a public link — no server, no deployment pipeline, no code. The mechanics of the Editor, the App preview, the Console, and version history are all covered thoroughly in the first article, so this piece won't repeat that ground. What follows is everything that's arrived since. What's Actually Changed Since Then The short version: Opal stopped being just a tool for wiring together fixed, manually chosen models, and started being able to make some of those choices itself. In February 2026, Google Labs shipped what it calls an agent step, and it's a meaningfully different way of building than the original three-step model of User Input, Generate, and Output. There's a second, quieter signal worth noting alongside the feature itself. Opal now has an official home under Google for Developers https://developers.google.com/opal , rather than sitting only inside the Google Labs experimental catalog where it launched in July 2025. Google Labs is where the company tests ideas that may or may not stick. Getting folded into the main developer site is usually a sign a product has earned a longer-term commitment, and the pace of feature releases since backs that up. The Agent Step: Letting Opal Decide the Path Here's the actual difference. In the original Generate step, you picked one specific model — Gemini for text, Imagen for an image — and wrote it a prompt. The step did exactly that one thing, every time, in the exact order you wired it. Select Agent instead, and the step stops being tied to a single model at all. You describe a goal rather than a fixed instruction, and the system figures out, at the moment it's actually running, which model or tool best serves that goal — calling on Gemini's reasoning to plan an approach, reaching for a web search tool if it needs current information, or triggering an image or video model if the goal calls for one. According to reporting on the rollout, Google described the shift https://www.socialsamosa.com/news-2/google-updates-opal-adds-agent-driven-workflow-system-11152917 as moving away from fixed, manually configured processes toward agent-driven automation that needs less setup from the person building it. The digital storybook example from that same coverage makes the difference concrete. Before this update, building a storybook generator in Opal meant deciding page counts and writing out prompts for each page in advance, because the workflow could only execute the exact steps you'd pre-wired. With the agent step, you can hand it a goal instead — something like "write and illustrate a five-page children's story about a lost kite" — and the agent works out what information it actually needs, suggests plot points as it goes, and adjusts the story's direction based on what it generates along the way, rather than following a script written before it started. Three New Tools That Ship With the Agent Step The agent step's flexibility comes from three specific tools that arrived alongside it, and it's worth understanding each one individually rather than treating "agent" as one undifferentiated upgrade. 1. Memory lets an Opal app hold onto information across sessions instead of starting from a blank slate every single time someone opens it. A user's name, a stated preference, a detail they gave you three runs ago — all of that can persist and get pulled back in automatically the next time that same person returns. 1. Dynamic Routing , exposed through what's called the "@ Go to" tool, is what lets the agent pick its own next step while it's running, instead of following a single path you wired by hand ahead of time. If a workflow has a few different directions it could reasonably take depending on what the user provides, the agent can choose the one that actually fits, rather than forcing every user down one identical sequence regardless of their situation. 1. Interactive Chat lets the agent pause mid-run and actually ask the user something — a missing detail, a choice between two directions — before continuing. This is the piece that removes the most guesswork. Earlier versions of Opal could only work with whatever the User Input step collected up front. An agent with Interactive Chat can notice it's missing something it needs and just ask, the same way a competent human assistant would, rather than quietly assuming and possibly getting it wrong. The Fuller Model Lineup The model roster available inside a Generate step has grown noticeably since the first article, which only had reason to cover Gemini for text and logic, Imagen for images, and Veo for video. Today's picker looks like this: | Model | What It's For | |---|---| | Agent | Dynamically selects models and tools based on a stated goal | | Gemini Flash | Fast, everyday text and reasoning tasks | | Gemini Pro | More complex reasoning and multi-step tasks | | Nano Banana | Image editing and generation | | Nano Banana Pro | Complex visuals that need to include accurate text | | AudioLM | Text-to-speech generation | | Veo | Text-to-video and image-to-video generation | | Lyria 2 | Instrumental music generation | That's a genuinely wider toolkit than what existed when the first article published, and it's part of why the agent step matters as much as it does. An agent choosing its own path is far more useful when there's an actual range of specialized models for it to choose between, rather than one model doing double duty for every kind of output. The App We're Building: An AI Interview Prep Coach For this article, we're building something the original three-step types genuinely couldn't have pulled off on their own: an Opal app that takes a job description and a resume, asks a clarifying question if something important is missing, decides for itself whether it needs to search the web for information specific to that role, and produces a tailored interview prep document. It also remembers the user's target role and experience level, so a second visit doesn't require explaining everything over again from scratch. It's worth being specific about why this app, rather than another version of the SEO-keyword generator from the first piece. That one worked perfectly well with a fixed path: input, one generate step, output, done — every time, for every user, in the same order. An interview prep coach doesn't fit that shape. Whether it needs to ask a follow-up question depends on what the user actually submits. Whether it needs to search the web depends on whether the role or company is one the model already has solid context on. And whether it should skip straight to generating prep material depends on whether it already knows this user from a previous session. Those are exactly the three problems Memory, Dynamic Routing, and Interactive Chat exist to solve, so this build puts each of them to real, direct use rather than as a tacked-on demo. Starting Opal and Writing the Initial Prompt Click Create New the same way you would for any Opal, and this time, describe the whole idea in one detailed prompt rather than a narrow single-purpose one: Build an application that collects a job description and a resume from the user, asks a clarifying question if key details like the target role or seniority level are missing, researches typical interview questions for that specific role and company if needed, and generates a personalized interview prep document. Remember the user's target role and experience level for future visits. Opal will translate that into a starting workflow, typically a User Input step feeding into an Agent-based Generate step, feeding into an Output step. Expect to refine the wiring by hand afterward — this initial pass gets you a working skeleton, not a finished app. Setting Up the User Input Step Click into the User Input node and set it up to collect two things: the job description as text, and the resume as a file upload. In the Advanced settings for this step, set the input type to accept a file or "any," if you want to allow either a pasted text resume or an uploaded document , so the step actually shows an upload field to the end user rather than only a text box. Configuring the Agent Generate Step This is where the real work happens. Select the node, choose Agent from the model dropdown instead of a fixed model, and write a goal-oriented prompt rather than a rigid instruction: Using the job description and resume provided, identify the target role, company, and seniority level. If any of these are unclear or missing, ask the user directly before continuing. Research common and role-specific interview questions for this position if you don't already have strong context on it. Generate a prep document with likely questions, suggested talking points based on the candidate's actual experience, and two or three questions the candidate should ask the interviewer. With the prompt field focused, type @ to bring up the tools menu and attach Memory , so it can store the user's target role and level, and Interactive Chat , so it can actually pause and ask instead of guessing when something's missing. You don't need to manually attach a web search tool here. Because this is an agent step, it can reach for a search tool on its own, at runtime, specifically when it decides the role or company needs research it doesn't already have solid context on. That's the dynamic routing piece doing its job without you wiring a fixed path for it. Watching Opal Wire In a Search Tool When Needed You won't see a web search step permanently sitting in your canvas the way you would in the old fixed-model approach, and that's expected. It only appears in execution when the agent actually decides it's needed. This is the clearest visual difference between building with the old Generate step and building with the new Agent step: the workflow diagram itself can look almost identical between two different apps, while what actually happens when a real user runs them can diverge based on their specific input. Setting Up the Output Step Add an Output step, connect it to the Agent step's result, and set the output type to Google Doc, since a prep document is something most people will want to keep, search, and revisit before an actual interview rather than read once on a webpage and lose. Give it a clear title template — something like referencing the role and company pulled from the earlier step — so a user building prep docs for multiple applications can tell them apart at a glance in their Drive. Testing It and Watching the Agent Decide Switch to App view and run it with a real example — a pasted job description for a mid-level product manager role, and an uploaded resume. Pay closer attention to the Console for this run than you might have with a fixed-path app, because it's now showing you something genuinely new: not just what each step did, but which tool or model the agent chose to use and why, since that choice isn't fixed in the workflow itself anymore. Run the same app twice with two different resumes, and it's entirely normal to see two different paths in the Console. One run might trigger a web search because the company is one the model has thin context on. Another might skip straight to generating the document because the role is common enough that no research step was necessary. That variability isn't a bug to chase down; it's the actual point of building with an agent step instead of a fixed one. Sharing and Publishing Once the app is behaving the way you want, sharing it works exactly the way it's described in the first article: click Share app , toggle it to publish publicly, and you'll get a URL anyone can use to run it themselves, with the option to restrict access to specific people instead if you'd rather keep it private. Nothing changed here with the agent step update, so there's no need to walk through it a second time. What's Still Worth Knowing Before You Build on This It's worth staying honest about where this still stands, since Opal remains officially an experimental Google Labs product even with its new home on the developer site. There's no documented way to export a working Opal prototype directly into production-ready code, so if an app like the one built here needs to graduate into a real, standalone product, expect to rebuild it against the Gemini API https://ai.google.dev/ rather than deploy the Opal version as-is, based on what current documentation covers https://www.toolworthy.ai/tool/opal-google . There's also no published quota or rate-limit policy yet, so how the platform behaves under heavy, sustained usage isn't something Google has formally committed to in writing, and production-grade enterprise features like SSO or audit logging aren't part of the documented feature set as of this writing either. None of that should discourage building with it. The pace of real, substantive change backs up the opposite conclusion: agent-driven workflows, three new tools, an expanded model lineup, and availability that reportedly grew to more than 160 countries — all landed within roughly seven months of the tool's original launch. That's a fast clip for any product, let alone one still labeled experimental. Wrapping Up The apps in the first article followed a path you drew for them, start to finish, the same way, every time. The one built here decides part of that path on its own, pauses to ask when it's genuinely unsure instead of guessing, and remembers the person using it well enough that their second visit doesn't start from zero. That's a real shift in what "no-code app" means inside this tool, not just a new item on a features list, and it's worth building something with it before the next update quietly changes the picture again. \ Shittu Olumide\ https://www.linkedin.com/in/olumide-shittu/ https://www.linkedin.com/in/olumide-shittu is a software engineer and technical writer passionate about leveraging cutting-edge technologies to craft compelling narratives, with a keen eye for detail and a knack for simplifying complex concepts. You can also find Shittu on Twitter https://twitter.com/Shittu Olumide .