Skip to content

Grok & agent systems — May 2026

Strategic snapshot: Grok product posture + Crusty (Hermes) local agent stance + wiki maintenance workflow for https://wiki.darcymenard.com. Cross-links: projects/crusty, Grok-Brief, projects/personal-projects-wiki, projects/openclaw-autonomy-org.

Capability bullets below reflect xAI Grok circa mid-May 2026 (Skills ship, Grok Build beta, tiers). Re-check vendor docs before wiring production automations.

Latest Grok capabilities (mid-May 2026)

  • Skills system (shipped ~May 12–13): reusable, modular workflows and persistent expertise. Invoke via /skill-name or /skill-creator. Supports document generation (docx, pdf, pptx, xlsx), file operations in sandbox, custom automations, and treats Grok as a persistent workspace layer — prebuilt and fully custom skills; integrates with agents.
  • Grok 4.3 + computer use: native ability to write/run code, install dependencies, and produce real output files (documents, presentations, spreadsheets, etc.) inside a sandboxed computer environment. Rolling out to SuperGrok / Premium+ users.
  • Grok Build (early beta, May 14): terminal-based CLI coding agent for professional software engineering — plan/review/approve workflow, parallel sub-agents, integrates with Skills, AGENTS.md, plugins, MCP. Tier-limited (SuperGrok Heavy, ~$300/mo at time of writing). Strong fit for complex codebases and heavy automations.
  • Multi-agent architecture (Grok 4.20 / grok-4.20-multi-agent): multiple specialized agents collaborate in parallel on a shared backbone for deeper research, reasoning, and synthesis. Agent count and effort are configurable.
  • Connectors: native OAuth integrations (Gmail, Google Calendar, Drive, GitHub, Notion, Slack, etc.) for direct read/write inside Grok — scoped and revocable. Caution: prompt-injection risk on sensitive accounts; treat connected inboxes/docs as hostile input surfaces.
  • Tiers: X Premium+ and SuperGrok cover Skills, computer use, and core models solidly for most workflows. SuperGrok Heavy unlocks Grok Build CLI and higher limits / early access.

Crusty + local agent strategy (Hermes + Grok OAuth)

Crusty (dedicated local hardware — see projects/crusty) is the home for persistent agents tuned for always-on work: email/calendar summarization, reminders, content pipelines, publishing gates, etc.

Recommended harness: Hermes Agent (Nous Research — open-source, self-hosted, framed as self-improving) with native xAI Grok OAuth (browser login; uses existing SuperGrok / Premium+ subscription — no separate XAI_API_KEY for covered Grok paths). Hermes supports a Telegram gateway, custom skills/plugins, MCP, memory, and tool use; it can operate on local filesystem, Git, and browser actions where configured.

Why Hermes on Crusty (vs cloud-only Grok)

  • Isolation for sensitive access (e.g. Gmail/Calendar scopes) under your machine and policy boundaries.
  • Always-on without relying on cloud round-trips for routine automation.
  • Self-improving skills loop aligns with iterated local agent ops.
  • Continuity with the existing projects/crusty / projects/openclaw-autonomy-org philosophy (delegated autonomy, Telegram gates, audited execution).

Hybrid model: local Crusty + cloud Grok

Layer Role
Local (Crusty + Hermes) Always-on schedules, Telegram remote control, sensitive-account integrations where posture demands it, routine wiki/repo maintenance intent, sandboxed execution, Git operations after approval.
Cloud (Grok grok.com / subscription Grok) Heavy multi-agent reasoning, deep synthesis, high-quality documents/presentations (Skills + computer use), rapid prototyping — use when frontier tooling or parallel agents beat local economics.

Handoff pattern: use cloud Grok for hard conversations or research; emit structured update payloads (sections, bullets, filenames) for the local agent to apply, diff, gate, commit, push.

Wiki maintenance workflow (wiki.darcymenard.com)

Goal: Keep the public wiki (projects/personal-projects-wiki) a living, agent-maintained knowledge base driven from conversations — without moving public hosting onto Crusty.

Architecture

  • Source of truth: Git repo on Crusty — Markdown under wiki/.
  • Agent loop: edits locally → commits with clear messages → pushes.
  • Hosting: Vercel (or equivalent) continues auto-deploy on push (see MkDocs site_url: https://wiki.darcymenard.com/; other deploy notes on tools-and-repos).
  • Remote control: Telegram bot attached to Hermes on Crusty (same gate philosophy as projects/crusty dailies).

Update flow (target)

  1. Chat in cloud Grok for synthesis — or explicitly ask for a wiki update payload (structured deltas).
  2. Or message the Telegram bot with natural-language instructions.
  3. Hermes (via a dedicated WikiMaintainer skill) extracts relevant facts, proposes structured edits, surfaces diff + summary for approval.
  4. On approval: patch Markdown → commit → push.
  5. Vercel deploys → confirmation + published link back to human.

WikiMaintainer skill (Hermes — to build)

Property Choice
Scope Wiki directory only (path allowlist); no unrelated filesystem.
Git pull, edit, diff, commit, push — push only behind explicit approval.
Outputs Consistent headings: projects tables, glossary touchpoints, dates, cross-links ([wiki/...](<wiki/...>)).
Governance Mandatory approval before git push; session logging / monitoring where Hermes supports it.
Evolution Treat prompts + checklists as a living skill — refine from each merge.

Security (minimal bar)

  • Deploy key / token: repo-scoped; minimum permissions for push to this wiki repo only.
  • Filesystem sandbox within Hermes/agent config.
  • Approval gate before any publish push (non-negotiable).
  • Logging adequate to audit what changed and why.
  • Public wiki keeps blast radius lower than automating private financial systems — still no excuse for careless credentials.

Why this approach

  • Turns scattered chats into durable structured context.
  • Enables mobile upkeep via Telegram.
  • Keeps sovereignty for always-on, sensitive-ish surfaces while reserving cloud for frontier reasoning and doc generation.
  • Low incremental risk: site is already public.
  • Extends naturally to reports, glossary maintenance, status pages — same Git + approve + push backbone.

Next actions (execution checklist)

  1. Wire Hermes + Telegram gateway on Crusty end-to-end.
  2. Implement WikiMaintainer skill (scoped Git/files + structured proposal + approval).
  3. Configure repo credential posture + approval UX.
  4. Dry run: one small wiki section update (git pull → edit → show diff → approve → push → verify deploy).

Canonical cold-start routing for blank Grok threads remains Grok-Brief — this page is architecture/strategy, not the paste-pack.