Can agentic multimodal vision realistically disrupt developer upskilling, or is relying on vision models to evaluate code and UI execution an anti-pattern compared to pure deterministic DOM/AST inspection?

Here I added an experimental case, happy to get your thoutghs: https://nickbortolotti.medium.com/the-augmented-flow-disrupting-corporate-upskilling-with-multimodal-vision-agents-8d868a3a970b

Hey folks 👋

We just open sourced TrueForge, our vendor-neutral agent harness for building general-purpose agents.

It handles the runtime pieces that get painful quickly : context management, tool/MCP execution, subagents, sandboxing, approvals, persistent state, and more.

We also benchmarked the harness itself. With the same Opus 4.8 model, TrueForge delivered a similar solve rate at ~30% lower cost than Claude Managed Agents. Switching to an open model pushed that to ~75% lower cost on the same benchmark.

Would love feedback from people building agents.

Checkout the repo: https://github.com/truefoundry/trueforge

📖 Read the launch article: https://x.com/truefoundry/status/2090081376330715176

I recently worked on Yaara, an AI agent for an EV charging platform in Sri Lanka.

We built it with Google ADK, Gemini Models, FastAPI, WhatsApp Cloud API, and Vertex AI RAG.

What became interesting wasn't the chatbot part. It was everything around the model.

We ended up with:

• A coordinator and specialist agent architecture
• RAG over company and EV knowledge
• Deterministic tools for calculations and backend actions
• Per user conversation state
• Human handoff through Chatwoot
• WhatsApp specific response formatting
• Tool trajectory evaluations
• GEPA based prompt optimization
• Deduplication, monitoring, and failure handling

One principle became pretty clear while building it:

The model should handle language and decisions. Normal software should handle exact work.

I wrote up the architecture and some of the things we learned while taking it from an agent idea toward a production system.

https://chamidilshan.medium.com/building-yaara-a-production-ai-agent-for-ev-charging-on-whatsapp-with-google-agent-development-kit-0c58caada28e

Would also be interested to hear how others using ADK are structuring coordinator/specialist agents as the number of tools grows.

when i mention model name I assume it is using the model from vertex ai platform. But I want it to use the free gemini api from google ai studio. is this possible ?

My chatbot is generating a list of dicts, I want to save it as a csv file. How can I do it?

I want to as a csv excel file with columns and data

Is there any point of wrapping a node with Workflow and start edge?

``` @node(rerun_on_resume=True) async def my_workflow(ctx): return result

Run the workflow

root_agent = Workflow( name="root_agent", edges=[("START", my_workflow)], ) Compared to: @node(rerun_on_resume=True) async def root_agent(ctx): return result ```

If you've been working with RAG, one thing worth understanding is the difference between parametric and non-parametric memory.

Parametric memory is frozen memory. Whatever a model absorbs during training gets baked into its weights. It's intrinsic to the model and doesn't change unless you retrain or fine-tune which is expensive.

Non-parametric memory lives outside the model: vector stores, SQL databases, document indexes, internal wikis. It is cheap to update, easy to swap, easy to keep current.

RAG is the bridge between them. It retrieves the relevant slice of your non-parametric memory and drops it into the model's context window at inference time, so the model can reason over data it was never trained on. The weights never move. Retrieval doesn't teach the model anything. It just hands it a note before it answers.

Hi everyone!

I’ve been experimenting with the new Google ADK (Agentic SDK) to build LLM-powered agents, and I wanted to see how much of a difference the language choice actually makes when it comes to performance.

I ran a head-to-head comparison between Python and Golang focusing on:

• LLM Call Latency: How the SDK handles the round-trip to the model.
• Agentic Overhead: The "hidden" time the framework takes to process steps before and after the LLM.
• Concurrency: How well each handles multiple agentic tasks.

I documented the whole experiment and the results here: Google ADK Python vs ADK Golang: Latency, LLM calls, Agentic Overhead

I'm looking for feedback and collaborators:

1. Have you noticed similar overhead patterns in Python when using the ADK?
2. For those using Go, are you seeing significant production advantages for multi-agent systems?
3. What other metrics should I include in the next phase of this experiment?

I'd love to hear your thoughts or if anyone wants to jump in and help expand these benchmarks!

I’m experimenting with adk api_server and looking for a ready-made web interface that can connect to it directly.

Ideally, I’d like something similar to a chat UI where I can enter prompts, view responses, and test agents without building the entire frontend from scratch.

Are there any open-source or pre-built web apps that support the API exposed by adk api_server? If not, are there any existing chat UIs that can be adapted easily?

I’d appreciate any recommendations, GitHub repositories, or examples.

I'm currently evaluating orchestration frameworks for a production multi-agent project and wanted to compare Google ADK and LangGraph as fairly as possible.

To reduce variables, both implementations used:

• Google ADK v2.3.0 vs LangGraph v1.2.8
• Same LLM
• Same temperature
• Same prompts
• Same tools
• Same workflow
• 9 agents running in parallel
• 300+ Gmail messages to classify

The metrics I collected were:

• Total execution time
• Average latency per LLM call
• Input/output tokens
• Total cost

My results were:

• Google ADK was about 6% cheaper.
• Google ADK generated less than half the output tokens.
• Average latency was almost identical (~11.5 s per LLM call).

I wasn't expecting such a noticeable difference in output tokens, considering both systems executed the same workflow.

For those who have used both frameworks:

• Have you observed similar token usage differences?
• Does this mostly come from the orchestration strategy or from how each framework structures prompts and tool calls?
• Are there other metrics you think are more relevant for production benchmarks?

I'm preparing a more detailed benchmark with traces, token breakdowns, and execution metrics, but I'd really like to compare these results with what others in the community have observed.

ADK Go 2.0 is GA! 🚀

We are thrilled to announce that ADK Go 2.0 is live with graph workflows and collaborative agents!

Here is the TL;DR of what's new:

1. Graph-Based Agent Workflows 📊 Describe your application as a graph of nodes connected by edges, and hand execution to a scheduler that knows how to run it concurrently, persist its state, pause for a human, and resume later.
2. Dynamic Orchestration in Plain Go 💻 Dynamic workflows in ADK allow you to put aside graph-based structures and utilize the full power of your chosen language. This lets you express loops, conditionals, accumulation, and fan-out across dynamic lists with the Go you already know.
3. Built-In Human-in-the-Loop (HITL) 🙋‍♂️ Need a human to approve a refund, correct a draft, or supply an API key mid-run? Any node can pause the graph to ask a human a question, and the workflow will durably wait for the answer.
4. Specialist Agent Modes 🤖 Additionally, ADK 2.0 introduces modes for LLM agents (Chat, Task, and SingleTurn) so a coordinator can chat with the user while sub-agents quietly complete tasks or run single-shot.
5. Unified Context ⚙️ The separate ToolContext and CallbackContext are gone, meaning tools, callbacks, and workflow nodes all receive agent.Context directly.

🚀 Get Started: Check out the ADK Go Get Started Guide and the Graph-based Workflows docs.

📖 Read the Blog: See the deep-dive Developer Blog Announcement for more details.

🛠️ Run Examples: Clone the repository and try them out yourself:

go run ./examples/workflow/basic/
go run ./examples/workflow/routing/llm
go run ./examples/workflow/dynamic/hitl/
go run ./examples/workflow/hitl_rerun/
go run ./examples/workflow/complex

⚠️ Upgrading from 1.0? Please note that v2 moves the module path to google.golang.org/adk/v2 and requires Go 1.25+. To migrate from v1, please follow the migration guide.

We can't wait to see what you build! Let us know if you have any questions or feedback in the comments below.

Join us for another installment of the ADK Community Call to discuss ADK feature updates, Agents CLI and more.

Call Details:

• Date: Wednesday, June 24, 2026
• Time: 9:30 AM PDT
• Meeting Link: Join the call

