I Built My First AI Agent on Gemini Enterprise Agent Platform — A Developer's Honest First Look

Manoj Kiran — Mon, 27 Apr 2026 10:10:29 +0000

I Built an AI Agent in just Minutes with Gemini Enterprise Agent Platform — Here's What Nobody's Talking About
Google Cloud NEXT '26 dropped over 250 announcements. Amid the noise of TPU v8, Gemini 3.1 Pro, and the "$750M partner fund" headlines, one announcement caught my eye — and honestly, it should catch yours too.

Vertex AI is dead. Long live the Gemini Enterprise Agent Platform.

Now, I know what you're thinking: "Great, another rebrand." That's exactly what I thought too. But after spending a full weekend building agents on it, I'm convinced this isn't just a name change — it's a fundamental philosophical shift in how Google wants developers to think about AI. And the developer experience? It's genuinely surprising.

Here's what I found, what I built, and what I think Google still needs to figure out.
**

The Quick Version: What Actually Happened
**
If you haven't caught up, here's the summary:

At Cloud NEXT '26, Google announced that Vertex AI has "evolved" into the Gemini Enterprise Agent Platform — a unified platform for building, scaling, governing, and optimizing AI agents. It brings together everything developers previously had to cobble together across Vertex AI, Agent Builder, Google Agentspace, and various other tools into one roof.

But here's what most coverage missed: the platform isn't just for enterprise teams with budgets. There's a genuine free tier, the SDK is open-source (the Agent Development Kit, or ADK), and you can go from zero to a deployed agent in under 30 minutes.

I had to try it myself.

*Figure : The old way vs. the new way — one unified platform replacing scattered tooling.
*

Setting Up: The Developer Onboarding Experience
Step 1: The Google Cloud Console
I headed to the Gemini Enterprise Agent Platform console and navigated to the "Agent Platform" section. The console has been redesigned with two distinct paths:

Agent Designer — A no-code/low-code visual builder for creating agents through a drag-and-drop interface
Agent Development Kit (ADK) — A code-first SDK for developers who want full control
As a developer, I naturally went straight for the ADK. But here's the thing — I ended up using both, and that's actually the platform's secret weapon.
**
Step 2:Installing the SDK**
The setup was surprisingly painless:

bash

Create a virtual environment

python -m venv agent-env source agent-env/bin/activate

Install the Agent Platform SDK and ADK

pip install google-cloud-agent-platform pip install google-adk
That's it. No complex dependency chains, no API key juggling through multiple consoles. One SDK, one install.

Step 3: Your First Agent in ~15 Lines of Code
Here's the agent I built — a customer support assistant that can answer questions, look up order status, and escalate issues:

python

from google.adk import Agent, Tool from google.cloud import agent_platform_v1

Define a simple tool — in production, this would call your database/API

def lookup_order(order_id: str) -> dict: """Look up an order by its ID and return status details.""" # Replace with your actual data source orders = { "ORD-12345": {"status": "shipped", "eta": "April 30", "items": 3}, "ORD-67890": {"status": "processing", "eta": "May 2", "items": 1}, } return orders.get(order_id, {"error": "Order not found"})
def escalate_ticket(issue: str, customer_name: str) -> dict: """Escalate a customer issue to a human agent.""" return { "ticket_id": f"TKT-{hash(issue) % 100000:05d}", "status": "escalated", "message": f"Issue from {customer_name} has been escalated." }

Create the agent with tools and instructions

support_agent = Agent( name="support-assistant", model="gemini-2.0-flash", instruction="""You are a helpful customer support assistant. You can look up order status and escalate issues. Always be polite, specific, and offer concrete next steps. If you don't know something, say so honestly.""", tools=[ Tool(name="lookup_order", function=lookup_order), Tool(name="escalate_ticket", function=escalate_ticket), ] )

Test locally

`response = support_agent.run(message="Where is my order ORD-12345?")
print(response.text)

Output: "Your order ORD-12345 has been shipped! It contains 3 items and is expected to arrive by April 30."

Fifteen lines of actual logic. No boilerplate. No complex configuration YAML. No deploying a Flask server just to test an agent locally.`

This is the kind of developer experience that makes you go: "Wait, that worked on the first try?"

Deploying to Agent Runtime: Where It Gets Real
Building an agent locally is one thing. Deploying it so it's accessible, scalable, and observable is another. This is where most platforms fall flat.

The Gemini Enterprise Agent Platform has a concept called Agent Runtime — essentially a managed hosting layer for your agents. Here's how I deployed:

bash

Deploy the agent to Agent Runtime

gcloud alpha agent-platform runtimes agents deploy support-agent \ --region=us-central1 \ --display-name="Customer Support Agent" \ --entry-point=agent.py
And within about 2 minutes, I had a live endpoint:

python from google.cloud import agent_platform_v1

Query the deployed agent

client = agent_platform_v1.AgentPlatformClient() agent_endpoint = f"projects/{PROJECT_ID}/locations/us-central1/agents/support-agent"

response = client.query_agent( agent=agent_endpoint, message="Can you escalate my issue? The refund hasn't processed." ) print(response.text)
What Actually Impressed Me
1. The Free Tier is Real, Not a Gimmick

Google is offering a monthly free tier that includes 180,000 vCPU-seconds and idle time isn't billed. For a solo developer experimenting or building a side project, this is genuinely usable. You can prototype, test, and even run light production workloads without opening your wallet.

2. Agent Observability is Built In, Not Bolted On

The Agent Observability dashboard lets you visually trace the reasoning chain of your agent — every tool call, every model invocation, every decision point. Think of it like a debugger, but specifically designed for agent workflows. This alone makes it worth exploring over rolling your own LangChain + LangSmith setup.

3. The A2A Protocol for Multi-Agent Systems

Google introduced the Agent-to-Agent (A2A) Protocol at NEXT '26, and it's integrated directly into the platform. This means your agents can discover, communicate, and coordinate with each other without custom glue code. I tested chaining my support agent with a simple "refund processor" agent — the orchestration happened through the platform's built-in A2A support, not through manual API wiring.

What I Think Google Got Wrong (The Honest Part)
I promised a real take, so here it is — the platform isn't perfect. Not even close.
**

The Rebrand from Vertex AI is Confusing, Not Clever** Every existing Vertex AI user now has to mentally remap their workflows. The documentation is in transition — some pages still say "Vertex AI," some say "Gemini Enterprise Agent Platform," and the migration path isn't as smooth as Google suggests. Vertex AI SDK releases after June 2026 won't receive updates, which means there's a hard deadline pushing developers to migrate. If you have production systems on Vertex AI, this isn't a gentle nudge — it's a forced march.

2. Agent Designer Needs More Depth
The no-code Agent Designer is marketed as a way for "anyone to create agents," but in practice, it's limited to straightforward single-step workflows. For anything involving conditional logic, multi-step reasoning, or custom data connectors, you'll end up in the ADK anyway. The low-code promise is real, but the ceiling is low.

3. The Documentation is Still Catching Up
I hit multiple dead-end documentation links and inconsistent API references during my build. The ADK site (adk.dev) has solid getting-started guides, but the enterprise-specific features — Model Armor governance, data connector setup, enterprise grounding — have thin documentation. For a platform that's supposedly "GA," the docs feel more like "public beta."

4. Where's the CI/CD Story?
There's no clear guidance on how to integrate Agent Runtime deployments into existing CI/CD pipelines. I ended up writing custom GitHub Actions workflows using the gcloud CLI. For an enterprise platform, this should be a first-class citizen with Terraform providers, proper GitOps support, and deployment rollback mechanisms.

The Bigger Picture: Why This Matters for Developers
Here's my honest take after going deep: the Gemini Enterprise Agent Platform is Google's bet that the "model era" is ending and the "agent era" is beginning.

Think about it. For the past two years, the conversation has been about which model is better — GPT-4, Claude, Gemini, Llama. But as models converge in capability, the differentiation shifts to what you build around the model — the tools, the governance, the orchestration, the observability. That's exactly what this platform provides.

For developers, this means:

You're no longer just calling an API. You're designing autonomous systems that reason, decide, and act.
Governance isn't optional. Model Armor (included free on all editions) provides content filtering and safety guardrails out of the box. In a world where one hallucination can tank your brand, this matters.
The A2A Protocol could be a big deal. If it gets adopted broadly (and that's a big if), it becomes the HTTP of agent communication — a standard protocol for agents regardless of who built them.
My Verdict: Should You Care?
Yes, but with eyes open.

If you're building AI-powered products or even just experimenting with agents, the Gemini Enterprise Agent Platform offers the most complete developer experience I've seen from any cloud provider. The free tier makes it accessible, the ADK is well-designed, and Agent Runtime removes the operational burden of hosting.

But don't sleep on the migration overhead if you're already on Vertex AI, and don't expect the no-code path to solve complex use cases. This is a powerful tool for developers willing to write code, not a magic button for non-technical teams.

The real test will be June 2026, when Vertex AI enters its sunset phase. If Google nails the migration tooling and documentation by then, this platform could become the default home for AI agent development. If not, well... developers have long memories.

Resources to Get Started
Gemini Enterprise Agent Platform Console
Agent Development Kit (ADK) Documentation
Agent Runtime Quickstart
Agent Designer Overview
A2A Protocol Announcement
Google Cloud NEXT '26 Wrap-Up (250+ Announcements)

Debugging a Failing Test Entirely from the Terminal with GitHub Copilot CLI

Manoj Kiran — Sat, 31 Jan 2026 04:10:01 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built DevFlow, a minimal TypeScript + Node.js project designed to demonstrate a terminal-first debugging workflow using GitHub Copilot CLI.

The project intentionally includes a failing unit test. Using natural language prompts in the terminal, I asked Copilot CLI to diagnose the failure, explain the root cause, apply a precise fix, and verify the solution — all without opening an editor.

The goal of this project is not application complexity, but to showcase how GitHub Copilot CLI accelerates real debugging workflows directly from the command line.

Repository

Demo Pull Request

Team

@manoj_kiran_4ff6ecaa902bd (submission author)

@kondam_aishwarya_6e02608e (teammate)

Demo

Below is the full terminal-based demo showing how GitHub Copilot CLI was used end-to-end: from detecting a failing test to fixing it and validating the result.

Initial execution of npm test in Windows PowerShell showing a failing unit test. The test sum function adds two numbers fails because the expected value is incorrectly set to 5 while the actual result is 4. This failure is intentional and serves as the starting point for the Copilot CLI debugging demo.

GitHub Copilot CLI launched inside Windows PowerShell using the copilot command. Copilot initializes and requests folder trust before interacting with the project files.

A natural-language prompt is issued to Copilot CLI: “diagnose why npm test is failing”. Copilot begins inspecting the project configuration and test files to understand the failure.

Copilot CLI analyzes the test files and clearly identifies the root cause: the test in tests/failing.test.ts expects sum(2, 2) to equal 5, which is logically incorrect. Copilot explains the issue in plain English before suggesting a fix.

Copilot CLI applies a minimal and precise edit to the codebase, changing the expected value in the failing test from 5 to 4. The terminal output shows the exact file modified and the line change, making the fix fully transparent.

Despite an environment limitation (PowerShell 6+ not installed), Copilot CLI successfully completes the analysis and fix. This demonstrates Copilot CLI’s resilience and usefulness even in constrained environments.

Re-running npm test after Copilot’s fix shows all tests passing successfully. This confirms that the Copilot-generated change resolved the issue correctly and the project is now in a healthy state.

My Experience with GitHub Copilot CLI

Using GitHub Copilot CLI felt like having a debugging partner directly inside the terminal.
Instead of manually scanning test files and logs, I simply described the problem in natural language. Copilot CLI quickly located the issue, explained the reasoning behind the failure, and applied a safe, minimal fix.
What stood out most:

Natural-language debugging without leaving the terminal
Clear explanations, not just code changes
Minimal, auditable edits ideal for PRs and reviews
Terminal-first workflow that fits real developer habits

I used GitHub Copilot CLI to diagnose, fix, and verify a failing test entirely from the terminal using natural language.

This experience showed how GitHub Copilot CLI can significantly reduce debugging time while keeping developers in control.

Forem: Manoj Kiran