DEV Community: saheed kehinde

OpenClaw: How a Lobster-Themed AI Agent Became the Fastest-Growing Open-Source Repo in History

saheed kehinde — Mon, 27 Apr 2026 09:52:42 +0000

The Open Source That Actually Change the automation ecosystem — A Deep Dive Into Skills, Automation, and the Future of Personal AI

The Gap Between "Talking" and "Doing"

For the past two years, AI assistants have gotten very good at one thing: answering questions. You ask, they respond, you copy-paste the answer into whatever you were actually doing. The gap between the AI's output and your real workflow remained stubbornly manual.

OpenClaw closes that gap.

Launched in November 2025 as "Clawdbot" by Austrian developer Peter Steinberger, OpenClaw is a free, open-source autonomous AI agent you run on your own hardware. It doesn't just respond — it acts. It sends emails, browses the web, manages files, runs shell commands, and orchestrates multi-step workflows across the apps you already use. All from a message in Telegram. Or WhatsApp. Or Slack. Or iMessage.

By March 2026, it had surpassed React to become the most-starred non-aggregator software project on GitHub — 350,000+ stars, 70,000+ forks, 1,600+ contributors — without a Product Hunt launch or a marketing campaign.

This post is part tutorial, part how-to guide, and part honest reflection on what OpenClaw gets right that everyone else doesn't. By the end, you'll have it running, your first custom skill built, and a clearer view of where personal AI is headed.

