AI Doesn't Need to Run Everything: Notes from ClawCon Chicago.

I went to ClawCon at the University of Chicago last week half expecting to feel like a fraud.

My concern was specific. I had been skeptical of OpenClaw since it went viral earlier this year. The framework is genuinely impressive from an engineering standpoint. It runs as a persistent daemon, connects LLMs like Claude or GPT to your apps through messaging interfaces, and keeps an autonomous loop running around the clock. But I could never identify many real problems where that persistent autonomy was actually the point. I kept waiting for someone to change my mind.

Three hours and one very good hot honey pineapple pepperoni pizza later, nobody had.

What OpenClaw actually is

For context: OpenClaw started as a side project by Austrian developer Peter Steinberger in late 2025 and grew faster than anything GitHub has seen. Over 250,000 stars. Sam Altman hired Steinberger directly in February 2026, and an independent foundation now stewards the project. Nvidia's Jensen Huang called it "probably the single most important release of software, you know, probably ever" at GTC 2026. That is either prescient or outstanding conference hype.

The framework works like this: you install it on your own hardware, wire in an LLM as the brain, connect it to your messaging apps and productivity tools, and it runs a continuous loop. Receive input, reason, act, store memory, repeat. You interact through Telegram or WhatsApp as if texting a very capable assistant who never sleeps.

That last part is the hook. It is also where most of the confusion starts.

Three demos. One pattern.

Every presenter at ClawCon was doing something genuinely interesting. The real takeaway was that none of them needed OpenClaw to actually do it. Here is what that looked like in practice.

The shrimp tank

A college student had wired OpenClaw and Claude's vision capability to a live stream of his shrimp aquarium. He could message it on Telegram and ask "how are they doing?" or "has there been any movement in the last five minutes?" A Raspberry Pi collected temperature and water chemistry readings. Every morning, a summary landed on his phone.

It was cool. Then I started thinking about what the AI was actually doing.

The vision and chat layer earns its place. Claude synthesizing meaning from a live video feed and responding naturally over Telegram is not trivial. That interface is a real AI use case.

The operations layer is not.

If this were a commercial shrimp operation, here is what you would build: threshold alerts wired directly to the Raspberry Pi readings, automated triggers that activate heating or cooling when temperature drifts, a filter notification when sediment crosses a limit, and a dosing mechanism tied to pH levels. None of that requires a language model. It requires a rules engine and a few sensors.

AI was the right tool for the interface. It was not the right tool for the operations. That distinction matters more than it sounds.

The coffee finder

Someone built a Chicago-specific coffee shop finder with a custom review mechanism. Polished, fast to ship, genuinely useful to look at. The real question it raised had nothing to do with the technology.

How big is the moat?

If a solo developer can build a polished, functional app in a weekend, so can the next person. And so can a company with a full engineering team behind it. The question to ask before you publicize something like this is not "can I build it?" It is "can anyone copy it before it grows?" AI compressed the execution timeline. It did not make the idea defensible.

That is not a knock on the builder. It is the new reality of building with AI.

The moat question has always mattered. What changed is the timeline. It used to take months to ship something polished enough to attract copycats. That buffer is gone. Proprietary data, distribution, and network effects are still how defensible products get built. AI does not change what makes something hard to copy. It just removed the runway that used to buy you time to figure that out.

The sales management workflow

This one stuck.

The problem was real and messy. Sales teams are fluid. Reps join and leave. Accounts transfer. An SDR handles the first conversation, a rep picks it up, a sales engineer gets pulled in. Third-party tools hold data. Notes live everywhere. Historically, any one person trying to understand the full picture of an account had to dig through all of it manually. Slow, disorganized, and entirely dependent on whoever kept the best notes.

He built an internal sales knowledge base using existing MCP connectors to their tools. No new infrastructure. Then he built a set of skills and workflows in Claude Cowork so the system could prep before client calls, flag risks in QBR meetings, and keep managers informed without them having to chase individual reps.

Two things made this the best demo of the night.

First, it solved a problem that actually needed AI. The task requires reading unstructured content across multiple sources, inferring intent, and synthesizing something coherent. That is not a rules engine problem. That is a language model problem.

Second, the failure mode is tolerable. If Claude misread a note, the rep catches it and makes a joke about their own chicken scratch. Nobody misses a deal. Nobody fires off an angry email. The worst case is a mildly awkward moment in a meeting. That is an acceptable error rate for a tool that replaces hours of manual prep.

“More information, even imperfect information, beats less.”

What Michigan announced

The University of Michigan launched the Institute for Agentic Computing in partnership with the OpenClaw Foundation. Two goals shown at ClawCon: 100 new agentic systems engineers trained by end of 2026, and a collaboration with the Booth School of Business at the University of Chicago to support 100 new agentic systems startup founders.

Both goals are worth watching. Not because OpenClaw is about to autonomously run your supply chain. Because the gap between what these frameworks can actually do and what most people know how to build with them is wide. Training engineers and founders to close that gap is the right bet.

Two questions worth asking

Before building anything with AI, run through these two:

Does this solve a real problem that real people actually have?

Does this problem require a language model, or would a script or rules engine do the job?

ClawCon did not change my mind about persistent autonomy. It confirmed that the most interesting work happening with AI right now is not about agents that run forever. It is about understanding what a language model does better than anything else, and scoping your work to that.

The pizza was also very good.