Chapter 56: Meet Your Personal AI Employee Quiz

Test your understanding of AI Employee architecture, OpenClaw platform mastery, security models, deployment patterns, and production readiness across all 16 lessons.

<Quiz title="Chapter 56 Assessment" questions={[ { question: "Your AI Employee sends a heartbeat every 30 minutes, checks a task list, and sends follow-ups without being asked. Which of the five AI Employee dimensions does this demonstrate?", options: [ "Multi-channel", "Always-on", "Proactive", "Extensible" ], correctOption: 2, explanation: "The proactive dimension means the agent acts on its own schedule through heartbeats and cron jobs instead of waiting for a prompt. Multi-channel is about reaching people on WhatsApp, Discord, and other platforms simultaneously. Always-on means the gateway runs 24/7 as a local service, which is a precondition for proactive behavior but not the same thing. Extensible is about plugins, MCP, and custom hooks.", source: "Lesson 1: The AI Employee Moment" }, { question: "After installing OpenClaw, the gateway restarts 18 times in 10 minutes. The log repeats 'Gateway start blocked.' What is the most likely cause?", options: [ "The gateway.mode config is not set", "The API key has expired", "WhatsApp QR code timed out", "Node.js version is incompatible" ], correctOption: 0, explanation: "The crash loop occurs because gateway.mode is not configured. The LaunchAgent starts the gateway before the configuration is complete, creating a crash-restart cycle. The fix is one command: openclaw config set gateway.mode local. An expired API key would cause model failures, not startup crashes. QR timeout affects WhatsApp pairing, not gateway startup. Node.js version issues would be caught by the installer or openclaw doctor.", source: "Lesson 2: Install & Connect Your Employee" }, { question: "You rotate your Anthropic API key and set the new key as an environment variable. The agent still uses the old key. What should you do?", options: [ "Restart the gateway process", "Reinstall OpenClaw from scratch", "Clear the WhatsApp session cache", "Delete auth-profiles.json and reconfigure" ], correctOption: 3, explanation: "OpenClaw caches credentials in auth-profiles.json, which takes priority over environment variables. Deleting this cache file forces OpenClaw to use the new credentials. Restarting the gateway does not clear the cache. Reinstalling is unnecessary since only the cache needs clearing. WhatsApp session cache is unrelated to model provider authentication.", source: "Lesson 2: Install & Connect Your Employee" }, { question: "You ask your agent to book a flight, but it fails. You ask it to draft an email, and it succeeds. What explains this difference?", options: [ "The agent's memory was full", "Tool profiles restrict available tools", "The model refused the request", "The WhatsApp channel dropped the message" ], correctOption: 1, explanation: "Tool profiles determine which tools the agent can access. The messaging profile provides a limited set of tools suitable for communication tasks like email drafts. Flight booking requires external API access or browser tools not available in the messaging profile. Agent memory does not affect tool availability. Model refusal would apply to both tasks. WhatsApp dropping a message would prevent any response entirely.", source: "Lesson 3: Delegate Real Work" }, { question: "Your workspace files total 350 lines. After optimization, they total 67 lines. What is the primary benefit of this reduction?", options: [ "The agent responds in a different language", "The gateway starts up more quickly", "Fewer tokens consumed on every message", "More plugins can be loaded simultaneously" ], correctOption: 2, explanation: "Workspace files (SOUL.md, IDENTITY.md, AGENTS.md, TOOLS.md, USER.md) load into context on every message. At 350 lines, roughly 2,000 tokens are consumed before the customer speaks. At 67 lines, this drops by 80%. The savings compound across every interaction. Language is set by content, not file size. Gateway startup is not affected by workspace file length. Plugin loading is independent of workspace size.", source: "Lesson 4: Customize Your Employee's Brain" }, { question: "HEARTBEAT.md loads at a different time than SOUL.md. When does HEARTBEAT.md load?", options: [ "Only during 30-minute heartbeat cycles", "Once during gateway startup only", "On every incoming customer message", "When the operator manually triggers it" ], correctOption: 0, explanation: "HEARTBEAT.md loads only during the 30-minute heartbeat cycle, not on every message. This is a deliberate optimization: heartbeat instructions are irrelevant to customer conversations and would waste tokens if loaded every time. SOUL.md, IDENTITY.md, AGENTS.md, TOOLS.md, and USER.md load on every message. BOOTSTRAP.md loads once and should be deleted after use. Manual triggering is not how heartbeat loading works.", source: "Lesson 4: Customize Your Employee's Brain" }, { question: "You search ClawHub expecting thousands of skills. You find approximately 100. Where is the real ecosystem?", options: [ "In the OpenClaw GitHub repository issues", "In the dozens of bundled plugins shipped with OpenClaw", "In third-party npm packages for agents", "In the community Discord server downloads" ], correctOption: 1, explanation: "OpenClaw ships dozens of bundled plugins (roughly half loaded, the rest disabled by default). These cover messaging channels, voice, browser autonomy, security tools, and more. The bundled plugins ARE the ecosystem. ClawHub is real but young with roughly 100 community skills. The GitHub issues page is for bug reports, not skill distribution. npm packages and Discord downloads are not official distribution channels for OpenClaw capabilities.", source: "Lesson 8: Plugins, Bundles & The Decision Tree" }, { question: "You configure an MCP server using a URL endpoint. Nothing happens. No error appears in chat. What went wrong?", options: [ "The remote MCP server is not running or the URL is wrong", "The agent's tool profile blocks MCP tools", "WhatsApp cannot forward MCP tool results", "OpenClaw does not support streamable-http transport at all" ], correctOption: 0, explanation: "OpenClaw supports both stdio (command + args) and streamable-http (url) MCP transports. A URL endpoint is valid configuration for a remote server. However, if the remote server is not running or the URL is wrong, the failure is silent: no error appears in chat, only in the gateway debug log. The MCP server being down is the most likely cause here. Tool profiles do not specifically block MCP tools. WhatsApp handles MCP results normally.", source: "Lesson 7: Connect External Tools" }, { question: "You want 5 daily checks: email, calendar, tasks, weather, and news. You create 5 separate cron jobs. What is the cost problem?", options: [ "Cron jobs cannot run in parallel", "The gateway blocks more than 3 cron jobs", "Each cron creates a full agent session with token costs", "Cron output cannot be delivered to channels" ], correctOption: 2, explanation: "Each cron job creates its own agent session, loading workspace files and consuming tokens independently. Five cron jobs means five full sessions per cycle, roughly 5x the token cost. A single heartbeat with a 5-item checklist achieves the same outcome for 1x the cost. Cron jobs can run with configurable concurrency. There is no 3-cron limit. Cron output is delivered to configured channels normally.", source: "Lesson 9: Make It Proactive" }, { question: "You enable TTS in 'always' mode. Every reply arrives as a voice note, including confirmations like 'Done.' What mode fixes this?", options: [ "Tagged mode where the agent decides when to speak", "Inbound mode for voice responses only", "Off mode with manual voice note sending", "Priority mode for important messages only" ], correctOption: 0, explanation: "Tagged mode lets the agent decide when voice is appropriate using [[tts]] directives in its response. The agent speaks for descriptions and explanations, types for confirmations and short answers. You add instructions to SOUL.md telling the agent when voice adds value. Inbound mode responds with voice only when the customer sends a voice note. Off mode disables TTS entirely. Priority mode does not exist in OpenClaw.", source: "Lesson 10: Give It a Voice" }, { question: "You create a second agent and set its identity, but messages still go to the main agent. What did you likely forget?", options: [ "The second agent needs its own API key", "Identity changes take effect on new sessions only", "Both agents cannot share the same WhatsApp number", "The second agent must be on a different VPS" ], correctOption: 1, explanation: "Identity changes take effect on new sessions only due to session caching. Starting a new conversation with the agent triggers the updated identity. Both agents can share the same WhatsApp number with routing rules. Each agent does not need its own API key; they share the model provider. Both agents run on the same gateway, not separate infrastructure.", source: "Lesson 11: Add a Second Agent" }, { question: "Five customers message your agent in the same second. What happens to the fifth customer's message?", options: [ "It is dropped and the customer gets no response", "All five process in parallel with no delay", "It triggers a rate limit error on WhatsApp", "It queues for about 3-8 seconds until one of the first four finishes" ], correctOption: 3, explanation: "OpenClaw uses a two-layer queue: session lanes (maxConcurrent=1 per customer for sequential ordering) feed into a global lane (maxConcurrent=4 across customers). The first four messages process in parallel. The fifth queues in the global lane and starts when the fastest of the four completes, typically 3-8 seconds. Messages are never dropped due to concurrency. The default allows 4 parallel, not 5. WhatsApp does not rate limit incoming messages at this volume.", source: "Lesson 13: Orchestrate Other Agents" }, { question: "You run openclaw security audit and get 2 critical findings. How many commands does it take to reach zero criticals?", options: [ "Two commands: groupPolicy allowlist and credentials chmod", "One command that auto-fixes everything", "Five commands covering each security layer", "Zero commands because criticals resolve on restart" ], correctOption: 0, explanation: "Two commands take you from 2 criticals to zero: setting the WhatsApp group policy to allowlist and fixing credential file permissions with chmod 700. The security audit has an auto-fix option but not all issues are auto-fixable. Five commands would be excessive for the two specific criticals. Gateway restart does not resolve security configuration issues.", source: "Lesson 15: Deploy to Production" }, { question: "Your plugin uses api.registerHook('before_tool_call', handler). It compiles. The hook never fires. What should you use instead?", options: [ "api.addHook('before_tool_call', handler) for newer versions", "api.registerHook with the internal.enabled config flag", "api.on('before_tool_call', handler) which uses the typed hook system", "api.createHook('before_tool_call', handler) for custom hooks" ], correctOption: 2, explanation: "api.on() is the typed hook system that feeds into registry.typedHooks, which is what lifecycle hooks actually check. api.registerHook() is the legacy untyped system that requires additional config flags and a name property to function. While registerHook can work with specific configuration, api.on() is the correct and reliable approach. api.addHook and api.createHook do not exist in the OpenClaw API.", source: "Lesson 14: Gate Your Agent's Tools" }, { question: "You write a before_tool_call hook to gate the bash tool. It never triggers. You check the log and see the tool name is different. What is the actual tool name?", options: [ "shell for all command execution", "exec after internal normalization", "terminal for interactive sessions", "cmd for Windows compatibility" ], correctOption: 1, explanation: "OpenClaw normalizes the bash tool name to exec internally via normalizeToolName(). If you write a hook checking for 'bash', it never matches because the runtime uses 'exec'. The first step when writing tool hooks is to log the actual toolName from the event. shell, terminal, and cmd are not used by OpenClaw's tool name normalization.", source: "Lesson 14: Gate Your Agent's Tools" }, { question: "You build a requireApproval hook for core tools. A customer triggers an MCP tool that contacts an external API. The approval flow does not fire. Why?", options: [ "The requireApproval hook only works on WhatsApp", "MCP tools are automatically approved by the gateway", "The customer does not have approval permissions", "MCP tools bypass the before_tool_call hook pipeline" ], correctOption: 3, explanation: "MCP tools are appended to the tool list after hook wrapping occurs in pi-tools.ts. This means before_tool_call hooks, including requireApproval, do not intercept MCP tool calls. This is a known architectural gap. If you need approval on MCP operations, the gate must be inside the MCP server itself. The hook works on all channels, not just WhatsApp. MCP tools are not auto-approved; they skip the pipeline entirely. Customer permissions are not relevant here.", source: "Lesson 14: Gate Your Agent's Tools" }, { question: "During Docker Compose deployment, the .env file contains literal ${OPENCLAW_GATEWAY_TOKEN} instead of the actual token value. What caused this?", options: [ "The openssl command failed to generate a token", "Docker Compose does not support environment variable expansion", "The setup script ran in a non-interactive SSH session where heredocs fail", "The gateway token must be set manually before running setup.sh" ], correctOption: 2, explanation: "Heredoc expansion behaves differently in non-interactive SSH sessions or restricted shells. Variables that should expand remain literal. The fix is to SSH in properly and get an interactive bash session before running setup.sh. openssl token generation is independent of heredoc issues. Docker Compose supports env vars normally. The token is auto-generated; manual setting is not required.", source: "Lesson 15: Deploy to Production" }, { question: "Your VPS gateway binds to 127.0.0.1 and you access the Control UI through an SSH tunnel. Why is no TLS certificate needed?", options: [ "SSH provides the encryption and the key provides authentication", "The Control UI does not transmit sensitive data", "Docker encrypts all container traffic automatically", "Hetzner provides managed TLS for all VPS instances" ], correctOption: 0, explanation: "The SSH tunnel provides both encryption (tunnel IS the encryption) and authentication (SSH key IS the authentication). The loopback binding ensures nothing outside the VPS can reach the gateway directly. Together, these replace the need for TLS certificates, reverse proxies, and API gateways. The Control UI does handle sensitive data including config and tokens. Docker does not encrypt container traffic by default. Hetzner does not provide managed TLS.", source: "Lesson 15: Deploy to Production" }, { question: "You skip the onboarding wizard (Step 6) during Docker Compose setup. The gateway starts, the Control UI loads, but the agent never responds. Why?", options: [ "The WhatsApp channel is not connected", "No model provider is configured so inference fails silently", "The security audit has not been run yet", "The gateway token was not generated properly" ], correctOption: 1, explanation: "Skipping the onboarding wizard means no model provider is configured. The gateway runs, serves the Control UI, accepts connections, but every agent request fails because there is no model to send inference to. The error is deep in the agent loop, not at startup. WhatsApp connection is separate from model configuration. The security audit is not required for basic functionality. The gateway token affects Control UI authentication, not agent responses.", source: "Lesson 15: Deploy to Production" }, { question: "In NemoClaw's 4-pod architecture, which pod holds the API keys?", options: [ "The Sandbox pod where the agent runs", "The Gateway pod that handles channel routing", "The Policy Engine pod that enforces restrictions", "The Privacy Router pod that forwards model requests" ], correctOption: 3, explanation: "The Privacy Router pod is the API key vault. It holds all provider credentials and adds them to requests before forwarding to model APIs. The Sandbox pod has the agent but explicitly has NO API keys. The Gateway pod handles channels and routing, not credentials. The Policy Engine enforces filesystem, syscall, and network restrictions but does not store API keys.", source: "Lesson 16: Isolate with NemoClaw" }, { question: "An attacker gains root access inside the NemoClaw sandbox pod. They run printenv, scan the filesystem, and sniff network traffic. What can they steal?", options: [ "Nothing because the keys are in a separate pod and network namespace", "API keys from the environment variables", "Credentials from the privacy router config file", "The gateway authentication token from the Control UI" ], correctOption: 0, explanation: "The sandbox pod has no API keys in its environment, filesystem, or network traffic. The agent calls inference.local without credentials; the router adds the real key in a separate network namespace. Even with full root access, the attacker cannot reach the router's credential store. The worst they can do is abuse inference through inference.local, which rate limiting handles. The gateway token is also not in the sandbox pod.", source: "Lesson 16: Isolate with NemoClaw" }, { question: "What type of enforcement does NemoClaw's Policy Engine use to restrict the sandbox?", options: [ "Application-level JavaScript checks in Node.js", "Cloud provider firewall rules managed by Hetzner", "Kernel-level primitives: Landlock, seccomp, and network namespaces", "Docker container labels that restrict process capabilities" ], correctOption: 2, explanation: "The Policy Engine uses Linux kernel primitives: Landlock for filesystem access control, seccomp for system call filtering, and network namespaces for routing isolation. These are enforced by the kernel, not by the application. The agent cannot override them because they are in a different process. Application-level JavaScript checks are what tool profiles use (Tier 1). Cloud provider rules and Docker labels are not how NemoClaw enforces policy.", source: "Lesson 16: Isolate with NemoClaw" }, { question: "The NemoClaw sandbox has a default-deny network policy. The agent needs to reach the Discord API. How does the operator allow it?", options: [ "The agent requests permission through a chat message", "Discord is allowed by default for all sandbox configurations", "The agent modifies its own network policy file", "The operator adds the discord policy preset" ], correctOption: 3, explanation: "Operators add presets through the OpenShell TUI or CLI. The discord preset allows outbound connections to Discord gateway and API endpoints. The agent cannot approve its own network access because the policy engine is in a different pod. Discord is not allowed by default; the default policy is deny-all except inference.local. The agent cannot modify policy because it runs in a separate network namespace with no access to the policy configuration.", source: "Lesson 16: Isolate with NemoClaw" }, { question: "Every OpenClaw capability follows a 4-step pattern. What is the correct order of the Activation Dance?", options: [ "Install from ClawHub, restart gateway, set permissions, test manually", "Write the plugin code, compile it, register hooks, deploy to production", "Bundled plugin exists, disabled by default, enable via config, configure settings", "Enable the feature flag, set the API key, bind to channel, verify in logs" ], correctOption: 2, explanation: "The Activation Dance is: (1) bundled plugin exists in extensions/, (2) disabled by default for security, (3) enable via plugins.entries..enabled = true, (4) configure feature-specific settings. Restart the gateway after step 3. This pattern applies to every capability: voice, skills, security tools, and custom plugins. Installing from ClawHub is a different workflow. Writing plugin code is the producer side (Lesson 14). Feature flags are not how OpenClaw manages capabilities.", source: "Lesson 2: Install & Connect Your Employee" }, { question: "After a Hetzner deploy, the Control UI prompts for a gateway token. You paste the one from your local .env file and login fails every time. What went wrong?", options: [ "The production gateway generates its own token during setup; the local .env token is not used remotely", "SSH tunnels cannot forward authentication headers, so tokens are always rejected", "Gateway tokens expire one hour after install and must be refreshed daily", "Docker Compose strips the token from the environment when containers restart" ], correctOption: 0, explanation: "The setup script generates a fresh gateway token on the server during install and writes it to the production .env. Your local development token is unrelated. Read the production token from the server (cat .env on the host or via the CLI) and paste that one into the Control UI. SSH tunnels forward TCP transparently including auth headers. Tokens do not expire on a fixed schedule. Docker Compose preserves environment variables across restarts via env_file.", source: "Lesson 15: Deploy to Production" }, { question: "Your agent writes SOUL.md content like 'You are the world's best assistant at everything.' What does Emma's feedback reveal about this approach?", options: [ "The personality is too generic to be useful", "Every word costs tokens on every single message", "The agent ignores SOUL.md content entirely", "SOUL.md only loads during heartbeat cycles" ], correctOption: 1, explanation: "SOUL.md loads into context on every incoming message. Verbose, generic personality descriptions waste tokens without improving agent behavior. The optimization exercise in Lesson 4 reduced total workspace from 350 to 67 lines, saving 80% of per-message token costs. The personality issue matters too, but the token cost is the quantifiable problem. The agent does use SOUL.md content. SOUL.md loads on every message, not just heartbeats.", source: "Lesson 4: Customize Your Employee's Brain" }, { question: "What is the relationship between OpenClaw and NemoClaw?", options: [ "NemoClaw is a competitor that replaces OpenClaw", "NemoClaw is a newer version of OpenClaw with better performance", "NemoClaw is a deployment pattern wrapping OpenClaw in NVIDIA's OpenShell sandbox", "NemoClaw is a mobile app for managing OpenClaw agents" ], correctOption: 2, explanation: "NemoClaw = OpenClaw + OpenShell + Privacy Router + Policy Engine. It is not a fork, not a competitor, and not a new version. It is the deployment pattern where OpenClaw runs inside NVIDIA's OpenShell sandbox infrastructure for out-of-process policy enforcement and API key isolation. The same agent, same workspace files, same skills, different security architecture.", source: "Lesson 16: Isolate with NemoClaw" }, { question: "The Activation Dance is first taught in Lesson 2. By Lesson 14, the student's relationship to this pattern has changed. How?", options: [ "The student writes a plugin that others activate through the same dance", "The student disables the dance for faster development", "The student replaces the dance with direct API calls", "The student automates the dance with a shell script" ], correctOption: 0, explanation: "In Lesson 2, the student is a consumer of the Activation Dance (enabling bundled capabilities). By Lesson 14, the student builds a custom plugin that follows the same pattern: it must be discovered via load.paths, enabled via entries, and configured. The student goes from consumer to producer. The dance cannot be disabled as it is the platform's security design. Direct API calls and shell scripts do not replace the pattern.", source: "Lesson 14: Gate Your Agent's Tools" }, { question: "You want your agent to act on its own schedule. You have 5 tasks to check every 30 minutes. What is the most token-efficient approach?", options: [ "Five cron jobs, one per task, each on a 30-minute interval", "Five separate agents, each handling one task", "One cron job that runs every 6 minutes for each task sequentially", "One heartbeat with a 5-item checklist in HEARTBEAT.md" ], correctOption: 3, explanation: "One heartbeat with a 5-item checklist uses 1x token cost per cycle. Five separate cron jobs each create their own full agent session, resulting in 5x the token cost for the same work. The heartbeat's lightContext and isolatedSession options further optimize token usage with a 95%+ reduction. Five agents would be even more expensive. A 6-minute rotation would still create 5 sessions per 30 minutes.", source: "Lesson 9: Make It Proactive" }, { question: "A customer's session lane has maxConcurrent=1. The customer sends three messages in rapid succession. What happens?", options: [ "All three process simultaneously for faster response", "The first processes while the second and third queue sequentially", "The second and third messages are dropped as duplicates", "The gateway merges all three into a single combined message" ], correctOption: 1, explanation: "Session lanes enforce maxConcurrent=1 per customer, meaning messages from the same customer process sequentially. This prevents race conditions: if a customer says 'Book 2pm' then immediately 'Wait, make that 3pm,' the messages must process in order. Parallel processing would create booking conflicts. Messages are never dropped due to concurrency. The gateway does not merge messages.", source: "Lesson 13: Orchestrate Other Agents" }, { question: "Your custom plugin has two registrations: plugins.load.paths for discovery and plugins.entries for activation. You add only load.paths. What happens?", options: [ "The plugin loads and works immediately", "The gateway crashes with a missing configuration error", "The plugin is discovered but never activates, with no error message", "The plugin loads in read-only safe mode" ], correctOption: 2, explanation: "Adding a plugin to load.paths makes OpenClaw discover it. It appears in openclaw plugins list. Its manifest is validated. But it never calls register(api) unless you also set plugins.entries..enabled = true. There is no error. No warning. The plugin sits in the registry looking loaded, doing nothing. This is the discovery vs activation gotcha, one of the 5 documented plugin development pitfalls.", source: "Lesson 14: Gate Your Agent's Tools" }, { question: "The gateway binds to 0.0.0.0 without a gateway auth token. What security risk does this create?", options: [ "Anyone on the network can access the agent's admin interface", "The agent's responses become slower due to network overhead", "The WhatsApp connection drops due to port conflicts", "The agent loses access to its workspace files" ], correctOption: 0, explanation: "Binding to 0.0.0.0 exposes the gateway to the entire network. Without a gateway auth token, anyone can access the admin interface, reconfigure the agent, read its memory, and send messages on its behalf. The agent can read files, browse the web, and execute code, making its admin interface a high-value target. Performance, WhatsApp connection, and workspace access are unrelated to bind address configuration.", source: "Lesson 2: Install & Connect Your Employee" }, { question: "You try sessions_spawn with a free-tier model. The model acknowledges the task but answers directly instead of using the tool. What is the underlying problem?", options: [ "sessions_spawn is disabled for free-tier accounts", "Free-tier models treat tools as suggestions they can ignore", "The tool requires a separate API key to function", "sessions_spawn only works with multi-agent configurations" ], correctOption: 1, explanation: "Free-tier models like Gemini Flash Lite have poor tool-use reliability. They understand conversational context but choose to answer directly rather than invoke available tools. When forced to invoke, they hallucinate parameters. The fix: clear session context and use forceful prompting, or switch to a capable model (Claude Sonnet, GPT-4). The tool is not account-restricted, does not need a separate key, and works with single-agent setups.", source: "Lesson 13: Orchestrate Other Agents" }, { question: "Which workspace file loads once and should be deleted after use?", options: [ "SOUL.md for agent personality", "HEARTBEAT.md for scheduled tasks", "IDENTITY.md for agent identity", "BOOTSTRAP.md for self-configuration" ], correctOption: 3, explanation: "BOOTSTRAP.md loads once and enables the agent to self-configure through conversation. After the initial setup is complete, BOOTSTRAP.md should be deleted because its instructions are no longer relevant and would waste tokens if the loading mechanism changed. SOUL.md loads on every message. HEARTBEAT.md loads only during heartbeat cycles. IDENTITY.md loads on every message.", source: "Lesson 4: Customize Your Employee's Brain" }, { question: "The three-tier security model progresses through the chapter. What is the correct order from Tier 1 to Tier 3?", options: [ "Tool profiles, requireApproval hooks, NemoClaw out-of-process sandbox", "Security audit, password rotation, firewall configuration", "NemoClaw sandbox, requireApproval hooks, tool profiles", "Encryption at rest, encryption in transit, access control lists" ], correctOption: 0, explanation: "Tier 1 is in-process tool profiles (which tools the agent can use, introduced in Lesson 3). Tier 2 is plugin hooks with requireApproval (operator gates on sensitive operations, built in Lesson 14). Tier 3 is out-of-process NemoClaw sandboxing (kernel-level isolation and API key separation, Lesson 16). Each tier builds on the previous. The other options describe general security concepts not specific to OpenClaw's security model.", source: "Lesson 16: Isolate with NemoClaw" }, { question: "The Docker Compose deployment is cheaper than NemoClaw by roughly $10/month. What does the extra spend on NemoClaw buy?", options: [ "Faster model inference and lower latency", "Automatic horizontal scaling across multiple VPS instances", "Out-of-process policy enforcement and API key isolation from the agent", "Built-in monitoring dashboard with alerting capabilities" ], correctOption: 2, explanation: "The extra $10 buys a fundamentally different security architecture: API keys in a separate pod the agent cannot reach (privacy router), kernel-level enforcement (Landlock, seccomp, network namespaces), and default-deny network policy. This is not more security features; it is a different trust model where the agent physically cannot break the rules. Inference speed, scaling, and monitoring are not what NemoClaw adds over Docker Compose.", source: "Lesson 16: Isolate with NemoClaw" }, { question: "In the Agent OS mental model, what component maps to the 'cron daemon' in a traditional operating system?", options: [ "The gateway process that handles routing", "The plugin system that extends agent capabilities", "The session manager that tracks conversations", "The heartbeat scheduler that triggers periodic agent actions" ], correctOption: 3, explanation: "The Agent OS mental model maps heartbeats to the cron daemon: both execute periodic tasks on a schedule without requiring user interaction. Gateway maps to kernel (process management, I/O routing). Plugins map to device drivers (extending system capabilities). Sessions map to process memory (per-process state). Workspace files map to firmware (loaded at boot, configures behavior).", source: "Lesson 9: Make It Proactive" }, { question: "Your agent has zero critical security findings. The tool profile is set to messaging (a limited tool set). A user sends a prompt trying to get the agent to reconfigure itself. Can this work?", options: [ "No, the messaging profile completely prevents all reconfiguration", "Yes, if the prompt bypasses tool profiles through a plugin vulnerability", "No, because the security audit locks all configuration permanently", "Yes, but only if the user has admin channel permissions" ], correctOption: 1, explanation: "Tool profiles are in-process checks in the same Node.js runtime as the agent. They block exec and other tools normally. But if an attacker finds a path around the runtime (plugin vulnerability, prototype pollution, dependency exploit), the tool profile is irrelevant because it is in the same process. This is why Tier 3 (NemoClaw, out-of-process enforcement) exists. Security audit does not lock configuration permanently. OpenClaw does not have admin channel permissions for this purpose.", source: "Lesson 14: Gate Your Agent's Tools" }, { question: "After deploying to production, you access the Control UI through an SSH tunnel on port 19000. The page loads and the sidebar appears, but no data shows up. What is the most likely cause?", options: [ "The gateway is in a crash loop and needs to be restarted", "The SSH tunnel is not forwarding traffic correctly", "The gateway's allowedOrigins does not include localhost:19000", "The Docker container needs to expose port 19000 in its compose file" ], correctOption: 2, explanation: "This is the CORS mismatch paper cut. Your local gateway already uses port 18789, so you tunnel the production Control UI to a different port (19000). The browser sends requests from http://localhost:19000, but the gateway's allowedOrigins only lists 18789. The page loads (static assets work), the sidebar appears, but API calls fail silently. Fix: add the tunnel port to allowedOrigins via the CLI.", source: "Lesson 15: Deploy to Production" }, { question: "The setup.sh script is several hundred lines of bash. What is the core flow if you strip it to essentials?", options: [ "Build image, run wizard, pin config, start gateway", "Pull image, expose ports, set DNS, start monitoring", "Clone repo, install dependencies, compile source, run tests", "Provision VPS, install Docker, configure firewall, deploy container" ], correctOption: 0, explanation: "The core flow is: build the Docker image (Step 4), run the onboarding wizard (Step 6), pin gateway.mode and gateway.bind (Step 7), start the gateway (Step 9). The remaining 6 steps are validation, directory creation, secret generation, permissions, origin config, and optional sandbox setup. The script does not manage DNS, monitoring, dependencies compilation, tests, VPS provisioning, or firewall rules.", source: "Lesson 15: Deploy to Production" }, { question: "WhatsApp uses the Baileys library for connection. Which statement about Baileys is accurate?", options: [ "It uses the official Meta Business API with full support", "It connects through a Meta-approved partner integration", "It requires a WhatsApp Business account with verified badge", "It reverse-engineers the WhatsApp Web protocol via linked-device mode" ], correctOption: 3, explanation: "Baileys reverse-engineers the WhatsApp Web protocol and connects as a linked device, the same way WhatsApp Desktop links. This is NOT the official Meta Business API and violates their Terms of Service. Meta can ban accounts using unofficial automation without warning. This is why a dedicated phone number is recommended for production, not your personal number. No Meta approval, partner integration, or Business verification is involved.", source: "Lesson 2: Install & Connect Your Employee" }, { question: "A plugin has three files. What are they?", options: [ "config.yaml, handler.js, and test.spec.js", "package.json, openclaw.plugin.json, and index.ts", "manifest.xml, plugin.py, and requirements.txt", "setup.cfg, init.py, and plugin.toml" ], correctOption: 1, explanation: "An OpenClaw plugin consists of three files: package.json (npm package metadata), openclaw.plugin.json (plugin manifest with name, version, and entry point), and index.ts (the plugin code with api.on() hook registrations). This is the TypeScript plugin format used in Lesson 14 to build the requireApproval hook. The other options describe different ecosystems (Python, XML-based) not used by OpenClaw plugins.", source: "Lesson 14: Gate Your Agent's Tools" }, { question: "sessions_spawn blocks the calling agent until the subagent completes. sessions_yield does not. When is sessions_yield the better pattern?", options: [ "When the task requires immediate results for the current response", "When the subagent needs access to the parent's conversation context", "When the customer expects an acknowledgment now and a follow-up later", "When the free-tier model refuses to use sessions_spawn" ], correctOption: 2, explanation: "sessions_yield lets the agent respond immediately ('I have kicked off research on that') while the subagent works in the background. The result arrives asynchronously as a follow-up. This matches conversational expectations in messaging platforms where users expect acknowledgment, not a 14-second pause. sessions_spawn is better when results are needed for the current response. Context sharing and model limitations are not the deciding factor between the two patterns.", source: "Lesson 13: Orchestrate Other Agents" }, { question: "What is the relationship between bundled plugins and the Activation Dance in OpenClaw?", options: [ "All bundled plugins are active by default and require no configuration", "Roughly half are loaded by default; the rest are disabled and require explicit enablement", "All bundled plugins are disabled until the operator enables each one individually", "Bundled plugins load automatically when the agent first references them" ], correctOption: 1, explanation: "OpenClaw ships dozens of bundled plugins. Roughly half are loaded by default and the rest are disabled. Disabled plugins must be explicitly enabled via the Activation Dance (plugins.entries..enabled = true). This is a security design: nothing auto-activates. The disabled plugins include capabilities like voice, advanced security tools, and specialized integrations that require configuration before use.", source: "Lesson 8: Plugins, Bundles & The Decision Tree" }, { question: "You correct your Employee in WhatsApp: 'From now on, when I ask for a meeting summary, include action items at the top with owner names.' OpenClaw's Skill Workshop plugin is enabled. What happens?", options: [ "The correction is saved to MEMORY.md as a long-term preference", "The phrase pattern triggers Workshop to draft a SKILL.md proposal that you review and apply", "OpenClaw rejects the request because skills cannot be authored from chat", "The correction is forgotten when the session ends" ], correctOption: 1, explanation: "Skill Workshop watches for correction phrases like 'next time', 'from now on', and 'remember to'. When it detects one, the heuristic plus an LLM reviewer drafts a SKILL.md proposal capturing the rule and queues it in pending state. You then run skill_workshop list_pending, inspect the proposal, and apply or reject it. MEMORY.md stores facts and preferences but does not generate slash-invocable skills. Skills can absolutely be authored from chat. Workshop's whole purpose is preserving corrections across sessions, so they are not forgotten.", source: "Lesson 6: Install & Author Agent Skills" }, { question: "Two skills with the same name exist in your OpenClaw setup: one in <workspace>/skills/research-brief/ and one bundled with OpenClaw. Which one wins at session start, and why?", options: [ "Bundled wins because it ships pre-tested with the platform", "The newest by file modification time wins", "<workspace>/skills/ wins because it is the highest tier in the six-tier precedence model", "Both load and the agent uses the larger SKILL.md body" ], correctOption: 2, explanation: "OpenClaw checks six skill location tiers in order, top wins on name collision: workspace/skills, workspace/.agents/skills, ~/.agents/skills, ~/.openclaw/skills, bundled, then skills.load.extraDirs and plugin skills. Workspace skills are the override layer. This lets you replace any bundled skill for a specific project by dropping a same-named SKILL.md into the workspace's skills/ folder. File modification time is irrelevant. The runtime never loads two same-named skills simultaneously.", source: "Lesson 6: Install & Author Agent Skills" }, { question: "You want to add a no-code marketing capability to your Employee. Which extension type fits and what does it cost in code?", options: [ "A native plugin in TypeScript, costing a custom code file and a build step", "A bundle plugin from the .claude-plugin/ directory format, costing zero code", "An MCP server with a custom Python implementation", "A hook in openclaw.json that intercepts every message" ], correctOption: 1, explanation: "Bundle plugins use the .claude-plugin/ directory format and are file-based, no code required. They package skills, commands, and connectors as a domain bundle. Anthropic's knowledge-work-plugins repo (and Panaversity's business plugins) ship marketing, sales, finance, and other domain bundles you clone and install. Native plugins are TypeScript code running in-process; they are how channels and model providers are built but overkill for domain workflows. MCP servers add external tool access but are not the right shape for packaging marketing skills. Hooks intercept messages but do not register skills or commands.", source: "Lesson 8: Plugins, Bundles & The Decision Tree" }, { question: "Your agent needs to know how to structure a customer-onboarding conversation. The escalation path says start with the lightest extension. What do you reach for first?", options: [ "A native plugin so the conversation logic runs deterministically", "An MCP server so the conversation can call external systems", "A skill (SKILL.md) because pure knowledge needs no tool access or gateway capability", "A bundle plugin because conversations always require multiple skills" ], correctOption: 2, explanation: "The escalation path: start with a skill, escalate to MCP if you need external tool access, escalate to a plugin if you need to extend the gateway itself. A conversation structure is pure knowledge: the agent reads the SKILL.md instructions and follows them. No external tools, no gateway capabilities. Native plugins are for platform developers extending the gateway in TypeScript. MCP is for live external connections, not conversation patterns. A bundle plugin can include skills but is heavier than needed for one conversation pattern.", source: "Lesson 8: Plugins, Bundles & The Decision Tree" }, { question: "The privacy router in NemoClaw adds the real API key to requests. Where does the router store the key?", options: [ "In the sandbox pod's environment variables", "In a shared Kubernetes secret accessible to all pods", "In an encrypted file on the host filesystem", "In the router pod's own process memory, inaccessible to the sandbox" ], correctOption: 3, explanation: "The privacy router stores API keys in its own process memory within the router pod. The sandbox pod has no access to this memory because it runs in a separate process, separate pod, and separate network namespace. Keys are not in sandbox environment variables (that would defeat the purpose). They are not in shared Kubernetes secrets accessible to all pods. Host filesystem storage would be accessible through mount points.", source: "Lesson 16: Isolate with NemoClaw" }, { question: "OpenClaw bundles three TTS providers. Microsoft Edge TTS requires no API key. What makes tagged mode smarter than always mode for voice output?", options: [ "Tagged mode uses a higher quality voice model for better audio", "Tagged mode compresses audio files to use less WhatsApp bandwidth", "The agent decides when to speak versus type using [[tts]] directives", "Tagged mode sends voice notes only to contacts who prefer audio" ], correctOption: 2, explanation: "In tagged mode, the agent evaluates each response and decides whether voice or text is more appropriate, inserting [[tts]] directives when voice adds value (descriptions, explanations) and typing for short confirmations. In always mode, every response becomes a voice note, including 'Done' and 'OK,' which is annoying and wastes bandwidth. Quality and compression are the same across modes. Contact preferences are not a mode feature; the agent makes the decision based on content.", source: "Lesson 10: Give It a Voice" } ]} questionsPerBatch={18} />