By equipping your custom subagents with mid-flight reporting capabilities via send_message, you transform your multi-agent architecture from a silent black box into a transparent, event-driven pipeline capable of streaming live progress and triggering instant circuit breakers.
Here is what you will get out of this deep dive:
- Why subagents become black boxes without mid-flight telemetry.
- How to implement bidirectional agent messaging using send_message.
- Full breakdown of a real-world example skill you can use.
- BONUS: Four messaging anti-patterns to avoid in production agent workflows.
📝 About this series: Welcome to the Elevating Antigravity Agent Skills series, a 5-part engineering guide to mastering the agent tools that reduce orchestration tax and transform AI agents into autonomous collaborators: ask_question, generate_image, define_subagent + invoke_subagent, send_message, and manage_subagents.
Subagent “black box” friction
In Part 3 (Parallel subagents), we unlocked execution speedups by using define_subagent and invoke_subagent to dispatch parallel tasks across isolated workspace branches. But as multi-agent workloads grow from quick scripts to complex, multi-step pipelines, a new friction point emerges.
When you dispatch multiple background subagents to execute long-running tasks the parent orchestrator enters a sleep state. Until every subagent finishes its entire trajectory, neither the orchestrator nor the developer has any visibility into worker progress.
In traditional distributed systems, we don’t dispatch long-running background workers without log streaming, heartbeats, or event queues. In agentic engineering, we solve this with send_message.
The anatomy of inter-agent messaging
While invoke_subagent handles the initial lifecycle spawn of a subagent, send_message enables active, targeted communication between persistent agents during execution.
The tool signature is intentionally lightweight, requiring only two parameters:
- Recipient: The unique target conversationID (such as the Parent Orchestrator’s ID or a peer worker’s ID).
- Message: The text or structured JSON payload to deliver.
Crucially, when a subagent calls send_message, the Antigravity runtime delivers the message directly into the target recipient’s context window and triggers an immediate reactive wakeup. The parent orchestrator doesn’t waste tokens polling in a loop, it wakes up only when an event arrives.
Tool capability comparison
To understand where send_message fits alongside lifecycle tools, review the operational differences below:
A reference walkthrough of real-time subagent reporting
To see event-driven subagent messaging in practice, let’s examine multi-step-workflow-reporter, a workspace skill, that orchestrates three parallel worker subagents. Each worker executes a mock 4-step workflow, pausing 5 seconds between steps and reporting milestone completion back to the parent orchestrator via send_message.
.agents/skills/multi-step-workflow-reporter/
└── SKILL.md
Stage 1: Define worker agent with reporting directives
First, our orchestrator registers a custom subagent type named pipeline_step_runner. The system prompt explicitly instructs the subagent to report milestone completions back to the parent using structured JSON payloads.
## Workflow Steps
### 1. Register Custom Worker Persona (`define_subagent`)
Invoke `define_subagent` to register a specialized worker subagent persona:
- **name**: `pipeline_step_runner`
- **description**: "Executes a 4-step workflow and reports completion of each milestone back to the orchestrator via send_message."
- **system_prompt**: "You are a pipeline step runner subagent. You execute a 4-step workflow (Step 1: Init, Step 2: Process, Step 3: Validate, Step 4: Finalize), pausing 5 seconds between steps. After successfully completing EACH step, call send_message to transmit a progress report to the Parent Orchestrator ID provided in your task prompt. Format your payload as structured JSON: {\"worker\": \"<Role>\", \"step\": <step_number>, \"name\": \"<Step Name>\", \"status\": \"COMPLETE\"}."
- **enable_write_tools**: `true`
- **enable_mcp_tools**: `false`
- **enable_subagent_tools**: `false`
Stage 2: Dispatch workers with parent context grounding
Next, the orchestrator retrieves its own conversationID and dispatches three worker subagents concurrently in a single invoke_subagent call. By injecting the parent’s ID directly into each worker’s prompt, the subagents know exactly where to address their updates.
### 2. Dispatch Parallel Workers (`invoke_subagent`)
Retrieve the parent orchestrator's conversation ID (e.g. `parent-123`).
Dispatch 3 worker subagents concurrently in a single `invoke_subagent` call using `TypeName: "pipeline_step_runner"`. For each worker (`Dataset Ingestion Worker`, `Image Processing Worker`, `Model Inference Worker`), set `Role` to the worker name and `Prompt` to:
> *"Execute your assigned pipeline for '<Role>'. Transmit step completion payloads via send_message to Recipient '<parent_id>'."*
Stage 3: Mid-flight telemetry streaming
As each worker executes its steps, it invokes send_message at every boundary. Here is what Worker A transmits upon completing Step 2:
### 3. Handle Incoming Telemetry & Update Live Dashboard
As `send_message` events arrive reactively from active subagents:
1. Parse the incoming JSON telemetry payload.
2. Render or update a consolidated live status dashboard in the chat window:
```markdown
⏳ **Live Pipeline Execution Dashboard**
* **Dataset Ingestion Worker**: [██████████░░░░░░░░░░] Step 2/4 Complete (Process)
* **Image Processing Worker**: [█████░░░░░░░░░░░░░░░] Step 1/4 Complete (Init)
* **Model Inference Worker**: [███████████████░░░░░] Step 3/4 Complete (Validate)
```
Stage 4: Reactive orchestrator dashboard updates
Instead of sleeping silently until all four steps across all three workers finish, the parent orchestrator reactively wakes up as each event arrives. It updates a live progress dashboard in the chat window for the developer:
When all of the workers have finished, the orchestrator provides a final execution summary:
Bonus: Four anti-patterns to avoid when messaging agents
As you integrate send_message into your team’s custom agent skills, avoid these four common design mistakes:
1. Avoid unbounded ping-pong message loops
Avoid instructing subagents to reply automatically to every incoming message without a strict termination condition. Unbounded ping-pong dialogue between subagents can consume a lot of tokens. Require an explicit STATUS: COMPLETE or TERMINATE flag to end conversation cycles.
2. Avoid un-grounded recipient IDs
Subagents cannot guess the parent’s conversationID. Always explicitly pass the parent’s target ID in the worker’s initial launch prompt (invoke_subagent), or store it in a shared workspace context file during initialization.
3. Avoid unformatted text dumps
Avoid sending free-form conversational prose between agents (“Hey boss, I just finished step 2 and everything looks fine…”). Instruct your subagents to transmit structured JSON strings or prefixed headers ([PROGRESS], [ERROR], [ABORT]). Structured payloads make message parsing fast and deterministic.
4. Avoid high-frequency spam
Do not instruct subagents to send a message for every line edited or file read. Message transport incurs context overhead. Limit send_message invocations to major milestone boundaries (e.g., pipeline steps, test suite completions, or fatal errors).
🚀 Builder challenge: The multi-agent “circuit breaker” pattern
Streaming progress logs is great, but the true power of send_message emerges when handling unexpected failures.
Imagine Worker C encounters a fatal database corruption at Step 3. In a traditional unmonitored setup, Worker A and Worker B would blindly continue executing for another two minutes, wasting API tokens and computing resources on a job destined to fail.
By leveraging bidirectional send_message channels, you can implement an automated Circuit Breaker.
Your challenge:
- Have one of the subagents encounter an unrecoverable error and send an urgent signal back to the parent orchestrator using its conversation ID.
- Have the orchestrator broadcast an abort signal to active children or forcefully terminate them.
- Gracefully exit the workflow and report the incident to the user.
💡 Sneak Peek at Article 5: While send_message handles cooperative soft-aborts, manage_subagents gives orchestrators hard circuit-breaking powers to list, monitor, and forcefully terminate active workers. Stay tuned for Article 5!
Did you attempt the challenge? Share your skill’s strategy in the comments below!
Conclusion
Adding send_message to your agent orchestration toolkit bridges the gap between static task execution and resilient multi-agent networking. By pairing lifecycle spawning with mid-flight telemetry and emergency circuit breakers, your agent teams run faster, fail safer, and remain fully transparent to developers.
Try adding mid-flight status reporting to your team’s longest-running subagent skill today, and test the Circuit Breaker pattern to protect your workflows against cascading failures!
📌 Elevating Antigravity Agent Skills Series Index
- Part 1: Building interactive UI workflows with ask_question
- Part 2: Automating Image Generation with generate_image
- Part 3: Defining & Invoking Subagents with define_subagent, invoke_subagent
- Part 4: Inter-Agent Communication with send_message (📍 You are here)
- Part 5: Managing Active Agent Lifecycles with manage_subagents
Additional resources
- Tool Reference: List of supported Antigravity tools
- Article: How to automate modernization with Antigravity and multi-agent orchestration
- Example source: source code
Help others find this post
- Save this post to find it later.
- Subscribe to my The Agentic Developer newsletter.
- Share this article across social media.
- Follow me on LinkedIn or X for more agentic engineering insights.
Thanks for reading!
Originally published at https://www.linkedin.com.
Elevating Antigravity agent skills, Part 4: Subagent messaging was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source Credit: https://medium.com/google-cloud/elevating-antigravity-agent-skills-part-4-subagent-messaging-42bd72d44600?source=rss—-e52cf94d98af—4
About the Author