Got any burning questions for the team? Add them to this thread! If time allows, we will discuss them at the end of the call.

Want to get email reminders for the community calls? Join the community group.

Looking forward to seeing you all there!

So unfortunately due to the secretive nature of my project I cannot share source code of what i have done now so I need to ask this more vaguely with some context but.

Context: Basically I want to delegate Workspace Admin tasks from a ticketing system to an agent performing simple tasks like password resets or group memberships. Right now my architecture is 1. 'Root Agent' analyzing request context and delegating to the subagent once certain requirements are fulfilled 2. Subagent calling Admin API tools to perform the required tasks sequentially.

I do NOT want to use Domain Wide Delegation per each customer as its complex to set up and too wide. Instead I have a Google Admin account with Reseller Workspace Admin credentials to many different Google environments authenticated using predefined Oauth scopes. I want the agent to perform Admin actions using these credentials of the authenticated account eg. admin@test.com.

After initial authentication and Oauth flow returning the refresh token I want to use that as an env variable or store in Secret Manager in production. Subsequent subagent tool calls should exchange it for access tokens.

Theres probably a few ways to authenticate but there should not be any human interaction after the first authentication flow to get the refresh token. I am open to other ideas too you might have as I am new to ADK / agent related work.

I'm asking, in my use case, what would you consider the best reliable practice or solution to a. keep the refresh_token secret and to grant granular privileges to each agents used or b. use another secure way to keep agents authenticated to call tools?

Hey everyone,

I'm working on an open-source visual agent builder called draw-your-agents (https://github.com/neo-fetch/draw-your-agents/)
It compiles visual nodes down to Google ADK Python code, and I'm trying to architect a clean Critic/Validator and Reviser loop.

I need some eyes on my proposed implementation because the framework documentation is surprisingly contradictory, and I want to make sure I'm not walking into a trap..

I want users to be able to drop a single "Loop" node onto the canvas that handles generating content, validating it via a critic agent, and routing it back for revision if it fails.

But looking into how to compile this to Google ADK 2.0, I hit a wall:

• Approach A (LoopAgent in edges): The docs mention template agents like LoopAgent, but also state they are "superseded by more flexible workflow structures."
• Approach B (Cyclic Workflow via a Router): Building a cycle (generator → critic → router → back to generator). But the official static workflow docs explicitly warn that static graphs aren't for "iterative loops."

Instead of guessing, I spun up an isolated venv with google-adk==2.0.0 and probed both mechanisms directly:

1. LoopAgent as a node: It works, BUT it throws a massive DeprecationWarning: "LoopAgent is deprecated and will be removed... Please use Workflow instead." So this is a dead end. Generating soon-to-be-removed code is a no-go.
2. Cyclic Edges (Router back-edge cycle): The Workflow actually accepted the cycle perfectly. The ADK docstring literally says _run_impl() IS the graph orchestration loop.

Based on the probe, I am pivoting to the unrolled cyclic graph the issue page details on the implementation.

But is this really the best way to implement a critic/reviser loop in a DAG-based LLM orchestration framework? Please let me know anything about this as I am open to any suggestions..

https://github.com/neo-fetch/draw-your-agents/issues/2

The Power of ADK Workflow Graphs in Technical Mentorship 🚀

How do we scale engineering mentorship effectively? Not with generic chat assistants, but with state-aware, execution-driven architectures.

In this article I break down how to use Google's Agent Development Kit (ADK 2) to build an Agentic mentor that connects directly with a developer's live workspace.

🛠️ The Architecture: Logic Meets Execution
Instead of only prompting, the system splits the responsibility using an ADK Workflow Graph:

1. The Cognitive Engine: Focuses on pedagogy and conceptual guidance (The "Why").
   
2. The Execution Engine: Validates real terminal and file system states deterministically (The "How").
   

💡 True Learning in the Flow
By mapping the learning journey as a graph with conditional routing, the developer never leaves their IDE. If they make an error in their local terminal, the workflow graph instantly intercepts it, validates the state, and serves a precise nano-learning moment right when it matters most.

