[nmrg] review of draft-wmz-nmrg-agent-ndt-arch-04

[chong feng <[e-mail]>]

Hi authors and all,

I have reviewed this draft; some comments, I think, may be discussed.

**1. Clarification of Network Applications and Interaction Models**

Section 5.2.1 treats "Network Applications" as a single category, but it's
actually lumping together two cases with very different interaction
patterns:

- Traditional deterministic systems (OSS/BSS, orchestration), and
- Autonomous AI agents acting as consumers of the Hybrid Agent System.

For traditional apps, RESTful APIs are a natural fit — but the draft
doesn't address how a deterministic API request gets translated into a
semantic intent the agent system can consume. For autonomous agents,
A2A-style interaction makes sense. The architecture needs to treat these as
distinct interaction models, not one generic "application interface."

**2. Need for an Explicit Semantic Layer**

Section 5.3.2 lists RESTful API, NLPI, A2A, and A2A-T as possible "intent
interfaces." These are transport mechanisms — they say nothing about what
the intent actually *means*. The architecture would be stronger with an
explicit semantic layer that describes intent objectives, scope,
constraints, context, and expected outcomes, independent of the underlying
transport (REST, A2A, MCP, etc.).

This is a familiar separation in IETF work — YANG models sit above
NETCONF/RESTCONF, not inside them. The same principle applies here. The
semantic model of an intent (or an agent delegation, or a capability
invocation) should not be coupled to the protocol carrying it.

The same point extends to agent delegation and function invocation inside
the Hybrid Agent System.

**3. In a single NDT, most tasks do not need a long-lived, business-bound
agent**

The draft defines Task AI Agents as long-lived entities bound to specific
business scenarios — Section 7's registration, discovery, and team
formation all assume pre-provisioned, persistent agents. I would argue this
single default is the root of the complexity, and that the draft conflates
three kinds of things that should be kept apart:

- **Tool / Function Module**: stateless, discoverable at call time, invoked
through MCP or similar. "Query BGP neighbor state," "push a config diff,"
"run a simulation." No lifecycle to manage.

- **Ephemeral Task Agent**: created by the Network AI Agent on demand for a
specific subtask, lives only as long as that subtask runs, destroyed when
done. Has a scoped goal, a set of tools, and internal state for the
duration. Needs no registry, no discovery, no health monitoring — the
spawning agent already knows what it created.

- **Persistent Agent**: a long-lived entity with independent goals, ongoing
state, and lifecycle management. Only makes sense for agents that need to
continuously sense their environment and adapt — not for one-off
operational functions.

The problem is not the number of agents — it is the combination of
"long-lived" and "business-bound." A persistent agent bound to a specific
business scenario accumulates state coupled to that business logic, and the
pool of such agents grows without bound, each dragging in registration,
discovery, monitoring, consistency, and lifecycle management. That
complexity is not inherent to agents; it is the product of that combination.

What genuinely needs to be long-lived — execution environment, context,
session state — is cross-cutting infrastructure and should not be bound to
any specific business. Business logic, by contrast, should be created on
demand, used, and reclaimed, or degraded to plain tool calls where possible.

Concretely: a scoped agent that checks BGP neighbor state during a
troubleshooting flow should be spawned, executed, and destroyed when the
task ends — not registered in a fabric and monitored for its whole lifetime.

So for a single NDT, the default should be tool calls or ephemeral agents.
Persistent agents should be reserved for rare cases with a clear, stated
justification — and even then, kept decoupled from specific business flows.
This shift would eliminate much of the Agent Fabric machinery for
single-domain operation and make the architecture considerably simpler —
without losing the value of agents for tasks that genuinely need multi-step
reasoning and tool orchestration.

**4. Agent Fabric: keep it for cross-domain, drop it for single-domain**

Following from the above: Agent Fabric (Section 5.3.5) becomes relevant
primarily in cross-domain scenarios (Section 5.3.4), where agents from
different administrative domains need to discover and negotiate with each
other. Within a single autonomous domain, if task agents are ephemeral and
capabilities are exposed as tools, there's no registration problem to solve.

A simpler internal model:

```
Network AI Agent
       |
      MCP
       |
Function Modules / Tools
       |
  (ephemeral task agents spawned as needed)
```

Agent Fabric stays for inter-domain agent collaboration, where discovery
and trust establishment are real problems. But it shouldn't be the default
path for every operational function inside a domain.

**Overall**

The architecture has a solid foundation — combining Hybrid Agent Systems
with Network Digital Twin is a good direction. But the draft currently
mixes three concerns that would benefit from cleaner separation:
communication protocols (REST, A2A, MCP), semantic models (intent,
delegation, capability description), and the entity lifecycle — where the
default should be ephemeral, with long-lived, business-bound agents
reserved only for cases with explicit justification. Untangling these would
make the whole thing more interoperable and less prescriptive about agent
decomposition.

Best

Frank