Spec defect: §6.2.5 shows wrong YAML for `type: subgraph` node — actual schema is missing #3

New issue

Open

opened 2026-05-27 05:24:01 +00:00 by hurui200320 · 0 comments

hurui200320 commented

2026-05-27 05:24:01 +00:00

Member

Problem

§6.2.5 is supposed to define the type: subgraph graph node. Instead, the YAML block shown is the deprecated agent template instantiation form, which belongs in §4.8:

# What §6.2.5 actually shows — this is NOT a subgraph node:
  <agent_name>:
    agent_template: <template_name>   # DEPRECATED - use `template` instead
    params: <mapping>

The actual schema for a type: subgraph node — what fields it accepts, what graph it invokes, and how the subgraph result is incorporated into the parent graph state — is never defined anywhere in the spec.

The only behavioral statement is:

Compliant implementations MUST record metadata.subgraph = <graph_route_name> and metadata.subgraph_pending = true.

This implies type: subgraph nodes are placeholder stubs that merely annotate state, but it is completely unclear:

What field specifies which graph to invoke (graph:, route:, something else)?
Is the subgraph actually executed, or just flagged?
If executed, how does the parent graph receive the result?
If it's a stub, what is its purpose over a no-op?

Impact on Library Implementation

type: subgraph cannot be parsed, validated, or executed without a schema definition. An implementor must either omit support (violating §4.3 which mandates all defined node types) or invent an arbitrary schema.

Fix Needed

Replace the §6.2.5 content with:

The correct YAML schema for a type: subgraph node (field name, type, required/optional)
The execution semantics: does the subgraph run synchronously, asynchronously, or is it a future/deferred execution marker?
How the subgraph's output state is merged back into the parent graph state

References

§6.2 — Node types table (lists subgraph as a defined type pointing to §6.2.5)
§6.2.5 — Subgraph Nodes (contains wrong YAML)
§4.3 — Agent Types (all defined types must be supported)

## Problem §6.2.5 is supposed to define the `type: subgraph` graph node. Instead, the YAML block shown is the deprecated agent template instantiation form, which belongs in §4.8: ```yaml # What §6.2.5 actually shows — this is NOT a subgraph node: <agent_name>: agent_template: <template_name> # DEPRECATED - use `template` instead params: <mapping> ``` The actual schema for a `type: subgraph` node — what fields it accepts, what graph it invokes, and how the subgraph result is incorporated into the parent graph state — is never defined anywhere in the spec. The only behavioral statement is: > Compliant implementations MUST record `metadata.subgraph = <graph_route_name>` and `metadata.subgraph_pending = true`. This implies `type: subgraph` nodes are placeholder stubs that merely annotate state, but it is completely unclear: - What field specifies which graph to invoke (`graph:`, `route:`, something else)? - Is the subgraph actually executed, or just flagged? - If executed, how does the parent graph receive the result? - If it's a stub, what is its purpose over a no-op? ## Impact on Library Implementation `type: subgraph` cannot be parsed, validated, or executed without a schema definition. An implementor must either omit support (violating §4.3 which mandates all defined node types) or invent an arbitrary schema. ## Fix Needed Replace the §6.2.5 content with: 1. The correct YAML schema for a `type: subgraph` node (field name, type, required/optional) 2. The execution semantics: does the subgraph run synchronously, asynchronously, or is it a future/deferred execution marker? 3. How the subgraph's output state is merged back into the parent graph state ## References - §6.2 — Node types table (lists `subgraph` as a defined type pointing to §6.2.5) - §6.2.5 — Subgraph Nodes (contains wrong YAML) - §4.3 — Agent Types (all defined types must be supported)

hurui200320 added the

labels

2026-05-27 05:27:14 +00:00

~~hurui200320 referenced this issue 2026-05-27 09:32:50 +00:00~~

Remove memory_enabled from LLM agent config — make all actors stateless by design #21