Reliably calling workflows from other workflows

Has anyone found a way to reliably get workflows to call other workflows? I have tried a few things and implemented in the format shown in the example documentation, but the models frequently end their output with something like:

@[/geocoding-pipeline] The contract has been approved. The api-service layer changes have been completed and verified. Please read @/memories/session/feature_contract.md and implement the changes marked for the geocoding-pipeline layer.

Where the agent often hallucinates what a user would type, sort-of, to call the workflow: @[/geocoding-pipeline]. Which itself is incorrect, I have tried “always on” rules that enforces typing as “/geocoding-pipeline” but that does not actually call a workflow either, when an agent outputs that text string.

I ported a bunch of agents from my VSCode setup into Antigravity, and originally using the VSCode template format, it appeared that the agent would perform end-to-end tasks. I then refactored into something that aligned with Antigravity documentation and I no longer get the end-to-end task complete.

I had decided to switch to the Antigravity templates as I couldn’t be sure if the workflow was actually being called by the starting workflow, or if the model was hallucinating its way through, and was hoping that by conforming to the documentation formats, it would provide better visibility into workflows calling other workflows, but it did not.

VS-Code/Copilot has a specific “agent” tool, and in the chat window I can see specifically when a subagent has been called. This would be a really welcome addition to Antigravity to provide better visibility of what the agents are actually doing. Further, actually knowing what tools Agent has access to would really help in filling out workflows so I could actually tell the agent that it can or should use a specific tool to accomplish a job.

As is usually the case, I seem to have fixed the issue. For anyone curious, when porting the workflow to antigravtiy I had added a new section under my dispatcher agent’s workflow that gave a template for how specialists should return a summary report. This was after the <\workflow> wrapped section as show in the example below:

## 6. Post-Audit Routing
After george's verdict:
- Any High/Medium finding → call `/the-architect` for a follow-up contract.
- Only Low/no findings → call `/trowel` to mark milestone complete.
- Verdict `Pass` → also call `/git-manager` for commit and push.
</workflow>

<return-template>
**Specialist: save the FULL report below to `@/memories/session/specialist-reports/<your-agent-name>-<short-timestamp>.md` via `antigravity/memory` BEFORE returning. Then return ONLY the TL;DR + the artifact path.**

## TL;DR
<one to three sentences naming the layer, the change shipped, and either "green" or the named blocker>

## Artifact
`@/memories/session/specialist-reports/<your-agent-name>-<short-timestamp>.md`

---

## Full Report (saved to artifact, NOT echoed to chat)

### Layer: <Layer-Name>

### Files Touched
- `<workspace-relative path>` — <one-line purpose> (lines `<L#-L#>`)

### Diff Summary
<key before/after snippets in fenced code blocks>

### Commands Run
- `<exact command>` → <exit code or key output>

### Decisions & Alternatives
- <decision> — <why; what was rejected and why>

### Risks / Follow-ups
- <anything the next layer or auditor should know; "none" if truly none>
</return-template>

I removed the return-template portion from the workflow and moved it into an “Always-On” rule. End-to-end tasks are now occuring again with each specialist workflow generating a report file, which, in a way, acts as a flag that a new workflow was called, I hope.. :smiley: