multi-agentic system

A developer built a distributed multi-agent system using Google's open-source Agent Development Kit and the Agent-to-Agent (A2A) protocol, in which a researcher, judge, and content_builder run as independent HTTP services that discover each other via A2A agent cards. The pipeline researches a topic, has the research critiqued and looped back until an editor approves it, then writes a course module, with progress streamed to a browser front end over Server-Sent Events. A single command starts the three A2A servers, runs the pipeline, and shuts them down on exit.

This post is my submission for DEV Education Track: Build Multi-Agent Systems with ADK https://dev.to/deved/build-multi-agent-systems . A distributed multi-agent system that researches a topic, has the research critiqued, loops until an editor approves it, then writes a course module. The Agent Development Kit and the Agent-to-Agent protocol are both open source, so the multi-agent design itself is unchanged — three agents still run as independent HTTP services that discover each other through A2A agent cards. This starts the three A2A servers, waits for their agent cards, runs the pipeline, writes results to output/ , and shuts the servers down. The codelab ships a browser front end; this is the local equivalent. One command brings up the whole system — the web process starts the three A2A servers on launch and stops them on exit, so there is nothing else to run: .venv\Scripts\python.exe scripts\run web.py then open http://localhost:8080 Type a topic and press Build the course . The page shows the three agents as a live pipeline diagram: each box is a separate process, and it lights up as its A2A reply arrives — researcher researching → done, judge reviewing → approved or looping the researcher back for another pass , content builder writing → done. An event log timestamps each step, and the finished module renders as formatted markdown in the "paper" pane on the right. Progress is pushed to the browser over Server-Sent Events GET /api/runs/{id}/events ; a 5-second poll for the finished document is the fallback if the stream hiccups. The same backend the CLI uses drives it, so a run here is identical to run all.py — it just does not write to output/ . Other endpoints: GET /api/health model + which agent cards are up and POST /api/runs start a run, returns {"run id": ...} .