What happened
For the last few years, most conversations about artificial intelligence have started with a familiar question:
Which AI gives the best answer?
Which chatbot writes better emails? Which model codes faster? Which assistant can summarize a long document without missing important details?
On May 19, 2026, Google gave us a reason to start asking a different question:
What happens when AI stops answering and starts doing?
At Google I/O 2026, the company announced Gemini 3.5 Flash, expanded its agent-first development platform, introduced Managed Agents through the Gemini API, and demonstrated more proactive AI experiences across Search, the Gemini app, and shopping.
These were separate product announcements, but they pointed in the same direction.
Google was trying to make AI less like a search box and more like an assistant that could participate in getting something done.
Not just tell you how to complete a task.
Actually help complete it.
That difference deserves considerably more attention than another leaderboard score.
First, what exactly is an AI agent?
Let's remove the marketing language.
A traditional chatbot receives a question and generates a response.
An AI agent is software that uses an AI model to pursue a goal through a sequence of steps. Depending on its design and permissions, it can inspect information, call tools, execute code, retrieve files, update records, and decide what to do next.
Imagine you ask an AI assistant:
"Find the best flight to New York next Friday."
A conventional chatbot might search for flight information, compare options, and recommend one.
An agent might be able to search flights, compare prices, check your calendar, consult your preferences, prepare a booking, and ask for your approval before purchase.
Give it broader permissions, and it might even complete the booking.
The intelligence involved may be similar.
The authority is not.
And authority changes the risk.
When a chatbot gives you incorrect information, you might make a bad decision after reading it.
When an agent acts incorrectly, the mistake may already have happened.
An incorrect answer about a flight is inconvenient.
An incorrect flight booking can cost money.
An incorrect change to a company's financial records can become considerably more serious.
That is why the distinction between an AI assistant and an AI agent matters.
What Google actually introduced
The May 19 announcements included several changes worth separating.
1. Gemini 3.5 Flash: a model positioned for agentic work
Google introduced Gemini 3.5 Flash as part of a new model family emphasizing intelligence and fast execution.
In its developer announcement, Google claimed that Gemini 3.5 Flash exceeded Gemini 3.1 Pro on almost all benchmarks while running significantly faster than other frontier models.
That is Google's reported comparison, not an independent finding.
Still, speed matters for agents in a way it may not matter for a one-shot chatbot response.
Consider a task that requires fifteen separate actions.
The agent may need to interpret your request, search for information, read a document, call an API, inspect a result, adjust its plan, and repeat.
If each step is slow, the whole workflow becomes frustrating.
If each step is expensive, the entire task may become uneconomical.
A model suited to agentic work therefore needs more than impressive reasoning. It needs an effective combination of capability, latency, consistency, tool use, and cost.
Google's announcement addressed part of that equation.
It did not, by itself, prove that an agent built on the model would be reliable across every business environment.
2. Managed Agents: making agents easier to build
The more consequential developer announcement may have been Managed Agents in the Gemini API.
Google described a service in which developers could start an agent that reasons, uses tools, and executes code within an isolated, temporary Linux environment.
It also described ways to define custom agents using instructions, skills, data, and versionable files.
This matters because building an agent is not just a matter of writing a good prompt.
A functioning agent needs somewhere to execute, some way to access tools, controls on what it can access, and infrastructure that can handle failures.
Traditionally, the developer had to assemble much of that infrastructure.
Managed Agents aimed to reduce this burden.
That is genuinely useful.
But reducing deployment complexity is not the same as removing operational responsibility.
A cloud sandbox can isolate execution.
It cannot independently decide whether a business action is appropriate.
3. Search began moving beyond finding information
Google also announced new agentic capabilities for Search.
The ambition was broader than presenting answers alongside web links. Google described experiences in which Search could help users accomplish tasks and generate useful interactive experiences from their questions.
Think about the difference between these two requests:
"Which exercise routine would suit a beginner?"
And:
"Build me a practical weekly exercise planner based on my schedule and preferences."
The first primarily requires explanation.
The second involves understanding constraints, organizing information, and creating something usable.
The practical appeal is obvious. Many people do not want to become experts in software simply to solve a small problem.
They want the result.
But even here, an important distinction remains: generating a useful tool is not equivalent to guaranteeing its accuracy or long-term reliability.
4. Shopping became another target for agentic AI
Google introduced Universal Cart as part of its agentic commerce strategy.
The idea was to bring products from different shopping experiences into a more unified cart and make purchasing easier across supported retailers.
This may sound less technically exciting than a new language model.
In everyday life, it could be more consequential.
Most people are not interested in the internal architecture of a shopping assistant.
They care whether it finds the correct product, compares prices properly, avoids misleading listings, and does not spend their money without understanding their intentions.
That last point is particularly important.
Commerce turns an AI recommendation into a potential financial action.
The moment an AI system participates in a transaction, questions of authorization, accountability, and user control become unavoidable.
The real shift was not a single model
It would be a mistake to look at these developments and conclude that Google suddenly invented autonomous AI agents in May 2026.
It did not.
Agents, tool calling, workflow automation, code execution, and AI-assisted research were already established areas of development.
What made May 19 significant was their increasing integration into mainstream products and developer platforms.
AI capabilities that previously required specialized engineering were being packaged into experiences available to more people.
The direction was clear.
AI was moving from a system you consult toward a system you delegate work to.
That is a meaningful shift.
And it deserves a different standard of evaluation.
Why it matters
I think the AI industry has spent too much time arguing about which model is the smartest.
That question matters, but it is incomplete.
A brilliant model with unreliable tools, poor permissions, unpredictable costs, and no accountability is not a reliable business system.
And an average model, placed inside a carefully designed workflow, can sometimes create more value than an extraordinary model running without boundaries.
The real question is not simply how intelligent an AI system has become.
It is whether we can trust the entire system to carry out the right action under the right conditions.
1. For ordinary people, AI could finally become less work
This is the part of the agentic shift I find genuinely exciting.
A lot of technology promises convenience while quietly transferring work to the user.
You install an application.
Create an account.
Configure settings.
Learn the interface.
Connect another application.
Troubleshoot an error.
And eventually complete the task you wanted to do in the first place.
Software often creates its own administrative burden.
A useful AI agent could reduce that burden.
Instead of learning five different interfaces, you could express an intention in ordinary language and let the software coordinate the necessary steps.
That is a meaningful accessibility improvement.
Not everyone knows how to automate a spreadsheet, write an API integration, or build a dashboard.
They should not need to.
But we need to be careful about the word could.
An agent that saves you twenty minutes but makes a hidden mistake requiring two hours to correct has not improved your life.
It has merely moved the inconvenience somewhere harder to see.
Convenience must be measured by successful outcomes, not by how impressive the demonstration looks.
2. Agents will force us to rethink trust
There is a fundamental psychological difference between asking for advice and granting permission.
When you ask a friend what restaurant to visit, you retain control.
When you ask that friend to book the restaurant, you are giving them authority to act.
If they misunderstand you, the consequences are different.
AI is no exception.
People may become comfortable with an agent because it speaks fluently, remembers preferences, and appears confident.
But fluency is not reliability.
Memory is not judgment.
And a convincing explanation is not evidence that the underlying decision was correct.
This becomes especially dangerous when software hides its process behind a pleasant interface.
A user sees:
"Done. I've taken care of it."
What the user may not see is that the agent chose the wrong customer record, misunderstood a contract clause, or ignored a relevant constraint.
For that reason, I would rather use a system that occasionally says, "I need your confirmation," than one that confidently makes irreversible decisions without showing its reasoning and evidence.
The best assistant is not the one that acts most independently. It is the one that knows when independence is appropriate.
3. Businesses will need to separate intelligence from permission
Imagine a company introduces an AI agent to help with customer support.
At first, the agent reads documentation and drafts suggested replies.
That is relatively easy to control.
Then the company lets it look up customer accounts.
Next, it can modify subscriptions.
Eventually, it can approve refunds or change billing information.
Each step increases the agent's usefulness.
Each step also increases the consequences of failure.
The solution is not necessarily to avoid agentic AI.
It is to distinguish between what the agent can understand, what it can recommend, and what it can execute.
These are separate capabilities.
A model might understand a refund policy perfectly well without being authorized to issue a refund.
It might recommend changing a production configuration without having permission to modify the production system.
That separation should be intentional.
An AI system does not become more valuable simply because it has more access.
Sometimes, excessive access makes it less suitable for deployment.
4. The security boundary is no longer just the prompt
A common discussion about AI safety focuses on harmful or misleading outputs.
For agents, that is only one part of the problem.
Consider an agent reading an external webpage.
The page includes a hidden instruction telling the agent to ignore its original task and send confidential information somewhere else.
The user never asked for this.
The agent's developer never authorized it.
But the instruction appears inside material the agent needs to process.
This is a prompt-injection scenario.
With a conventional chatbot, the attack might contaminate an answer.
With a tool-using agent, it might influence an action.
This is why a web page, email, PDF, or retrieved document should be treated as information—not as a source of authority over the system.
An agent must distinguish between instructions from its legitimate user and instructions embedded in untrusted material.
That sounds obvious when written down.
It is much harder to guarantee in a system that routinely reads arbitrary content and calls powerful tools.
The appropriate defense is not a stronger warning in the prompt alone.
It is a combination of restricted permissions, technical enforcement, tool-level validation, isolation, monitoring, and testing against adversarial inputs.
5. Sovereignty becomes a practical concern
Another question deserves more attention than it usually receives:
Where does the information go, and who controls the infrastructure?
For personal experimentation, using a convenient hosted assistant may be perfectly reasonable.
For an enterprise handling sensitive information, the answer depends on much more.
Where is the model running?
Where is the data stored?
Who can access the logs?
Are requests retained?
Which jurisdictions and contractual commitments apply?
What happens if the service becomes unavailable?
Can the organization change models without rebuilding the entire workflow?
These are not abstract philosophical objections.
They affect procurement, compliance, business continuity, negotiating power, and incident response.
A system can be technically excellent and still be the wrong choice for a particular organization.
That is why I resist the idea that every company should immediately adopt the newest frontier AI service.
Technology selection is an architectural decision, not a popularity contest.
6. The economics need to work after the demonstration
An agent may complete a task through a sequence of model calls, searches, tool executions, retries, and validations.
Each step may incur cost.
The model's advertised price per token tells only part of the story.
The useful measurement is the cost of a successfully completed task.
Suppose one workflow costs $0.20 when it succeeds immediately.
That looks attractive.
But if the workflow frequently fails, requires repeated attempts, and regularly needs employee intervention, the actual cost may be much higher.
The correct comparison is not:
"How much does the model cost?"
It is:
"How much does the complete process cost, including failures, supervision, infrastructure, and recovery?"
That is where many promising prototypes encounter reality.
An agent that is faster than a human on its best attempt may still be slower and more expensive over hundreds of messy, real-world cases.
7. Accountability cannot be outsourced to a model
If an AI agent makes an incorrect business decision, the organization cannot simply blame the model.
The model did not decide to deploy itself.
People selected the system, granted access, defined its responsibilities, and chose the circumstances in which it could act.
That means someone must own the outcome.
In practice, this requires clarity about:
- who authorized the workflow;
- what actions the agent could perform;
- what information it used;
- how its actions were recorded;
- when human approval was required; and
- how the organization can investigate and reverse a mistake.
The goal is not to create a bureaucratic obstacle around every automated action.
It is to make responsibility visible.
Without that, autonomy becomes an excuse for avoiding accountability.
Why we're not using it (yet)
The verdict for this development is watching.
That does not mean the technology is unimportant.
It means the announcements do not, by themselves, establish that Google's newly introduced agentic capabilities are the right choice for a governed production environment.
There are two separate questions here.
First: Is the direction of development useful?
Yes.
The movement toward agents that can work with tools, execute code, and complete constrained tasks is meaningful. Making this infrastructure easier to use is valuable.
Second: Should an enterprise immediately put its sensitive workflows behind these newly announced services?
Not without evaluation.
At AI Standards, the relevant question is not whether a product demonstration is impressive. It is whether a particular architecture satisfies the operational, security, and governance requirements of the people who will depend on it.
For these May 2026 announcements, I would focus on five reasons not to rush.
Reason one: a managed execution environment is not a complete governance system
Google's Managed Agents announcement described isolated execution environments and easier ways to deploy agents.
That addresses real engineering problems.
It does not automatically answer every enterprise governance question.
Isolation is one control.
It does not establish which business records an agent should access, which actions require approval, or whether a particular outcome is compliant with an organization's policies.
Those decisions belong in the architecture surrounding the agent.
Reason two: vendor benchmarks do not represent every production workload
Google presented strong performance claims for Gemini 3.5 Flash.
Those claims are worth investigating.
But enterprise tasks have their own characteristics.
A coding benchmark does not tell us whether a model reliably handles a company's complex approval workflow.
A reasoning benchmark does not guarantee correct financial calculations.
A tool-use evaluation does not necessarily reproduce the messy mixture of ambiguous instructions, broken integrations, and incomplete data present in a real organization.
Before changing models, the sensible approach is to build an evaluation set using representative tasks.
If the current system already performs them reliably, switching models should require a measurable advantage.
Otherwise, the organization may be introducing migration risk in exchange for novelty.
Reason three: autonomy should increase gradually
I would not begin by giving a newly deployed agent unrestricted authority over customer accounts, payments, production databases, or confidential records.
I would begin with a narrower task.
Perhaps the agent can gather information and draft a proposed action.
Then it can perform a reversible operation in a controlled environment.
Later, once performance and failure handling are understood, some actions can become automated under explicitly defined conditions.
This is not an argument against autonomy.
It is an argument for earning it.
A system should demonstrate reliability at lower levels of authority before receiving higher ones.
Reason four: provider dependency needs to be understood
A managed agent service can simplify development significantly.
It can also create dependencies on the provider's runtime, APIs, tooling, pricing, and policies.
Those dependencies are not automatically unacceptable.
Every useful platform introduces trade-offs.
The important question is whether the organization understands them.
Can instructions and workflow definitions be versioned independently?
Can logs be exported?
Can model calls be routed through an alternative provider?
Can the business continue operating if one external service fails?
Could part of the workflow run on infrastructure the organization controls?
For some applications, the convenience of a fully managed service will outweigh the cost of dependency.
For others, portability and sovereignty will matter more.
There is no universal answer.
There should, however, be an intentional one.
Reason five: the cost of failure may be higher than the value of automation
A harmless mistake in a personal shopping recommendation is one thing.
A mistaken insurance decision, financial transaction, or production-system change is another.
The same general agent architecture should not receive the same degree of freedom in both environments.
This is why I would avoid treating agentic as a product category that automatically deserves deployment.
The appropriate level of autonomy depends on the consequences of a mistake.
If an error is easy to identify and reverse, greater automation may be reasonable.
If an error is difficult to detect, costly, or irreversible, the control requirements should be stronger.
The governing principle is simple:
The greater the consequence of an action, the stronger the evidence and authorization required before an AI system can perform it.
That is the approach I would use to assess Google's new capabilities before recommending them for sensitive client work.
The verdict could change.
A successful evaluation might justify controlled testing or eventual adoption.
But announcing a capability is not the same as proving it is suitable for production.
And watching is a valid engineering decision when the evidence is incomplete.
What to verify before you adopt it
If you're a CTO, founder, engineering leader, or simply someone considering whether to trust an AI agent with meaningful responsibilities, here are five checks I would run before making a decision.
1. Test complete tasks, not just impressive answers
Create a representative evaluation set of real work.
Include normal cases, ambiguous requests, missing information, conflicting instructions, unexpected tool failures, and cases where the agent should decline to act.
Do not measure only whether the model produced plausible text.
Measure whether the workflow reached the correct outcome.
For each task, record whether it succeeded, whether any actions were unauthorized, how often human correction was required, the time taken, and the total cost.
Most importantly, inspect failures.
An average success rate can conceal rare but unacceptable mistakes.
A workflow that gets 99 routine tasks right and makes one irreversible unauthorized change may still be unsuitable for deployment.
Adoption question: Can you show evidence that the system performs your actual business tasks reliably, including difficult and adversarial cases?
2. Audit every permission the agent receives
List the tools, files, APIs, databases, and external services available to the agent.
Then ask whether each permission is truly necessary.
If the agent only needs to read a customer record, it should not receive unrestricted database modification privileges.
If it needs to prepare a payment, that does not mean it should execute the payment without approval.
Use scoped credentials and enforce authorization in the underlying tools, rather than relying on the model to remember what it should not do.
Test what happens when the agent attempts an action outside its authority.
The action should fail because the system prevents it—not simply because the model was politely instructed not to try.
Adoption question: If the model makes a bad decision, can the technical permission system still prevent the dangerous action?
3. Prove your data boundaries
Document what information the agent can access, where it is processed, how long it is retained, and who can inspect it.
Check the provider's contractual and technical controls for the actual product and deployment configuration being considered.
Do not assume that a security property advertised for one service automatically applies to another.
Test the data path.
Can confidential information appear in tool arguments, generated files, debugging logs, or unexpected external requests?
What happens when the agent reads untrusted information containing instructions to disclose data?
For regulated or sovereignty-sensitive workloads, review residency, access controls, encryption, retention, and applicable legal requirements.
Adoption question: Can you trace sensitive information through the entire workflow and enforce its permitted destinations?
4. Test interruption, recovery, and reversibility
Real systems fail.
APIs time out.
Network connections drop.
Records change between steps.
Users revise instructions.
Agents may execute an action successfully but fail to receive confirmation.
That last case is especially important.
Imagine a payment API processes a transaction, but the response times out. The agent assumes the payment failed and retries.
Without appropriate safeguards, the system could create a duplicate transaction.
A production agent needs deliberate failure handling.
For consequential actions, use appropriate mechanisms such as idempotency keys, transaction boundaries, confirmations, compensating actions, and human escalation.
Keep an auditable record of what the system attempted and what actually happened.
Give operators a reliable way to stop execution.
Adoption question: When the agent fails halfway through a task, do you know exactly what happened and how to recover safely?
5. Measure economic value and human effort together
Run the agent on a representative workload.
Calculate its total cost, not just the price of model inference.
Include tool calls, infrastructure, retries, observability, external services, supervision, and rework.
Compare those costs with the current process.
But do not ignore user experience.
A workflow may save the company money while forcing employees to repeatedly check unclear decisions.
That is not necessarily an improvement.
Likewise, a slightly more expensive agent may be worthwhile if it saves substantial human effort without increasing risk.
The objective is useful work completed correctly, safely, and with less friction.
Adoption question: Does the complete system demonstrably improve the process after accounting for failures, supervision, and operating cost?
The decision
I do not think the most important AI product of the future will necessarily be the model that produces the most impressive answer.
It may be the system that quietly completes an ordinary, frustrating task without making life more complicated.
That is what makes the agentic direction so promising.
Most people do not wake up wishing they could use a larger language model.
They want to deal with less administrative work.
They want understandable answers.
They want to avoid repeating information across five applications.
They want technology that helps without demanding that they become experts in it.
Businesses want many of the same things.
They want fewer manual handoffs, faster processes, better use of information, and more time for work that actually needs human judgment.
AI agents could help deliver those outcomes.
But only if we resist an increasingly tempting mistake: assuming that because a system can perform an action, it should be trusted to perform it independently.
There is a difference between capability and permission.
There is a difference between a successful demonstration and a reliable production system.
And there is a difference between automating work and improving someone's life.
Google's May 2026 announcements showed a credible direction for the technology.
They did not eliminate the need for careful decisions about authority, trust, cost, security, and responsibility.
So my verdict is watching.
Not because I am skeptical of AI agents as a concept.
Because I think they are important enough to evaluate properly.
The industry will keep announcing more powerful systems.
The question worth returning to is much simpler:
Does this make life easier without making the consequences of failure harder to control?
If the answer is yes—and we can demonstrate it—then we have something worth adopting.
If not, another impressive announcement can remain exactly that.
An announcement.
And that's fine.