final pass

Author: anupras-mohapatra-arm

content/learning-paths/laptops-and-desktops/dgx_persistent_agent/1_introduce.md

@@ -1,5 +1,5 @@
 ---
-title: Expplore persistent AI runtime architecture on NVIDIA DGX Spark
+title: Explore persistent AI runtime architecture on NVIDIA DGX Spark
 description: Explore the persistent AI runtime architecture for NVIDIA DGX Spark, including Hermes Agent orchestration, Ollama inference, Qdrant memory, and CPU/GPU responsibilities.
 weight: 2
 

content/learning-paths/laptops-and-desktops/dgx_persistent_agent/2_build.md

@@ -102,7 +102,7 @@ You'll see a message confirming that Docker is installed and working.
 
 ### Install NVIDIA Container Toolkit
 
-The NVIDIA Container Toolkit enables Docker to expose the GPU to containers using the `--gpus` flag. Without it, containers can't access the GPU regardless of the driver version installed on the host.
+The NVIDIA Container Toolkit allows Docker to expose the GPU to containers using the `--gpus` flag. Without it, containers can't access the GPU regardless of the driver version installed on the host.
 
 Add the NVIDIA Container Toolkit GPG key:
 
@@ -148,7 +148,7 @@ nvcr.io/nvidia/cuda:13.0.1-devel-ubuntu24.04 \
 nvidia-smi
 ```
 
-If you have not pulled this image before, Docker downloads it before running `nvidia-smi`. This can take a few minutes depending on your network connection.
+If you have not pulled this image before, Docker downloads it before running `nvidia-smi`. The download can take a few minutes depending on your network connection.
 
 The output is similar to:
 
@@ -354,7 +354,7 @@ docker compose up -d
 ```
 
 {{% notice Note %}}
-The first `docker compose up -d` run can take several minutes because Docker needs to pull the service images. The time depends on your network speed.
+The first `docker compose up -d` run can take several minutes, depending on your network speed, because Docker needs to pull the service images.
 {{% /notice %}}
 
 Verify that the containers are running:
@@ -435,13 +435,13 @@ exit
 
 These model names are used throughout the examples, so make note of them. The architecture supports other suitable models.
 
-Because the `models/` directory is mounted into the container as a volume, downloaded models are stored on the host at `~/dgx-hermes-agent/models/` and persist even if the container is removed or recreated.
-
 | Model | Purpose |
 |---|---|
 | `qwen2.5:7b` | Local chat, summarization, reasoning |
 | `nomic-embed-text` | Embedding generation for semantic memory |
 
+Because the `models/` directory is mounted into the container as a volume, downloaded models are stored on the host at `~/dgx-hermes-agent/models/`. The models persist even if the container is removed or recreated.
+
 ### Verify local inference
 
 Open a shell in the Ollama container:

content/learning-paths/laptops-and-desktops/dgx_persistent_agent/3_deploy_orch_runtime.md

@@ -9,9 +9,7 @@ layout: "learningpathall"
 
 In this section, you'll add Hermes Agent to the runtime stack.
 
-Hermes Agent acts as the orchestration layer for the local AI runtime. It watches the workspace, detects runtime events, and coordinates the next action without requiring a user to manually run each step.
-
-Hermes is the CPU-side orchestration runtime. It runs continuously, watches the shared workspace, and reacts when new files are created. This is the first step toward a persistent local AI agent.
+Hermes Agent acts as the CPU-side orchestration layer for the local AI runtime. It watches the workspace, detects runtime events, and coordinates the next action without requiring a user to manually run each step. This is the first step toward a persistent local AI agent.
 
 In this section, Hermes doesn't call a language model yet. You'll first build the event-driven runtime foundation, where a new file in `workspace/inbox/` triggers a filesystem event, Hermes handles it, and prints a content preview to the logs.
 
