NVIDIA-NeMo · dmariali · Aug 12, 2026 · Aug 6, 2026 · Aug 6, 2026 · Aug 6, 2026
@@ -8,14 +8,17 @@ author: Danielle Ali and Codex
 
 > This file is the durable contract for the local NeMo Platform assistant.
 > Keep it aligned with the implementation under `agents/nemo-studio-copilot/`.
+> The adjacent `agent.yaml` and `skills/` directory are the clean, size-bounded
+> fileset used for Platform registration; the source project retains its
+> packaging config and MCP executable.
 
 ## Role
 
 Help NeMo Platform developers inspect and operate their current workspace through Studio using the NeMo Platform SDK.
 
 ## Purpose
 
-This agent provides a conversational backend for NeMo Studio so developers can confirm that a packaged NVIDIA NeMo Agent Toolkit (NAT) agent can be built, deployed, and used to interact with NeMo Platform. It should make routine discovery and operational tasks faster without requiring users to translate their intent into CLI commands or raw API requests.
+This agent provides a conversational backend for NeMo Studio so developers can build, deploy, and use a Fabric-hosted agent to interact with NeMo Platform. It should make routine discovery and operational tasks faster without requiring users to translate their intent into CLI commands or raw API requests.
 
 The mission is grounded in the current deployment proof of concept and its implementation: answer simple read-only questions immediately, carry out explicit multi-step platform tasks through supported SDK operations, verify consequential results, and request missing context rather than guessing or entering an unbounded reasoning loop.
 
@@ -30,9 +33,8 @@ The mission is grounded in the current deployment proof of concept and its imple
 
 | Tool or source | Purpose | Credentials/scopes | Side effects | Freshness / expected failures |
 |---|---|---|---|---|
-| NeMo Platform Python SDK (`nemo_api`) | Access supported platform resources and actions through dot-separated SDK resource paths | Uses the deployment's platform base URL and active workspace; upstream secrets remain managed by NeMo Platform | Read and write operations depend on the requested SDK action | Workspace-scoped calls fail when no workspace is supplied; unavailable plugin resources or invalid SDK paths must be reported without repeated retries |
+| NeMo Platform Python SDK (`nemo_api`) over packaged MCP | Access supported platform resources and actions through dot-separated SDK resource paths | Uses the deployment's platform base URL and active workspace; mutations require a valid Studio session and approval | Read and write operations depend on the requested SDK action | Workspace-scoped calls fail when no workspace is supplied; unavailable plugin resources or invalid SDK paths must be reported without repeated retries |
 | Platform status helper (`check_status`) | Check evaluation, customization, audit, and Data Designer jobs | Same platform access as the SDK client | Read-only | A service may expose different status subresources; report when no supported status method exists |
-| Deterministic list fast paths | Return names for common read-only list requests without an LLM round trip | Same platform access as the SDK client | Read-only | Must use the active workspace and return a direct clarification or error if required context is absent; must not fall through to the full agent loop after a recognized request fails |
 | Packaged agent skills | Supply task-specific playbooks when spec-compliant skills are included in the image | No separate credentials | Depends on the selected playbook and SDK action | The agent must log which skills are loaded; an empty or malformed skills directory means no playbooks are available |
 
 ## Model
@@ -42,37 +44,36 @@ The mission is grounded in the current deployment proof of concept and its imple
 
 ## Framework
 
-- Resolution: langgraph-nat
-- Notes: LangGraph Deep Agent wrapped as a custom NAT workflow
+- Resolution: fabric-deepagents
+- Notes: NeMo Fabric using the preinstalled `nvidia.fabric.langchain.deepagents` adapter
 
 ## Harness
 
-- Description: A LangGraph Deep Agent with SDK tools, optional packaged skills, deterministic read-only fast paths, and a custom NAT wrapper compatible with Studio and evaluation request shapes
-- Agent loop: Deep Agents orchestrates model and tool turns; recognized list requests bypass the model; complex runs must have explicit iteration, retry, and wall-clock limits
-- Tool dispatch: The model calls typed LangChain tools that resolve NeMo Platform SDK resources and return serialized results or concise errors
-- Context management: Studio conversation messages are normalized into LangChain messages; the model receives a concise system prompt and packaged skills when available
-- State management: LangGraph state holds the conversation and scratch data; packaged skill files and temporary files use routed filesystem backends
+- Description: A Fabric-hosted Deep Agent with packaged skills and a stdio MCP server for NeMo SDK and Studio UI operations
+- Agent loop: Fabric's Deep Agents adapter orchestrates model and MCP tool turns
+- Tool dispatch: Harness-native MCP tools resolve NeMo Platform SDK resources and return serialized results or concise errors
+- Context management: Fabric receives OpenAI-compatible chat messages and supplies the system prompt and packaged skills to Deep Agents
+- State management: Fabric owns runtime session state, workspace files, and artifacts
 - Guardrails: API-only operation; no CLI or arbitrary subprocess route; ambiguous workspace or destructive target requires clarification
 - Observability: Structured application logs for fast-path selection, tool failures, model requests, retries, health probes, and final workflow errors; agent-specific telemetry exporters are disabled
