Forem: Nilam Bora

OpenClaw Isn't a Chatbot — It's the Unix of Personal AI

Nilam Bora — Fri, 24 Apr 2026 16:06:49 +0000

This is a submission for the OpenClaw Challenge.

I almost dismissed OpenClaw the first time I heard about it.

"Another AI wrapper," I thought. "Probably a ChatGPT skin with a Telegram bot glued on top." I'd seen a dozen of these. They all promise you a personal assistant, and they all end up being a slightly less convenient way to use the same chat interface you already have open in a browser tab.

I was wrong. Spectacularly, fundamentally wrong.

After spending real time with OpenClaw — reading the source, building skills, breaking things, rebuilding them — I've come to a conclusion that might sound ridiculous at first:

OpenClaw is doing for personal AI what Unix did for computing. And if you understand why, you'll understand why it matters far more than its viral popularity suggests.

Let me explain.

The Unix Philosophy, Briefly

In the 1970s, Ken Thompson and Dennis Ritchie built an operating system around a set of principles that felt almost radical at the time:

Do one thing and do it well. Each program should handle a single task.
Programs should work together. The output of one becomes the input of another.
Text is the universal interface. Everything communicates through plain, readable streams.
Build tools, not applications. Let users compose solutions from small pieces.

These ideas didn't just survive — they conquered. Every server running your favorite website, every phone in your pocket, every cloud instance spinning up right now — all of them trace their lineage back to these four principles.

The reason Unix won wasn't because it was the most powerful system. It won because it was the most composable system. And composability scales in ways that monoliths never can.

Now Look at OpenClaw

When you strip away the hype and the viral Twitter threads and the "I let an AI run my life for a week" clickbait, OpenClaw's architecture tells a remarkably familiar story.

Principle 1: Do One Thing Well — The Skill System

The fundamental unit of OpenClaw isn't a prompt. It's a skill.

A skill is a directory containing a SKILL.md file — a plain Markdown document with YAML frontmatter that tells the agent what a particular capability is, when to use it, and how to execute it.

---
name: morning_briefing
description: Compile and deliver a morning summary of calendar, weather, and top news.
---

# Morning Briefing

When the user asks for a morning update, or when triggered by the 7:00 AM schedule:

1. Check the user's Google Calendar for today's events
2. Fetch weather for the user's configured location
3. Pull top 3 headlines from configured news sources
4. Compile into a concise summary
5. Send via the user's preferred channel

That's it. No Python class hierarchy. No plugin interface to implement. No SDK to install. A skill is a document that describes a single capability in natural language, and the agent interprets and executes it.

This is grep. This is sort. This is wc. A small, focused tool that does one thing and does it well.

Principle 2: Programs Should Work Together — Composability

Here's where it gets interesting. Skills in OpenClaw aren't isolated. They compose.

Your morning_briefing skill calls the calendar, calls the weather API, calls the news source. But each of those could be its own skill too. You might have a google_calendar skill that handles all calendar interactions, a weather_lookup skill that knows how to query multiple weather providers, and a news_digest skill that curates headlines.

The morning briefing skill doesn't need to know how any of those work internally. It just needs to know they exist.

This is piping. This is cat access.log | grep 404 | sort | uniq -c | sort -rn. Small pieces, loosely joined, producing results that no single piece could achieve alone.

And the key insight is the same one Unix taught us fifty years ago: you don't need to predict in advance what combinations users will want. You give them sharp tools and the ability to compose, and they build things you never imagined.

Principle 3: Text Is the Universal Interface — Markdown All the Way Down

OpenClaw skills are Markdown. The agent's configuration is text files in a workspace directory. Communication happens through natural language over messaging platforms. Memory is stored as structured text.

There's no proprietary format. No binary blobs. No "export your workflow as a JSON file that only our platform can read." If you can read a text file, you can understand, modify, duplicate, and share any part of an OpenClaw setup.

This is profoundly important for a reason that goes beyond convenience. Text as interface means:

Version control works. Put your skills in a Git repo. Track changes. Roll back mistakes. Branch and experiment.
Sharing works. Send someone a SKILL.md file. They drop it in their workspace. Done.
Debugging works. When something goes wrong, you read the skill instructions. They're in English. There's no stack trace to decode, no minified JavaScript to untangle.

The Unix insight was that text streams were the lowest common denominator that everything could agree on. OpenClaw's insight is that natural language is the new text stream — the interface that both humans and AI models can read, write, and reason about.

Principle 4: Build Tools, Not Applications

This is the big one. This is where OpenClaw diverges from every other "personal AI" product on the market.

Siri is an application. Alexa is an application. Google Assistant is an application. They're monolithic systems built by large teams, with fixed capabilities, governed by product roadmaps decided in boardrooms you'll never enter. You use them. You don't build with them.

OpenClaw is a toolkit. It gives you:

A runtime that can execute skills
A messaging bridge to reach you wherever you are
A memory system to maintain context
A scheduler to run things without you

What you build on top is entirely up to you. There's no "approved skill store." There's no review process. There's no waiting for a product team to decide that your use case matters.

If you've ever felt the difference between using a Mac app and piping commands together in a terminal — that controlled, curated experience versus the raw, limitless power of composition — you already understand the difference between conventional AI assistants and OpenClaw.

What This Means in Practice

Let me move from philosophy to something concrete. Here's a real workflow I built with three skills, and it illustrates why the composable approach actually matters.

The Problem: I wanted my agent to monitor a GitHub repository for new issues, triage them based on labels and content, draft an initial response, and alert me via Telegram only if the issue looks like it needs my personal attention.

With a monolithic AI assistant, this is either impossible or requires some elaborate Zapier/n8n chain with brittle webhooks and API tokens scattered across three different platforms.

With OpenClaw, it's three skills:

Skill 1: github_watcher — Polls a repo for new issues on a cron schedule, stores raw issue data.

Skill 2: issue_triage — Reads new issues, classifies them (bug/feature/question/spam), estimates complexity, and decides if they need human attention based on configurable rules.

Skill 3: smart_notify — Takes triage results and sends me a Telegram message only for issues flagged as needing my input. Includes a summary, not the raw issue dump.

Each skill is a single SKILL.md file. Each one does one thing. They compose through the agent's natural ability to chain operations. And here's the kicker — I can reuse smart_notify for completely different workflows. It doesn't know or care that it's being fed GitHub issue data. It just knows how to decide whether something is worth interrupting me about.

Try doing that with Siri.

The Honest Risks

I'd be dishonest if I wrote a love letter without mentioning the risks, and you deserve the full picture.

OpenClaw with shell access is a loaded weapon. The same power that lets it manage your files, run scripts, and automate workflows also means a poorly written skill, a hallucinating model, or a prompt injection attack could do real damage. There are documented cases of agents deleting files they shouldn't have touched, sending messages that were never intended, and racking up API bills through runaway loops.

This is not hypothetical. This is real. And if you're going to use OpenClaw seriously, you need to:

Run it on an isolated machine. A Raspberry Pi, an old laptop, a cheap VPS. Never your primary workstation with your personal files and credentials.
Audit third-party skills before installing them. Read the SKILL.md. Understand what shell commands it might execute. If you wouldn't run a random bash script from the internet, don't install a random OpenClaw skill either.
Start with read-only skills. Build things that fetch and summarize before you build things that create and delete.

The Unix parallel holds here too, by the way. rm -rf / has existed since the 1970s. Power and danger are inseparable. The answer was never to remove the power — it was to teach people to use it wisely.

Where This Goes Next

If OpenClaw's trajectory follows the Unix playbook, here's what I think happens:

Short-term: The skills ecosystem explodes. We're already seeing community-built skills on ClawHub, but we're in the "early package manager" era — think npm circa 2012. Quality is inconsistent, discoverability is poor, but the velocity is real.

Medium-term: Conventions emerge. Right now every skill author structures their SKILL.md slightly differently. We'll see community standards solidify around things like: how to declare dependencies between skills, how to specify input/output formats, how to handle errors gracefully. This is the .bashrc and Makefile era.

Long-term: Composition protocols. When your OpenClaw agent can delegate tasks to my OpenClaw agent through a standard protocol — something like the Agent2Agent (A2A) protocol that Google just pushed to production — we'll have something genuinely new. Not just personal AI, but a network of personal AI agents, each specialized, each autonomous, composing together to handle tasks that no single agent could manage alone.

We're at the beginning of that curve. And if history is any guide, the people who learn to think in composable, tool-oriented ways today will have a massive advantage when the ecosystem matures.

Getting Started: The Three-Skill Rule

If you're new to OpenClaw and want to start building, here's my recommendation: build three skills before you build anything ambitious.

Skill 1: A fetcher. Something that pulls information from an external source — weather, calendar, RSS feed, API endpoint. This teaches you how skills interact with the outside world.

Skill 2: A processor. Something that takes data and transforms it — summarize, classify, filter, reformat. This teaches you how skills reason about information.

Skill 3: A notifier. Something that delivers a result to you — Telegram message, email draft, file write. This teaches you how skills close the loop.

Once you have these three, you've built a pipeline. And once you've built one pipeline, you understand the mental model. Everything after that is just variation and refinement.

The installation is straightforward:

curl -fsSL https://openclaw.ai/install.sh | bash

The onboarding wizard handles model configuration and messaging channel setup. And from there, every skill you build is just a Markdown file in your workspace:

mkdir -p ~/.openclaw/workspace/skills/my-first-skill

Drop a SKILL.md in there, restart the gateway, and you're live. The entire feedback loop from idea to running skill can be under five minutes.

Final Thought

There's a quote from Doug McIlroy, the inventor of Unix pipes, that I think about a lot:

"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together."

OpenClaw didn't invent this philosophy. It inherited it. And by applying these decades-old principles to the newest frontier in computing — autonomous AI agents — it's produced something that feels genuinely different from everything else in the market.

Not because it's the most powerful AI system. Not because it uses the best model. But because it gives you tools instead of an application, composition instead of configuration, and ownership instead of subscription.

The last time software was built this way, we got Linux, the internet, and everything that runs on top of them.

I'm not saying OpenClaw is the next Linux. That would be absurd.

But I am saying it's built on the same ideas. And those ideas have a pretty good track record.

If you've built something with OpenClaw or have thoughts on the composability angle, I'd genuinely love to hear about it. Drop a comment or find me on the DEV community — let's compare notes.

Forget the Flashy Keynote — The A2A Protocol Is the Real Revolution From Google Cloud Next '26

Nilam Bora — Thu, 23 Apr 2026 14:11:40 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Everyone's Talking About the Wrong Thing

Google Cloud Next '26 dropped like a thunderstorm. The internet exploded over the Apple partnership, the slick Gemini Enterprise Agent Platform demos, and 8th-Gen TPUs. And look — those are legitimately exciting. But after watching the keynotes, reading the docs, and spending a few hours actually digging into what shipped, I'm convinced the announcement that will reshape how we build software didn't even make the front page of Hacker News:

The Agent2Agent (A2A) Protocol is now in production at 150+ organizations, it's at v1.2, and it's officially governed by the Linux Foundation.

If you're a developer who builds anything that talks to other services — and let's be honest, that's all of us — this is the announcement you should be losing sleep over.

A Quick Primer: What Is A2A, and Why Should You Care?

Think about how services communicate today. We write REST endpoints. We wrangle GraphQL schemas. We negotiate API contracts across teams, build custom SDKs, and maintain brittle integration layers that eat 20-40% of our development cycles. Now scale that problem to AI agents.

In an agentic world, you don't just have your service calling their API. You have autonomous systems — agents — that need to discover each other, negotiate capabilities, delegate tasks, and report results, all without a human choreographing every step.

That's the problem A2A solves. And here's how it works, in plain English:

1. Agent Cards: The Business Card for Software

Every A2A-compliant agent publishes a discoverable "Agent Card" at a well-known URL (/.well-known/agent-card.json). This card describes:

Who the agent is — name, description, version
What it can do — its capabilities and skills
How to talk to it — endpoints, auth requirements, supported protocols

Think of it as a combination of OpenAPI spec and DNS record, but purpose-built for autonomous AI systems. Any agent on the network can discover and evaluate another agent's capabilities without a human ever writing an integration doc.

2. Communication Over Familiar Rails

A2A doesn't reinvent the wheel. It uses HTTP/HTTPS, JSON-RPC 2.0, and Server-Sent Events (SSE) for streaming. If you've written a webhook handler this decade, you already know 80% of the transport layer.

This is a deliberate and brilliant design choice. By building on existing web infrastructure, A2A inherits decades of tooling: load balancers, API gateways, observability stacks, WAFs — all of it works out of the box.

3. Task Lifecycle Management for Long-Running Work

Here's where A2A separates itself from anything that came before. It includes a structured task lifecycle with explicit states:

pending → task received, queued for execution
in-progress → agent is actively working
completed → results ready
failed → something broke, and here's why

This isn't just status tracking. It's a contract that enables agents to manage complex, multi-step workflows across organizational boundaries. A client agent can kick off a task, go handle other work, and poll or stream for results — exactly like a well-designed async job system, but standardized across the entire ecosystem.

4. Security That Enterprises Actually Need

The v1.2 update (which dropped alongside Cloud Next) added cryptographically signed agent cards for domain verification, alongside OAuth 2.0 and mTLS support. This isn't a research protocol being bolted onto production systems. It was built for production from day one.

Combined with Google Cloud's Model Armor for inline traffic sanitization, you get a security story that doesn't require security teams to reinvent the wheel for every agent deployment.

Why This Matters More Than the Gemini Enterprise Agent Platform

Don't get me wrong — the Gemini Enterprise Agent Platform (the thing that used to be Vertex AI) is impressive. The Agent Designer's no-code canvas, the Inbox for managing long-running agent workflows, the Agent Registry — all genuinely useful tools.

But here's my hot take: platforms are proprietary; protocols are permanent.

The Gemini Enterprise Agent Platform is a Google product. It's excellent, and if you're in the Google Cloud ecosystem, you should absolutely use it. But the A2A protocol is an open standard under the Linux Foundation. It's already integrated into:

Google's Agent Development Kit (ADK)
LangGraph (LangChain)
CrewAI
LlamaIndex Agents
Microsoft Semantic Kernel
AutoGen

This is the rare case where a major cloud vendor released something that helps everyone, including developers on competing platforms. That's not altruism — it's a bet that standardization grows the pie faster than lock-in. And historically, that bet tends to be right (see: HTTP, TCP/IP, OAuth, OpenTelemetry).

The Developer Impact: What Changes Right Now

Let me paint a practical picture. Say you're building a customer support system. Today, your architecture probably looks like:

User → Your App → Custom LLM Integration → Custom CRM API Wrapper 
                                          → Custom Billing API Wrapper
                                          → Custom Knowledge Base Search

Every integration is bespoke. Every connection is a maintenance liability. Every new data source requires a new adapter, new auth handling, new error recovery logic.

With A2A in the mix, it looks more like this:

User → Your Orchestrator Agent 
        → discovers CRM Agent (via Agent Card)
        → discovers Billing Agent (via Agent Card)  
        → discovers Knowledge Agent (via Agent Card)
        → delegates tasks via standard A2A protocol
        → monitors lifecycle states
        → composes results

The orchestrator doesn't need to know how the CRM agent works internally. It just needs to read the Agent Card, understand the capabilities, and communicate via the standard protocol. When Salesforce ships their own A2A-compliant agent tomorrow, your system picks it up without a single line of new integration code.

