Deep Stack Blog

The Website Was the Anomaly

2026-04-28T00:00:00+01:00

The website-as-sales-outlet era is ending. Most coverage of the agent economy is missing why.

Stablecoin volume hit $28 trillion in Q1 2026. Roughly 76 percent of it was bots shuffling dollars between exchanges, wallets, and liquidity venues, with retail-sized transfers falling 16 percent over the same period, the sharpest drop on record. The headline number is mostly automated plumbing wearing a new costume, and Telegram's launch of Agentic Wallets on TON last week is being read as one more entry in the same story.

That reading is wrong. The interesting thing about Telegram and TON is not that another payment standard joined Google's AP2, Stripe's MPP, and Coinbase's x402. The interesting thing is that commerce is returning to where humans already are, and the only reason the website existed in the first place is that computers could not yet do commerce in conversational threads. LLMs and natural language processing change that.

The website was a workaround, not a destination

Trade started as a conversation. Two people, with something to trade, and a conversation that led to an immediate exchange. That was the user experience for several thousand years. The mail-order catalogue replaced it for a few decades in the 19th and 20th centuries. The e-commerce website replaced the catalogue for the last 25.

We treat the website-as-sales-outlet as the natural state of commerce because it is the only state most working professionals have ever known. It is not natural. It is the workaround we accepted because computers could not yet hold a conversation, evaluate an offer, and authorise a payment on a buyer's behalf.

The website became a convenient place to store and exchange product data, terms of sale, transaction settlement information, and shipping logistics. The catalogue model transitioned to digital due to the emergence of computer networks and the convenience, safety, and speed they provided.

That constraint is gone. A language model running inside a chat thread can identify the product, negotiate the price, authorise the payment, schedule the shipment, and follow up on the return. A blockchain can settle the transaction in under a second for a fraction of a cent. The website-as-sales-outlet era ends because the constraint that created it ends. Consumers will continue to browse websites to view products just as people traditionally looked at storefronts.

Three primitives converged

The conversational-commerce thesis is not new. What is new is that three primitives finally converged enough to make it work.

The first is the conversational layer. Models capable enough to handle complex intents in natural language are now table stakes. Claude, GPT, Gemini, DeepSeek, and the open-weight tier under them all clear the bar.

The second is the authorisation layer. iOS LocalAuthentication and Android BiometricPrompt expose face and fingerprint verification to user-space applications. Banking apps have used these for years. A chat-application agent can request biometric confirmation of a $200 transfer without owning the operating system.

The third is the settlement layer. Card rails were never designed to support agent-frequency transactions. Visa interchange carries a per-swipe floor of around ten cents plus 1.5 to 3 percent. That makes pay-per-inference, pay-per-API-call, and pay-per-microservice transactions structurally impossible at the volumes agents will generate. TON, Solana, and Ethereum L2s settle in under a second for fees in fractions of a cent. Whether the eventual winner is TON, USDC on Solana, a central bank digital currency, or something not yet visible, the rails will not be Visa interchange.

Telegram and TON are the first stack to wire all three onto one surface. Cocoon, Telegram's distributed GPU compute network launched in November 2025, closes the loop by letting agents settle the cost of their own thinking on the same chain where they execute their transactions. No other ecosystem has that vertical integration today. Stripe agents still rent inference from Anthropic and pay for it through traditional rails. Google agents run on Google Cloud and bill there.

Agents do not buy the way humans buy

The most uncomfortable implication for senior operators is that branding does not work on a transformer.

Super Bowl spots, loyalty programs, design polish, "delightful" interactions, the four-decade investment that consumer brands have made in human emotional response, none of it earns return at the agent layer. An agent representing a buyer optimises for cost, speed, safety, and verifiability. It does not feel anything about your packaging.

The brands that survive the transition are the ones that reposition for agent discovery. That means structured product data, machine-readable warranty and returns terms, verifiable claims with provenance attached, and APIs that expose price, availability, and trust signals in a form an agent can parse without taking a screenshot. The companies that already have this work in flight, like Walmart's product data infrastructure or Mastercard's tokenised credentials, get a head start. The companies that spent the last decade investing in app polish and short-form video do not.

This is the hidden cost most agentic-commerce coverage skips. The platform tax is not the part that creates the real friction. The uncomfortable truth is that the moat consumer brands built around human attention does not map to agent traffic. Procter and Gamble will not stop selling soap, but the path from buyer-intent to buyer-decision moves to a layer where their marketing budget has zero leverage.

Operators in regulated, network-effect, or proprietary-data businesses retain advantage. Operators in CRUD-app SaaS and attention-driven consumer brands have a problem that no rebrand fixes.

The fragmentation counter, and why it loses

The strongest counter-argument to the chat-collapse thesis is fragmentation. Agent surfaces will multiply, not consolidate. Apple Intelligence, Google Gemini, Meta AI, Telegram, Amazon Rufus, Shopify Sidekick, ChatGPT, each gate-keeping its own commerce surface, with brands ending up maintaining six agent integrations the way they maintain six mobile apps. The platform tax does not disappear. It re-emerges as an agent tax.

That counter is partially right. Multiple agent surfaces will exist, and they will compete on lock-in for several years.

The pattern of platform lock-in always ending the same way limits how long this will last. AOL walled gardens lost to the open web. WAP lost to the mobile web. Proprietary instant messaging lost to IP-based interop. iMessage is losing ground to RCS under regulatory pressure. The companies that try to host commerce inside walls eventually lose to the ones that do not.

If today's chat platforms refuse to host conversational commerce on terms users find acceptable, new platforms will emerge that do. The market routes around obstacles. The fragmentation counter does not say the thesis is wrong. It says the thesis takes longer than the optimists claim. That is a timing question, not a structural one.

What to do now

Three concrete actions for a CTO, head of product, or enterprise architect reading this in 2026.

Audit your data for agent-readability. If a third-party agent reaching your public API or website cannot extract your product catalogue, pricing, return policy, warranty terms, and provenance claims in a structured form, you are invisible at the agent layer. Schema.org markup is a starting floor. Real agent-readability looks like a versioned, signed, machine-queryable product feed with first-party trust signals attached.

Pick your bet on which one or two agent surfaces to integrate first. Maintaining six is not viable. The first integrations should be the surfaces where your buyers already are and the surfaces with credible volume. For consumer commerce that probably means WhatsApp and Telegram for the global mass market plus Apple Intelligence or Google Gemini for North American trust. For B2B commerce the answer is different and worth its own analysis.

Start budgeting for agent-frequency payment rails. If your CFO is still negotiating Visa interchange in 2027, you are competing on the wrong cost structure for any business that will see agent-mediated transactions. That does not mean adopting crypto today. It means having an answer to "how would we settle one million transactions per day at a $0.001 unit price" before a competitor demonstrates that they can.

The companies that wait for the agentic-commerce story to "settle down" will be repositioning under pressure 18 months later than the ones that move now.

The conversation owns the next decade

The companies winning today built their moats around human attention. Display ads, app store rankings, brand loyalty, the aesthetic of a checkout flow. Those moats do not price agent traffic correctly. Card rails do not price it correctly either. The next decade of commerce gets rewritten by whoever owns the conversation, not whoever owns the checkout.

Telegram and TON are betting the conversation surface is chat. Whether they win, or a platform that has not been built yet wins, the structural shift is the same. Commerce returns to where humans already are. The agents start doing the talking. The website-as-sales-outlet era is ending, and the people who recognise it as a workaround rather than a natural state will reposition first.

Five Walled Gardens Just Opened for AI Agents. They Are Not Being Generous.

2026-04-19T00:00:00+01:00

Five vendors made the same move in the last six weeks. Cloudflare turned email into an agent-native primitive. Microsoft opened the Windows 11 taskbar to third-party agents that can act on the desktop. Salesforce launched Headless 360 to expose its platform as infrastructure for outside agents. Mastercard wired up agent-driven card payments through Lobster.cash. And Sundar Pichai told an interviewer that Google Search will become an "agent manager."

The categories: email, operating system, enterprise data, payments, search. Five different layers of the computing stack. No coordination between the players. The same direction.

This is not the openness it looks like. It is defence.

The Five Fronts

Cloudflare's Email Service moved to public beta on April 17, with native sending from Workers, automatic SPF, DKIM, and DMARC setup, sub-15-millisecond delivery from its global network, and a Model Context Protocol server so external agents can discover and use email as a primitive. The pitch was three lines of code to send email. The named incumbents being squeezed were SendGrid, Mailgun, and Postmark.

Microsoft is opening the Windows 11 taskbar to third-party AI agents that can act on the desktop. The agent gets a first-class surface inside the operating system, not a sidebar app or a chat panel. That is a real architectural choice: the OS treats agents as something closer to processes with permissions than to applications with windows.

Salesforce launched Headless 360, which turns the platform into infrastructure for third-party agents. Salesforce already has Agentforce for its own internally-built agents. Headless 360 is the move that says: build your agents anywhere you want, just keep using our data.

Mastercard's integration with Lobster.cash lets AI agents make card purchases. The exact authentication mechanics matter less than the fact that the world's second-largest card network is now publicly building rails for delegated, agent-initiated transactions. Agents can spend money.

Sundar Pichai, in a recent interview: "Search would be an agent manager, in which you're doing a lot of things." And: "a lot of what are just information seeking queries will be agentic search. You will be completing tasks, you have many threads running." Search becomes orchestration. Many agents in parallel, working on tasks for the user, with Google as the conductor.

Five layers, five vendors, one quarter. None of them work together.

What They Are Actually Defending Against

The thing being defended is not market share. It is relevance.

An AI agent paired with a model that can write production-quality code is not just a user of SaaS. It is a builder of SaaS. The same agent that calls SendGrid's API can stand up a Postfix instance behind a Cloudflare tunnel, configure SPF and DKIM, and have working transactional email by lunchtime. The same agent that queries Salesforce can build a CRM in a weekend on Postgres and a few thousand lines of code. The same agent that integrates with a payment provider can wire up Stripe directly without the intermediary.

The economics of build-versus-buy assumed a developer team measured in person-months and a SaaS subscription measured in dollars per seat per month. Both numbers are now wrong. Building is measured in LLM tokens, which is to say a couple of hundred dollars for most of these categories. Buying is still measured in seats.

Why pay for a SaaS subscription when you can have an agent build you a working replacement for the cost of a few steak dinners? That is the question every SaaS executive started asking themselves this year. The answer they all converged on, independently, was the same: be the agent's default infrastructure before the agent learns it can build its own.

The New Moat Is Not the Product

If the product is reproducible in a weekend, the product is no longer the moat. What remains defensible is whatever the agent cannot trivially rebuild.

For Mastercard, that is the acceptance network: every merchant on the planet that already takes their cards. An agent can write payment integration code, but it cannot recreate forty years of merchant relationships. For Salesforce, it is the data: the customer record that already lives in a million CRM instances, plus the integrations into every other enterprise system. An agent can build a CRM, but it cannot retroactively populate it with a decade of your sales history. For Google, it is the queries: the distribution at the point where the user actually expresses intent. For Microsoft, it is the OS surface: the agent that lives in the taskbar is one click away from the user, every time. For Cloudflare, it is the operational floor: sub-15-millisecond delivery globally, with no DevOps team to maintain.

What every incumbent is selling to agents now is not a feature set. It is the part of their business an agent cannot replicate at any price.

What This Means For You

If you build infrastructure for a living, the question is no longer how to serve developers better. It is which parts of your offering survive once an agent starts doing the procurement. If the answer is your API surface and a developer relations team, you are exposed. If the answer is a network you have spent twenty years building, data nobody else can reach, or an operational floor you have set, you have something defensible. Identify it, double down on it, and make sure the agent's first call lands at your door.

If you advise clients on AI integration, the conversation has shifted. The question is no longer "which SaaS should we buy." It is "which agents should we buy, and which should we have an agent build for us." Anything that depends on network effects, proprietary data, or regulated infrastructure stays a buy. Anything that is essentially a CRUD application with a polished UI is moving into build territory, and the cost of building has dropped by two orders of magnitude.

If you run a SaaS business, the move every incumbent above made this quarter is the move you also need to make. Open up to agents on terms that route them through you, before they learn to route around you. Treat agents as a new class of user with their own identity, scoped permissions, and audit requirements. The vendors that figure this out first will become the agent's default for their category. The vendors that wait will discover their category was the one the agents decided to build themselves.

What Comes Next

The next six months will sort the incumbents into three groups. The ones with a real moat beyond the product, who become indispensable to agents and capture the new traffic. The ones with no moat beyond the product, who get bypassed quietly while their churn dashboards stay green for another quarter or two. And the ones who tried to wall the agents out entirely, who get bypassed loudly.

Many major vendors made the same move in the last six weeks. Watch which categories follow in the next six. The ones that do not are telling you something important about their products.

AI Agents Will Leak Your API Keys. Here Is the Architecture That Stops It.

2026-03-31T00:00:00+01:00

OpenClaw has a credentials problem. Researchers have documented more than 40,000 exposed instances on the public internet. Cisco's AI security team has confirmed data exfiltration and prompt injection in production environments. One engineer hijacked a running agent in under two hours. These are not edge cases or theoretical risks. They are happening now, at scale.

The root cause is not a bug in OpenClaw. It is a design gap in how AI agents interact with external services, and OpenClaw is not alone in having it.

Why Agents Leak Credentials

When an AI agent needs to call an external API, those credentials have to live somewhere. In most current implementations, they are stored in the agent's configuration or injected into its system prompt. Both approaches put credentials inside the context window the model operates on.

The model has no concept of confidentiality at the credential level. It treats a Stripe API key the same as a name in a contact list: it is text, and it will repeat text when asked. A prompt injection attack, a poorly scoped question, or a malicious tool result that tricks the agent into revealing its configuration can extract those credentials. The agent is not misbehaving. It is doing exactly what it was built to do.

This is not specific to OpenClaw. Any agent framework that passes credentials to the model as context is exposed in the same way.

The Broker Pattern

The correct architectural response is to remove credentials from the model's context entirely. Rather than giving the agent credentials to make an API call, you give it a broker. The agent says what it wants to do. The broker finds the right endpoint, injects the credential at runtime from a separate encrypted vault, and makes the call. The model never handles the secret. It only ever receives the result.

This is what Jentic Mini implements. It is an open-source, self-hosted service that sits between your agent and the APIs it connects to. When OpenClaw, or any other agent framework, requests an API operation, Jentic Mini resolves the correct endpoint from a catalog of 10,000-plus APIs, retrieves the credential from its vault, executes the request, and returns the response. The LLM sees none of the authentication machinery.

Beyond credential isolation, Jentic Mini enforces fine-grained permissions at the broker layer. Most APIs do not offer scoped access. Gmail, for example, does not let you grant an agent permission to draft emails without also granting permission to send them. Jentic Mini enforces that distinction at its own layer, even when the underlying API cannot. It also provides a single kill switch that revokes all agent API access instantly, and a full audit log of every call made.

What It Gets Right

The broker pattern is the correct answer to this class of problem. If the model never receives the credential, it cannot leak it. The permission enforcement layer addresses a real gap that most OAuth implementations have not caught up to. The kill switch and audit trail are what any production deployment actually needs and currently lacks.

The approach also separates concerns correctly. Runtime security tools focus on what the agent does on the host machine: command execution, file access, shell operations. Jentic Mini focuses on how the agent connects to external services. These are different layers, and patching one does not cover the other.

What Remains Unresolved

The broker pattern centralises risk rather than eliminating it. Jentic Mini now holds all your credentials in one encrypted vault. A compromise of that vault is worse than credentials scattered across individual agent configs, because the attacker gets everything at once. The same kill switch that gives you control is also a single point of failure.

Credential isolation also does not stop prompt injection. An attacker who successfully injects instructions into an agent can still direct it to make legitimate-looking API calls through the broker. The credentials stay hidden, but the data those APIs return is not protected. Exfiltration via API results remains a live threat.

The API catalog has a quality problem in the long tail. Jentic's own CEO acknowledges that the first 400 or so APIs are solid, and that reliability becomes harder to guarantee beyond that point. At 10,000-plus APIs, the coverage looks impressive. The consistency does not match it.

The self-hosted edition uses BM25 keyword search to match agent requests to API operations. The commercial tier uses semantic search, with a stated accuracy improvement of 64 percent. That is a substantial gap, and it matters in any non-trivial deployment where selecting the right API endpoint has to be reliable.

There is also an operational cost that is easy to underestimate. Running Jentic Mini means running another service, maintaining its vault, keeping it updated, and monitoring it. It is not heavy infrastructure, but it is real overhead, and it becomes a dependency in your agent's critical path.

Finally, Jentic Mini's own documentation carries an explicit early-access warning: not recommended for production use at this stage. Take that literally.

The Honest Assessment

Jentic Mini is the right idea, implemented early. The broker pattern will become standard infrastructure as agent deployments move from experiments into workloads that touch real credentials and real data. The alternative is agents with secrets in their context windows, which is where most deployments sit today.

The question for your team is not whether this pattern matters. It does. The question is whether this specific implementation is ready for your use case. If you are connecting agents to anything with real consequences, the answer right now is no.

If you are thinking about what production agent security will need to look like, understanding this architecture is worth your time. The problem is real, the pattern is right, and the infrastructure to execute it properly is still catching up.

OpenClaw Gets a Security Layer. Here Is What It Does.

2026-03-27T00:00:00+00:00

OpenClaw is a continuously running AI agent orchestration application that has access to your shell, your file system, your messaging apps, and your APIs. It ships with none of the controls you would expect from software that has that kind of reach.

Zenity, a company focused on AI security, released an open-source framework this week that fills the gap. It is called the OpenClaw Security Platform. It adds detection and blocking capabilities directly inside OpenClaw agent workflows. The framework is available now and requires no fork of OpenClaw.

The Problem It Solves

OpenClaw's architecture is intentionally open. The framework lets developers wire AI agents to essentially any external system through a plugin model. That openness is what makes it useful and what makes it dangerous.

An agent operating through OpenClaw can execute shell commands, read and write files, send messages, and call external APIs, all in sequence, autonomously, using the user's credentials. Over 21,000 OpenClaw instances were exposed with no authentication in its early weeks. The lack of a native security layer compounds that problem: even a properly authenticated instance has no built-in mechanism to inspect what its agents are actually doing at runtime.

The OpenClaw Security Platform is designed to be dropped into an existing OpenClaw setup without migration. It operates as either a lightweight plugin or a full reverse proxy and evaluates agent activity at three checkpoints in the execution flow.

Three Checkpoints

The framework intercepts events at points where something meaningful is about to happen or has just happened.

message.before: Inbound prompts and messages are inspected before they enter the agent's context. This is the right place to detect prompt injection attempts, filter personally identifiable information (PII), and screen for inputs that violate policy before the agent begins reasoning about them.

tool.before: Tool calls are evaluated before execution. An agent about to run a shell command, make an API request, or write a file hits this checkpoint first. This is where dangerous commands can be blocked before any damage occurs.

tool.after: Tool output is evaluated after execution. Even when a tool call looks safe, the response can expose secrets or sensitive data. This checkpoint catches that.

The three-stage model mirrors how security controls work in other execution environments: inspect input, inspect the action, inspect the result. The coverage is not new thinking, but it is good to see it applied cleanly to an AI agent framework.

Six Evaluator Tiers

The framework supports six types of evaluators, each suited to a different class of detection problem. They run in a fixed sequence ordered by performance cost, and they short-circuit on a block verdict.

regex (~1 µs): Pattern matching for secrets, credentials, PII, and dangerous command strings. Ships with pre-built rules for AWS keys, GitHub tokens, and common shell commands that should not run autonomously. Fastest tier by a wide margin.

Sigma (~1 ms): Standard YAML threat detection rules, the same format used across the security industry. Sigma rules from the broader ecosystem can be mapped to OpenClaw events without modification. Teams with existing security operations centre (SOC) tooling can reuse what they already have.

CEL (~1 ms): Common Expression Language for conditional policy evaluation. Provides full access to every field in an event with standard boolean logic. Useful for policies that regex cannot express cleanly.

SQL (~10 ms): In-memory SQLite for temporal queries. This is the most architecturally interesting evaluator tier. It enables rate limiting, burst detection, and session-level anomaly scoring, which requires looking across multiple events rather than evaluating each one in isolation.

ML (~50 ms): Local ONNX (Open Neural Network Exchange) model inference for prompt injection detection, toxicity classification, and custom classifiers. Models run locally; no data leaves the machine. The ONNX runtime makes this tier accessible without requiring a hosted inference service.

LLM (~500 ms): Semantic evaluation using an LLM as a judge. Policy-driven, structured verdicts. Useful for decisions that require understanding intent rather than matching patterns. The latency cost means this should sit at the end of the chain, invoked only when the faster tiers have not already resolved the event.

The performance chain is a thoughtful design choice. The cheapest evaluators always run first and, on a block verdict, the remaining evaluators are skipped entirely. Regex catching a secret in a prompt means ML and LLM never wake up. This makes the overhead of running security checks predictable and manageable.

Two Deployment Modes

The framework offers two ways to sit inside an OpenClaw deployment, and the difference matters.

Shim plugin: Installs as a native OpenClaw plugin. It registers hooks and forwards events to a local Python evaluation server over HTTP. The shim can block at tool.before but only detect and alert at message.before and tool.after. This is a limitation of how OpenClaw's plugin hooks work: message.before and tool.after are fire-and-forget in the plugin model, so those stages cannot prevent an event, only observe it.

API proxy: Sits between OpenClaw and the Anthropic API as a reverse proxy on port 9920. Because it intercepts every request and response at the transport layer, it can block, redact, or detect at all three stages, including rewriting streamed responses. No plugin installation is required. OpenClaw does not need to be reconfigured beyond pointing it at the proxy instead of the Anthropic API directly.

The proxy mode is the more capable option. The shim mode is the lower friction option. The choice depends on whether tool level blocking alone is sufficient or whether full coverage is required.

The Bring-Your-Own-Security Philosophy

One design decision worth noting: the framework does not ship with opinions about what constitutes dangerous behavior. It ships with the mechanism to evaluate events and the infrastructure to act on those evaluations. What counts as a block, a redact, or a detect is up to the team deploying it.

This is a deliberate choice, and a reasonable one. What is dangerous in an OpenClaw deployment varies by context. A developer environment running experimental workflows has different risk tolerances than a production system handling customer data. A framework that encodes a fixed threat model would be wrong for most of the environments it is deployed in.

The trade-off is that the framework requires security judgment to be useful. The pre-built regex rules lower the barrier to getting started, but teams that want meaningful coverage will need to write evaluators that reflect their actual threat model.

What to Make of It

The OpenClaw Security Platform addresses a real gap. Agents that can execute shell commands and call external APIs without any inspection layer are a meaningful operational risk, and that risk grows as OpenClaw deployments move from developer experiments to production workloads.

The architecture is sound: three checkpoints, six evaluator tiers ordered by cost, two deployment modes for different integration constraints, a real-time dashboard, and a clean HTTP API for the evaluation server. For teams building on OpenClaw who have been waiting for a security story, this is a practical starting point.

Whether it is sufficient depends on what you are building. The shim plugin's inability to block at message.before and tool.after is a limitation that matters in high-risk deployments. The API proxy solves that, but adds a network hop and a new process to maintain. Neither mode offers persistence beyond in-memory state, which limits what the SQL evaluator can do across sessions.

These are not criticisms of the framework so much as an honest accounting of what it covers and what it does not. It is open source, available now, and fills a gap that OpenClaw itself has not addressed.

The project is at github.com/zenitysec/openclaw-security-platform.

Anthropic Just Shipped What Made OpenClaw Go Viral

2026-03-26T00:00:00+00:00

On March 22, Tencent launched a tool that lets its WeChat platform integrate with OpenClaw agents. The same week, Alibaba, Baidu, ByteDance, and MiniMax all shipped OpenClaw-based products. When four of China's largest technology companies integrate the same open-source project in the same week, you are no longer looking at a developer curiosity. You are looking at infrastructure.

One day later, Anthropic shipped Claude Code Channels.

The timing is not a coincidence. OpenClaw proved, at scale, that there is a massive demand for AI agents accessible through messaging apps. People want to text their AI, not open a browser tab. They want it to act while they're away, not wait to be asked. Channels is Anthropic's answer to that thesis, built natively into Claude Code, with a different architectural bet on how to do it safely.

How OpenClaw went from viral to infrastructure

When Peter Steinberger launched OpenClaw in January 2026, it reached 60,000 GitHub stars within a week. Andrej Karpathy posted about it. Jensen Huang called it "definitely the next ChatGPT" at Nvidia's GTC keynote. The project was renamed twice under trademark pressure and crypto chaos, and kept growing.

The viral developer interest was real. But OpenClaw's bigger story played out elsewhere.

OpenAI and Anthropic don't operate commercially in China. That created a gap: a market of over a billion potential users with access to capable AI models, but no mainstream consumer interface. OpenClaw filled it. WhatsApp, Telegram, WeChat, and Discord are the apps people already have open. An orchestration layer that routes through those apps, runs on local hardware, and connects to any LLM is exactly what that gap needed.

Tencent's WeChat integration on March 22 was the signal. This is no longer a side project. It is a pattern, and the major platforms are adopting it.

What Channels actually does

Channels is a feature in Claude Code, currently in research preview (requires v2.1.80 or later and a claude.ai login). It adds a class of MCP server that can push events into a running Claude Code session, rather than waiting to be queried.

The practical result: you send a message from your phone via Telegram, Discord, or iMessage, and it arrives in your Claude Code session as an event. Claude reads it, does the work, and replies back through the same channel. The answer shows up in Telegram, not the terminal.

The setup flow is deliberate. You install a plugin (Telegram, Discord, or iMessage), restart Claude Code with the --channels flag naming that plugin, and go through a pairing flow where the bot sends you a code and you confirm it. Then you lock down the sender allowlist. Only IDs you have explicitly approved can push messages. Everyone else is silently dropped.

Anthropic also ships a demo called fakechat, a localhost chat UI with no authentication required, designed to let you test the flow before connecting a real messaging platform. It is a good sign that the team thought about onboarding.

The architectural difference that matters

OpenClaw and Channels solve the same user problem with fundamentally different architectures, and the difference has real implications.

OpenClaw is an always-on, always-running local agent. It operates using your credentials continuously, even when you are not at the keyboard. It can message you proactively, triage email at 3am, and run scheduled tasks that span days. The breadth is only limited by what APIs you wire to it. The cost of that breadth is a wide attack surface: in OpenClaw's early weeks, security researchers found 21,639 exposed instances with no authentication.

Channels is session-scoped. Events only arrive while your Claude Code session is open. If you close the terminal, the channel goes silent. There is no always-on agent operating with your credentials in the background. The security posture is meaningfully narrower: no persistent process, no credential exposure outside the active session, and org-level controls for Team and Enterprise users that admins can manage from the claude.ai console.

This is a deliberate trade-off. Channels solves the "I want to reach my AI from my phone while it's working on my machine" problem. It does not solve the "I want my AI to act autonomously while I sleep" problem. OpenClaw does the latter. Whether that is the right problem to solve depends on your risk model.

China's decision to restrict OpenClaw from state enterprises and government agencies is a data point here. When a government bans something from its own offices, the security concern is not theoretical. The hybrid identity problem, where an AI agent operates continuously using human credentials that most security systems cannot distinguish from a real user, is exactly what that ban is reacting to.

What Channels still does not solve

Channels is a research preview, and it shows. It requires Bun as a dependency. It requires a claude.ai login, so console and API key authentication is not supported. The --channels flag syntax may change before it stabilises.

More fundamentally, the always-on gap is real. If you close your laptop, Claude stops listening. For the workflow of asking Claude to keep working while you commute or sleep, Channels does not help unless you run Claude in a persistent background process. That is solvable, but it is extra setup that OpenClaw handles out of the box.

The feature is also Claude Code only. OpenClaw routes to any LLM. If your workflow spans Claude, ChatGPT, and Gemini depending on the task, Channels is not a replacement.

What the signal actually is

The interesting question is not whether Channels is better than OpenClaw. It is not, for many use cases. The interesting question is what it means that Anthropic shipped this at all.

Anthropic is one of the most cautious AI labs on deployment decisions. They do not ship speculative features quickly. That they shipped a native chat-bridge feature in research preview, before it is fully stable, says something about how seriously they take the demand OpenClaw surfaced.

The category of AI accessible via messaging apps that acts while you're away is no longer a third-party experiment. It is a native feature in a flagship developer tool. The next step is obvious: a version that is always-on, fully governed, with enterprise-grade audit trails and identity controls. That product does not exist yet from Anthropic or anyone else. But the direction is now clear.