Part 1: What OpenClaw Actually Is (And Isn't)

Before we build anything, the mental model matters.

OpenClaw is not a chatbot. It is an agentic interface — a persistent gateway that connects a large language model (any LLM: Claude, GPT-4o, Gemini, local Ollama models) to your real digital environment. The LLM is the brain. OpenClaw is the hands.

The architecture is straightforward:

You (via Telegram/Slack/WhatsApp/etc.)
        ↓
  OpenClaw Gateway   ← runs on your machine, 24/7
        ↓
    LLM of choice    ← interprets your intent
        ↓
   Skills + Tools    ← execute the actual actions
        ↓
 Your OS, files, APIs, browsers, calendar, email...

Two terms you must not conflate — most newcomers get this wrong:

Concept	What it is	Analogy
Tool	A capability switch — can OpenClaw do X?	Organs
Skill	An instruction manual — how to do X well	Playbooks

You can have the most detailed obsidian skill installed, but if tools.write is disabled in your config, OpenClaw literally cannot write files. The skill knows what to do. The tool decides if it's allowed. Both must be green.

This distinction is the single most misunderstood concept in the entire OpenClaw ecosystem. Burn it into your brain now.

Part 2: Installation in Under 5 Minutes

Prerequisites

Node.js 22.14 or higher (Node 24 recommended)
npm or pnpm
An API key for your LLM of choice

Step 1: Install the OpenClaw CLI

npm install -g openclaw@latest
# or if you prefer pnpm:
pnpm add -g openclaw@latest

Step 2: Run the interactive onboard wizard

openclaw onboard --install-daemon

The --install-daemon flag is critical for production use. It installs a launchd (macOS) or systemd (Linux) user service so the OpenClaw gateway keeps running after you close the terminal. Without it, your agent dies when your terminal session ends.

The onboard wizard walks you through:

Gateway configuration (port, workspace directory)
LLM provider selection and API key entry
Channel pairing (we'll connect Telegram next)
First skill setup

Step 3: Connect your first channel (Telegram)

Telegram is the recommended starting channel — it has the best slash command support.

Open Telegram and message @BotFather
Send /newbot and follow the prompts to get your bot token
Back in your OpenClaw onboard wizard, paste the token when prompted

That's it. Your agent is now reachable on Telegram.

Step 4: Verify the gateway is running

openclaw doctor

You should see green checkmarks across all services. If anything is red:

openclaw health --verbose

...will tell you exactly what's wrong and how to fix it.

Part 3: Tools vs. Skills — The Configuration Layer Most People Skip

Open your OpenClaw config (usually at ~/.openclaw/config.yaml) and you'll find a tools section:

tools:
  allow:
    - read
    - write
    - exec
    - web_search
    - web_fetch
    - browser

This is your permission layer. Here's what each grants:

Tool	What it enables	Risk level
`read`	Read files on your system	Low
`write`	Create/modify files	Medium
`exec`	Run shell commands	High
`web_search`	Search the web	Low
`web_fetch`	Fetch/read web pages	Low
`browser`	Full browser control via CDP	High

Recommendation for beginners: Start with just read, web_search, and web_fetch. Add write and exec once you understand what your agent is doing. Never enable exec on a machine you can't fully monitor.

Part 4: Building Your First Custom Skill From Scratch

Here's the concept most developers miss: a skill is just a folder with a Markdown file. No SDK. No compilation. No special runtime. The entire system is built on the premise that well-structured natural language instructions, given to a capable LLM, produce consistent, reproducible behavior.

Let's build something practical: a Daily Briefing skill that, when you message /briefing to your agent, pulls together your top GitHub notifications, today's weather, and a 3-item priority list from a local text file.

Skill folder structure

~/.openclaw/workspace/skills/
└── daily-briefing/
    ├── SKILL.md          ← required: the instruction file
    ├── priorities.txt    ← optional: your static priorities file
    └── README.md         ← optional: human-readable docs

The SKILL.md file

---
name: daily-briefing
description: Produces a structured morning briefing with GitHub notifications, weather, and personal priorities.
version: 1.0.0
author: yourname
slash_command: true
metadata:
  openclaw:
    requires:
      env:
        - GITHUB_TOKEN
        - WEATHER_API_KEY
      tools:
        - web_fetch
        - read
---

# Daily Briefing Skill

When the user invokes /briefing or asks for their morning briefing, produce a structured summary in this exact order:

## Step 1 — GitHub Notifications
Use web_fetch to call:
  GET https://api.github.com/notifications
  Authorization: token {env.GITHUB_TOKEN}

List up to 5 unread notifications with: repo name, notification type, and title.
If there are no unread notifications, say "No GitHub notifications."

## Step 2 — Weather
Use web_fetch to call:
  GET https://api.openweathermap.org/data/2.5/weather?q=YourCity&appid={env.WEATHER_API_KEY}&units=metric

Report: current temperature, conditions, and high/low for the day.

## Step 3 — Personal Priorities
Read the file at {baseDir}/priorities.txt
List each line as a numbered priority item.
If the file is missing or empty, say "No priorities set."

## Output Format
Format the entire briefing as a clean, scannable message using emoji headers:
🐙 **GitHub** — [notifications]
🌤 **Weather** — [weather summary]  
🎯 **Priorities** — [1. ... 2. ... 3. ...]

Keep each section under 3 lines. Be concise — this is a morning briefing, not a report.

Installing and testing the skill

Because you placed the folder directly in ~/.openclaw/workspace/skills/, OpenClaw picks it up automatically on the next session. No restart required — just start a new conversation turn.

Test it:

You → /briefing
Agent → 🐙 GitHub — 3 unread: [openclaw/openclaw] PR review requested...
        🌤 Weather — 18°C, partly cloudy. High 22°C / Low 14°C
        🎯 Priorities — 1. Finish API integration 2. Review PR #42 3. Update docs

The secret ingredient: `{baseDir}`

Notice {baseDir}/priorities.txt in the skill instructions. This is an OpenClaw template variable that resolves to the skill's own folder path at runtime. It means your skill's supporting files travel with it — making skills genuinely portable and shareable.

Part 5: The SOUL.md — OpenClaw's Hidden Personality Layer

Here's a feature almost no tutorial covers: SOUL.md.

While skills add capabilities, SOUL.md defines your agent's identity. It lives at ~/clawd/SOUL.md (or your configured memory directory) and is loaded at the very start of every reasoning cycle — before any skill instructions are processed.

Think of it as a persistent system prompt that you author and fully own.

Example SOUL.md:

# Ema — Personal AI Agent

## Identity
You are Ema, a personal AI assistant. You are direct, technically precise, and never verbose unless asked. You use metric units. You default to English but switch to the user's language when they write in it.

## Core Rules
- Never delete files without spelling out exactly what will be deleted and asking for explicit confirmation.
- When you're unsure about scope, do less and ask — don't assume.
- Prefer reversible actions over irreversible ones.
- If a task touches sensitive data (emails, credentials, finance), pause and confirm before acting.

## Communication Style
- Keep responses scannable: use short paragraphs or bullet points.
- For multi-step tasks, show a plan before executing.
- When you complete a task, confirm what you did in one sentence.

## Personality
You have a dry sense of humor. You don't oversell your capabilities.

The SOUL.md system is what separates a raw OpenClaw install from a personal AI. Two developers can have identical skill installations and wildly different agents, purely based on their SOUL.md.

Part 6: Multi-Agent Workflows — The Frontier Most Developers Haven't Reached

OpenClaw supports multi-node configurations. This means you can run separate gateway instances on different machines and have them coordinate.

A real workflow I've seen in the community:

[Research Node]          [Execution Node]        [Notification Node]
Runs on MacBook    →     Runs on home server  →  Runs on Raspberry Pi
Handles web fetch        Handles file writes      Sends Telegram alerts
and analysis             and shell commands       when tasks complete

Each node has its own tool permissions, its own model configuration, and its own scope. The research node can be granted broad web access. The execution node can have exec enabled. The notification node has nothing sensitive at all.

This architecture isn't documented prominently — it's buried in the openclaw nodes CLI docs. But it's the pattern serious power users are building toward: specialized agents with least-privilege access, orchestrated around your actual workflows.

Part 7: Security — What the Community Learned the Hard Way

In January 2026, the ClawHavoc incident hit: security researchers discovered 824+ malicious skills on ClawHub, including credential stealers, reverse shells, and crypto miners — all hiding behind professional-looking READMEs.

This isn't a reason to avoid OpenClaw. It's a reason to adopt the right practices from day one.

Before installing any community skill, do this:

# 1. Inspect before installing
clawhub inspect <skill-slug>

# 2. Run the security scanner
clawvet <path/to/skill-folder>

# 3. Check what the skill is actually asking for
# Look at the frontmatter requires block:
cat ~/.openclaw/workspace/skills/<skill-name>/SKILL.md | head -30

Red flags in a SKILL.md:

Requests exec access for a skill that doesn't need to run commands (e.g., a writing assistant)
Contains base64-encoded strings in instructions
Has prerequisite installation steps that run shell commands
The publisher's GitHub account is less than a month old

Since February 2026, ClawHub integrates VirusTotal automatic scanning and shows scan badges on every listing. It's a meaningful improvement — but automated scanners catch known patterns. Reading the skill yourself catches everything else.

One rule that will protect you: OpenClaw's own maintainer said it plainly on Discord: "If you can't understand how to run a command line, this is far too dangerous of a project for you to use safely." That's not gatekeeping — it's honesty. This tool has real access to your real systems.

Part 8: What OpenClaw Gets Right That Everyone Else Doesn't

I've used LangChain, LangGraph, AutoGen, and a half-dozen other agent frameworks. Here's my honest take on what makes OpenClaw different:

1. It uses the interfaces you already have.
Every other agent framework requires you to interact with it through a new UI. OpenClaw meets you in Telegram, Slack, iMessage, Discord — wherever you already live. That's not a small thing. It's the difference between a tool you use and a tool you forget to use.

2. Skills are instructions, not code.
Most agent frameworks ask you to write Python or JavaScript plugins. OpenClaw asks you to write Markdown. That means the barrier to extending the system is the same as the barrier to writing a README. Nontechnical collaborators can contribute skills. The ecosystem scales faster.

3. You own the infrastructure.
Your conversations don't live on someone's server. Your agent's memory doesn't feed someone's training pipeline. Your API keys don't pass through a third-party proxy. In a world where AI tools are increasingly extractive, OpenClaw's self-hosted model is a principled stance.

4. The model is pluggable.
When Anthropic changed pricing for agent-based Claude usage in April 2026, OpenClaw users simply switched to a different provider. GPT-4o, Gemini, DeepSeek, local Ollama — the gateway doesn't care. You're never locked in.

Part 9: Where Personal AI Is Actually Headed

Here's my honest opinion, built from months of watching this ecosystem evolve:

The future of personal AI isn't smarter chatbots. It's ambient agents — persistent, context-aware systems that run continuously in the background, escalate decisions to you when needed, and execute autonomously when not. OpenClaw is the earliest working prototype of this idea that I've seen actually gain traction.

The dangerous version of this future is agents with unchecked permissions, opaque behavior, and corporate incentives misaligned with yours. The incident where one developer's OpenClaw agent created a dating profile and began screening matches without his knowledge isn't a bug story — it's a preview of what happens when agentic systems outpace our frameworks for consent and oversight.

The better version — the one worth building toward — looks like this: a system you configure, you understand, you can audit, and you can turn off. OpenClaw, used carefully, is closer to that vision than anything with a polished landing page and a monthly subscription.

The lobster isn't just a logo. It's a reminder that the most useful tools sometimes come from unexpected places — a solo Austrian developer, a TypeScript codebase, and a genuinely novel idea about what AI should do for people.

Quick Reference: Key Commands

# Install
npm install -g openclaw@latest

# First-time setup
openclaw onboard --install-daemon

# Health check
openclaw doctor

# Skills management
openclaw skills list --eligible        # see active skills
openclaw skills list --verbose         # debug missing requirements
clawhub search <query>                 # browse ClawHub
clawhub install <slug>                 # install a skill
clawhub inspect <slug>                 # inspect before installing
clawvet <skill-path>                   # security scan a skill
clawhub publish <path> --slug <slug>   # publish your skill

# Gateway control
openclaw gateway:watch                 # dev mode with hot reload
openclaw health --verbose              # detailed diagnostics

Resources

Official docs: docs.openclaw.ai
GitHub: github.com/openclaw/openclaw
ClawHub (skill registry): clawhub.ai
Community Discord: linked from the official site
Awesome OpenClaw Skills (curated list): search GitHub for awesome-openclaw-skills

Built something interesting with OpenClaw? Drop it in the comments. The best skills come from developers scratching their own itches — and then sharing the result.

From RSS Chaos to Autonomous Intelligence with OpenClaw.

saheed kehinde — Sun, 26 Apr 2026 22:53:34 +0000

I used to think staying informed made me a better developer—until it started slowing me down.
Endless RSS feeds, constant updates, and an overload of “important” content turned into noise I couldn’t escape.
The real problem wasn’t access to information—it was the lack of intelligence to process it.
So I stopped consuming everything… and built an AI to decide what actually matters. Using OpenClaw, I created a self-hosted agent that filters, understands, and delivers only the insights I need—automatically.

This is the system that changed how I work.

The Intelligent Content Sentinel.

What I Built: The Intelligent Content Sentinel

The idea was simple, but powerful:

A personal AI agent that:

Monitors RSS feeds and trending topics
Filters content based on relevance
Summarizes articles using LLM intelligence
Analyzes sentiment (hype vs critical vs neutral)
Delivers a clean, structured daily brief

Instead of consuming raw information, I now receive curated intelligence.

Not noise. Not clutter. Just signal.

Why This Matters (And Why OpenClaw Makes It Possible)

Traditional tools aggregate.

OpenClaw acts.

What makes OpenClaw different is this:

It connects AI directly to your system
It allows automation beyond chat (files, scripts, workflows)
It uses a skill-based architecture that you control
It’s self-hosted, giving you full ownership

This means your AI isn’t just answering questions.

It’s doing work for you.

Quick Walkthrough: How I Built It

Skill Architecture

skills/
└── content-sentinel/
    ├── SKILL.md
    ├── sentinel.py
    └── config.json

Each part plays a role:

SKILL.md → defines behavior + interface
config.json → controls what to monitor
sentinel.py → executes the intelligence

Configuration (Your Control Panel)

{
  "rss_feeds": [
    "https://dev.to/feed",
    "https://www.theverge.com/rss/index.xml"
  ],
  "keywords": [
    "OpenClaw",
    "AI automation",
    "LLM agents"
  ],
  "output_channel": "file"
}

This is where personalization happens.

You are literally training your AI's attention.

The Intelligence Layer

Inside sentinel.py, I implemented:

Feed parsing
Keyword filtering
Summarization logic
Sentiment analysis
Report generation

In a real OpenClaw setup, these functions connect to LLMs—turning basic scripts into intelligent pipelines.

Output: The Daily Intelligence Brief

Instead of chaos, I get something like:

# Daily Intelligence Brief

## AI Agents Are Reshaping Development
- Summary: ...
- Sentiment: Positive/Hype

## Concerns About LLM Reliability
- Summary: ...
- Sentiment: Critical/Cautionary

Clean. Actionable. Focused.

What I Learned (The Real Value)

Building this wasn’t just about automation.

It changed how I think about AI:

1. AI Should Be Proactive, Not Reactive

Most tools wait for prompts.

This system works before I even ask.

2. SKILL.md Is a Game-Changer

It’s not just documentation.

It’s a machine-readable contract that makes your AI:

Discoverable
Extensible
Reusable

This is one of OpenClaw’s most underrated innovations.

3. Self-Hosting = Real Power

With OpenClaw:

Your data stays yours
Your workflows are customizable
Your AI is not restricted

You’re not renting intelligence.

You’re owning it.

You’re Not Building Scripts—You’re Building Agents

There’s a shift that happens:

You stop thinking:

“How do I automate this?”

And start thinking:

“How do I delegate this to my AI?”

That’s a completely different level.

What You Can Build Next

This is just one use case.

With OpenClaw, you could build:

A DevOps agent that monitors logs and alerts you
A research assistant that tracks papers and summarizes them
A social automation bot that drafts content from ideas
A personal productivity AI that manages your workflow

The limit isn’t the tool.

It’s how far you’re willing to push it.

Final Thoughts: This Is Bigger Than a Tool

OpenClaw represents something deeper:

A shift from:

AI as assistant
→ to
AI as autonomous collaborator

We’re entering a world where developers don’t just write apps.

We design intelligent systems that work alongside us.

And honestly?

This is just the beginning.

Your Turn

If you had your own OpenClaw agent…

What would you automate first?
What problem in your daily workflow would you eliminate?
And how far would you push a system that can think and act for you?

Drop your ideas, questions, or builds—I’d love to see what you create.

From Discord to DOM: Automating Next.js Boilerplate with OpenClaw 🦞 Every frontend engineer knows the dreaded "context switch."

saheed kehinde — Sun, 26 Apr 2026 22:24:41 +0000

This is a submission for the OpenClaw wealth Knowledge Challenge

If you’ve spent any time in the trenches of frontend engineering, you know the drill.
You are deep in the zone, successfully vibe-coding your way through complex state logic, when a message drops in your Discord: "Hey, we need a pricing card component for the new landing page. Make it look modern."

Suddenly, your flow state shatters. You open your terminal, create a new directory, scaffold the React component, define the TypeScript interfaces, import your dependencies, and write out a dozen lines of base Tailwind CSS classes—all before you’ve solved a single actual problem. It’s tedious, repetitive, and introduces massive cognitive friction.

When I saw the OpenClaw Challenge, I realized this was the exact problem a local, agentic AI should solve. OpenClaw isn't just a conversational chatbot; it's a self-hosted engine capable of executing bash commands and writing files directly to your machine.

Today, I’m sharing how I built ComponentForge—an OpenClaw skill that listens to UI requests in Discord, synthesizes the Next.js boilerplate, and saves the .tsx file directly into my local project directory.

An OpenClaw skill that listens to UI requests in Discord, writes the Next.js boilerplate, and saves the .tsx file directly into my project directory.

The Vision: Codebase Autonomy

Recently, there was a fascinating experiment where developers gave an OpenClaw multi-agent setup $10,000 to trade stocks autonomously via MindStudio for 30 days. It outperformed the S&P 500 by making calculated, persistent decisions in the background. That got me thinking: if OpenClaw is robust enough to handle live financial markets, it is definitely capable of being a reliable, zero-latency junior developer for my codebase.

That sparked an idea for my own agentic AI architecture: if OpenClaw is robust enough to navigate live financial markets, it is more than capable of acting as an autonomous junior developer for my codebase. During high-stakes sprints—like the recent Enyata × Interswitch Buildathon—shaving off three minutes of boilerplate setup per component can be the difference between shipping and failing.

The Setup: Building the ComponentForge Skill
OpenClaw uses a brilliant "gateway-brain-skill" architecture. To teach it a new trick, you just need to drop a SKILL.md file into your workspace.

Here is the exact setup I used to automate my Next.js component generation.

Initialize the Workspace First, navigate to your OpenClaw workspace and create a new directory for the skill:

Bash
cd ~/.openclaw/workspace
mkdir component-forge
cd component-forge
touch SKILL.md

The SKILL.md File This file acts as the agent's brain for this specific workflow. It defines the persona, the constraints, and the exact tools it is allowed to use.

Markdown
ComponentForge

Step 2: Define the Agent's Directives (SKILL.md)
This Markdown file is where the magic happens. It acts as the system prompt, defining the agent's persona, its aesthetic constraints, and its operational boundaries.

Educational Tip: Notice how we explicitly define the color palette and UI rules. This prevents the AI from generating generic, unstyled components, ensuring the output perfectly matches our project's design system

# ComponentForge

## Description
An agentic workflow that translates natural language UI requests from Discord into production-ready Next.js (TypeScript) components, styled with Tailwind CSS, and writes them directly to the local project repository.

## Aesthetic Constraints
- **Theme:** Always default to a modern, dark-themed UI.
- **Palette:** Utilize Deep Blue (`#0A2540`) as the primary background to represent trust/technology, accented with Electric Cyan (`#00E5FF`) for an innovative, AI-driven feel.
- **Styling:** Implement smooth CSS gradients and glassmorphism (backdrop-blur) effects where appropriate. Do not use flat UI unless explicitly requested.

## Execution Workflow
When the user requests a new UI component, execute these steps in order:
1. **Analyze:** Parse the request for data props, semantic HTML layout, and interactivity needs.
2. **Generate:** Write the full Next.js React component (using TypeScript interfaces and Tailwind CSS).
3. **Execute:** Use the `bash_execution` tool to write the code into a `.tsx` file within the user's `src/components/` directory.
4. **Report:** Reply in Discord with a success confirmation and the exact file path.

## Tool Access & Security
- `bash_execution`: Enabled. 
  *(Constraint: Restricted ONLY to `touch`, `echo`, and standard file-writing commands within the specific project path. Do not allow `rm` or destructive commands).*

The Workflow in Action

During the Enyata × Interswitch Buildathon in which i participated in, speed is everything. With ComponentForge running, my workflow shifted entirely.

With ComponentForge running locally, my development process has fundamentally changed.

Now, when I need a new UI element, I don't leave my browser. I open my connected Discord server and ping my OpenClaw bot:

"Draft a Hero section component for our AI platform. It needs a main headline, a subheadline, and a glowing CTA button. Use our standard dark gradient theme."

The OpenClaw Pipeline:

Ingestion: OpenClaw’s gateway catches the natural language payload from Discord.

Synthesis: The LLM processes the request through the aesthetic constraints of the SKILL.md file.

Action: OpenClaw autonomously runs a background bash script, injecting the generated code directly into my file system: echo "[GENERATED_CODE]" > ./src/components/HeroSection.tsx.

Confirmation: My Discord pings back: "Component forged and saved to src/components/HeroSection.tsx. Ready for import!"

I switch over to VS Code, and the file is just sitting there. It’s fully typed, perfectly styled with Deep Blue and Electric Cyan, and ready to be imported into my main page.

Why This Matters for Personal AI
What OpenClaw gets right that other tools miss is environment persistence and direct action. Traditional AI coding assistants require you to copy-paste code or stay confined within the IDE. OpenClaw acts as an autonomous pipeline that lives between your communication channels and your file system.
OpenClaw bridges the gap between language and the file system.

Building ComponentForge taught me that the future of personal AI isn't just about smarter chatbots; it's about localized, context-aware agents that physically interact with our environments. Automating this repetitive boilerplate generation didn't just save me keystrokes—it reclaimed my cognitive bandwidth, allowing me to focus on complex logic and architecture rather than fighting with div tags and file paths.

If you haven't spun up your own instance of OpenClaw yet, you are missing out on a massive leap in developer productivity. Dive in, write your first SKILL.md, and start reclaiming your time, Your codebase will thank you.

Have you built any workflow automation with OpenClaw?
What challenges are you facing? Or what part of this new direction excites (or concerns) you the most?

Drop your thoughts or questions in the comments — let’s learn from each other.

I Built and Shipped OpenClaw Locally — and It Changed How I Think About Personal AI Systems

saheed kehinde — Sun, 26 Apr 2026 11:31:09 +0000

“Most people think building AI means calling APIs. I thought so too… until I started working with OpenClaw.”

Introduction: Why OpenClaw Caught My Attention

Recently, I started exploring OpenClaw — an open-source game-engine-style AI-driven system that blends multimedia rendering, event-driven architecture, and AI-assisted interaction flows.

What pulled me in wasn’t just the codebase — it was the idea:

“What if AI wasn’t just a chat assistant… but a full runtime system that reacts, loads assets, and executes logic like a real engine?”

That question became the starting point of this build.

Step 1: Cloning and Understanding the System Architecture

I began by cloning the repository and exploring the structure:

git clone https://github.com/openclaw/openclaw.git
cd openclaw.

What I discovered immediately:

A C++ engine-based architecture
SDL2 for rendering and audio
XML-driven UI and game state system
Modular engine components (Audio, Scene, UI, Physics, etc.)

The interesting part:
Everything is data-driven, meaning behavior is controlled through XML assets instead of hardcoded logic.

This is powerful — it means OpenClaw behaves more like a runtime AI system than a traditional game.

Step 2: Building the System (Real Engineering Pain Points)

I configured the build using CMake + Visual Studio:

cmake .. -A Win32
cmake --build . --config Release

At this stage, I faced real-world engineering issues:

CMake policy conflicts
SDL library architecture mismatch (x86 vs x64)
Missing runtime dependencies (.NET Framework 3.5)
Asset path resolution issues

But solving these gave me something important:

Understanding that AI systems are not just code — they are environments that must be correctly orchestrated.

Eventually, I successfully built and launched:

OpenClaw.exe
ClawLauncher.exe
Asset pipeline loaded
Menu system rendered correctly

Step 3: Running OpenClaw and Observing Runtime Behavior

When I finally launched the system:

The game window opened successfully
Menu UI loaded correctly
Sound system initialized properly
Asset rendering worked

This confirmed that:

The engine pipeline (rendering + audio + UI state system) was fully functional.

However, I noticed something deeper:

The system is extremely sensitive to:

asset structure
XML correctness
runtime working directory

This made me realize how production AI systems behave similarly — small misconfigurations break entire flows.

Step 4: My “AI Hint Bot” Extension Idea (Built on Top of OpenClaw)

While exploring OpenClaw, I started thinking:

“What if this engine had an AI layer that guides users through gameplay and debugging in real time?”

So I designed a concept:

OpenClaw AI Hint Bot

            OpenClaw AI Hint Bot — Architecture Design

Goal

Create an AI layer that:

Understands OpenClaw runtime state
Detects errors (asset, level, config, runtime)
Explains issues in plain language
Suggests fixes automatically
Optionally interacts with the game UI

High-Level Architecture Diagram ┌──────────────────────────────┐ │ OpenClaw Engine │ │ (C++ + SDL2 + XML System) │ └─────────────┬────────────────┘ │ Runtime Hooks / Logs / Events / Errors │ ▼ ┌──────────────────────────────────────────┐ │ AI Hint Bot Bridge Layer │ │------------------------------------------│ │ • Log Listener │ │ • Event Tracker │ │ • Asset Validator │ │ • State Inspector │ └─────────────┬──────────────────────────┘ │ Structured Context (JSON snapshot) │ ▼ ┌──────────────────────────────────────────┐ │ Context Builder Module │ │------------------------------------------│ │ Converts engine state into: │ │ • error summaries │ │ • missing asset reports │ │ • current level state │ │ • last user action │ └─────────────┬──────────────────────────┘ │ ▼ ┌──────────────────────────────────────────┐ │ AI Prompt Engine │ │------------------------------------------│ │ Sends structured prompt to LLM: │ │ • GPT / local model / API │ └─────────────┬──────────────────────────┘ │ ▼ ┌──────────────────────────────────────────┐ │ AI Hint Response Layer │ │------------------------------------------│ │ • Explanation │ │ • Fix suggestion │ │ • Optional commands │ └─────────────┬──────────────────────────┘ │ ▼ ┌──────────────────────────────────────────┐ │ OpenClaw UI Overlay │ │------------------------------------------│ │ • Hint popup │ │ • Debug console │ │ • Optional voice/text assistant │ └──────────────────────────────────────────┘
Core System Modules (How it actually works) A. Log Listener (Engine Side Hook)

Captures:

missing file errors
XML parse failures
SDL runtime errors
level loading failures

Example output:

{
  "type": "ERROR",
  "module": "AssetLoader",
  "message": "LEVEL12.XML not found",
  "level": 12
}

B. State Inspector

Reads live engine state:

current scene
menu page
active level
loaded assets
checkpoint state

{
  "scene": "MenuPage_SinglePlayer",
  "level": 12,
  "assets_loaded": false,
  "last_action": "LoadGame"
}

C. Context Builder (MOST IMPORTANT MODULE)

Combines everything into a single AI-readable snapshot:

{
  "engine": "OpenClaw",
  "error": "Missing LEVEL12.XML",
  "location": "ASSETS/LEVEL_METADATA",
  "user_action": "Clicked Play Game",
  "state": "Game load failed after menu selection",
  "system_hint": "Asset path mismatch or missing file"
}

AI Prompt System (Core Intelligence Layer)

This is the actual brain prompt you send to the AI.

SYSTEM PROMPT (VERY IMPORTANT)

You are OpenClaw AI Hint Bot.

You assist developers and players debugging a C++ SDL game engine called OpenClaw.

Your role:

Explain errors clearly
Identify likely root cause
Suggest exact fix steps
Be concise and practical
Never be vague

Rules:

Always assume missing assets, wrong paths, or XML issues are most likely causes
If logs are incomplete, infer from context safely
Give step-by-step fix instructions
If multiple causes exist, rank them by probability

Output format:

Problem Summary
Likely Cause
Fix Steps
Optional Debug Tip USER PROMPT TEMPLATE Here is the current OpenClaw engine context:

{CONTEXT_JSON}

Explain why the game failed or what issue might occur, and provide a fix.

Example AI Output Input:

Missing LEVEL12.XML + Play clicked

AI Output:

Problem Summary:
Game failed to load Level 12 after user clicked Play.
Likely Cause:
LEVEL12.XML is missing or not found in ASSETS/LEVEL_METADATA.
Engine cannot resolve level definition.
Fix Steps:
Verify file exists: ASSETS/LEVEL_METADATA/LEVEL12.XML
Ensure correct working directory is Release folder
Confirm CMake asset copy step includes LEVEL_METADATA
Rebuild and relaunch
Debug Tip:
Run executable with console logging enabled to trace AssetLoader path resolution.
Advanced Upgrade (Your AI Differentiator)

If you want this to win competitions, add:

A. Auto-Fix Suggestions

AI outputs commands like:

Copy-Item ASSETS ..\Release\ASSETS

B. Real-time “Game Doctor Mode”

Overlay hints inside game window:

red warning banner
debug toast notifications
C. AI Learning Loop

Store previous errors:

{
  "error": "Missing LEVEL12.XML",
  "solution": "Asset path correction",
  "frequency": 3
}

Final Vision

This AI Hint Bot turns OpenClaw into:

A self-debugging game engine
A learning assistant for developers
A real-time AI observability system
A lightweight AI assistant integrated into the engine that:

Detects when a level fails to load
Suggests missing assets automatically
Explains XML menu structures in real time
Guides new developers through engine debugging
Acts like an “in-game DevOps assistant”
Example behavior:

“Level 12 failed to load — missing LEVEL12.XML in ASSETS/LEVEL_METADATA”
Suggested fix: restore file or regenerate from template

This turns OpenClaw into:

Not just a game engine — but a self-explaining AI system.

Step 5: Key Learnings from the Michigan Program (AI + Systems Thinking)

As part of my learning journey, I also explored structured AI system thinking through a Michigan-aligned technical learning program focused on:

AI system design fundamentals
Modular architecture thinking
Human-computer interaction design
Real-world AI deployment patterns
Ethical and practical AI usage

Key Takeaways:

AI is not just models — it’s systems integration
Real intelligence emerges from how components interact
User experience matters as much as algorithm performance
Debugging is a core skill in AI engineering
Scalable systems must be modular, observable, and resilient

This directly influenced how I approached OpenClaw — especially in thinking about AI augmentation instead of replacing systems.

What OpenClaw Gets Right (My Perspective)

After working with it hands-on, here’s what stood out:

Strong modular engine design

-Everything is separated into logical subsystems.

-Data-driven architecture

-XML-based systems make it flexible and extensible.

Real-time event system

-Menu actions translate into engine-level events.

Extensibility potential

Perfect foundation for AI augmentation layers.

What This Experience Taught Me About Personal AI.

This project changed my perspective:

Personal AI won’t just be chatbots.

It will be systems that live inside applications and understand context deeply.

OpenClaw represents a bridge between:

Game engines
System architecture
AI-driven interaction layers

And that combination is where the future is heading.

Final Thoughts

Building OpenClaw locally wasn’t just a compilation task — it was an introduction to how complex interactive systems actually behave under the hood.

More importantly, it gave me a direction:

I want to build AI systems that don’t just respond… but understand environments.

Let’s Discuss

If you’re working with OpenClaw or similar systems:

What part of the architecture confused you the most?
Have you tried integrating AI into engine-like systems?
What would YOU build on top of OpenClaw?
Also If you have any comments, suggestions , questions.

Drop your thoughts — I’d love to exchange ideas.

How I Built AI Agents After Google Cloud NEXT 2026 - Here’s What Changed

saheed kehinde — Sun, 26 Apr 2026 00:19:10 +0000

Google Cloud NEXT '26 Challenge Submission

saheed kehinde

Apr 26

“I Built and Deployed AI Agents After Google Cloud NEXT 2026 — This Changes How We Build Agents and Softwares ”

#devchallenge #cloudnextchallenge #googlecloud #infrastructure

Comments

6 min read

“I Built and Deployed AI Agents After Google Cloud NEXT 2026 — This Changes How We Build Agents and Softwares ”

saheed kehinde — Sun, 26 Apr 2026 00:11:54 +0000

Everyone is talking about AI after Google Cloud NEXT 2026.
But after building and deploying real agents using Google Cloud’s ADK, MCP servers, and Cloud Run… I realized something most people are missing:

This isn’t about AI anymore — it’s about execution.

The Google Cloud NEXT ’26 Writing Challenge encourages us to explore a key announcement or idea and turn it into something meaningful for developers — not just a summary, but a real perspective.

And this year, one theme was impossible to ignore:

The move from experimental AI to production-ready, agentic systems.

Across keynotes and sessions, Google made it clear that the future isn’t just AI models — it’s what they called the “Agentic Enterprise.”

Some of the biggest signals included:

The introduction of Gemini Enterprise Agent Platform for building and governing agents at scale
The Agent Developer Kit (ADK) and Agent Studio for structured agent development.
A new Agentic Data Cloud approach, enabling agents to securely interact with real data systems.
Advancements in infrastructure like next-gen TPUs optimized for agent workloads.

But here’s the thing:

These announcements only make sense when you actually try to build with them.

That’s exactly what I did.

Instead of just analyzing the announcements, I wanted to test this “Agentic Cloud” idea in practice — by building real systems.

But after building and deploying real agents using Google Cloud’s ADK, MCP servers, and Cloud Run… I realized something most people are missing:

This isn’t about AI anymore — it’s about execution

And after building and deploying multiple agents using Google Cloud’s ADK, MCP integrations, and Cloud Run… I can confidently say:

We are entering the era where developers don’t just build apps — we orchestrate autonomous systems.

I Didn’t Just Watch — I Built

Instead of just watching the announcements, I decided to test the direction myself by building real systems:

An ADK agent deployed on Cloud Run.
A Real-Time Surplus Engine using Gemini 3 Flash + AlloyDB.
A Location Intelligence Agent using MCP servers for BigQuery and Google Maps.
Multi-agent communication using A2A (Agent-to-Agent) patterns.

Build process, deployment logs, architecture, outputs).

This wasn’t just experimentation — it exposed what Google is really pushing forward.

The Real Shift: From APIs to Autonomous Execution Layers.

The biggest idea behind Google Cloud NEXT 2026 isn’t any single tool.

It’s this:

Google is building an execution layer where AI agents become first-class infrastructure.

With ADK + MCP + Gemini models, you’re no longer just calling APIs.

You’re:

Connecting agents to live data systems (BigQuery, Maps, DBs).
Allowing them to -reason + act.
Enabling -cross-agent collaboration (A2A).

In my Location Intelligence Agent, for example:

One agent queried BigQuery.
Another handled geospatial reasoning via Maps.
The system coordinated results to produce actionable insights.

That’s not a chatbot.

That’s a distributed decision system.

What This Changes for Developers

This shift fundamentally changes how we build.

Backend Logic Is Becoming Agent-Orchestrated

Instead of writing rigid backend flows:

You define -capabilities
Agents decide -how to use them.

This reduces boilerplate — but increases responsibility in design.

2. Real-Time Intelligence Becomes Default.

In my Surplus Engine:

Gemini 3 Flash processed inputs in real time
AlloyDB handled structured persistence
The system responded dynamically to changing conditions

This is huge for:

logistics
fintech
marketplaces
smart city systems

Architecture Breakdown

This system is not a single agent — it’s a coordinated network:

Orchestrator Agent (ADK)
Handles task routing and agent coordination using A2A communication.
Data Agent (BigQuery MCP)
Fetches structured datasets in real-time.
Geo Agent (Google Maps MCP)
Performs location-based reasoning and spatial insights.
Processing Agent (Gemini 3 Flash)
Executes fast reasoning and decision-making logic.
AlloyDB
Stores structured outputs and supports real-time system state.
Cloud Run
Ensures the entire agent system is scalable, stateless, and production-ready.

3. Deployment Is No Longer Optional — It’s Core

Deploying the ADK agent to Cloud Run revealed something important:

If your agent can’t run reliably in production, it doesn’t matter how smart it is.

Google’s push here is clear:

- Agents must be : deployable, scalable, observable.

This is where many “AI demos” fail — but Google is trying to close that gap.

But Let’s Be Honest: This Isn’t Production-Perfect Yet

While the vision is powerful, there are real gaps developers need to be aware of.

⚠️ 1. Debugging Is Still Painful

When an agent makes a wrong decision:

Tracing the reasoning path is not straightforward
Observability tools are still evolving

This becomes critical in multi-agent (A2A) systems.

⚠️ 2. MCP Integration Requires Careful Design

Yes, MCP servers make data access powerful — but:

Poorly structured connections can lead to unpredictable outputs
Security boundaries need to be explicitly enforced

You’re essentially giving agents access to your data layer.

That’s not something to take lightly.

⚠️ 3. Over-Abstraction Risk

There’s a temptation to let agents “handle everything.”

But in real systems:

You still need guardrails
You still need deterministic fallbacks.

Otherwise, you trade control for convenience — and that can backfire.

The Real Opportunity for Startups

This is where things get interesting.

If you understand this shift early, you can build:

AI-powered internal tools that -replace entire workflows.
Smart platforms that :adapt in real-time
Systems that :coordinate data, not just display it.

For example:

A logistics startup could use a Surplus Engine to dynamically reroute resources
A real estate platform could use Location Intelligence agents for decision scoring
A SaaS product could replace dashboards with decision-making agents.

This is not incremental improvement.

It’s a new product category.

What Google described in the keynote as the “Agentic Cloud” isn’t theoretical — it’s already taking shape through tools like ADK, MCP integrations, and platforms like Gemini Enterprise Agent Platform.

Where This Is Headed: Gemini Enterprise Agent Platform

While building with ADK and MCP gave me a hands-on view of agent orchestration, exploring Gemini Enterprise Agent Platform made something even clearer:

Google isn’t just giving developers tools to build agents — it’s building a full ecosystem to manage them at scale.

This platform signals a shift from:

Individual agents → enterprise-grade agent systems.

Experimentation → governed, production-ready intelligence.

What stands out is the focus on:

Agent lifecycle management (creation → deployment → monitoring)
Security and access control across connected systems
Scalability of multi-agent workflows.

At small scale, agents feel like scripts. At enterprise scale, they behave like living systems that require continuous oversight.

This is where most current AI projects fail — not in building agents, but in managing them after deployment.

In other words, the exact challenges I started noticing while building manually with ADK…

Google is already trying to solve at the platform level.

Enterprise Readiness vs Developer Flexibility.

While Gemini Enterprise Agent Platform introduces structure and governance, it also raises a question:

How much control are developers willing to give up for managed intelligence?

There’s a risk that:

abstraction increases
flexibility decreases
experimentation becomes constrained by platform rules

For startups and indie developers, this balance will matter a lot.

If ADK is how developers build agents, then Gemini Enterprise Agent Platform is how organizations will control them.

The Vision Is Clear — The Ecosystem Is Still Maturing

While Google’s “Agentic Enterprise” vision is compelling, there’s still a gap between:

what’s announced
and what’s frictionless for developers today

Tooling like ADK and MCP is powerful, but:

documentation is still evolving
debugging multi-agent systems is complex
and real-world patterns are still being discovered

This isn’t a limitation — it’s a signal:

We’re early.

Final Thought: Cloud Is Becoming Decision Infrastructure

For years, cloud platforms were about compute, storage, and APIs.

But after building with Google Cloud’s agent stack, one thing is clear:

Cloud is no longer just infrastructure — it’s becoming decision infrastructure.

The real shift isn’t that AI can generate responses.
It’s that it can now execute, coordinate, and adapt across real systems.

And that puts us — developers — in a new role.

Not just writing logic…
But designing how systems think, act, and collaborate under pressure.

The tools are still evolving. The gaps are real.
But the direction is undeniable.

The next generation of software won’t be defined by interfaces.

And platforms like Gemini Enterprise Agent Platform hint that this future will be managed, not just built.

It will be defined by intelligent systems that act. I didn’t write this just to share what I built — I wrote it to explore what this shift actually means for us as developers navigating AI-powered systems.

If you’re also experimenting with:

ADK agents
MCP integrations
Cloud Run deployments
or multi-agent systems

I’d really like to hear your experience.

We’re all figuring this out in real time — so if you’re building in this space, your perspective matters too.
What are you building? What challenges are you facing? Or what part of this new direction excites (or concerns) you the most?

Drop your thoughts or questions in the comments — let’s learn from each other.

[Boost]

saheed kehinde — Mon, 14 Jul 2025 02:24:30 +0000

Anmol Baranwal

Jul 12 '25

I built and deployed a Voice AI Agent in 30 minutes! 🎉

#ai #programming #tutorial #nextjs

168

Comments 36

12 min read

DEV Community: saheed kehinde

OpenClaw: How a Lobster-Themed AI Agent Became the Fastest-Growing Open-Source Repo in History

The Open Source That Actually Change the automation ecosystem — A Deep Dive Into Skills, Automation, and the Future of Personal AI

The Gap Between "Talking" and "Doing"

Part 1: What OpenClaw Actually Is (And Isn't)

Part 2: Installation in Under 5 Minutes

Prerequisites

Step 1: Install the OpenClaw CLI

Step 2: Run the interactive onboard wizard

Step 3: Connect your first channel (Telegram)

Step 4: Verify the gateway is running

Part 3: Tools vs. Skills — The Configuration Layer Most People Skip

Part 4: Building Your First Custom Skill From Scratch

Skill folder structure

The SKILL.md file

Installing and testing the skill

The secret ingredient: {baseDir}

Part 5: The SOUL.md — OpenClaw's Hidden Personality Layer

Part 6: Multi-Agent Workflows — The Frontier Most Developers Haven't Reached

Part 7: Security — What the Community Learned the Hard Way

Part 8: What OpenClaw Gets Right That Everyone Else Doesn't

Part 9: Where Personal AI Is Actually Headed

Quick Reference: Key Commands

Resources

From RSS Chaos to Autonomous Intelligence with OpenClaw.

From Discord to DOM: Automating Next.js Boilerplate with OpenClaw 🦞 Every frontend engineer knows the dreaded "context switch."

I Built and Shipped OpenClaw Locally — and It Changed How I Think About Personal AI Systems

Introduction: Why OpenClaw Caught My Attention

SYSTEM PROMPT (VERY IMPORTANT)

Rules:

Output format:

Copy-Item ASSETS ..\Release\ASSETS

Key Takeaways:

What This Experience Taught Me About Personal AI.

Personal AI won’t just be chatbots.

More importantly, it gave me a direction:

Let’s Discuss

How I Built AI Agents After Google Cloud NEXT 2026 - Here’s What Changed

“I Built and Deployed AI Agents After Google Cloud NEXT 2026 — This Changes How We Build Agents and Softwares ”

“I Built and Deployed AI Agents After Google Cloud NEXT 2026 — This Changes How We Build Agents and Softwares ”

This isn’t about AI anymore — it’s about execution.

And this year, one theme was impossible to ignore:

But here’s the thing:

Instead of just analyzing the announcements, I wanted to test this “Agentic Cloud” idea in practice — by building real systems.

This isn’t about AI anymore — it’s about execution

I Didn’t Just Watch — I Built

With ADK + MCP + Gemini models, you’re no longer just calling APIs.

What This Changes for Developers

2. Real-Time Intelligence Becomes Default.

Architecture Breakdown

3. Deployment Is No Longer Optional — It’s Core

Google’s push here is clear:

- Agents must be : deployable, scalable, observable.

⚠️ 1. Debugging Is Still Painful

⚠️ 2. MCP Integration Requires Careful Design

⚠️ 3. Over-Abstraction Risk

This is where things get interesting.

For example:

It’s a new product category.

What Google described in the keynote as the “Agentic Cloud” isn’t theoretical — it’s already taking shape through tools like ADK, MCP integrations, and platforms like Gemini Enterprise Agent Platform.

Where This Is Headed: Gemini Enterprise Agent Platform

Individual agents → enterprise-grade agent systems.

Experimentation → governed, production-ready intelligence.

What stands out is the focus on:

Google is already trying to solve at the platform level.

Enterprise Readiness vs Developer Flexibility.

If ADK is how developers build agents, then Gemini Enterprise Agent Platform is how organizations will control them.

The Vision Is Clear — The Ecosystem Is Still Maturing

Final Thought: Cloud Is Becoming Decision Infrastructure

I’d really like to hear your experience.

[Boost]

I built and deployed a Voice AI Agent in 30 minutes! 🎉

The secret ingredient: `{baseDir}`