◉ANTIGRAVITY LABJP
Articles/Agents & Manager
◈ Agents & Manager/2026-07-12Advanced

When A2A Tasks Sat Stuck in 'working' — Field Notes on Tracing State Transitions to Detect Stalls

Antigravity's A2A coordination fails less by crashing and more by sitting in 'working' without progress. This walks through recording state transitions as one timeline and naming a stalled task down to which agent and which edge froze, along with what running agents daily has taught me.

A2A4Antigravity385multi-agent50observability19state-machinepython28

✦ Premium Article

An overnight agent pipeline I let run had stopped by morning with "0 tasks completed." Not a single error in the logs. The orchestrator had sent three tasks and was still waiting for them to finish, indefinitely. The receiving agents showed no sign of having even started; the tasks were quietly frozen in the working state.

The maddening part was not being able to tell which agent, and where, had frozen. A2A (Agent-to-Agent) failures show up less as loud exceptions and more as a state that simply refuses to advance. Here are my field notes on measuring that silent stall as a timeline of state transitions, and on naming the stalled task down to the edge—drawn from running agents solo as an indie developer.

Why the Stall Happens Quietly

An A2A task advances through a state machine: submitted → working → input-required → completed / failed / cancelled. If it crashes, it transitions to failed, and at least the fact of failure remains. But what I see most in production is the pattern that never even reaches failed—it stays in a non-terminal state while only time passes.

The "silent stalls" I have observed fall into three paths.

PathWhat is happeningSymptom from the sender
Undelivered envelopeA missing trace_id or wrong destination means the message never reaches the peerStays submitted; never even transitions to working
Missed capability discoveryThe skill is unregistered in the peer's capabilities, so discover returns no candidateYou think you sent it, but the peer is treated as nonexistent
Skipped task_stateThe peer finished processing but replied without asserting completedWork is done, yet you keep waiting in working

What all three share is that the stall comes from a transition that fails to happen—not from an error. So no amount of staring at exception logs yields a clue. What to look at is the time axis: which state a task is sitting in, and for how long.

Record State Transitions as One Timeline

First, decide the unit of monitoring. Not individual log lines, but each task's state transitions held as one timeline. Each transition keeps the trace_id, task ID, agent, from/to states, and timestamp, in a form that lets you measure the time spent in a state (dwell time).

Recorded fieldMeaning
task_id / trace_idWhich task's chain of events this is
agentThe agent that caused the transition
from_state → to_stateThe transition edge. The unit for naming a stall
dwell_secondsSeconds spent in the immediately preceding state

The key is to see a stall by edge (from → to), not by task. Even for the same working stall, whether submitted → working is not firing or working → completed is not firing points at entirely different suspects. The former is envelope or discover; the latter is the peer's skipped transition. Viewed by edge, the guess about the cause lands a step faster.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
✦Separates the three quiet paths of an A2A stall—undelivered envelope, missed capability discovery, and a skipped task_state—by symptom
✦Records transitions as one timeline and names a stalled task down to which agent and which edge froze, in a working Python watchdog
✦Derives the stall threshold from the p95 of dwell time, and picks a DAG shape to keep tracing cheap
Secure payment via Stripe · Cancel anytime
✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $10 for lifetime access
View Membership →

Related Articles

◈ Agents & Manager2026-04-27
Five Paths to Sell AI Agents Built on AgentKit 2.0 — How Indie Developers Should Pick a Distribution Channel
Where should a solo developer sell an agent built on Antigravity? Five channels — marketplace, own site, SaaS embed, consulting-to-product, subscription — compared by take-home share, customer distance and time to first revenue, with Stripe checkout code and a usage-cap check.
◈ Agents & Manager2026-04-26
Designing Antigravity Agent Traces That Tell You Why It Failed — Observability in Practice
Run Antigravity agents long enough and unreadable failure logs pile up fast. This piece walks span structure, attribute design, failure tagging, dashboards, cost visibility, and retry policy — backed by six months of production metrics — so you can cut post-incident debugging time in half.
◈ Agents & Manager2026-04-14
Build an AI Agent SaaS with Antigravity × AgentKit 2.0 × Stripe — A Complete Implementation Guide for Solo Developers
How to build a subscription AI agent SaaS with AgentKit 2.0, Stripe and Antigravity. Architecture, billing, Webhook idempotency, production deployment — plus the Redis concurrency-slot bug that quietly locks out your heaviest users.