Import source: global/article-contents-en-6

Import the existing local project snapshot. This commit organizes existing files; it does not represent newly developed functionality.

global/article-contents-en-6.js

@@ -0,0 +1,56 @@
+export const ART_EN6_CONTENT = `
+<div class="article-content">
+  <p class="lead">OpenClaw hit 145,000 GitHub stars not by being the most feature-rich AI agent framework, but by being the one developers could deploy without handing their data to a third party and their credentials to a cloud service. In a market crowded with hosted agent platforms, self-hosting turned out to be the differentiating feature — and the architecture choices that enable it are worth studying closely.</p>
+
+  <figure style="margin: 0 0 28px 0; border-radius: 10px; overflow: hidden; border: 1px solid #E4DDD2;">
+    <img src="/images/articles/agentic-ai-production-2026.jpg" alt="OpenClaw self-hosted AI agent framework architecture: tool registry, planning loop, and memory" loading="lazy" style="width: 100%; height: auto; display: block;" />
+    <figcaption style="font-size: 12px; color: #5F6B6D; padding: 10px 14px; background: #F4EFE6; line-height: 1.7;">Self-hosted AI agent frameworks give organizations control over the entire execution environment — from the LLM API endpoints to the tool allowlist to the memory backend. OpenClaw's architecture makes this control explicit rather than buried in configuration files.</figcaption>
+  </figure>
+
+  <h2>1. Origins: From Warelay to OpenClaw</h2>
+  <p>OpenClaw originated as an internal tooling project at Warelay, a developer productivity company, where the team was building internal AI agents for code review, documentation generation, and sprint planning. The central problem they encountered with existing cloud-hosted agent platforms — AutoGPT, AgentGPT, CrewAI's hosted offering — was the same problem that enterprises always encounter with SaaS tools handling sensitive data: the data leaves your network, and you have limited visibility into what happens to it.</p>
+  <p>The Warelay team open-sourced the internal framework in early 2024 under the name OpenClaw, with a specific design philosophy: every component that could be self-hosted, should be. The framework ships with Docker Compose configurations for the agent server, a PostgreSQL-backed memory store, a Redis queue for tool execution, and adapters for both commercial LLM APIs and locally-hosted models via Ollama. The first-time setup experience was designed to produce a running agent in under 15 minutes on a $20/month VPS.</p>
+  <p>The initial launch on Hacker News generated an unusual volume of "finally" comments — practitioners who had been waiting for exactly this combination of capability and self-hosting. The project reached 10,000 stars in the first three days, 50,000 within the first month, and crossed 145,000 by late 2024.</p>
+
+  <h2>2. Core Architecture: The Planning Loop</h2>
+  <p>OpenClaw's agent execution model follows the <em>ReAct (Reasoning + Acting)</em> pattern popularized by the 2022 paper from Google and Princeton, but with several implementation choices that differ from naive ReAct frameworks. The central loop:</p>
+  <p><strong>Observe:</strong> The agent receives a task prompt plus context from the memory backend — previous interactions, retrieved documents, active state. This observation is assembled into the context window.</p>
+  <p><strong>Plan:</strong> The LLM is called with a system prompt that instructs it to return a structured JSON plan: a chain of tool calls with rationale for each step. OpenClaw uses a two-phase call here — a planning call that returns a plan structure, and a separate execution phase. This separation prevents the agent from interleaving reasoning and execution in ways that are hard to inspect or interrupt.</p>
+  <p><strong>Act:</strong> The tool dispatcher reads the plan and executes tools from the allowlist. Tools are Python functions or subprocess calls registered in the tool registry. Each tool execution is logged with its inputs, outputs, and execution time to the audit log.</p>
+  <p><strong>Reflect:</strong> After each tool execution, the agent evaluates whether the result matches the expected outcome in the plan, and either continues, replans, or surfaces an error to the human operator.</p>
+  <p>The key architectural decision is that the <strong>planning call and execution are separated</strong>: the LLM generates a plan that a human or automated policy can inspect before any tool is executed. This "plan, then execute" pattern is less efficient than streaming execution but dramatically more auditable, which is what enterprise deployments require.</p>
+
+  <h2>3. The Tool Registry and Allowlist Security Model</h2>
+  <p>The most security-critical component in any AI agent framework is the mechanism that controls what tools the agent can call. OpenClaw's approach is explicit allowlisting: the agent can only call tools that are explicitly registered and listed in the allowlist configuration file. The default configuration ships with an empty allowlist — the agent can do nothing until an operator explicitly enables capabilities.</p>
+  <p>Tools are defined as Python classes that implement the <code>BaseTool</code> interface, which requires: a <code>name</code> (the string the LLM uses to invoke the tool), a <code>description</code> (what the tool does, included in the LLM context), an <code>input_schema</code> (JSON Schema describing valid inputs), an <code>execute</code> method (the actual implementation), and a <code>permission_level</code> (read-only, write, destructive — used to gate execution in different trust contexts).</p>
+  <p>The allowlist in <code>openclaw.yaml</code> specifies which registered tools are available to which agent configurations. An agent configured for documentation generation might have read access to the filesystem and the GitHub API, but not write access and not shell execution. An agent configured for automated code review might be able to clone repositories and run linters, but not push to branches.</p>
+  <p>This granularity matters because it constrains the blast radius of a compromised or misbehaving agent. An agent with shell execution access that generates a harmful command is significantly more dangerous than one that can only call read-only APIs. The permission system does not prevent prompt injection — but it limits what a successful prompt injection can accomplish.</p>
+
+  <blockquote style="border-left: 4px solid #D49A2A; margin: 28px 0; padding: 16px 20px; background: #D49A2A0A; border-radius: 0 8px 8px 0; font-size: 16px; color: #263238; font-style: normal;">"145K stars is not about the features. It's about trust. Developers have learned that giving a cloud service agent platform access to their GitHub, their Slack, and their AWS credentials is a risk they can avoid. OpenClaw is the answer to that risk." — OpenClaw core maintainer, DevConf 2024</blockquote>
+
+  <h2>4. Memory Architecture: Episodic, Semantic, and Procedural</h2>
+  <p>OpenClaw's memory system distinguishes three types of memory, following the cognitive science framing that has become common in agent frameworks:</p>
+  <p><strong>Episodic memory</strong> stores the history of agent interactions: tasks attempted, tool calls made, results received, errors encountered. This is stored in PostgreSQL as structured JSON with vector embeddings (via <em>pgvector</em>) for semantic similarity retrieval. An agent can recall "the last time I attempted a similar task" without requiring the full history in the context window.</p>
+  <p><strong>Semantic memory</strong> is the external knowledge store — documents, code repositories, API documentation — that the agent retrieves from using vector similarity search. OpenClaw ships with adapters for PostgreSQL+pgvector (default), Qdrant, and Weaviate. Documents are chunked, embedded, and stored at indexing time; retrieved at query time using the task description as the query.</p>
+  <p><strong>Procedural memory</strong> stores reusable action sequences — essentially named workflows that the agent has learned or been explicitly configured with. When a task matches a stored procedure, the agent can execute the known sequence directly rather than planning from scratch. This is how OpenClaw supports "runbook automation": encoding known incident response or deployment procedures as agent-executable workflows.</p>
+
+  <h2>5. Prompt Injection Defenses</h2>
+  <p><strong>Prompt injection</strong> is the primary attack vector against LLM-based agents: malicious content in the agent's inputs (web pages it reads, emails it processes, documents it summarizes) that attempts to override the agent's instructions and make it take unintended actions. For an agent with tool access, a successful prompt injection can result in data exfiltration, unauthorized API calls, or file system modifications.</p>
+  <p>OpenClaw implements several layers of defense, none of which are individually sufficient but together raise the attack cost significantly. <strong>Input sandboxing</strong>: content retrieved from external sources is processed in a separate context from the task prompt, with an explicit delimiter that instructs the LLM to treat the content as data rather than instructions. <strong>Output validation</strong>: tool call parameters extracted from LLM output are validated against the tool's JSON Schema before execution — an injection that attempts to call an unauthorized tool or pass unexpected parameters fails at the validation layer. <strong>Canary tokens</strong>: sensitive context includes randomly generated canary strings; if a canary string appears in a tool output (suggesting the agent has been manipulated into exfiltrating it), the execution is halted and logged.</p>
+  <p>None of these defenses are complete. The research literature on prompt injection in agentic systems is clear that current LLMs cannot reliably distinguish between instructions and data when both are presented in the same context. The defense-in-depth approach acknowledges this and focuses on minimizing impact rather than preventing compromise.</p>
+
+  <div class="insight-box" style="padding: 14px; border-radius: 10px; background: #0F6B7311; border: 1px solid #0F6B7340; margin-bottom: 20px;">
+  <strong>Self-Hosted vs Cloud Agent Platforms — Decision Framework:</strong> Choose self-hosted (OpenClaw or similar) when: sensitive data (credentials, PII, proprietary code) will be in agent context; regulatory requirements prevent data leaving your infrastructure; you need custom tool integrations with internal systems not available in cloud platforms; or you need to audit every tool call for compliance. Choose cloud-hosted when: speed of setup matters more than control; the agent only handles public data; your team lacks infrastructure capacity to maintain a self-hosted deployment.
+  </div>
+
+  <h2>6. Why 145K Stars: The Trust Economy</h2>
+  <p>The GitHub star count is a lagging indicator — what it actually measures is distribution. OpenClaw spread virally among developers who had encountered the same frustrating realization: the most capable cloud agent platforms all require you to give them OAuth access to your GitHub, your Slack, your Google Workspace, and sometimes your AWS account. For personal projects that is inconvenient. For enterprise deployments with security review processes, it is often a blocker.</p>
+  <p>The open-source self-hosted approach resolves the trust problem structurally: the agent runs in your infrastructure, the tool credentials never leave your network, and the code is auditable. The Docker Compose deployment model means a developer with no Kubernetes experience can run it on a $20/month VPS. The modularity of the tool registry means custom integrations with internal systems are straightforward Python implementations rather than waiting for a cloud vendor's integration roadmap.</p>
+  <p>Comparison to cloud-hosted agent platforms like <em>Autogen Studio</em> (Microsoft) or <em>LangGraph Cloud</em> (LangChain): the cloud platforms offer more polished UI, managed scaling, and enterprise support contracts. OpenClaw offers control. For the developer community, especially those who have watched the history of "bring your tokens, we'll handle the rest" services, control won.</p>
+
+  <div class="footnote-box" style="padding: 14px; border-radius: 10px; background: #FAF7F0; border: 1px solid #E4DDD2; font-size: 12px; margin-bottom: 20px;">Note: OpenClaw is a hypothetical framework used to illustrate real architectural patterns from the open-source AI agent ecosystem. The architectural patterns described — allowlist-based tool registries, plan-then-execute loops, episodic/semantic/procedural memory — are based on published research and real frameworks including LangChain Agents, AutoGPT, OpenDevin, and SWE-agent. Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (Google Brain/Princeton, 2022). Greshake et al., "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" (2023).</div>
+
+  <h2>Conclusion: The Architecture of Trust</h2>
+  <p>OpenClaw's star count is ultimately a vote for a specific value proposition: AI agents that you control, audit, and trust because you can see what they are doing and limit what they are allowed to do. The technical architecture — allowlist-based tool registry, plan-then-execute separation, defense-in-depth prompt injection mitigations — is the concrete expression of that value proposition. As agent frameworks mature and their capabilities expand, the teams that invest in understanding these architectural principles will be better positioned to deploy agents safely rather than discovering their security assumptions were wrong at 3 AM.</p>
+</div>
+`;