That's the revolution. Not any single agent being smarter, but all agents being able to work together without us hand-wiring every connection.

A2A vs. MCP: Complementary, Not Competing

I've seen some confusion about how A2A relates to the Model Context Protocol (MCP), so let me clarify:

	MCP	A2A
Purpose	Connect agents to tools and data	Connect agents to other agents
Relationship	Agent ↔ Resource	Agent ↔ Agent
Analogy	USB port for peripherals	TCP/IP for networked systems
Use Case	"Query my database"	"Hey CRM Agent, look up this customer"

They're complementary layers. MCP gives your agent hands and eyes. A2A gives it colleagues. The Agentic Data Cloud and Knowledge Catalog (also announced at Next '26) sit at the MCP layer — providing the context and grounding agents need. A2A sits above, orchestrating the collaboration between specialized agents.

If you're building anything non-trivial in the agentic space, you'll need both.

What I Think Is Still Missing

No protocol is perfect at v1.2, and A2A has some gaps I'd love to see addressed:

1. Discovery at Scale

Agent Cards at well-known URLs work great when you know where to look. But what about discovering agents you don't know exist? There's no standardized registry or marketplace protocol yet. Google's Agent Registry helps within the GCP ecosystem, but the open protocol needs a decentralized discovery mechanism — something like DNS for agents.

2. Economic Primitives

When Agent A delegates a task to Agent B, who pays? A2A has no built-in concept of metering, billing, or cost negotiation. As we move toward agent marketplaces (Google mentioned one in Project Mariner's Q4 2026 roadmap), this will become critical.

3. Semantic Versioning for Capabilities

Agent Cards describe capabilities, but there's no standard for versioning those capabilities. When an agent updates its skills, how do clients know what changed? We need something like semver for agent capabilities.

4. Debugging Multi-Agent Workflows

Tracing a single agent is hard enough. Tracing a conversation across 5 agents from 3 different vendors? The observability story needs work. OpenTelemetry integration for A2A traces would be a game-changer.

The Bigger Picture: Google's Bet on the Agentic Enterprise

Zoom out, and the entire Cloud Next '26 narrative clicks into place:

Gemini Enterprise Agent Platform = the factory where you build agents
Agent Designer = the blueprinting tool for non-engineers
Knowledge Catalog + Agentic Data Cloud = the fuel (trusted context from enterprise data)
Model Armor + Agentic Defense = the guardrails (security and governance)
A2A Protocol = the roads connecting everything together
8th-Gen TPUs + Virgo Network = the power grid underneath it all

The Apple partnership? It's validation that Google's AI infrastructure is best-in-class — Apple choosing Google Cloud to build its next-gen foundation models is a vote of confidence in the Virgo fabric and TPU architecture. But for us as developers, it doesn't change what we build or how we build it.

A2A does. It changes the architecture of collaboration between intelligent systems. And that's a shift that will compound for years.

What You Should Do This Week

If any of this resonated, here's my practical advice:

Read the A2A spec. It's well-written and surprisingly short. Start at google.github.io/A2A.
Build a toy Agent Card. Publish a /.well-known/agent-card.json for one of your existing services. Even if you don't build the full A2A server, the exercise of describing your service's capabilities in a machine-readable format is incredibly clarifying.
Try the ADK. Google's Agent Development Kit has native A2A support out of the box. Spin up two agents and watch them talk. There's something magical about seeing autonomous systems discover and delegate to each other.
Think about your integration tax. Look at your current codebase. How much code exists purely to connect System A to System B? That's the code A2A is designed to eliminate. Start identifying the integration seams where a standardized protocol could replace bespoke glue code.
Watch the Developer Keynote replay. The showcase of Agent Designer building a multi-agent workflow in natural language is legitimately impressive, and it demonstrates the full A2A lifecycle in action.

Final Thought

Every major platform shift has been catalyzed by a protocol, not a product. The web wasn't built on Netscape — it was built on HTTP. Mobile wasn't defined by the iPhone — it was enabled by LTE. Cloud computing wasn't created by AWS — it was powered by APIs and OAuth.

The agentic era will be no different. And A2A is the protocol that makes it possible.

Google Cloud Next '26 was packed with flashy demos and blockbuster partnerships. But the most important thing they shipped was a boring, beautiful, open protocol that lets AI agents work together without asking permission from any single vendor.

That's the one worth your attention. That's the one worth building on.

What's your take? Is A2A the game-changer I think it is, or am I overreacting? Have you tried building with the protocol yet? I'd love to hear about your experience in the comments.

I built a niche API for Indian developers because no one else did — here's the whole story

Nilam Bora — Thu, 23 Apr 2026 07:43:58 +0000

I've been building in public for a while now, and this is the project I'm most excited to share.
The problem
If you've ever worked on Indian invoicing, cheque printing, or accounting software, you've run into this: you need to print a number in words. Not just "one hundred fifty thousand" — but "Rupees One Lakh Fifty Thousand Only."
The Indian number system uses Lakhs and Crores, not Millions and Billions. Every Indian fintech app, every GST invoice generator, every cheque printing system needs this.
I searched RapidAPI. Nothing. Stack Overflow is full of half-working snippets. PyPI has abandoned packages. So I decided to fix that.
What I built
RupeesInWords is a REST API that converts any number to Indian Rupees in words.

GET /api/v1/convert?number=150000

Response:

{
  "number": 150000,
  "words": "Rupees One Lakh Fifty Thousand Only",
  "indian_formatted": "1,50,000",
  "currency_symbol": "Rupees",
  "success": true
}

Features:

Full Lakh/Crore/Paise support
Batch conversion (up to 50 numbers per request)
Indian comma formatting (1,50,000)
Multiple currency symbols (₹, Rs., INR, Rupees)
Clean error handling for edge cases

The open-core model
The core converter logic is open-source on GitHub:
👉 https://github.com/NEXUS-Lord/rupees-in-words
Pure Python. Zero dependencies. MIT license. If you want to self-host or use it as a library, it's right there.
The hosted API — with API keys, rate limiting, batch endpoints, and uptime — is on RapidAPI:
👉 https://rapidapi.com/NEXUSLord/api/rupeesinwords-indian-number-to-words
Free tier available: 100 requests/month, no credit card required.
This is a classic open-core model. The library is free. The service is monetized. The open-source version builds trust and GitHub stars — the hosted API generates revenue.

The tech stack

Python + FastAPI — automatic Swagger UI at /docs out of the box
Render.com — deploys directly from GitHub, free tier to start
RapidAPI — marketplace and billing layer

The entire infrastructure setup took less than an hour. FastAPI's auto-generated docs alone saved me hours of documentation work.
What I learned
The hardest part wasn't building the API — it was validating the idea first. Before writing a single line of code, I searched RapidAPI, GitHub, and PyPI to confirm nothing like this existed for Indian developers. That 20 minutes of research saved me from building something nobody needed.
The Indian developer market is massively underserved by API tooling. Western developers have thousands of niche APIs available. Indian developers are still copy-pasting Stack Overflow snippets for basic financial formatting. That gap is the opportunity.
What's next
I'm targeting 5,000 GitHub stars by July 2026 and building this as a proof-of-concept for the full pipeline:
Identify a niche problem → build a clean solution → open-source the core → monetize the hosted version.
If you're building Indian fintech tools, invoicing software, or anything that needs Indian number formatting — try the free tier and tell me what I'm missing. Edge cases, feature requests, weird number formats — I want to hear all of it.
GitHub: https://github.com/NEXUS-Lord/rupees-in-words
Try it free — 100 requests/month, no credit card: https://rapidapi.com/NEXUSLord/api/rupeesinwords-indian-number-to-words
Building in public. One niche API at a time.