If your team runs Claude Code, Channels is worth testing. The fakechat quickstart takes ten minutes. The Telegram integration takes twenty. The session-scoped security model is the right trade-off for most professional environments.

And if you are thinking about AI agent governance in your organisation, pay attention to why China banned OpenClaw from its government offices. The hybrid identity problem is not going away. The platforms are starting to take it seriously.

OpenClaw Is What Siri Should Have Been And That's the Problem

2026-03-23T00:00:00+00:00

For about fifteen years, the promise of a personal AI assistant has been just out of reach. Siri launched in 2011 and gave us voice-activated reminders. Cortana tried and mostly made people miss the Start button. Google Assistant got pretty good at answering questions you could have just Googled. The common thread: these tools answer when asked. They don't act.

OpenClaw is different. And in a few short months, it's become the clearest proof yet that the category of truly autonomous personal AI agents is no longer a research demo it's here, it's open source, and it's pulling credentials from your inbox.

What happened, and fast

Peter Steinberger an Austrian developer who previously built and sold PDF toolkit company PSPDFKit for roughly $119 million launched the project in January 2026 under the name Clawdbot. Within 24 hours it had 9,000 GitHub stars. Within a week, 60,000. Andrej Karpathy posted about it. David Sacks (the White House's AI and crypto czar) praised it. Jensen Huang called it "definitely the next ChatGPT" at Nvidia's GTC keynote and announced NemoClaw, an AI agent platform built around it.

The viral growth also attracted the usual parasites: crypto scammers sniped the @clawdbot X handle within seconds of a name announcement, a fake $CLAWD token briefly hit a $16 million market cap before crashing 90%, and Anthropic sent a polite trademark email pointing out that "Clawdbot" and its AI assistant "Clawd" were perhaps uncomfortably similar to a certain commercial LLM named Claude. The project renamed to Moltbot, then settled on OpenClaw open source plus the lobster mascot that had survived the chaos intact.

In February, Steinberger partnered with OpenAI, staying open source but gaining the resources to scale. The lobster had molted twice and kept growing.

What it actually is, architecturally

Strip away the hype and OpenClaw is an orchestration and routing layer, not an AI model itself. Here's the architecture in plain terms:

The agent lives in your messaging apps. WhatsApp, Telegram, iMessage, Slack, Discord, Signal. You text it the same way you'd text a colleague. There's no separate app to open, no context switch.

It routes to your LLM of choice. OpenClaw doesn't do the AI heavy lifting it sends your messages to Claude, ChatGPT, or Gemini (your call) and relays the response. The intelligence is rented; the orchestration is local.

It runs on your hardware. OpenClaw runs locally, which is why a Mac Mini has become a popular host. The local execution is also what gives it access to your files, calendar, email, and local services. No cloud intermediary sees your data but that also means no cloud provider is managing your security posture.

It maintains state across sessions. Unlike a chat interface that forgets everything when you close the window, OpenClaw persists context. It remembers what you told it last Tuesday.

The result is something that feels less like software and more like a junior employee who has been given the keys to your digital life.

The three things that actually matter

A lot of AI tools compete on model quality. OpenClaw competes on integration depth, and its three core differentiators are genuinely new:

Persistent memory. Most AI interactions are stateless every session starts from scratch. OpenClaw tracks your preferences, ongoing projects, and past conversations. This sounds like a small thing until you realise it means the agent can build a working model of you over time. It learns that you prefer bullet summaries over prose, that you always need Monday's briefing by 7am, that project X is the one where the client is difficult.

Proactive notifications. This is the feature that separates OpenClaw from every other AI assistant. It messages you. You can wake up to a text: "Here are your three priorities today, one email that needs a reply before 10am, and a reminder that your standing sync is at 2." You didn't ask. It just did it. For anyone who has tried to use AI as a productivity tool, this is the missing piece: most AI tools wait to be told what to do, which means you have to remember to ask.

Real automation. Depending on how you configure it: scheduled tasks, email triage, file organisation, form filling, smart home control, research threads that span days. The breadth is only limited by what APIs you're willing to wire it to.

The security problem and why it's bigger than OpenClaw

Here is where the honest analysis has to get uncomfortable.

In the early weeks of Clawdbot's existence, security researchers found hundreds of publicly accessible deployments with no authentication, exposing API keys, chat logs, and system access to anyone who could find the URL. By the time the dust settled, security firm Censys had identified 21,639 exposed instances primarily in the US, China, and Singapore. Koi Security found 341 malicious "skills" among the 33,843 available on the ClawHub directory.

Steinberger and the team moved quickly to patch specific vulnerabilities. But patching individual bugs is not the core issue.

The deeper problem was articulated clearly by Roy Akerman, head of cloud and identity security at Silverfort: "When an AI agent continues to operate using a human's credentials, after the human has logged off, it becomes a hybrid identity that most security controls aren't designed to recognize or govern."

Read that again. When OpenClaw is running on your Mac Mini, it is operating as you. It has your email credentials. It can send messages on your behalf. It can access files you have access to. And it does this continuously not just when you're at the keyboard.

Your organisation's security infrastructure was designed around human logins. It can detect when a human account suddenly downloads gigabytes of data at 3am. It cannot easily detect when an AI agent is doing something slightly unusual over a long period of time, because the AI agent looks like you, has your authorisation, and generates activity that looks entirely plausible.

This is not a problem any LLM provider can solve for you. It is an architectural challenge for every organisation that allows its people to use AI agents and right now, most organisations don't have an answer.

Should you care?

For personal use: OpenClaw is genuinely impressive and clearly points in a direction the whole industry is heading. If you're technically capable and have the appetite to configure it carefully including working through the security checklist at openclaw.ai it's worth exploring. If you want something that just works out of the box, it's not there yet.

For team or organisational use: Not yet. The security story is immature, the surface area is wide, and the category is still figuring out what "securing an AI agent" even means.

The bigger signal: OpenClaw is a milestone, not a finished product. It proves that there is a huge demand for AI assistants and that people want them badly enough to install and configure something genuinely complex. The next 18 months will produce more polished versions of this architecture from Steinberger's continued work with OpenAI, from competitors, and from enterprise software vendors who are watching closely.

The question worth asking now is: when this lands in your organisation, do you have a framework for governing AI agents?

The Dangers of Autonomous AI in Military Applications

2026-03-10T00:00:00+00:00

America's current war with Iran is a good example of the dangers of using artificial intelligence in war. A newly released video suggests that a US Tomahawk missile likely struck a girl's school in Iran, killing 175 people, most of them children.

US media has published many articles making it clear that the US military is using artificial intelligence in its military operations against Iran. Reports suggest that the US military is using large language models (LLMs) like Anthropic's Claude and OpenAI's ChatGPT for a number of tasks such as mission planning, logistics, and target identification.

I don't doubt that this strike was the result of an error in the target identification systems that the US military employed.

It seems pretty obvious that even at the Pentagon, the capabilities of large language models are poorly understood. Large language models can generate language with almost 100% accuracy, and this has given rise to a well-known cognitive bias called the halo effect. This bias colors our perception of everything else about a person or product simply because they excel at one thing — leading us to assume they are good at other things too.

For example, if a company produces really good TVs and then releases headphones, the halo bias would lead us to assume the headphones are of good quality as well.

Large language models are essentially mathematical equations that are very good at predicting the next letter in a sequence, based on the surrounding corpus of text. They cannot and do not think like humans do. Humans are biological systems; large language models are digital ones.

As a result, large language models exhibit a number of attributes that are very dangerous in the context of war and demonstrate their lack of fitness for military use.

These include:

No instinct for self-preservation
No empathy
Algorithmic bias

It is humanity's drive for self-preservation that makes humans open to compromise and negotiation — without which the human race would surely end.

Modern warfare is supposed to be conducted according to rules of engagement that have evolved through a combination of international humanitarian law, past conflicts, and professional military codification. These rules came about because of our ability to empathize with other human beings and our desire to inflict as little suffering as possible on others.

Large language models have been trained on data drawn from essentially all the content of the internet, extracted from websites and converted into machine-readable text. Anyone who has spent time on the internet can attest that this data is full of human prejudices. Because of this, large language models reflect these prejudices in their outputs and behavior.

Beyond these core issues, there are several other concerns with using large language models in a military context.

Flash Wars or Hyper Wars

In modern warfare, strategic advantage is gained by compressing the Observe-Orient-Decide-Act (OODA) loop. When adversarial AIs are engaged in conflict against each other, this loop — and the resulting tempo of battle — will accelerate beyond human comprehension. Artificial intelligence can act at superhuman speed, making it impossible for humans to react to or even follow its actions.

Inexplicability of decisions or actions

We do not currently understand how or why LLMs behave the way they do. These are effectively black boxes, with very little insight available into their internal workings. Current AI models are built to accept an input and predict the correct output. The model learns to do this by identifying patterns in its training data and repeatedly performing statistical calculations, reducing prediction error with each iteration. How the model identifies those patterns, or determines how to reduce the errors, is not well understood.

Hallucinations

Large language models can generate factually incorrect or completely false responses when given a question or task where the training data is sparse. The model fills in the gaps with the most statistically plausible-sounding words, which may have absolutely nothing to do with reality. Sometimes the model is over-fitted to the data on a specific topic, causing it to make connections where none exist. In other cases, it may be under-fitted, causing it to guess based on little more than general context. Since large language models have no agency and no real-world experience, they lack the mental model of the world that humans rely on when making judgments.

In a military context specifically, cross-model hallucinations — which are common in AI vision models — present a significant likelihood of error. The AI may see an object in an image that is not actually there. This may have been a factor in the strike on the girls' school in Iran.

These are some of the broad and well-known reasons for not using artificial intelligence in military applications. This technology is relatively new, and the full spectrum of its dangers is yet to be discovered.