| English | 中文版 |
Status: Proposed Version: 0.7 Date: 2026-05-09 Authors: Ori Lynn / INNO LOTUS PTY LTD Depends-On: NPS-1 (NCP v0.7), NPS-2 (NWP v0.13), NPS-3 (NIP v0.9), NPS-4 (NDP v0.8), NPS-5 (NOP v0.6), token-budget v0.5
This specification defines compliance requirements for building Agent-as-a-Service (AaaS) platforms on the NPS protocol suite, covering three architectural layers: service entry, internal orchestration, and data access.
Agent-as-a-Service is a cloud service model where providers expose AI Agent capabilities through standardized APIs to consumers (other Agents or human applications), without requiring consumers to understand internal implementation details.
| Current Pain Point | NPS-AaaS Solution |
|---|---|
| Incompatible APIs across Agent platforms | Unified Anchor Node entry (cluster front door) + Bridge Node (NPS↔external) + NWP standard frame protocol |
| Non-standard, unobservable internal orchestration | NOP DAG orchestration + OpenTelemetry tracing |
| High token overhead for AI accessing traditional DBs | Vector Proxy Layer vectorization middleware |
| No Agent identity/permission standard | NIP NID identity + scope delegation chain |
| No service quality guarantees | CGN-Estimate Token Budget + back-pressure control (CGN-Billing for commercial settlement, see token-budget §2.1) |
Consumer Agent
│
▼
┌─────────────────────────────────┐
│ Anchor Node (NWP type) │ ← Service entry, external API
│ • Authentication (NIP) │
│ • Routing / Rate limit / CGN │
│ • Service catalog (NWM) │
└──────────┬──────────────────────┘
│ DelegateFrame (NOP)
▼
┌─────────────────────────────────┐
│ Orchestration Layer (NOP) │ ← Business coordination
│ • DAG task decomposition │
│ • K-of-N sync / preflight │
│ • Retry / timeout / cancel │
└──────┬────────────┬─────────────┘
│ │
▼ ▼
┌────────────┐ ┌────────────────────┐
│ Action Node│ │ Memory Node │
│ (Worker) │ │ + Vector Proxy │ ← Traditional DB vectorized
└────────────┘ │ Layer │
└────────────────────┘
Renamed from “Gateway Node” by NPS-CR-0001 in v1.0-alpha.3. The role described in this section — stateless cluster entry point that routes inbound NWP
Actionframes into NOPTaskFrames — is unchanged. The wire valuenode_type: "gateway"was removed and parsers MUST reject it. Implementations MAY add long-lived member-node registry behavior on top of the per-request stateless dispatch (NPS-2 §2.1 Anchor Node — detailed semantics); the topology read-back surface (topology.snapshot/topology.stream) is defined in NPS-2 §12 and is mandatory at L2 (see §4.3 below) per NPS-CR-0002.
Anchor Node is an NWP node type serving as the unified entry point for AaaS
services. It does not handle business logic directly but routes requests to the internal
NOP orchestration layer. A single Anchor Node MAY simultaneously declare other roles
(e.g. Memory Node) via NDP Announce.node_roles array form (NPS-4 §3.1).
| Property | Value |
|---|---|
| Node type | anchor |
| NWM node_type | "anchor" |
| NDP node_roles | ["anchor"] (or array form including "anchor") |
| Frame entry | ActionFrame (0x11) |
| Internal conversion | ActionFrame → NOP TaskFrame (0x40) |
| Responsibility | Protocol | Description |
|---|---|---|
| Authentication | NIP | Verify consumer NID, check scope |
| Service catalog | NWP NWM | Expose available Actions via NWM manifest |
| Request routing | NOP | Convert ActionFrame to TaskFrame, decompose DAG |
| Token metering | CGN-Estimate (budget / quota) · CGN-Billing (settlement) | Per-request Token Budget management uses CGN-Estimate; commercial settlement records MUST use CGN-Billing per token-budget §2.1 |
| Rate limiting | NWP | NID-based rate limiting |
| Observability | NOP Context | Inject trace_id/span_id for full-chain tracing |
| Cluster registry (optional at L1, mandatory at L2) | NDP + NWP | Track member nodes registered via Announce.cluster_anchor; surface them through topology.snapshot / topology.stream (NPS-2 §12) |
{
"nwm_version": "0.10",
"node_type": "anchor",
"node_id": "nwp://api.example.com/agent-service",
"display_name": "Example AaaS Anchor",
"capabilities": ["nop:orchestrate", "nwp:invoke", "nip:delegate"],
"actions": [
{
"action_id": "analysis.run",
"description": "Run a multi-step data analysis pipeline",
"params_schema": { "$ref": "#/schemas/analysis_input" },
"result_schema": { "$ref": "#/schemas/analysis_output" },
"estimated_npt": 2000,
"timeout_ms": 120000,
"async": true
}
],
"rate_limits": {
"requests_per_minute": 60,
"max_concurrent": 10,
"cgn_per_hour": 100000,
"cgn_profile": "estimate"
},
"auth": {
"required": true,
"min_nip_version": "0.4",
"required_scopes": ["agent:invoke"]
}
}
Consumer Anchor Node NOP Orchestrator
│ │ │
│── ActionFrame ──────────→ │ │
│ (action_id, params) │ │
│ │── verify NID + scope │
│ │── lookup action → DAG template │
│ │── build TaskFrame ─────────→ │
│ │ (DAG, context, budget) │
│ │ │── DelegateFrame → Workers
│ │ │── SyncFrame wait
│ │ ←── AlignStream(result) ── │
│ ←── CapsFrame(result) ──── │ │
Introduced by NPS-CR-0001 in v1.0-alpha.3 as the second half of the Gateway Node split. While Anchor Node sits at the front door of an NPS cluster (inbound NPS → routed NPS), Bridge Node sits at the outbound edge: NPS frames going out to non-NPS systems.
Bridge Node is an NWP node type that translates NPS frames to and from non-NPS protocols. It is stateless per request and does not participate in cluster topology.
| Property | Value |
|---|---|
| Node type | bridge |
| NWM node_type | "bridge" |
| NDP node_roles | ["bridge"] (or array form including "bridge") |
| NDP bridge_protocols | array of supported targets, e.g. ["http", "grpc"] |
| Frame entry | ActionFrame (0x11) carrying bridge_target |
Direction note. Bridge Node carries the NPS → external direction. The legacy
compat/*-bridgepackages historically published under LabAcacia (MCP / A2A / gRPC) carry the inverse direction (external → NPS) and have been renamedcompat/*-ingressto remove the naming collision. See NPS-CR-0001 §3.2 and CR-0001 §6.
| Responsibility | Protocol | Description |
|---|---|---|
| NPS frame ingest | NWP | Accept ActionFrame containing bridge_target (target external endpoint + protocol selector) |
| Outbound translation | HTTP / gRPC / MCP / A2A | Encode the NPS payload as the target protocol’s request format |
| Response translation | NWP | Decode the target’s response and return as CapsFrame |
| Authentication relay (optional) | NIP / vendor | Forward NIP credentials as the target protocol’s auth token (where mappable), or use vendor-side credentials configured per Bridge instance |
| Observability | NOP Context | Annotate spans with the target protocol + endpoint so end-to-end traces traverse the boundary cleanly |
The set below is the minimum that reference Bridge Node implementations are expected to support; concrete bridge_target schemas per target protocol are deferred to follow-up CRs.
| Target | NDP bridge_protocols value |
Notes |
|---|---|---|
| HTTP / HTTPS | "http" |
REST and streaming |
| gRPC | "grpc" |
Unary and streaming |
| Model Context Protocol | "mcp" |
LLM-tool integration target |
| Agent-to-Agent | "a2a" |
Google A2A v0.2 |
Additional protocols MAY be registered through future CRs by adding new bridge_protocols values.
Gateway Node (removed in v1.0-alpha.3) — the role formerly known as “Gateway Node” lives on as Anchor Node (this section’s §2). The new Bridge Node name was introduced because the term “bridge” had already been informally taken by
compat/*-bridge; those packages have been renamedcompat/*-ingress. See NPS-CR-0001 for full rationale.
Add a vector proxy layer in front of traditional databases (RDS/NoSQL):
AI Agent ←→ Vector Proxy Layer ←→ Traditional Database
(vector space) (SQL/document)
NWP Memory Node Interface
│
┌──────────┴──────────┐
│ Vector Proxy Layer │
│ │
│ ┌────────────────┐ │
│ │ Embedding Engine│ │ ← Embedding model (local/remote)
│ └───────┬────────┘ │
│ │ │
│ ┌───────┴────────┐ │
│ │ Vector Index │ │ ← ANN index (HNSW/IVF)
│ │ (memory/disk) │ │
│ └───────┬────────┘ │
│ │ │
│ ┌───────┴────────┐ │
│ │ Schema Mapper │ │ ← DB schema ↔ AnchorFrame mapping
│ └────────────────┘ │
└──────────┬───────────┘
│
┌──────────┴──────────┐
│ Traditional DB │
│ (PostgreSQL/MySQL/ │
│ MongoDB/...) │
└─────────────────────┘
vector_search capability)| Query Mode | Use Case | Token Savings |
|---|---|---|
| Vector semantic query | “Find records similar to X” | ~70-80% (return only top-K summary vectors) |
| Structured query + vector summary | Precise filter + AI-readable summary | ~40-60% (filter then vectorize-compress) |
| Passthrough query | Need complete raw data | 0% (fallback to traditional mode) |
{
"frame": "0x04",
"anchor_ref": "sha256:...",
"count": 5,
"data": [
{
"_id": "product:1001",
"_score": 0.95,
"_embedding": [0.12, -0.34, ...],
"name": "Widget Pro",
"price": 29.99
}
],
"vector_meta": {
"model": "text-embedding-3-small",
"dimensions": 256,
"index_type": "hnsw"
},
"token_est": 85
}
Compared to returning full row data with dozens of irrelevant columns, vector mode returns only top-K similar results + embedding vectors + key fields, reducing token_est from hundreds to double digits.
The Vector Proxy Layer is fully transparent to consumers. Standard NWP QueryFrame:
{
"frame": "0x10",
"anchor_ref": "sha256:...",
"vector_search": {
"field": "_embedding",
"vector": [0.11, -0.33, ...],
"top_k": 5,
"metric": "cosine"
},
"fields": ["name", "price", "_score"]
}
NWP v0.13 already supports the vector_search field (§6.4). The Vector Proxy Layer
only needs to implement this interface for seamless integration.
| Level | Name | Requirements |
|---|---|---|
| Level 1 | Basic | Anchor Node + NIP auth + NWM service catalog |
| Level 2 | Standard | Level 1 + NOP orchestration + OpenTelemetry tracing + Token Budget |
| Level 3 | Advanced | Level 2 + Vector Proxy Layer + K-of-N fault tolerance + audit log |
| Req ID | Description | Protocol |
|---|---|---|
| L1-01 | MUST deploy Anchor Node as the sole service entry point | NWP |
| L1-02 | MUST verify consumer NID via NIP | NIP |
| L1-03 | MUST publish NWM manifest with all available Actions | NWP |
| L1-04 | MUST support NPS unified port 17433 | NCP |
| L1-05 | MUST return NPS standard status codes and error frames | NCP |
| L1-06 | SHOULD support both HTTP mode and native mode dual transport | NCP |
| Req ID | Description | Protocol |
|---|---|---|
| L2-01 | MUST use NOP TaskFrame for internal task orchestration | NOP |
| L2-02 | MUST inject OpenTelemetry trace in TaskFrame.context | NOP |
| L2-03 | MUST support CGN-Estimate Token Budget with token_est in responses (budget / quota / telemetry surface only — see token-budget §2.1) |
CGN-Estimate |
| L2-04 | MUST support NOP preflight mechanism | NOP |
| L2-05 | MUST implement NOP retry and timeout semantics | NOP |
| L2-06 | SHOULD support async Actions (ActionFrame.async=true) | NWP |
| L2-07 | SHOULD implement AlignStream back-pressure control | NOP |
| L2-08 | MUST implement topology.snapshot and topology.stream reserved query types on Anchor Nodes that maintain a member registry, per NPS-2 §12. The version counter MUST be monotonic per Anchor lifetime and SHOULD survive in-process restarts via rebase + anchor_state.version_rebased event. Implementations claiming L2-08 MUST satisfy NPS-Node-Profile L1 for the host running the Anchor; an Anchor maintaining an active member registry SHOULD also satisfy Node-Profile L2. |
NWP §12 |
| L2-09 | SHOULD configure a reputation_policy in the NWM and consult at least one NPS-RFC-0004 compliant log operator on agent admission. The recommended minimum policy for L2 AaaS deployments is: reject agents with an active cert-revoked incident of any severity, or a rate-limit-violation / tos-violation incident of major or higher within the last 30 days. Nodes SHOULD publish their reputation_policy under the NWM reputation_policy key. |
NPS-RFC-0004 |
| Req ID | Description | Protocol |
|---|---|---|
| L3-01 | MUST deploy Vector Proxy Layer for vectorized queries | NWP |
| L3-02 | MUST support NWP vector_search interface | NWP §6.4 |
| L3-03 | MUST implement K-of-N sync fault tolerance (SyncFrame.min_required) | NOP |
| L3-04 | MUST maintain audit logs (NOP §8.3) | NOP |
| L3-05 | MUST implement scope delegation chain security (max 3 levels) | NIP + NOP |
| L3-06 | SHOULD support automatic schema discovery (DB schema → AnchorFrame) | NWP |
| L3-07 | SHOULD support hot vector index updates (incremental rebuild on data changes) | Vector Proxy |
| L3-08 | MUST emit CGN-Billing records (not generic CGN / CGN-Estimate) for any commercial settlement flow, per token-budget §2.1, §6.3. This implies verified_tokenizer-tier tokenizer resolution, NID-signed metering records, no sampling, no byte-size fallback, and audit-log integration sufficient for dispute / chargeback. The X-NWP-Tokens-Profile, X-NWP-Billing-Record, and X-NWP-Billing-Tokenizer-Tier response headers MUST appear on every billed response. |
CGN-Billing + NIP + NPS-RFC-0004 |
Consumer Agent Anchor Node NOP Vector Memory Node Action Worker
│ │ │ │ │
│── ActionFrame ────────→ │ │ │ │
│ action: analysis.run │ │ │ │
│ params: {query: "..."} │ │ │ │
│ │── verify NID ──→ │ │ │
│ │── build DAG ──→ │ │ │
│ │ TaskFrame │ │ │
│ │ ┌─────────┐ │ │ │
│ │ │ fetch │──→ │── DelegateFrame ──→ │ │
│ │ │ analyze │ │ │── QueryFrame ──→ DB
│ │ │ summarize│ │ │ (vector_search) │
│ │ └─────────┘ │ ←── CapsFrame ───── │ (top-K, 85 CGN) │
│ │ │ │ │
│ │ │── DelegateFrame ─────────────────────→ │
│ │ │ │
│ │ │ ←── AlignStream(result) ────────────── │
│ │ │ │ │
│ ←── CapsFrame ────────── │ ←── result ────── │ │ │
│ (vectorized summary, │ │ │ │
│ 85+50 CGN) │ │ │ │
Traditional approach: fetch returns full row data ~500 CGN → analyze processes ~300 CGN = 800+ CGN AaaS vectorized approach: fetch returns top-K vector summary ~85 CGN → analyze ~50 CGN = ~135 CGN
Token savings ~83%.
| Profile Component | NPS Protocol Dependency | Protocol Change Required |
|---|---|---|
| Anchor Node | NWP v0.13 | Yes: rename node_type: "gateway" to "anchor" (CR-0001); legacy "gateway" rejected. L2 cluster registry surfaces via topology.snapshot / topology.stream (CR-0002) |
| Bridge Node | NWP v0.13 | Yes: new node_type: "bridge" value (CR-0001) |
| Request routing | NOP v0.6 | No: reuses TaskFrame/DelegateFrame |
| Authentication | NIP v0.9 | No: reuses NID + scope |
| Vector queries | NWP v0.13 §6.4 | No: reuses vector_search |
| Vector Proxy | NWP + NCP | No: implementation-level middleware |
| Token metering — quota / budget | CGN-Estimate (token-budget v0.5) | No: reuses token_est, sampling-tolerant |
| Token metering — commercial settlement | CGN-Billing (token-budget v0.5) | Adds: verified_tokenizer requirement (NIP §5.1), NID-signed metering records, audit-log persistence, billing response headers (issue #40 / L3-08) |
| Audit trail | NOP v0.6 §8.3 | No: reuses context.trace_id |
Protocol changes required: NWP NWM node_type enum must accept "anchor" and "bridge" (replacing the removed "gateway"); NDP AnnounceFrame gains node_roles/cluster_anchor/bridge_protocols fields. All additive at the wire layer except the "gateway" removal — see NPS-CR-0001. Legacy node_kind remains a parse-time alias during the alpha compatibility window only.
| Version | Date | Changes |
|---|---|---|
| 0.7 | 2026-05-09 | CGN profile split (issue #40). §1.2 row, §2.2 Token-metering row, and §2.3 NWM example clarified to mark budget / quota surfaces as CGN-Estimate. §4.3 L2-03 narrowed to CGN-Estimate (telemetry / quota only). New §4.4 L3-08 requirement: any commercial settlement flow MUST emit CGN-Billing records (verified_tokenizer, NID-signed, no sampling / no byte-fallback, audit-log integrated, billing-class response headers). §6 protocol-relationship table split into Estimate / Billing rows and re-pointed at token-budget v0.5. Depends-On adds token-budget v0.5. |
| 0.6 | 2026-05-01 | alpha.5 update. New L2-09 requirement (§4.3): SHOULD configure a reputation_policy and consult at least one NPS-RFC-0004-compliant log operator; recommended minimum policy defined. Depends-On bumped: NPS-RFC-0004 Phase 3 (STH gossip). |
| 0.5 | 2026-05-01 | M8 cross-profile contract clarification. §4.3 L2-08 description extended: implementations claiming L2-08 MUST satisfy Node-Profile L1 for the Anchor host; active-registry Anchors SHOULD also satisfy Node-Profile L2. Depends-On bumped: NPS-2 (NWP v0.13 → v0.10), NPS-3 (NIP v0.9 → v0.6), NPS-4 (NDP v0.8 → v0.6). |
| 0.4 | 2026-04-27 | New L2-08 requirement (§4.3) mandating topology.snapshot / topology.stream on Anchor Nodes that maintain a member registry, per NPS-CR-0002 and NPS-2 §12. §2 intro placeholder (“reserved for v1.0-alpha.4”) replaced with concrete L2 mandate. §2.2 cluster-registry row promoted from “optional” to “optional at L1, mandatory at L2”. §6 protocol-relationship table re-pointed at NWP v0.13 to pick up the new §12 surface. Depends-On bumped: NPS-2 (NWP v0.13 → v0.8). |
| 0.3 | 2026-04-26 | Breaking (per NPS-CR-0001). §2 renamed Gateway Node → Anchor Node, all wire/manifest examples updated (node_type: "anchor", nwm_version: "0.7", min_nip_version: "0.4"); new §2.2 row for optional cluster registry. New §2A Bridge Node (NPS↔non-NPS protocol translation, bridge_protocols declaration, direction-vs-compat/*-bridge clarification). §1.2 / §1.3 architecture diagram and §6 protocol-relationship table updated; L1 §4.2 / §5 references re-pointed to Anchor Node. §6 protocol-change line replaced “add gateway” with “rename gateway → anchor + new bridge”. Depends-On upgraded to NCP v0.7 (RFC-0001) + NWP v0.13 (CR-0001) + NIP v0.9 (RFC-0003) + NDP v0.8 (CR-0001 fields). |
| 0.1 | 2026-04-15 | Initial draft: AaaS architecture overview, Gateway Node definition, Vector Proxy Layer design, three-tier compliance requirements |
Attribution: LabAcacia / INNO LOTUS PTY LTD · Apache 2.0