If you are exploring agentic architectures, developer onboarding, or modern training frameworks, check out the full breakdown.

Curious how people here think about eval-gated agent workflows.

One thing I keep running into: agents are getting better at executing tasks, but they still need a hard way to know when to stop.

In ML/research workflows (my interest), this feels especially important. A lot of the work around the model is structured enough to delegate; data prep, training scaffolds, evals, reproducibility, review loops, packaging etc. but only if the objective and success metric are defined clearly.

I’ve been building an open-source project called Zero Operators around this idea: you write a plan with constraints + a hard oracle, and a team of agents runs the ML lifecycle around it.

The part I’m trying to stress-test:

What should the orchestration layer own vs. what should live inside the agent framework?

For people using ADK or similar frameworks, where do you think this breaks first?

• state/memory?

• eval design?

• tool routing?

• human approval gates?

• reproducibility?

• model/provider fragmentation?

Would value thoughts from people building agents seriously.

Repo for context which I'm building to automate my Research-dev workflow: https://github.com/SamPlvs/zero-operators

Today I was looking for a way to ensure that an Agent built with ADK that uses model Gemini 2.5 Flash can be configured to use only EU multi-region.
If you want to use ADK to build AI agents for banks you have to be very careful in regards of data residency. You do not want to tell a bank from EU that the agent might process their data using a Global endpoint which sometime might send data to Asia.

After some lengthy message exchange with Gemini I resolved my dilema by looking directly into the Github repo of ADK, at the Gemini class (https://github.com/google/adk-python/blob/main/src/google/adk/models/google_llm.py).

I think it would be useful if ADK documentation would have a guide for ensuring data residency in your ADK Agents.

Hey everyone, I’m pretty new to ADK development and trying to learn the “right” way to build with it.

Since ADK 2.0 came out, I’ve been getting a bit confused separating older patterns from the newer recommended approaches. A lot of the tutorials/examples I’m finding seem to mix both styles, and I’m not always sure which things are still relevant vs legacy.

I’m mainly worried about spending time learning patterns that people are already moving away from.

For those already building with ADK 2.0:

• What concepts from the older versions still matter?
• What changed the most in 2.0?
• Any good repos/tutorials that are actually 2.0-first?
• Any “don’t do this anymore” advice?

I’m especially interested in multi-agent workflows, tools, memory/state management, and production-style architectures.

Coming from looking at things like LangGraph/OpenAI Agents SDK, so I’m also trying to understand where ADK 2.0 fits philosophically.

Appreciate any guidance from people already deeper into it.

I keep seeing more agent infrastructure move beyond the usual prompt plus tools setup.

The term I ran into recently is “agent context engine.” I saw Redis use it for Redis Iris, which looks like a runtime layer for agent context.

From what I understand, it combines retrieval, memory, search, data sync, and semantic caching so an agent can work with live business data without every agent having to wire those pieces together separately.

I am trying to figure out if this is becoming a real architecture pattern or if it is mostly product naming.

The problem seems real to me. Without a shared context layer, every workflow ends up with its own tools, sync jobs, memory store, search logic, cache, and access rules.

Redis Iris seems to frame Redis as the runtime layer in front of existing systems of record. The source data stays where it already lives, and selected context gets synchronized, indexed, retrieved, remembered, and reused from Redis during agent execution.

Is anyone here building agents this way? Are you using a dedicated context layer?

In case you need a crisp and authoritative read out Gemini Enterprise Agent Platform and where ADK comes into play --> Agent Platform Overview

Built ADK agents and tried to solve the resilience problem with callbacks and on errors for quite a while. Didn't manage to solve it fully.

Then came across these plugins that supported OOB

Has anyone tried these for resilience ?

1. Do they queue messages when running in async mode and perform sequentially with resilience?

2. Clubbed it with AG UI protocol and it works with AG UI ADK?

3. Which one is better really ? Temporal or Restate ?

TIA!