-- Verification: Consequential multi-step requests should read back final state when the SDK supports it; unit tests and the NAT evaluation configuration validate core behavior
-- Runtime: Custom NAT workflow served in a Docker deployment and consumed by local NeMo Studio
-- Notes: A recognized fast-path failure must terminate with a useful clarification or error instead of falling through to the model-driven graph
+- Verification: Consequential multi-step requests should read back final state when the SDK supports it; unit tests validate config translation, MCP exposure, and mutation approval
+- Runtime: NeMo Fabric server using the Deep Agents adapter, consumed through OpenAI-compatible chat completions
+- Notes: Fabric does not preserve the former NAT-only deterministic fast path or `/generate/full` evaluation contract
 
 ## Behavior
 
 - Be concise and action-oriented. Distinguish completed work from instructions or proposed work.
 - Use the active request workspace automatically when it is available.
 - When a required workspace, resource name, target, or other consequential parameter is missing or ambiguous, ask one focused clarification question and stop that run.
 - Do not interpret missing context as permission to choose a destructive target.
-- For recognized deterministic requests, return the SDK result or a direct actionable failure; never use the full agent as an error-recovery fallback.
 - Use only NeMo Platform SDK tools. Never invoke the CLI, shell, or subprocesses.
 - Attempt reasonable equivalent SDK operations when a method name differs, but bound retries and do not loop over equivalent failures.
 - Report upstream model, SDK, and service failures honestly. Never claim that a mutation or deployment succeeded without verification.
 - Avoid exposing API keys or secret values in prompts, logs, or responses.
 
 ## Success Criteria
 
-- Common read-only list requests, including workspaces, models, providers, filesets, datasets, benchmarks, and metrics, complete through one deterministic SDK operation and normally return within a few seconds.
+- Common read-only list requests, including workspaces, models, providers, filesets, datasets, benchmarks, and metrics, use one appropriate SDK tool operation.
 - Missing workspace or target context produces a clear clarification question rather than an exception, guessed value, or model-driven recovery loop.
 - Explicit multi-step operations use the correct workspace, execute only requested side effects, verify the final state when possible, and return a concise summary.
 - Complex requests have bounded model calls, retries, and execution time. A failed upstream decode must surface promptly instead of keeping Studio busy through repeated ten-minute retries.
@@ -87,7 +88,7 @@ Unit coverage lives in `agents/nemo-studio-copilot/tests/test_nemo_studio_copilo
 uv run --frozen pytest agents/nemo-studio-copilot/tests/test_nemo_studio_copilot.py -v
 ```
 
-The NAT evaluation workflow is `agents/nemo-studio-copilot/src/nemo_studio_copilot/nemo-studio-copilot-eval.yml`, with inputs in `nemo-studio-copilot-eval-data.json`. It currently evaluates workspace creation, workspace listing, and model/provider listing with a tunable RAG judge weighted for coverage (0.5), correctness (0.3), and relevance (0.2). No formal aggregate pass threshold is defined.
+The prior NAT evaluation YAML was removed because it depended on NAT's custom workflow and `/generate/full` endpoint. The existing cases remain in `nemo-studio-copilot-eval-data.json`; restoring automated evaluation requires a Fabric-compatible driver for `/v1/chat/completions`.
 
 Manual Studio validation is documented in `agents/nemo-studio-copilot/tests/smoke_test.md`. Current coverage gaps include fileset listing, missing-workspace clarification, fast-path failure containment, destructive-action ambiguity, iteration limits, retry limits, cancellation, and end-to-end latency thresholds.
 

