Traceloop from ServiceNow

This video was uploaded by OpenClaw. I didn't do anything. I just told Omri Barak to send the video to my OpenClaw bot, and then it just uploaded it to my LinkedIn profile (hopefully!). This is what the future looks like. A lot of people have been asking me lately - what's the big deal with OpenClaw? Why is everyone talking about it? In my opinion, it comes down to 3 things: 1. Cron Jobs. Not a new concept - they've been around since the early days of Linux. Schedule something, and it happens. Simple. With OpenClaw, I've been using one to scrape Tel Aviv apartment listings and get a WhatsApp message every day at 7pm with the results. Old idea, powerful new use case. 2. Messaging channels. OpenClaw plugged into WhatsApp, Telegram, and more. And this matters more than people think. When I interact with it over WhatsApp, it genuinely feels like texting a person. The interface isn't an app or a dashboard - it's a conversation. That changes everything about how you think about automation. 3. It has its own computer. It can browse the web, read and create files, check my LinkedIn, install packages - basically anything you'd do on a machine. It's not just answering questions. It's actually doing things. Take those 3 ingredients - scheduled tasks, natural messaging channels, and a computer of its own - and you get something that feels less like a chatbot and more like a digital employee. Are we one step closer to AGI? Maybe. But we're definitely one step closer to a world where agents just... handle things for you. What would you automate first?

We all saw the demos of Claude Cowork last month. They looked incredible. But honestly? I think we’re getting a little ahead of ourselves. Anthropic isn't quite solving the real problem yet. If you’ve ever tried to build a genuine AI copilot, you know there are two massive headaches you have to deal with: 1. Context Engineering: How do you engineer and build the right context so that the AI can actually answer your questions or solve your problem? For that, you can either use chunking (so you build a context that is right for answering a specific question), or using an agent. Then, you just give the agent the entire directory of data that you have, and then the agent can selectively choose the data that it needs to actually answer or solve the problem. 2. Integrations: This is much bigger, because you need to actually connect different data sources to your AI copilot or agent. All of this is largely solved for code just because code is basically text files in your computer. So you can give Claude Code access to your desktop directories and it just works. When thinking about productivity or an AI copilot for everything else, you need to connect to a lot of different tools. Think Gmail, Zoom, Calendar, and Notion, and many, many others. We tried to solve it with MCP, but it didn't really work. So, here is a wild thought. Maybe the solution isn't better APIs. Maybe the solution is just… files. Imagine if your Notion workspace was just a folder of markdown files on your desktop. Imagine if your Zoom calls were just text files sitting in a directory. Suddenly, you don’t need complex integrations. Claude Code could just read your "productivity stack" the exact same way it reads a Python script. I’m seriously thinking about testing this workflow. Has anyone else tried treating their entire work life as local files?

Debugging LLM conversations is a nightmare. You look at traces. You look at spans. You see inputs and outputs. But you still have no idea what your user actually saw. You keep jumping between logs trying to figure out what happened. So we built Sessions. You see the chat the way your user sees it with all the tracing details right next to it. Click on any span, see the prompts, the outputs, the guardrails. All in one place. No more guessing. No more jumping around. How do you debug your conversational AI today?

OpenAI released tracing for their agents framework. That’s it. I guess I need to shut down the company, right? I’m done. Well… not really. And yes, I might be biased, but hear me out. If you want real observability for your LLM application, you can’t rely on OpenAI. Why? Because OpenAI can only see their side of the story. They don’t see your tools. They don’t see your business logic. They don’t know what’s happening between your app and the model. Let’s say you’re building an agent and want to understand tool usage: Which tool was called How long each call took What the inputs and outputs were OpenAI’s tracing won’t help you here. You need something that sits on your side of the stack. And there’s something even more important: vendor lock-in. What happens when you want to switch from OpenAI to Claude, or different LLM? With OpenAI’s native tracing, you’re stuck. The UI, the telemetry, the insights—none of it carries over. But if you use a client-side observability tool, something model-agnostic, you get full visibility and flexibility. So no, I’m not shutting down the company. OpenAI tracing is a nice feature. But it’s not a full solution. If you want to build something that lasts, start with your own observability stack. Don’t give that control away. What’s your take? Are you sticking with OpenAI tools or going vendor-neutral?

So, You've built an AI agent and you want to make sure it's not hallucinating or just making mistakes. How do you do that? LLM as a judge. Here are some best practices on how to use it properly. 1. Building the prompt. Always use Yes or No questions. Don't ask your LLM "How good is this response for this question? Give me a number." to grade the response between 1 and 10. This will never work properly. But rather ask it, "Does this answer contain facts that are not relevant to the user question?" - the LLM can do that pretty well and will give you accurate results. 2. Choosing the right model. Some people will tell you that you have to use the same model to grade a result; others will tell you exactly the opposite - you *have* to use a different model. Actually, there isn't any research that prove this way or the other, so my suggestion is to use whatever you have. Just make sure it's a large model - so for example use gpt-5.2 and not gpt-5-mini. 3. Repeated runs improve quality. If you run the same judge prompt multiple times on the same response and average the responses, the accuracy will get higher. Have some more ideas? Better judge prompts? Write me in the comments