docs(landing): align docs + secondary landing with new lobu.toml schema

packages/landing/src/components/ArchitectureSection.tsx

@@ -17,8 +17,8 @@ export function ArchitectureSection(props: {
           class="text-center text-sm mb-12 max-w-xl mx-auto"
           style={{ color: "var(--color-page-text-muted)" }}
         >
-          Zero trust by default. Every agent runs in an isolated sandbox with no
-          direct network access.
+          Agents runs in an isolated sandbox with no direct network access, in
+          your infrastructure.
         </p>
 
         <div class="max-w-3xl mx-auto xl:max-w-none">

packages/landing/src/components/BenchmarkSection.tsx

@@ -162,7 +162,7 @@ export function BenchmarkSection() {
     <section class="pt-20 pb-20 px-4 sm:px-8">
       <CompactContentRail>
         <SectionHeader
-          title="Beats Mem0, Supermemory, and Letta on memory benchmarks"
+          title="Beats most common memory benchmarks"
           body="Apples-to-apples comparison on public memory datasets. Same answerer (glm-5.1 via z.ai), same top-K, same questions."
           className="mb-10"
         />

packages/landing/src/components/PlatformChatExamples.tsx

@@ -1,7 +1,7 @@
 /**
  * Renders a full chat-grid showcase for a platform docs page.
  * A use-case chip row at the top lets the visitor re-skin the three chat
- * windows with use-case-appropriate transcripts (devops, support, legal, …).
+ * windows with use-case-appropriate transcripts (engineering, support, legal, …).
  * The platform-specific theme (colors, chrome) stays fixed.
  */
 

packages/landing/src/components/PricingSection.tsx

@@ -3,7 +3,7 @@ import { ScheduleCallButton, ScheduleCallIcon } from "./ScheduleDialog";
 import { deliverySurfaces, formatLabelList } from "./platforms";
 
 const GITHUB_URL = "https://github.com/lobu-ai/lobu";
-const CLOUD_URL = "https://owletto.com/auth/login";
+const CLOUD_URL = "https://app.lobu.ai/auth/login";
 
 const deliverySurfacesLabel = formatLabelList(
   deliverySurfaces.map((surface) => surface.label)

packages/landing/src/components/connect-from/ConnectFromDocContent.astro

@@ -6,6 +6,7 @@ import {
 } from "../../connect-from-config";
 import {
   getLandingUseCaseShowcase,
+  getOwlettoBaseHostLabel,
   getOwlettoBaseUrl,
   getOwlettoMcpUrl,
   landingUseCaseWorkspaceOptions,
@@ -22,6 +23,7 @@ const client = getConnectFromClientConfig(clientId);
 const showcase = useCaseId ? getLandingUseCaseShowcase(useCaseId) : undefined;
 const owlettoMcpUrl = getOwlettoMcpUrl();
 const owlettoBaseUrl = getOwlettoBaseUrl();
+const owlettoBaseHostLabel = getOwlettoBaseHostLabel();
 
 const clientSwitcherLinks = connectFromClientIds
   .filter((id) => id !== clientId)
@@ -60,6 +62,7 @@ const relatedLinks = client.docsRelated.map((link) => {
   clientLabel={client.label}
   mcpBaseUrl={owlettoMcpUrl}
   owlettoBaseUrl={owlettoBaseUrl}
+  owlettoBaseHostLabel={owlettoBaseHostLabel}
   workspaces={landingUseCaseWorkspaceOptions}
   initialUseCaseId={useCaseId}
 />

packages/landing/src/components/connect-from/TryItSection.tsx

@@ -6,6 +6,7 @@ type TryItSectionProps = {
   clientLabel: string;
   mcpBaseUrl: string;
   owlettoBaseUrl: string;
+  owlettoBaseHostLabel: string;
   workspaces: LandingUseCaseWorkspaceOption[];
   initialUseCaseId?: string;
 };
@@ -14,6 +15,7 @@ export function TryItSection({
   clientLabel,
   mcpBaseUrl,
   owlettoBaseUrl,
+  owlettoBaseHostLabel,
   workspaces,
   initialUseCaseId,
 }: TryItSectionProps) {
@@ -26,17 +28,9 @@ export function TryItSection({
     [workspaces, selectedId]
   );
 
-  const mcpUrl = selected?.orgSlug
-    ? `${mcpBaseUrl}/${selected.orgSlug}`
-    : mcpBaseUrl;
-
-  const signInHref = selected?.orgSlug
-    ? `${owlettoBaseUrl}/${selected.orgSlug}`
-    : owlettoBaseUrl;
-
-  const signInLabel = selected?.orgSlug
-    ? `owletto.com/${selected.orgSlug}`
-    : "owletto.com";
+  const mcpUrl = selected?.mcpUrl ?? mcpBaseUrl;
+  const signInHref = selected?.owlettoUrl ?? owlettoBaseUrl;
+  const signInLabel = selected?.hostLabel ?? owlettoBaseHostLabel;
 
   const tabs = useMemo(
     () => workspaces.map((w) => ({ id: w.id, label: w.label })),

packages/landing/src/content/blog/filesystem-vs-database-agent-memory.mdx

@@ -109,7 +109,7 @@ Good agents should be able to **think messily and remember cleanly**.
 Lobu makes this split explicit.
 
 - Every agent has a local workspace.
-- In file-first projects, Lobu enables Owletto from `[memory.owletto]` in `lobu.toml` plus `owletto.yaml`.
+- In file-first projects, Lobu enables Owletto from `[memory.owletto]` in `lobu.toml`.
 - `MEMORY_URL` is still supported as an optional base-endpoint override for local or custom Owletto deployments.
 - If no Owletto config is resolved, Lobu uses `@openclaw/native-memory`, so memory stays local to that workspace.
 - If Owletto is configured, Lobu uses `@lobu/owletto-openclaw` when that plugin is installed, otherwise it falls back to native memory.

packages/landing/src/content/docs/getting-started/index.mdx

@@ -38,8 +38,7 @@ my-agent/
 │       └── ping.yaml          # test cases for agent quality
 ├── skills/                    # skills shared across all agents
 ├── models/                    # Owletto entity schemas (if memory enabled)
-├── data/                      # Owletto seed entities and relationships
-└── owletto.yaml               # Owletto project config (if memory enabled)
+└── data/                      # Owletto seed entities and relationships
 ```
 
 | Path | Docs |
@@ -48,7 +47,7 @@ my-agent/
 | `agents/*/IDENTITY.md`, `SOUL.md`, `USER.md` | [Agent Workspace](/guides/agent-prompts/) |
 | `agents/*/skills/`, `skills/` | [SKILL.md reference](/reference/skill-md/), [Skills](/getting-started/skills/) |
 | `agents/*/evals/` | [Evaluations](/guides/evals/) |
-| `models/`, `data/`, `owletto.yaml` | [Memory](/getting-started/memory/) |
+| `models/`, `data/` | [Memory](/getting-started/memory/) |
 | `docker-compose.yml`, `Dockerfile.worker` | [Deployment](/deployment/docker/) |
 
 ## Develop your agent

packages/landing/src/content/docs/getting-started/memory.mdx

@@ -10,7 +10,7 @@ Lobu has two different memory layers:
 
 They solve different problems. The filesystem is where an agent does work. Owletto is where the organization remembers what matters.
 
-- Owletto site: [owletto.com](https://owletto.com)
+- Owletto site: [app.lobu.ai](https://app.lobu.ai)
 - GitHub: [lobu-ai/owletto](https://github.com/lobu-ai/owletto)
 - Lobu memory overview: [/memory](/memory)
 
@@ -129,22 +129,22 @@ For file-first projects, the default setup is:
 ```text
 project/
 ├── lobu.toml
-├── owletto.yaml
 ├── models/
 └── data/
 ```
 
 ```toml
 [memory.owletto]
 enabled = true
-config = "./owletto.yaml"
+org = "my-org"
+name = "My Project"
 models = "./models"
 data = "./data"
 ```
 
 At runtime, Lobu resolves the memory backend like this:
 
-- If `[memory.owletto]` is enabled, Lobu derives the effective Owletto MCP endpoint from `owletto.yaml`.
+- If `[memory.owletto]` is enabled, Lobu derives the effective Owletto MCP endpoint from `org` in `[memory.owletto]`.
 - `MEMORY_URL` is still supported as an optional base-endpoint override, mainly for local or custom Owletto deployments.
 - If no Owletto endpoint is resolved, Lobu falls back to `@openclaw/native-memory`.
 - Agents can also override plugin configuration through `pluginsConfig` in agent settings.

packages/landing/src/content/docs/guides/agent-settings.md

@@ -41,14 +41,13 @@ Memory is pluggable. In file-first projects, the gateway first checks `[memory.o
 |---|---|
 | `[memory.owletto]` disabled or unresolved, and no `MEMORY_URL` override | `@openclaw/native-memory` — files under `/workspace` (per-thread PVC in K8s, `./workspaces/{threadId}/` in Docker). Not shared across threads. |
 | `[memory.owletto]` enabled | `@lobu/owletto-openclaw` — the OpenClaw memory plugin for Owletto. It translates OpenClaw memory calls into Owletto MCP requests via the gateway's `/mcp/owletto` proxy. Cross-session, shareable across agents. |
-| `MEMORY_URL` set | Used as the base Owletto MCP endpoint before Lobu scopes it to the org from `owletto.yaml`. Useful for local or custom Owletto deployments. |
+| `MEMORY_URL` set | Used as the base Owletto MCP endpoint before Lobu scopes it to the org from `[memory.owletto]` in `lobu.toml`. Useful for local or custom Owletto deployments. |
 
 `lobu init` now scaffolds the file-first Owletto layout for memory-enabled projects:
 
-- `owletto.yaml`
+- `[memory.owletto]` in `lobu.toml` (org, name, description, models, data)
 - `models/`
 - `data/`
-- `[memory.owletto]` in `lobu.toml`
 
 For **Lobu Cloud**, Lobu can use the hosted default automatically. For **Owletto Local** and **Custom URL**, `MEMORY_URL` remains the base-endpoint override.
 

packages/landing/src/content/docs/guides/architecture.mdx

@@ -25,7 +25,7 @@ Lobu runs as a gateway + worker architecture.
 
 ## Persistent Memory
 
-In file-first projects, Lobu resolves persistent memory from `[memory.owletto]` in `lobu.toml` plus the referenced `owletto.yaml`.
+In file-first projects, Lobu resolves persistent memory from `[memory.owletto]` in `lobu.toml`.
 
 - **`[memory.owletto]` enabled**: Lobu derives an Owletto MCP endpoint and uses `@lobu/owletto-openclaw`, falling back to native memory if the plugin is unavailable.
 - **`MEMORY_URL`**: still supported as an optional base-endpoint override for local or custom Owletto deployments.

packages/landing/src/content/docs/guides/troubleshooting.md

@@ -109,8 +109,7 @@ kubectl describe pvc <pvc-name> -n lobu
 curl http://localhost:8787/health
 
 # Check file-first memory config
-# - lobu.toml should contain [memory.owletto]
-# - owletto.yaml should exist and declare org:
+# - lobu.toml should contain [memory.owletto] with enabled = true and an org
 # - MEMORY_URL is optional; use it mainly for local/custom Owletto base URLs
 
 # Test connection

packages/landing/src/content/docs/platforms/discord.mdx

@@ -35,6 +35,6 @@ Under the hood, Lobu uses the Chat SDK Discord adapter to handle DMs and server
 
 ## Typical Use Cases
 
-- Team assistant in a Discord server (DevOps, support, knowledge base).
+- Team assistant in a Discord server (engineering, support, knowledge base).
 - Community bot that answers questions using your agent's skills and tools.
 - Developer tool that runs commands or queries APIs on behalf of server members.

packages/landing/src/content/docs/reference/lobu-toml.md

@@ -23,7 +23,8 @@ allowed = ["github.com"]
 
 [memory.owletto]
 enabled = true
-config = "./owletto.yaml"
+org = "my-agent"
+name = "My Agent"
 models = "./models"
 data = "./data"
 ```
@@ -95,7 +96,9 @@ nix_packages = ["imagemagick", "ffmpeg"]
 # File-first Owletto memory
 [memory.owletto]
 enabled = true
-config = "./owletto.yaml"
+org = "support"
+name = "Support"
+description = "Customer support agent"
 models = "./models"
 data = "./data"
 ```
@@ -111,19 +114,21 @@ Typical companion layout:
 ```text
 project/
 ├── lobu.toml
-├── owletto.yaml
 ├── models/
 └── data/
 ```
 
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
 | `enabled` | boolean | no | Enables file-first Owletto memory resolution for the project |
-| `config` | string | no | Path to the Owletto project config file, usually `./owletto.yaml` |
+| `org` | string | yes (when enabled) | Owletto organization slug — scopes the MCP endpoint |
+| `name` | string | yes (when enabled) | Human-readable project name |
+| `description` | string | no | Short project description |
+| `visibility` | string | no | `public` or `private`; defaults to Owletto's account setting |
 | `models` | string | no | Path to Owletto model files, usually `./models` |
 | `data` | string | no | Path to Owletto seed data, usually `./data` |
 
-When `[memory.owletto]` is enabled, Lobu reads `owletto.yaml`, extracts the project org, and derives the effective Owletto MCP endpoint. `MEMORY_URL` remains available as an optional base-endpoint override for local or custom Owletto deployments.
+When `[memory.owletto]` is enabled, Lobu reads `org` directly from `lobu.toml` and derives the effective Owletto MCP endpoint. `MEMORY_URL` remains available as an optional base-endpoint override for local or custom Owletto deployments.
 
 
 ### `[agents.<id>]`

packages/landing/src/content/docs/reference/owletto-cli.md

@@ -6,7 +6,7 @@ description: What the owletto CLI does, how it authenticates, and how to use it
 The `owletto` CLI starts local Owletto servers, connects agent clients, and runs memory tools directly.
 
 - GitHub: [lobu-ai/owletto](https://github.com/lobu-ai/owletto)
-- Hosted: [owletto.com](https://owletto.com)
+- Hosted: [app.lobu.ai](https://app.lobu.ai)
 
 ## Install And Run
 
@@ -88,7 +88,7 @@ Detects supported clients and auto-configures them. Falls back to manual steps w
 Authenticates the CLI against an Owletto MCP server using OAuth.
 
 ```bash
-npx owletto@latest login https://owletto.com/mcp
+npx owletto@latest login https://app.lobu.ai/mcp
 ```
 
 By default, the CLI opens a browser and completes an authorization-code flow with a local callback server.
@@ -102,7 +102,7 @@ Useful flags:
 Example for a headless box:
 
 ```bash
-npx owletto@latest login https://owletto.com/mcp --device
+npx owletto@latest login https://app.lobu.ai/mcp --device
 ```
 
 ### `owletto token`