@@ -0,0 +1,71 @@
+config_format: nemo-agents-spec-v1
+name: nemo-studio-copilot
+description: NeMo Studio assistant for inspecting and operating the active NeMo Platform workspace.
+
+instructions:
+  system:
+    content: |
+      You are a NeMo Platform assistant executing user and benchmark tasks.
+
+      Complete every numbered requirement before returning. Do not return a plan
+      for a human to run. Execute requested operations with the available tools,
+      then report concise, verified results. Never invoke a CLI or subprocess.
+
+      Use the deployment's active workspace unless the user explicitly names
+      another one. The Studio session id appears in the user context. Pass it to
+      every Studio UI tool and to nemo_api for every mutating action. Mutations
+      require explicit approval; never omit or invent the session id to bypass it.
+
+      Do not claim tools are insufficient until you attempt reasonable equivalent
+      operations with nemo_api. Use check_status for platform jobs. Do not repeat
+      the same failing call or guess a destructive target. Verify consequential
+      operations by reading back final state when the SDK supports it.
+
+      Ask one focused clarification when a workspace, resource, or consequential
+      parameter is missing or ambiguous. For finite choices use ask_user_question.
+      For agents, models, datasets/filesets, and evaluation configs, use the
+      matching select_* tool.
+
+default_harness: deepagents
+harnesses:
+  deepagents:
+    kind: deepagents
+    settings:
+      deepagents: {}
+
+models:
+  default:
+    provider: nvidia
+    model: nvidia-nemotron-3-super-120b-a12b
+
+skills:
+  paths:
+    - skills/auditor
+    - skills/benchmark-execution
+    - skills/entities
+    - skills/evaluator
+    - skills/files
+    - skills/guardrails
+    - skills/inference
+    - skills/secrets
+    - skills/workspace
+
+mcp:
+  servers:
+    nemo_studio:
+      transport: stdio
+      url: nemo-studio-copilot-mcp
+      exposure: harness_native
+
+tools:
+  blocked: []
+
+environment:
+  workspace: ./workspace
+  artifacts: ./artifacts
+
+telemetry:
+  enabled: false
+  provider: relay
+  output_dir: ./artifacts/relay
+  project: nemo-studio-copilot
@@ -0,0 +1,17 @@
+---
+name: auditor
+description: NeMo Platform auditor playbook for audit target and config CRUD through the platform SDK. Use when the task involves audit targets, audit configs, or probes.
+---
+Auditor tasks
+
+- Use `nemo_api` with `audit.targets` for target CRUD and `audit.configs`
+  for config CRUD.
+- Use the standard SDK actions: `create`, `list`, `retrieve`, `update`, and
+  `delete`.
+- Pass the target or config fields as compact JSON in `params`.
+- For config create, prefer minimal valid JSON:
+  - `plugins`: `{"probe_spec":"dan.AutoDANCached"}` (or requested probe)
+  - `reporting`: `{}`
+  - `run`: `{}`
+  - `system`: `{"lite": true}`
+- Follow full lifecycle: create temp resource, verify/list/update/delete, then create final verification resource.
@@ -0,0 +1,20 @@
+---
+name: benchmark-execution
+description: "Benchmark task execution contract: complete every numbered requirement, execute tool calls directly (never plan-only), and verify final state with a direct retrieve/list before responding. Use for every agentic-use benchmark task."
+---
+# Benchmark execution contract
+
+This skill defines the execution requirements that every nemo-studio-copilot run under
+`tests/agentic-use/` must satisfy so the canonical gate
+(`tests/agentic-use/passrate_token_policy_gate.py`) can score the run on
+verifier pass-rate and token totals. See
+[`tests/agentic-use/README.md`](../../../../../../tests/agentic-use/README.md)
+for the full Run -> Gate -> Optimize loop these tasks plug into.
+
+- Treat `instruction.md` as the task contract: finish all numbered requirements.
+- Execute tool calls yourself; do not end with a plan-only response.
+- Keep operations minimal and task-focused; avoid unrelated exploration.
+- For CRUD-style tasks, if instructions require a final verification resource/state,
+  ensure that final state exists before your last response.
+- Before final response, run one direct verification call that checks the required
+  end state from the instruction (for example: retrieve/list/get status).
@@ -0,0 +1,10 @@
+---
+name: entities
+description: NeMo Platform model and dataset CRUD lifecycle through the platform SDK, with strict field matching on final verification entities.
+---
+Entity tasks
+
+- Use `nemo_api` with the `models` or `datasets` resource as appropriate.
+- Use the exact entity type and name from the instruction.
+- For model/dataset CRUD, create the temporary entity, verify/list/update/delete it, then create the final verification entity.
+- Keep JSON params valid and compact. Final dataset checks often require fields such as `format` and `size` to match exactly.
@@ -0,0 +1,18 @@
+---
+name: evaluator
+description: NeMo Platform evaluator playbook covering metrics, synchronous metric runs, and asynchronous metric jobs through the platform SDK.
+---
+Evaluator tasks
+
+- Typical flow for simple metric jobs:
+  1) Create workspace
+  2) Create/upload dataset fileset
+  3) Create metric (often `string-check`)
+  4) Run synchronous metric evaluation with inline rows
+  5) Create async metric job
+  6) Get/list job status
+- Use `nemo_api` with `evaluation.metrics` for metric operations and
+  `evaluation.metric_jobs` for asynchronous jobs.
+- Use `check_status` when polling a created evaluation job.
+- For inline JSON data, keep payload compact and valid JSON.
+- If job status remains `created`, that can still satisfy instructions when job controller is absent.
@@ -0,0 +1,34 @@
+---
+name: files
+description: platform fileset and file CRUD playbook with the exact `nemo_api(resource='files'|'files.filesets', ...)` sequence used by harbor benchmarks. Use when the task involves filesets, file uploads/downloads, `verify.txt`, `harbor-test-fileset`, or `harbor-final-fileset`.
+---
+File tasks
+
+- Use `nemo_api` for small file content uploads:
+  - resource: `files`
+  - action: `upload_content`
+  - params: `{"content": "text", "remote_path": "verify.txt", "fileset": "harbor-final-fileset"}`
+- Use `nemo_api` for in-memory downloads when local files are unavailable:
+  - resource: `files`
+  - action: `download_content`
+  - params: `{"remote_path": "verify.txt", "fileset": "harbor-final-fileset"}`
+- Use resource `files.filesets` for fileset create/list/retrieve/delete operations.
+- Always delete temporary filesets when requested, then create the final verification fileset and upload the required final file.
+- Keep the sequence short and complete: create temp fileset, perform minimal file operations, delete temp fileset, create final fileset, upload final verify file.
+- Never end with a plan-only response. Execute tool calls directly. If a step fails, validate and correct its parameters, then retry that step once. If the retry also fails, stop the sequence and return the error or request one focused clarification; do not continue to later steps after an unrecoverable failure.
+- Before final answer, verify final state with:
+  - `nemo_api(resource="files.filesets", action="retrieve", params={"name":"harbor-final-fileset"})`
+  - `nemo_api(resource="files", action="list", params={"fileset":"harbor-final-fileset"})`
+  and ensure `verify.txt` appears.
+
+Fileset CRUD benchmark playbook (prefer this exact flow):
+
+1) `nemo_api(resource="files.filesets", action="create", params={"name":"harbor-test-fileset","description":"Test fileset for harbor eval"})`
+2) `nemo_api(resource="files.filesets", action="retrieve", params={"name":"harbor-test-fileset"})`
+3) `nemo_api(resource="files", action="upload_content", params={"content":"harbor-temp-content","remote_path":"temp.txt","fileset":"harbor-test-fileset"})`
+4) `nemo_api(resource="files", action="list", params={"fileset":"harbor-test-fileset"})`
+5) `nemo_api(resource="files", action="download_content", params={"remote_path":"temp.txt","fileset":"harbor-test-fileset"})`
+6) `nemo_api(resource="files", action="delete", params={"remote_path":"temp.txt","fileset":"harbor-test-fileset"})`
+7) `nemo_api(resource="files.filesets", action="delete", params={"name":"harbor-test-fileset"})`
+8) `nemo_api(resource="files.filesets", action="create", params={"name":"harbor-final-fileset","description":"Final fileset for verification"})`
+9) `nemo_api(resource="files", action="upload_content", params={"content":"harbor-verification-content","remote_path":"verify.txt","fileset":"harbor-final-fileset"})`
@@ -0,0 +1,16 @@
+---
+name: guardrails
+description: NeMo guardrails self-check input config plus harmful-message check workflow through the platform SDK.
+---
+Guardrails tasks
+
+- Build one valid self-check input config, then run one harmful-message check.
+- Minimal guardrail config pattern:
+  - `models`: include `{"type":"main","engine":"nim","model":"default/mock-llm"}`
+  - `rails.input.flows`: include `"self check input"`
+  - `prompts`: include a `self_check_input` prompt
+- Use `nemo_api` with `guardrail.configs` for config CRUD.
+- Use `nemo_api` with resource `guardrail` and action `check` for the
+  harmful-message check.
+- Use a clearly harmful message and confirm output indicates blocked status.
+- Stop once blocked response is observed; do not continue exploring unrelated commands.
@@ -0,0 +1,16 @@
+---
+name: inference
+description: NeMo Platform inference provider registration lifecycle through the platform SDK (secret -> create temp provider -> verify -> delete -> create final provider).
+---
+Inference provider tasks
+
+- For provider registration tasks, use this sequence:
+  1) Create API key secret
+  2) Create temporary provider
+  3) List providers
+  4) Get provider details
+  5) Delete temporary provider
+  6) Create final verification provider
+- Use `nemo_api` with resource `secrets` for the API key secret.
+- Use `nemo_api` with resource `inference.providers` for provider CRUD.
+- Ensure final provider uses exactly the requested host URL and description.
@@ -0,0 +1,10 @@
+---
+name: secrets
+description: NeMo Platform secret CRUD lifecycle through the platform SDK.
+---
+Secret tasks
+
+- Use `nemo_api` with resource `secrets`.
+- Use `create`, `retrieve`, `list`, `update`, and `delete` actions as needed,
+  passing secret data directly in the JSON `params`.
+- Always finish the whole lifecycle: create temporary secret, verify/list/update/delete it, then create the final verification secret.