@@ -252,7 +250,7 @@ mv /tmp/runtime-test.txt \
 ```
 Doing this avoids triggering the filesystem event before the file content has finished writing.
 
-Return to the terminal that is following Hermes logs. 
+Return to the terminal that's following Hermes logs. 
 
 The output is similar to:
 
@@ -278,7 +276,9 @@ This shared mount is what allows the host, Hermes, Ollama, and later memory work
 
 ## Understand CPU orchestration responsibilities
 
-This section demonstrates the CPU-side work required by persistent AI systems. The Arm CPU runs the long-lived service process, monitors filesystem events, schedules runtime activity, processes files, and manages the containerized service lifecycle. The GPU becomes important when model inference is added, but the persistent runtime is coordinated entirely by the CPU.
+This section shows the CPU-side work required by persistent AI systems. The Arm CPU runs the long-lived service process and monitors filesystem events. It schedules runtime activity, processes files, and manages the containerized service lifecycle. 
+
+The GPU becomes important when model inference is added, but the persistent runtime is coordinated entirely by the CPU.
 
 ## What you've accomplished and what's next
 
@@ -288,4 +288,4 @@ You also verified that creating a new file in `workspace/inbox/` triggers Hermes
 
 Next, you'll connect Hermes to Ollama for local LLM summarization.
 
-Before moving to the next section, press `Ctrl+C` in terminal 1 to stop the Hermes log stream. In the next section, you'll rebuild the Hermes container and run `docker logs -f hermes` again.
+Before moving to the next section, press `Ctrl+C` in the first terminal running Hermes logs to stop the Hermes log stream. In the next section, you'll rebuild the Hermes container and run `docker logs -f hermes` again.

content/learning-paths/laptops-and-desktops/dgx_persistent_agent/4_local_llm.md

@@ -22,7 +22,7 @@ workspace/inbox document
     -> Local LLM summary
 ```
 
-This introduces the first GPU-accelerated step in the persistent runtime.
+Connecting Hermes Agent to Ollama introduces the first GPU-accelerated step in the persistent runtime.
 
 ### Configure Ollama runtime access
 
@@ -215,9 +215,9 @@ mv /tmp/ai-runtime-note.txt \
 ~/dgx-hermes-agent/workspace/inbox/ai-runtime-note.txt
 ```
 
-Return to terminal 1 to see the Hermes log output. 
+Return to the first terminal running Hermes logs to see the Hermes log output. 
 
-The output similar to:
+The output is similar to:
 
 ```output
 [Agent] New file detected:
@@ -252,13 +252,15 @@ mv /tmp/gpu-inference-test.txt \
 nvtop
 ```
 
-The background command creates the file after five seconds, giving `nvtop` time to start before Ollama begins inference. During summarization, `nvtop` shows GPU activity from the Ollama model runtime. Watch the terminal running Hermes logs to see the Hermes log output as inference runs.
+The background command creates the file after five seconds, giving `nvtop` time to start before Ollama begins inference. During summarization, `nvtop` shows GPU activity from the Ollama model runtime. Watch the first terminal running Hermes logs to see the Hermes log output as inference runs.
 
 Press `q` to quit `nvtop` after reviewing the GPU activity.
 
 ## Understand CPU and GPU responsibilities
 
-The Arm Grace CPU coordinates the full workflow: watching the workspace, handling filesystem events, reading files, preparing model requests, and sending API calls to Ollama. The Blackwell GPU accelerates the model workload, running LLM inference, generating tokens, and producing the summary. This pattern repeats throughout the Learning Path. Hermes orchestrates and Ollama executes.
+The Arm Grace CPU coordinates the full workflow: watching the workspace, handling filesystem events, reading files, preparing model requests, and sending API calls to Ollama. 
+
+The Blackwell GPU accelerates the model workload, running LLM inference, generating tokens, and producing the summary. This pattern repeats throughout the Learning Path. Hermes orchestrates and Ollama executes.
 
 ## What you've accomplished and what's next
 
@@ -268,4 +270,4 @@ The runtime has moved from file detection to event-driven AI summarization.
 
 Next, you'll add persistent semantic memory with embeddings and Qdrant.
 
-Before moving to the next section, press `Ctrl+C` in the terminal running Hermes logs to stop the Hermes log stream. In the next section, you'll rebuild the Hermes container and run `docker logs -f hermes` again.
+Before moving to the next section, press `Ctrl+C` in the first terminal running Hermes logs to stop the Hermes log stream. In the next section, you'll rebuild the Hermes container and run `docker logs -f hermes` again.

content/learning-paths/laptops-and-desktops/dgx_persistent_agent/5_persistent_memory.md

@@ -23,7 +23,7 @@ workspace/inbox document
     -> persistent semantic memory
 ```
 
-This turns Hermes from an event-driven summarizer into a local AI runtime with long-term memory.
+Adding persistent memory turns Hermes from an event-driven summarizer into a local AI runtime with long-term memory.
 
 ### Understand persistent memory architecture
 
@@ -237,7 +237,7 @@ if __name__ == "__main__":
 
 #### Understand the code trace
 
