Skip to content

feat(google_adk): add ADK-112, workflow agent has no description - #79

Open
bradAGI wants to merge 1 commit into
trustabl:mainfrom
bradAGI:feat/adk-workflow-agent-description
Open

feat(google_adk): add ADK-112, workflow agent has no description#79
bradAGI wants to merge 1 commit into
trustabl:mainfrom
bradAGI:feat/adk-workflow-agent-description

Conversation

@bradAGI

@bradAGI bradAGI commented Aug 24, 2026

Copy link
Copy Markdown

adk_sequential_agent, adk_parallel_agent, and adk_langgraph_agent are valid applies_to tokens the engine discovers but no shipped rule used any of them — every ADK agent-scope rule targets adk_llm_agent, except ADK-108 for LoopAgent. I found this auditing which engine capabilities have zero rule coverage.

This extends ADK-101's routing check to the workflow classes. A workflow agent is routed to exactly like an LlmAgent: when the parent decides whether to hand off, the model sees only the child's description, so one without a description sits in the sub_agents tree unreachable through delegation — a silent routing bug, not an error.

It's easier to miss on a workflow agent than on an LlmAgent, which is why it's worth its own rule rather than widening ADK-101. A workflow agent has no instruction= and no model= of its own, so nothing else about its construction reads as model-facing text and the missing description doesn't look like an omission. What it orchestrates is also invisible from outside — the parent can't infer "runs these three steps in order" from the class name. The fix leans on that: describe what the workflow accomplishes, not its mechanics, since the parent's model is choosing whether this branch is the right one.

adk_langgraph_agent is deliberately left out. LanggraphAgent takes a compiled graph rather than an ADK sub_agents tree, so the delegation-routing argument doesn't obviously transfer — I'd want to check how the engine models it before claiming it in user-facing text. Happy to follow up if it does apply.

Numbered ADK-112 to avoid colliding with ADK-111 in the open PR #51.

Verification — engine built at main:

$ trustabl rules validate .
OK: 85 rule pack(s), 207 rule(s) valid under rule schema version 14

Fire (SequentialAgent, ParallelAgent, and LoopAgent each with no description=): ADK-104, ADK-112, ADK-201 — three separate ADK-112 findings, one per class, so all three applies_to values are exercised rather than assumed.
Silent (all three with a description=): ADK-104, ADK-201

(ADK-104 and ADK-201 are pre-existing rules firing on the fixture's LlmAgents and missing AGENTS.md.)

No new predicates, so no schema_version bump.

adk_sequential_agent, adk_parallel_agent, and adk_langgraph_agent are
valid applies_to tokens the engine discovers but no shipped rule used —
every ADK agent-scope rule targets adk_llm_agent, except ADK-108 for
LoopAgent. This covers the workflow classes for the routing check
ADK-101 already makes for LlmAgent.

A workflow agent is routed to exactly like an LlmAgent: the parent's
model sees only the child's description. It is easier to miss here,
because a workflow agent has no instruction= and no model= of its own, so
nothing else about its construction reads as model-facing text. What it
orchestrates is also invisible from outside — the parent cannot infer
"runs these three steps in order" from the class name.

Left adk_langgraph_agent out: LanggraphAgent takes a compiled graph
rather than an ADK sub_agents tree, so the delegation-routing argument
does not transfer without checking how the engine models it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant