Build Your Own Team of Managed Agents - Jack Wotherspoon, Google DeepMind
Read the talk
Build Your Own Team of Managed Agents
Jack Wotherspoon explains how Gemini Managed Agents combine a cloud sandbox, the Antigravity harness, reusable instructions, and separate conversation and filesystem state. The demos follow company filings through quantitative analysis and into reports built inside an application.
From a talk by Jack Wotherspoon
At a glance
Ideas worth remembering
A managed agent packages a cloud sandbox and an agent harness behind an API call, removing local execution interference and much of the infrastructure setup.
Interaction IDs continue conversations; environment IDs reuse workspaces. Keeping those separate lets a fresh agent build on saved files without inheriting the earlier conversation.
Skills and AGENTS.md supply working instructions, repositories supply code, and MCP servers supply service connectivity. A saved agent configuration makes the refined setup callable again by agent ID.
The credential proxy keeps the real token outside the sandbox and injects it into destination-matched requests. This isolates the secret rather than proving that every authenticated action is safe.
The NVIDIA demonstration makes specialization concrete: filing research produces metrics.json, a quant agent reads it and runs Python analysis, and a third agent can turn the research into a report.
An application can expose the final artifact rather than the agent's execution stream. The VOO example returns a PDF with analysis, charts, and links to the documents used.
Move the work off your laptop
A coding agent running verification can take over your browser, launch processes, and leave you dealing with pop-ups while you try to work. Jack Wotherspoon, a developer experience engineer at Google DeepMind, starts with this ordinary nuisance before introducing managed agents: run the coding-agent harness in a cloud sandbox rather than on your own machine. The agent can still write code, search the web, run tests, and inspect results; its working environment moves elsewhere.
The second problem is sharing that setup. A personal coding agent may have useful skills and carefully chosen instructions, but a colleague cannot automatically reuse them, and a customer-facing application should not depend on your laptop and personal subscription. As Wotherspoon puts it, “your laptop doesn't scale.” Moving execution to an API-accessible service makes the agent something an application can invoke rather than a workstation someone must keep running.
Doing this yourself means provisioning a container or virtual machine, loading its dependencies, building or installing the agent harness, and handling networking, firewall rules, and security. Gemini Managed Agents packages the sandbox and the Antigravity harness behind one API call. Additional calls request additional agent runs, leaving the service to manage the underlying infrastructure. The simplification is operational: the application still has to decide what work to request and how to use the result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An interaction can contain a whole agent run
The Interactions API gives that run a different shape from a simple model request. An input need not lead straight to a final text response. The agent may write a file, execute it, call an external tool, inspect the result, and continue. An interaction represents this multi-step work rather than treating the entire operation as an opaque input/output exchange.
What makes the demonstrated call a cloud-agent request? It selects the base Antigravity agent and sets environment="remote", then supplies the task as input. That environment setting requests remote execution. The useful distinction in the example is between choosing an agent, which includes a harness for doing work, and choosing only a model to generate a response.
Underneath the call, the Gemini API provisions a sandbox on Google Cloud infrastructure. The service provides tools such as Google Search and filesystem access, while custom functions and MCP tools can extend what the agent can reach. Startup material can include a GitHub repository, an AGENTS.md file, and skills. This lets a remote run begin with actual working material instead of asking the model to reconstruct a project from the prompt.
The building blocks have different jobs:
- Harness: Antigravity manages tool use and supplies built-in tools. Wotherspoon describes it as the same harness used in Google's Antigravity product suite.
- Environment: The sandbox filesystem holds the work. Another agent can reuse it and build on files already written there.
- Skills: Uploaded playbooks describe how the company or individual wants a task performed.
- Credentials: Authentication connects the agent to services; the later proxy example explains how the real secret stays outside the sandbox.
- Triggers: A schedule starts a run without waiting for a person to submit a task.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Choose the model for the job—and budget for its output
The harness does not fix the model choice. A model parameter in the agent configuration lets the same managed-agent setup serve different workloads. Wotherspoon proposes Gemini Flash for fast, efficient work and Gemini 4 Argon for deeper reasoning or extensive analysis. This separates the execution machinery from the reasoning capability selected for a particular task.
A second capability concerns how much the model can produce. Wotherspoon describes Gemini 4's “long decode”: instead of an output ceiling of around 64K tokens, it shares a one-million-token budget among input, thinking, and output. Those are competing uses of the same allowance, not three separate million-token capacities. The intended use is work such as mathematical reasoning or financial modeling whose answer may run for many pages.
The claimed benefit is room to finish an unusually long analysis without hitting a smaller output cap. Wotherspoon also reports improvements on mathematical and financial benchmarks, but supplies no named benchmark or score here. That supports understanding the proposed capacity change, not a quantified prediction of better financial analysis.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the files without inheriting the conversation
The key to handing work between agents is that conversation state and workspace state are separate server-side objects. An interaction records the conversation. Passing an interaction's ID into the next interaction continues that conversation into another turn. An environment represents the sandbox filesystem: documents, generated images, code, and other files. APIs can upload material into it or download the results.
What survives when the next agent starts fresh? Reusing an environment ID preserves access to the workspace without requiring the next agent to inherit the earlier conversation. The two paths below distinguish conversation continuation from file-based handoff. Continuing the conversation carries forward conversational state; reusing the environment gives a fresh interaction access to the work already saved.
The example begins with one agent collecting filings or annual reports, doing some work, and saving files. A later agent receives the same environment ID and starts with a fresh context window. It can read those saved materials and continue the analysis. The handoff therefore depends on what the first agent writes down: files preserve the selected work product, while the fresh conversation does not automatically contain every earlier exchange.
Two ways to carry state into the next interaction
Read the diagram as text
- Previous interaction. conversation-continuation — Holds server-side conversation state.
- Next conversational turn. conversation-continuation — Continues the conversation using the previous interaction's ID.
- Existing environment. workspace-handoff — Contains files saved by an earlier agent.
- Fresh agent interaction. workspace-handoff — Starts a new conversation while accessing the existing workspace.
- Previous interaction → Next conversational turn: Pass interaction ID to continue conversation.
- Existing environment → Fresh agent interaction: Reuse environment ID to access saved files.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Bring tools, instructions, and a repository
Customization comes through both connectivity and working material. Built-in code execution, file reading and writing, and Google Search cover common operations. Remote MCP servers connect other services. Uploaded skills and AGENTS.md files bring the playbooks used by a personal agent into the cloud environment. The code and generated files stay in the sandbox rather than modifying the developer's local workspace.
How does a repository-aware task get its starting context? The code example uploads an AGENTS.md file and connects a GitHub repository. The repository supplies the code to inspect; the instruction file supplies guidance for working on it. Together they support a task such as checking the project for bugs without requiring the developer to paste the codebase and its conventions into each request.
Once the setup behaves as intended, agents.create saves a reusable agent configuration. Subsequent calls invoke that agent by its agent ID. This is a different kind of reuse from the shared environment: the saved agent makes a refined setup callable again, while an environment holds the files produced during work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep secrets outside; make runs scheduled and specific
The credential mechanism refines the earlier description of giving agents authenticated access. The sandbox receives a dummy token, not the real GitHub secret. When the agent sends a request to the GitHub API, an intervening proxy matches the destination and injects the actual token. The agent can make an authenticated request without possessing the credential itself.
Where does the real token enter the request? The diagram places that change at the proxy, after the request leaves the sandbox. This addresses the specific risk of an agent finding a reusable secret in its environment. It does not, by itself, establish that every action available through the authenticated service is appropriate; the described protection is credential isolation and destination-matched injection.
Triggers make a saved agent useful without an interactive session. Examples include an 8:30 AM financial-analysis run, a daily briefing, email scanning that suggests replies, and checking a team's Jira board before sending a Slack update through a webhook. These are separate possible jobs. A schedule starts the chosen task; the task produces a result, which can then be delivered through a connected service.
Delegation uses the same API-based access. A managed agent can be configured to call other managed agents and fan out work. Wotherspoon favors narrow responsibilities—research a subject, draft notes, save the result—over one enormous assignment whose progress is difficult to measure. Writing an intermediate file gives the next specialist a concrete input and gives the builder an output to inspect. Scheduling decides when work starts; decomposition decides who does which part.
Authentication changes at the proxy
Read the diagram as text
- Agent sandbox. sandbox — Contains a placeholder token rather than the real GitHub secret.
- Credential proxy. outside-sandbox — Matches the API destination and injects the real token.
- GitHub API. external-service — Receives the request with the injected credential.
- Agent sandbox → Credential proxy: Outbound request uses placeholder token.
- Credential proxy → GitHub API: Matched request carries injected real token.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
NVIDIA filings become a quant agent's input
The first end-to-end demonstration assigns an SEC filing researcher to NVIDIA. An API call starts the company-research task. Step traces record individual operations, including file writes and code execution, so the builder can inspect the run at a finer level than the final response. The traces are useful for finding out what the agent actually did and where its workflow might need adjustment.
The researcher produces metrics in the shared filesystem. The next call starts a quant agent with the same environment ID, giving it access to metrics.json. This is the earlier state distinction doing real work: the quant agent receives its own task, but it does not need to repeat the filing research to get the saved metrics.
What changes between the research output and the quantitative result? The quant agent reads metrics.json, runs Python code files to analyze it, and produces a Markdown file containing research and a share-price forecast. The important transition is from a saved collection of metrics to code-based analysis and then a written interpretation. The demonstration establishes that handoff and artifact production; it does not establish the accuracy of the forecast.
A third agent can turn the accumulated research into a report. That separates gathering information, analyzing it, and presenting it into inspectable assignments rather than asking a single conversation to do everything. Google Docs and Slack are proposed delivery extensions: with the appropriate MCP servers connected, the workflow could write a document or send a message. Those integrations are possibilities described here, not completed steps in this demonstration.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From connected documents to an application report
The next example puts the managed agent behind an application. A connected Google Drive holds receipts and annual company data. The agent researches that material and creates a visualization, using a skill that describes how to build an interactive report. The service connection supplies the input; the skill supplies the procedure for turning it into the intended output.
This expands the role of the coding agent beyond editing a repository. The same remote execution setup can research documents, build a report, or generate application content. Wotherspoon points to AI Studio and its managed-agent gallery as a starting point, then opens a stock-research example to show what the API can look like behind a purpose-built front end.
After correcting the entry, he submits VOO. The ticker application uses several managed agents for specific research tasks. Its interface streams the execution steps exposed through the Interactions API, making the activity visible during the demo. Wotherspoon explicitly treats that stream as an illustrative interface choice: an application can use managed agents without showing customers the same running display.
The requested deliverable is a report based on the findings produced in the sandbox. Opening the result reveals a PDF containing research, analysis, key takeaways, and charts. The agent has moved from a short ticker input to a file the application can present, rather than stopping at a chat response.
What connects the report to its research inputs? The PDF includes links to the resources used. Wotherspoon describes the agent visiting Vanguard's site, finding documents, reading them, and analyzing their contents. The charts make the resulting analysis easier to inspect, while the source links provide a way to return to the underlying material. This final example completes the application path: accept a ticker, run specialized research in remote sandboxes, and return a report with both findings and references.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Related talks
- Why AI Agents Should Have Their Own Sandbox — Philipp Schmid, Google DeepMind
A closer look at the same execution model, including typed interaction steps, persistent filesystems, reusable agent configurations, and inspecting a running sandbox.
- Stop Telling Agents How — Dan Barrett, Raymond Weitekamp & Jose Montes de Oca, OpenProse
Compares the managed execution layer with a harness-agnostic approach to reusable workflows, explicit inputs and outputs, triggers, and dependency-aware multi-agent work.
- Backtest Your Agent Against Yesterday's Web — Ryan Ahern, Exa
Extends the financial-research example into evaluation: historical web cutoffs help test predictions without leaking information that became available after the outcome.
Read the complete timestamped transcript
- 0:12
Hi, everybody. Thank you so much for coming. My name is Jack Wotherspoon, and I am a DevX engineer at Google DeepMind, and today we're gonna talk about managed or cloud agents. Um, so raise of hands here, who all has heard of either cloud or managed agents or has used them? Okay. Well, we're, we're starting off on the right foot. Um, so you might have heard of them. If you-- For those who haven't, cloud or managed agents are essentially a way of instead of running a harness,
- 0:42
uh, and running coding agent on your own machine, you can actually just run them in the cloud on a sandbox. Um, so let's first start by why the heck would you even wanna do that? Well, sandboxes are really powerful for a number of reaso-reasons. Uh, number one, they're not running on your own machine, so you can, you know, spawn a cloud agent. It can go and write code, it can reason, it can do research, search the web. It can go ahead and write tests, run tests, uh,
- 1:12
verify, and actually come back with verified kind of answers. Um, and that's a really strong thing. If you've ever, like, tried to run verification either on your own laptop, you know, sometimes it steals the browser, um, it starts to run things for you, you start getting pop-ups and things like that. So running this all in the cloud, um, takes away that pain. And the other reason is that your laptop doesn't scale. Uh, you might start to have specific setups like agent skills, or you maybe have customized your
- 1:42
personal coding agent on your machine, but then how do you go and share that with a colleague? Or how do you integrate that into your app, right? You don't want your app that you're deploying to customers to be running, uh, with your own kind of subscription or things like that, right? So we want to be able to scale this up, um, in doing so. And managed agents or cloud agents are a great, great way to do that. So close. The sign almost stayed up. Don't worry about it.
- 2:13
So when it comes to kind of managed or cloud agents, you know, to do this yourself is quite a tedious process. Uh, you know, you have to actually spin up a container or a VM. You have to load things onto that, manage it. Um, and then you actually have to do harness engineering, you know, figure out ki-- build your own harness within the sandbox. Um, and then let's not even start to talk about networking or setting up firewall rules or all the security stuff. So that's where kind of managed agents come in, and, uh,
- 2:43
whether it's Gemini managed agents, Cloud managed agents, uh, we'll be talking about Gemini managed agents today, which is our offering, uh, in the Gemini API, uh, at DeepMind. And really now it boils down to just being a single API call. So that is really the beauty of managed agents. With a single API call, you're getting all the things we talked about. So you're getting the sandbox, you're getting the Antigravity harness built out of the box that is in the sandbox, and it can go ahead and do a lot of powerful things. Um,
- 3:13
you don't have to worry about managing any of the infrastructure or the scale as you need in your application. More agents, you can just be-- do more API calls.
- 3:26
Actually, we'll go back for a sec. So you can see here, this is our Interactions API. Um, it's our kind of new agent-first, uh, version of our SDKs and client libraries. So previously, we had kind of models. You would, you know, do an input, get an output, but that didn't really scale to agents in the new world we live in. So we launched a new kind of SDK, uh, covering interactions. So interactions are much more kind of mirroring what agents are doing. So it can be multiple
- 3:56
steps. You know, when a, when you do an agent call, it can go ahead and write files, call those files, call different MCP tools. Um, so really, this new Interactions API that we launched, uh, in one GA earlier this year, is now our kind of home for managed agents. So you just call the agent. Instead of having a model, you have an agent. So we have our base Antigravity agent, and then you set environment="remote". So that's that key thing that's now telling it, "Okay, we want a managed agent that runs in the
- 4:26
cloud." And then you give it kind of regular input as you're used to.
- 4:32
So here's kind of how the infrastructure actually looks under the hood. So when you call a managed agent, you kind of have that input that we saw, and then it calls the Gemini API, which has a bunch of, you know, built-in server-side tools like, um, searching the web through Google Search or file system tools to read and write files. Um, and you can also add your own custom functions or MCP tools as well. And then we have the sandbox. So that's actually running on kind of Google Cloud infrastructure. Um, so when you call the
- 5:02
Gemini API to get a managed agent, it goes ahead and actually sets up and spins up that sandbox for you, and you can go ahead and actually upload files to the sandbox. So if you have agent skills or AGENTS.md, or you want to load a GitHub repository on startup, uh, we allow you to do all that cool stuff.
- 5:23
So here are kind of the building blocks that make up a managed agent. These are kind of the different core pillars. Um, so you've got the harness itself, and that's the Antigravity harness. It's the exact same harness that's running, uh, in our Antigravity suite of products over at Google. So that's what's kind of figuring out the tool calls. It has the built-in tools. Um, and then we have the environment. And we'll talk a bit more about how the environment is kind of its own entity, um, which allows you to do really cool kind of multi-agent workflows by
- 5:52
having different agents pointed at the same sandbox, so they can write files. A different agent can pick that same environment up later and actually build upon those files. Um, and then we've got skills we talked about. So you can upload your skills to the sandbox, just as you would have potentially like playbooks or different ways of doing things at your company or on your personal agent. You can upload those to the managed agent as well. And then we have credentials. Credentials is a new piece of managed agent, which essentially lets us inject either kind of
- 6:22
tokens or your MCP OAuth into the managed agent sandbox, so you can access your different services. And then we also have triggers, which allow you to actually schedule a managed agent to run. So let's say at eight thirty-- e-eight thirty AM every morning before the market opens, you wanna go and, you know, do some kind of financial analysis before the market opens up. You could set a trigger. The managed agent would essentially wake up, um, run its task or run its input, output a result. You can l-- like, do webhooks so
- 6:52
that you could send a Slack message. Maybe it queries your team's Jira board every morning and sends, you know, here's what everyone's working on, um, and things like that. So we talked a little bit about the harness. Um, it's the Antigravity harness that runs under the hood, and you can change the different models that it runs with. Uh, yesterday we just launched, uh, Gemini 4 Argon, which is our new frontier model. Um, so I definitely recommend testing it out. It's a great model. Um, but we'll show it later on in this-- in demo.
- 7:23
And you can set the different model in the config for the managed agent in the agent config. As you see there, we have that kind of one-line parameter to set the model. So that's how you can kind of tune the managed agent based on the workflow. If you're wanting to do something that needs to be fast and efficient, you can use Gemini Flash. If you want to do something that's deep reasoning or potentially doing a lot of analysis, then you can use a different model like Gemini 4 Argon.
- 7:49
Like we said, Gemini 4 Argon was released yesterday. Um, it's a really great model. It's especially good at financial tasks, which is great for, hopefully for the audience here. Um, and really good also at doing data analysis across a wide range of documents. Um, and as always, the Gemini models are also super, super good at multimodal. Another really cool interesting, um, feature that we have with the Gemini 4 model is long decode. So normally models have an output token max of around sixty-four K tokens.
- 8:19
Um, but with Gemini 4, we actually have upped this so that now the one million kind of context window or token limit is now shared between input, thinking, and output. So output, as you need to kinda scale up, if you need to do extreme kind of math reasoning or financial modeling where the output might be pages and pages and pages long, the model can actually go and do that. And this is showing to actually advance some of the more mathematical and financial benchmarks out there.
- 8:51
So we talked a bit about the interactions API and environments, and this is kind of one of the key pillars. These are kinda two core primitives in managed agents that allow you to get a lot of flexibility and be able to customize kind of the agent configurations that you do. So these are kind of two different, um, stateful things on our back end in our server side. So interactions is what manages your conversation. So when you put an input and get an output and kind of a different turn with the model, um, those are
- 9:20
saved as kind of what we call interactions. So you can take one interaction, pass that ID to the next interaction, and that kind of, you know, is the second turn. Um, and then we also have environments. So environments are what's actually kind of in the file system on the sandbox. So when the agent goes and writes files or creates images or does, um, different file tasks on the actual sandbox in the cloud, that's kind of representative of the environment. Um, and you
- 9:50
can go ahead and use our APIs to download files from that environment or upload them. But having these two things kind of split out allows you to do some really cool things where you can actually see here that we are creating one agent interaction with our first code block, and it's gonna go ahead and do some work and save a file. And then we can pass that environment ID to our next agent. So it actually picks up. It has a very fresh, like, kinda context window and conversation, but it's reusing
- 10:20
the environment. So it can go and, you know, say save the Q3 filings in our workspace. Maybe we're gonna go, you know, fetch the, fetch the annual reports, the filings, and then we're gonna go and do some analysis, save that as a file, and then we can have a new agent come in, reuse that same exact environment, but this time have a fresh context window, um, kind of a multi-agent workflow, which is really cool.
- 10:46
So there are a bunch of built-in tools already in the sandbox, like code execution, reading and writing files, as well as Google Search. But we also support, you know, remote MCP servers, so you can bring your own servers, you can hook up to your favorite services, and really that takes the agent a step further and be able to actually do kind of daily tasks or things that you can build into your apps.
- 11:10
And we talked a little bit about it, but you can also kind of mount files to the file system. So you can upload your different AGENTS.md files, your skills, and kind of run through the playbooks that you have your agents doing on your personal machine, but doing it in an environment where you can kind of reproduce and have that work done for you, uh, in the cloud. So you don't have to worry about, you know, overwriting any files or messing up things on your machine. Everything runs in the cloud, um, and can just run as a process and get you back that output.
- 11:40
So here's a, here's a code sample where we are actually going to upload an AGENTS.md example into our, um, sandbox, and then we're also connecting a GitHub repository. So now you can actually have the agent look at your code, check for bugs and things like that. And then you can also save the agents. We also have an agents API, so you can do agents.create. So once you've kind of refined your workflow and found an agent that works for you, you can save it, so they can easily call it, you know, in multiple different times. You can iterate on
- 12:10
it and then save it for later.
- 12:14
And then you can just easily invoke your personal agent by calling it with its, uh, agent ID.
- 12:21
So another big part of the security aspect of managed agents is that secrets never actually enter the sandbox. So our managed agents have a proxy that sits, uh, as kind of a layer between the sandbox and our API. And it actually, what it does is it puts a placeholder kind of dummy token into the sandbox so that the agent can never kind of go rogue and say, "Oh, I see that I have this GitHub token laying around. Let me just see what else is on there." Um, so it can actually never do that because it never actually
- 12:51
has your GitHub token. So what it does is when it goes and calls the GitHub API, our proxy will then inject that token. It will match it to say, you know, it's API-- GitHub API. Um, we're gonna go ahead and inject this secret, um, so that way the agent can never do anything that it shouldn't be able to.
- 13:12
And we talked quickly about triggers, but triggers are also really powerful because you can have them set to kind of a daily briefing every morning, like we said, scan your emails, maybe suggest ones to reply to, or if you want to check on the stock market before it opens, um, you can do that. And this is a way to run one of your agents on a set schedule.
- 13:37
And we talked a little bit about multi-agent workflows, but managed agents can actually work really well, um, in multi-agent workflows. So you can actually set it up so that one managed agent knows how to, because it's just an API call, actually call other managed agents, um, and do work and fan out work. And then you can have very kind of niche and specific targeted agents that have one core purpose. They do that purpose really well. Um, you know, maybe it's drafting notes or doing research,
- 14:07
um, writes it to a file, gets that information saved, and the next agent can then take over from that different input. And this kind of breaks it up so that you can have things really controllable and really make sure that you're doing specific tasks well instead of just giving a super, super broad, you know, task to an agent and having it have no way of kind of measuring what it's actually doing.
- 14:32
So now we'll just quickly put this to the test. Um, so we can actually run the agents here and see what this actually looks like when you run one. So we have an S-- kind of an SEC filing researcher that just researches companies. We have it set to NVIDIA here, and we can go ahead and make call the a-API. So, like, again, this is just an API call. It's really easy to build into your own either internal workflows or to actually publish in your services or apps to external folks. So we can go see here.
- 15:03
There are step traces, so each thing the agent does, um, is saved as a step trace. So you can see we're having function result for the write to file, code execution, and you can kind of trace the-- what the agent is doing and optimize as you go to kind of make sure that the workflow is straightforward. And then we're reusing the same environment ID that we talked about. So because we're reusing the same environment ID in this scenario, we're actually having our agents pick up. So we can have-- We have this SEC filing researcher that went and did research on NVIDIA,
- 15:34
gave us a bunch of metrics as the output, and then we can now kick off this kind of quant agent, which will go take a look at the metrics because it's in the file system. It's reusing the same environment, the same sandbox, and now it can pick up its task and its job from that, um, metrics.json, take it, run a bunch of Python code files to see and actually look at it, make evaluation for NVIDIA. And if we go here and look at the MD file, we can see the managed agent went and actually
- 16:03
did research based on the metrics it got, and it's now kind of doing a forecast for the share price and the stock.
- 16:12
And then we can kick off a third agent just to kind of take that research and knowledge dump and turn it into a report. And if we had connected different MCP servers, like we could connect to Google Docs, have it actually output and write to a Google Doc or send a message in Slack so that you can really kind of create these customized workflows from managed agents.
- 16:34
And then you can also build managed agents super easily with the SDK into your own application. So this is just a demo here where we have a managed agent that is actually, um, connected to our service. Um, it's connected to our Google Drive, where we dumped in a bunch of receipts of our annual kind of, um, company data, and it's gonna go ahead and actually create this visualization, um, by-- from, from the, the data. And the managed agent is the one that's actually doing all the research. It has, you know, kind of a skill that will go out
- 17:04
and tells it kind of how to do this interactive report. Um, and then it's just kind of reasoning through it and building this out for us.
- 17:17
So it's really customizable. You can really kind of anything you can do on your own personal coding agent, you can kind of turn it easily into a managed agent that you can either run as a company daily or set up in your own app so that we have other ones on our, on our Gemini API on AI Studio where you can kind of create games on the fly, um, you can research documents and do all kinds of things.
- 17:44
So the easiest way to get started today is to go over to AI Studio and, uh, get started for free over there. And we also have our documentation for managed agents, but I'll quickly just do another demo here since we have a few minutes. This is one of our kind of managed agents examples that is on, uh, AI Studio in our gallery. Um, and this one's kind of just trying to showcase how you can actually build these managed agents into your own applications. Um, so this is, you know, create a nice front end and put in the stock.
- 18:15
Oh, not slash. So we can go ahead and do VOO. And this ticker agent is a bunch of our different managed agents that will go out and do specific tasks, um, and look for different analysis on a stock.
- 18:37
And again, this is kind of more of an illustration, illustration. As like, as you're building managed agents into your own apps, you might not wanna have this kind of stream. Um, but just to kind of visualize what the actual agent is doing, um, it's reasoning through all the different steps in the interactions API. And then this managed agent is told to kind of generate a report based on all of the findings and reasoning it did in its sandbox. So now if we go ahead and click on the report, we can see the managed agent outputted this kind of PDF, um, file for us
- 19:07
where we can see all of the research it did, see its analysis and key takeaways, as well as doing these charts so we can visualize. And it's also gonna go and link out to kind of all of the, um, resources, um, that it went and is actually using for this. So it actually went to the Vanguard, Vanguard site, found the different documents, read them in, and then did analysis on it.
- 19:34
And that is it on managed agents. Thank you very much.