-Hermes connects to Qdrant using the Docker service name `qdrant`, read from the `QDRANT_HOST` environment variable with a default fallback. On startup, `ensure_collection()` creates the `workspace_memory` collection if it does not already exist, configured with a vector size of 768 and cosine distance to match the `nomic-embed-text` model output.
+Hermes connects to Qdrant using the Docker service name `qdrant`, read from the `QDRANT_HOST` environment variable with a default fallback. On startup, `ensure_collection()` creates the `workspace_memory` collection if it doesn't already exist, configured with a vector size of 768 and cosine distance to match the `nomic-embed-text` model output.
 
 When a file is detected, `process_file()` calls `generate_summary()` and then `generate_embedding()` in sequence. The embedding uses `client.embed()` from the current Ollama Python SDK, and the result is read from `response["embeddings"][0]`. Hermes stores each document as a Qdrant `PointStruct` with the vector and a payload containing the file path, generated summary, and source content excerpt. The payload makes sure that future retrieval results include the document context needed to answer workspace queries.
 
@@ -276,7 +276,7 @@ vectors_config=VectorParams(
 )
 ```
 
-If you change the embedding model later, update the Qdrant collection dimension to match the new model output. If the dimensions do not match, Qdrant will reject the inserted vectors.
+If you change the embedding model later, update the Qdrant collection dimension to match the new model output. If the dimensions don't match, Qdrant will reject the inserted vectors.
 
 ### Rebuild Hermes
 
@@ -327,7 +327,7 @@ mv /tmp/memory-test.txt \
 ~/dgx-hermes-agent/workspace/inbox/memory-test.txt
 ```
 
-Watch the terminal running Hermes logs for the Hermes log output. 
+Watch the first terminal running Hermes logs for the Hermes log output. 
 
 The memory ingestion output is similar to:
 
@@ -361,9 +361,9 @@ http://localhost:6333/dashboard
 
 Confirm that the `workspace_memory` collection exists:
 
