DEV Community: Venkata Rahul Murarisetty

Focus Three: a distributed to-do prioritizer built with ADK, A2A and Cloud Run

Venkata Rahul Murarisetty — Sat, 01 Aug 2026 23:03:54 +0000

This post is my submission for DEV Education Track: Build Multi-Agent Systems with ADK.

What I Built

Focus Three takes a messy free-text brain dump and gives back the three things you should actually do today, with the reasoning attached. By messy I mean the usual: items are vague, deadlines are implied rather than stated, and half the entries are really three tasks in a trenchcoat.

Ranking is not the hard part. The hard part is that one prompt asked to prioritize a list will skip items it does not understand, quietly merge two tasks into one, and still hand back a confident top three that leaves out the thing that was on fire. None of that shows up in the output. Splitting the job across specialists made each failure surface somewhere I could fix it.

Cloud Run Embed

Paste in your own brain dump and watch it run. The frontend streams progress events, so you can see each specialist report in before the final three appear.

Give it a minute on the first run. The services scale to zero, so a cold start wakes five containers before the first agent speaks; after that a run takes about a minute.

All six services carry the DEV label from the embed guide:

gcloud run deploy focus-three \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --labels dev-tutorial=blog-devcommunity2026

Your Agents

Four LLM agents, all running gemini-3-flash-preview, each with one job, plus a small Python step that drives the retry loop.

Task Analyzer. Parses the raw dump into atomic tasks. It splits compound items, estimates effort in focused minutes, and records the exact source fragment each task came from. It emits a Pydantic TaskList instead of prose, so nothing downstream has to re-parse English.

Coverage Validator. The quality gate. It reads the original input alongside the parsed list and asks one question: is everything accounted for? Unsplit compound items, dropped fragments and tasks still too vague to act on all earn a fail plus specific feedback. It returns a strict pass/fail schema and is blocked from delegating or chatting, so a verdict is the only thing it can emit.

Escalation check. Not an agent, just Python, running in-process inside the orchestrator. It reads the validator's verdict out of shared session state and yields an event with escalate=True on a pass, which is the signal the parent loop catches to break out. On a fail it yields a plain event and the loop runs again with the feedback in context.

Urgency Checker. Scores each task 0-100 on deadline pressure and consequence of delay, with a one-line justification per task. I kept it separate from the final pick so scoring and selection can be debugged on their own.

Focus Agent. Picks the final three. Not just the top three by score: it enforces a shape on the day, so it will not hand you three four-hour tasks, and it always includes at least one quick win.

The Task Analyzer, the Coverage Validator and the escalation check sit inside a LoopAgent capped at three iterations. That loop, the Urgency Checker and the Focus Agent sit inside a SequentialAgent. Six Cloud Run services in total: the four LLM agents, the orchestrator and the frontend, wired together over A2A with agent-card URLs passed in as environment variables.

Key Learnings

The hard part was getting honest answers, not good ones.

Separating scoring from selection is what fixed that. Once the Urgency Checker has to publish a number and a one-line justification for every task, the Focus Agent cannot quietly drop the expensive ones. It has to argue for what it left out. On the test dump it returned the login bug (120 min, urgency 95), the slides (90 min, urgency 88) and the dentist (15 min, urgency 50), then explained that replying to the twelve emails scored higher urgency than the dentist but would have pushed the day to 255 minutes against a 240-minute budget. That trade-off note is the output I trust most, and it only exists because two agents disagree in the open instead of one agent deciding in private.

Constraining an agent turned out to be mostly about taking capabilities away. The Coverage Validator returns a strict pass/fail schema and is blocked from delegating or replying conversationally, so a verdict is the only thing it can produce.

Stack: Google ADK + A2A + Cloud Run + Gemini 3 Flash Preview

I Built an AI Agent with Claude's Tool-Use Loop (Web Search, SQL, and More)

Venkata Rahul Murarisetty — Sun, 12 Jul 2026 21:42:58 +0000

"AI agent" gets thrown around so much I figured I should just build one instead of reading more threads about it. The core idea turned out to be small: you put Claude in a loop and hand it some tools. It picks a tool, you run it, you hand back the result, and it keeps going until it has an answer.

Code is here if you want to skip ahead: claude-research-agent.

What it can do

Give it a task and it works out the steps on its own. Mine can:

search the web (no API key for this part, it just hits DuckDuckGo's HTML page)
open a URL and pull the readable text out
do math without me trusting eval
run read-only SQL against a SQLite file
read local files, but only inside the project folder
save findings to a notes file

The loop is basically the whole thing

Honestly this is most of it:

messages = [{"role": "user", "content": user_message}]

for _ in range(MAX_STEPS):
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=2048,
        tools=TOOL_SCHEMAS,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": response.content})

    if response.stop_reason != "tool_use":
        return final_text(response)

    tool_results = []
    for block in response.content:
        if block.type == "tool_use":
            result = run_tool(block.name, block.input)
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": result,
            })
    messages.append({"role": "user", "content": tool_results})

The thing to watch is stop_reason. If Claude says tool_use, it wants you to run something. You run it, drop the result back into the conversation as a tool_result, and loop. When it stops asking for tools, you're done. The MAX_STEPS cap is just there so a confused agent can't spin forever.

Tools are just functions

Each tool is a Python function plus a little JSON schema telling Claude when to reach for it. Want a new capability? Write a function, add its schema. The loop never changes, which was the part I liked most.

Guardrails, because this stuff can bite

The second your agent can run code or touch a database, you have to be careful:

the calculator parses an AST and only allows math, so something like __import__("os")... gets rejected instead of run
SQL is opened read-only and I block write keywords on top of that
file reads can't escape the project folder, so no ../../etc/passwd

Skip this and you've basically built a foot-gun with a chat interface.

Seeing it actually run

Here's a real run. I asked it to look up the latest Claude model and do some math, and it chained five tool calls by itself:

you> Search for the latest Claude model, then calculate 15% of 2340.

  web_search({"query": "latest Claude model"})
  calculator({"expression": "2340 * 0.15"})
  fetch_url({"url": "https://www.anthropic.com/news"})
  save_note({...})

agent> 15% of 2340 = 351, plus a short rundown of the current models.

Watching it decide the order on its own is the part that finally made "agent" click for me.

The bug that ate an hour

My web search kept coming back empty even though the results were clearly in the HTML. Drove me a little crazy.

Turns out DuckDuckGo wraps the matched words in <b> tags inside each snippet. My parser was resetting its state on every closing tag, so the inner </b> wiped everything before the result ever got saved. The fix was to only reset on the closing </a> and flush the last result at the end. Classic "the real-world HTML is messier than your test case" moment.

If you want to poke at it

The repo has the CLI, a small FastAPI web UI that shows the tool trace, and a test suite: github.com/venkatarahul27/claude-research-agent.

Curious what tools other people would bolt on. I'm tempted to give it a real browser next.