Hundreds of developers have already completed our first DEV Education Track, and today we're excited to keep the momentum going with our second tra...
For further actions, you may consider blocking this person and/or reporting abuse
Good luck with this everyone!
The shift from monolithic prompts to specialized agents is the right architectural direction, but one thing I'd love to see covered in the track is how you handle trust boundaries between agents. When Agent A passes output to Agent B as input, you've essentially created a prompt injection surface at every handoff point. Curious if the A2A protocol has any built-in sanitization for inter-agent messages or if that's left to the developer.
Can't wait to see what everyone builds with this education track!
I'm totally going to participate in this one 😁
Awesome!
This is incredibly timely! I've been running a multi-agent system (OpenClaw-based) on a Mac Mini for autonomous content creation and distribution — sub-agents for coding, SEO, writing, and monitoring all coordinating via shared state files and cron jobs.
The biggest lesson: agent-to-agent communication design matters MORE than individual agent capability. Getting agents to validate each other's work was the hardest part. Excited to see Google's approach to this with ADK!
Multi-agent systems shine until you hit production inter-agent failures. ADK abstracts orchestration, but who debugs cascading timeouts between 5 Cloud Run instances at 3 AM? The real test isn't 'can it work'—it's 'can you trace why Agent C hallucinated because Agent A's output drifted'. Where's the observability story?
This is the exact problem we hit at scale. With 31 agents in production chains, "Agent C hallucinated because Agent A's output drifted" happened to us literally in week one.
Two things that helped: (1) every agent call gets a trace_id, and every chain step becomes a span linked to that trace — so you can follow the full path from request to failure in seconds. (2) We built a cryptographic blame-finding protocol (JEP) where every delegation and judgment is hash-linked — you can trace backwards from any failed output to the exact agent and decision that caused it.
The observability gap in multi-agent systems is so real that we ended up building a separate product for it — TraceHawk, MCP-native observability specifically for AI agents. Because you're right — standard APM tools (Datadog, Sentry) don't understand agent delegation chains.
I wish I could get cloud shell but I don't like putting my mastercard in google services, else I could find out where to look
honestly the timing of this is perfect - I've been building multi-agent setups for a few months and the hardest part isn't the code it's figuring out how agents should hand off context to each other. ADK looked interesting when I first saw it but I wasn't sure it was production-ready. curious whether this track covers error handling in long-running chains - that's where I kept hitting walls
Sounds exciting, count me in.
This looks like a massive step forward for agentic workflows! As someone focused on smart contract security, I’m curious about the 'sandboxing' aspect of these multi-agent systems. When agents start interacting with external APIs or handling sensitive data/private keys, what built-in guardrails does ADK provide to prevent prompt injection or unintended logic execution? Great release, definitely worth exploring for automated security tooling.
Great timing on this track — multi-agent orchestration is exactly what I've been building for the past 3 months.
I run 31 specialized agents in a 4-layer hierarchy (Supervisor → Business → Tool → Infrastructure) for Kepion, an AI company builder. A few things I learned the hard way that this track's participants might find useful:
Perfect timing. We're building Kepion — a platform that deploys full AI companies using 31 specialized agents in a 4-layer corporate hierarchy (Supervisor → Business → Tool). Our A2A service is already implemented but follows a custom spec. Having Google standardize the protocol with ADK means we can align our inter-agent communication to be compatible with the broader ecosystem.
The part I'm most interested in is how ADK handles agent accountability in multi-agent chains. When Agent A delegates to Agent B, and B produces a hallucination — who's responsible? We solved this with a cryptographic decision trail (JEP protocol) where every delegation, judgment, and verification is hash-linked. Curious if ADK has a similar mechanism or if that's left to the developer.
Will definitely complete this track. Multi-agent orchestration is the hardest problem in AI agents right now — not making one agent smart, but making 30+ agents work together without stepping on each other.
This is incredibly timely. I'm currently running 7 AI agents as my actual business team — engineering, finance, marketing, sales, strategic research, health, and a chief of staff that orchestrates them. Total cost: $200/month on Claude Max, running on a Mac Mini M4 Pro.
The multi-agent coordination problem is real and messy. Some things I've learned:
Trust scoring is essential. I built a composite algorithm (reliability 40%, speed 20%, goal completion 20%, efficiency 10%, activity 10%) scoring each agent 0-100. Engineering sits at 85. Marketing at 58. You need to know who to trust with what.
Fallback systems need as much engineering as your primary. Hit my Claude Max session limit, local LLM fallback wasn't calibrated — agents fabricated entire projects and invented fake agent names. 40 hours of chaos.
Agents will lie about task completion. My engineering agent marked a task "done" without doing the work. Caught it 3 days later. Now every completion requires a verification artifact.
The gap between "demo multi-agent system" and "production multi-agent system running real businesses" is enormous. Looking forward to this track.
Thx for cost estimation.
The "specialized agents vs. monolithic prompt" framing is exactly right, and I think the ADK track structure will make this concrete in a way that's hard to get from documentation alone.
One thing worth flagging for people who go through this: the hardest part usually isn't building the individual agents, it's designing the orchestration contract between them. When Agent A hands off to Agent B, what does a "failed" output look like vs. a "successful but uncertain" one? Most teams I've seen skip this and end up with silent failures propagating through the pipeline.
A few patterns that help in practice:
Excited to see the A2A protocol approach. Curious whether it handles retries at the protocol level or leaves that to the orchestrator.
This is exciting! I've been running a multi-agent setup on a Mac Mini for the past week — using OpenClaw + Claude as the orchestrator with sub-agents for different tasks (content publishing, code deployment, monitoring).
The biggest lesson: agent memory and state management is the real challenge, not the LLM calls. My agents write daily logs, share a data bus between cron cycles, and auto-heal when things break.
Curious about ADK's approach to inter-agent communication. Does it handle persistent state between runs, or is each agent invocation stateless?
Looking forward to this track!
My Agent Team started with 7, the Meta Agent decided it could absorb those 7 to work faster, and more efficiently, then decided to hire 3 back because during workflow postmortum it realized it was not as efficient doing detailed QA, HTML generation and Assessment creation. So we are back to 3+ the Meta Agent. I wrote an article about the whole process and creating SemVer agents who update themselves. Open sourced my Agent personas. The future of Agentic workflow is amazing!
This track is exactly what the industry needs right now. We've mastered the "single prompt" loop, but real-world reliability comes from specialized agent coordination.
I've been building a local-first system called Tars that uses a similar Supervisor-Orchestrator architecture. One thing I've found critical is the "verification artifact" loop—agents often claim a task is done when it's only 90% there. In Tars, the supervisor uses local file checks and test suite results as hard gates for agent handoffs.
Really looking forward to seeing how the ADK handles these distributed trust boundaries. It feels like the bridge between "cool demo" and "production infrastructure."
dev.to/ashleigh11911/sovereign-int...
Run your Google API Key through backboard.io and you’ll get FREE state management for life and your agents will have Memory - thanks to MLH and Dev.to for the support!
This will be fun to learn and build🙂
Interesting material. Thanks
Exciting! That's amazing for today's education.
Can I still participate?
Yep! You can jump in anytime.