-![Qdrant dashboard showing the workspace_memory collection#center](qdrant_dashboard_2.png "Qdrant Dashboard")
+![Qdrant dashboard showing the workspace_memory collection, confirming that Hermes created the collection#center](qdrant_dashboard_2.png "Qdrant Dashboard")
 
-The dashboard shows the `workspace_memory` collection after Hermes starts and runs `ensure_collection()`. If the collection does not appear, check the Hermes logs for Qdrant connection errors and confirm that the `qdrant` container is running.
+The dashboard shows the `workspace_memory` collection after Hermes starts and runs `ensure_collection()`. If the collection doesn't appear, check the Hermes logs for Qdrant connection errors and confirm that the `qdrant` container is running.
 
 Open the collection and verify that points are being stored. Each point represents one ingested workspace document and contains:
 
@@ -372,13 +372,13 @@ Open the collection and verify that points are being stored. Each point represen
 - A `summary` payload field
 - A `content` payload field
 
-![Qdrant workspace_memory collection showing stored vectors and payload fields#center](qdrant_dashboard_3.png "Qdrant workspace_memory")
+![Qdrant workspace_memory collection showing stored vectors and payload fields#center](qdrant_dashboard_3.png "Qdrant workspace_memory vector and payload view")
 
 Use this view to confirm that Qdrant has stored both the vector and payload metadata. The payload fields are important because later retrieval steps need the path and summary to assemble useful context for the LLM.
 
 You can also inspect collection storage and memory usage:
 
-![Qdrant collection storage view showing persistent memory usage#center](qdrant_dashboard_4.png "Qdrant workspace_memory")
+![Qdrant collection storage view showing persistent memory usage#center](qdrant_dashboard_4.png "Qdrant workspace_memory memory usage view")
 
 The memory usage view confirms that Qdrant is maintaining persistent collection state on disk. This matters because the vector memory survives container restarts as long as the `../qdrant:/qdrant/storage` volume remains mounted.
 
@@ -388,7 +388,7 @@ You can also inspect collections from the host:
 curl http://localhost:6333/collections
 ```
 
-The response is similar to:
+The output is similar to:
 
 ```output
 {"result":{"collections":[{"name":"workspace_memory"}]},"status":"ok","time":0.0001}
@@ -408,4 +408,4 @@ The runtime can now ingest documents, summarize them, generate embeddings, and p
 
 Next, you'll add semantic retrieval and contextual question answering.
 
-Before moving to the next section, press `Ctrl+C` in terminal 1 to stop the Hermes log stream. In the next section, you'll rebuild the Hermes container and run `docker logs -f hermes` again.
+Before moving to the next section, press `Ctrl+C` in the first terminal running Hermes logs to stop the Hermes log stream. In the next section, you'll rebuild the Hermes container and run `docker logs -f hermes` again.

content/learning-paths/laptops-and-desktops/dgx_persistent_agent/6_semantic_retrieval.md

@@ -276,7 +276,7 @@ The main runtime loop checks for `/workspace/query.txt` on each iteration. When
 
 #### Understand runtime compatibility considerations
 
-Use `qdrant.query_points()` with `query=embedding` when calling the vector search API. Older examples use `query_vector=embedding`, which is not compatible with current versions of the Qdrant Python client. Read each result's payload with `result.payload` before assembling the retrieval context.
+Use `qdrant.query_points()` with `query=embedding` when calling the vector search API. Older examples use `query_vector=embedding`, which isn't compatible with current versions of the Qdrant Python client. Read each result's payload with `result.payload` before assembling the retrieval context.
 
 The `limit=3` value in `search_memory()` is hardcoded to keep the retrieval behavior easy to inspect. You can make it configurable later.
 
@@ -358,7 +358,7 @@ mv /tmp/semantic-memory-note.txt \
 ~/dgx-hermes-agent/workspace/inbox/semantic-memory-note.txt
 ```
 
-Watch the terminal running Hermes logs until each document is summarized, embedded, and stored.
+Watch the first terminal running Hermes logs until each document is summarized, embedded, and stored.
 
 The output is similar to:
 
@@ -405,7 +405,7 @@ The output is similar to:
 
 ### Test semantic retrieval
 
-In terminal 2, create a query file:
+In the second terminal, create a query file:
 
 ```bash
 echo "How do CPUs help persistent AI systems?" \
@@ -414,13 +414,17 @@ echo "How do CPUs help persistent AI systems?" \
 
 Hermes checks for `/workspace/query.txt` in the runtime loop. When it sees the file, it reads the question and removes the file. It then embeds the question, searches Qdrant, and sends the retrieved context to Ollama.
 
-In terminal 1, confirm that semantic search started:
+In the first terminal running Hermes logs, confirm that semantic search started.
+
+The output is similar to:
 
 ```output
 [Memory] Searching semantic memory...
 ```
 
-Then confirm that Hermes printed the question and the retrieved memory context:
+Then confirm that Hermes printed the question and the retrieved memory context.
+
+The output is similar to:
 
 ```output
 [Workspace Query]
@@ -469,7 +473,7 @@ The exact answer will vary, but it should refer to retrieved memory about CPU or
 
 ### Verify contextual reasoning
 
-In terminal 2, ask a second question:
+In the second terminal, ask another question:
 
 ```bash
 echo "Why does the runtime need semantic memory?" \
@@ -511,28 +515,14 @@ Summary:
 The runtime needs semantic memory because it retains embeddings and metadata that store relevant context from past workspace activities. This allows the system to effectively reason by retrieving pertinent information, enhancing its ability to understand and respond to new inputs more intelligently. Unlike simple keyword matching, semantic memory uses a vector database which captures the meaning of words or concepts, enabling more accurate and contextualized recall of past events or knowledge.
 ```
 
-## Understand the retrieval workflow
-
-The full retrieval workflow is:
-
-```output
-query.txt question
-    -> Ollama query embedding
-    -> Qdrant workspace_memory search
-    -> retrieved summaries
-    -> Hermes context prompt
-    -> Ollama contextual response
-    -> Hermes log output
-```
-
-This creates a local contextual reasoning loop using persistent memory.
-
 ## Understand CPU and GPU responsibilities
 
 The Arm Grace CPU coordinates the retrieval workflow: watching for `query.txt`, reading and deleting the query file, calling Ollama for the query embedding, searching Qdrant for relevant memories, parsing result payloads, assembling the retrieved context, and calling Ollama again for contextual reasoning.
 
 The Blackwell GPU accelerates query embedding generation, contextual LLM inference, and response generation. Qdrant performs the vector similarity search and returns the most relevant memory payloads.
 
+This retrieval workflow creates a local contextual reasoning loop using persistent memory.
+
 ## What you've accomplished and what's next
 
 You've added semantic retrieval and contextual reasoning to Hermes Agent. The runtime now turns a question into an embedding, searches Qdrant with `query_points(...)`, assembles retrieved memory, and sends that context to `qwen2.5:7b`.
@@ -541,4 +531,4 @@ The runtime can now store memory and reason over it through the local `/workspac
 
 Next, you'll add autonomous workspace cognition.
 
-Before moving to the next section, press `Ctrl+C` in terminal 1 to stop the Hermes log stream. In the next section, you'll rebuild the Hermes container and run `docker logs -f hermes` again.
+Before moving to the next section, press `Ctrl+C` in the first terminal running Hermes logs to stop the Hermes log stream. In the next section, you'll rebuild the Hermes container and run `docker logs -f hermes` again.