--- title: "Akshay πŸš€ on X: Self-Repairing Agent Harness" url: https://stacklist.com/card/178669c7-9359-42cd-9d3d-7d01bf545cdc source_url: "https://x.com/akshay_pachaar/status/2064051835636498924?s=12" stack: https://stacklist.com/c/technology/stack/1659549d-373d-4391-ba12-5a14d40c19ed summary: "Opik is an open-source AI observability platform that automates the repair loop for AI agents by combining tracing, diagnosis, and automated code fixes through its integrated Ollie coding agent. It addresses the gap in current observability tools by not just showing what happened, but diagnosing why it failed and proposing verified fixes to prevent regression." tags: "ai-agents, observability, debugging, opik, harness-repair, llm-monitoring, agentic-era" key_entities: "Akshay Pachaar (person), Opik (technology), Ollie (technology), LangGraph (technology), CrewAI (technology), Cursor (technology), agent-harness (concept), observability-platform (concept)" classification: "analysis" content_hash: "sha256:f98e09d2f6c58ed30080ac18fe93079a15b95fcc7c7913ada6b8bb4766515429" acp_version: "0.2" token_counts_approximate: 1778 visibility: public agent_accessible: true status: "final" --- # Akshay πŸš€ on X: Self-Repairing Agent Harness Akshay πŸš€ @akshay_pachaar Your Agent Harness Should Repair Itself When an AI agent fails in production, your observability tool shows you exactly what it did and almost nothing about how to fix it. You get a clean trace of the run, every model call and tool that fired, how long each step took, and what it cost in tokens. What you don't get is why it broke, the change that would fix it, or any promise the same thing won't happen again next week. So you scroll through the trace span by span, form a theory about what went wrong, write a patch by hand, and hope it doesn't break something that was working before. Then a new model ships with a fresh batch of failure modes, and you run that whole manual loop from the top. The real bottleneck isn't your observability. It's everything that has to happen after the trace lands on your screen. Cursor recently shared how much engineering goes into the harness around their agent, the layer of prompts, tools, and checks wrapped around the raw model. A better harness on the same model gives far better results, and that work never really ends. This is where every observability platform leaves you. It answers what happened, then hands back why it happened, what to change, and how to keep it from breaking again. That gap is the loop most teams are stuck in today. Here's why it keeps reopening, and what it finally takes to close it. Why Current Observability Breaks at Scale Most agent observability platforms deliver a trace and stop. You get a span tree, latency numbers, token costs, and a dashboard. What you don't get: why it failed, what to fix, or any guarantee it won't break again. "What happened" β†’ the platform handles this "Why it happened" β†’ manual "Here's the fix" β†’ manual "This won't break again" β†’ manual That was a reasonable product in 2023. It's the wrong abstraction for teams running agents in production today. The problem compounds itself. Every model upgrade introduces new failure modes. Every new tool adds new edge cases. The harness gets more complex faster than any team can manually track and repair. Here's the stack that does it. Opik: AI Observability & Evals For the Agentic Era Opik is an open-source logging, debugging, and optimization platform for AI agents and LLM applications. Opik is built around the premise that this loop should be automated, not staffed. The Four-Layer Stack Opik's architecture is one connected workflow. Trace β†’ Ollie diagnoses β†’ Ollie proposes a fix β†’ fix is applied and verified β†’ Test Suite locks the failure as a regression test β†’ back to Trace Here's each layer. Layer 1: Tracing Every LLM call, tool invocation, and retrieval step is instrumented automatically with a single decorator. Works with LangGraph, CrewAI, and 50+ frameworks out of the box. Every trace records which agent configuration was active for full reproducibility when you need to rerun a failing input later. That gives you full visibility. But visibility alone doesn't fix anything, which is where Layer 2 comes in. Layer 2: Ollie Every other observability platform stops at "here's your trace." Opik goes from trace to fixed code, powered by Ollie. Ollie is a coding agent built into Opik. One agent, full context. Without any code access, Ollie reads span trees, identifies failure modes, and explains the causal chain across every LLM call. Ask it, "why did the final answer ignore the retrieved context?" It walks the full span tree and surfaces the root cause. Run opik connect from your project root, and Ollie upgrades to full code-fix mode: Reads your source files Identifies the exact lines responsible Proposes a diff; nothing changes without your explicit approval Once you approve, Ollie reruns your agent against the exact inputs from the original failing trace, streams the new trace for side-by-side comparison, and locks the original failure as a regression case in your test suite. Bad trace β†’ root cause β†’ diff β†’ approve β†’ rerun β†’ regression locked Layer 3: Test Suites Most eval workflows: build a labeled dataset, define a numerical metric, compare floats. That model works for researchers. It doesn't match how engineers think about quality. Opik replaces it with plain-English assertions. Opik converts those into LLM-as-a-judge checks under the hood. Clean pass/fail per test case. The part that changes the workflow: every failing trace you debug automatically becomes a new test case. The suite grows from real production failures, not synthetic scenarios someone wrote in advance. Every cycle, the harness gets harder to break. But even with a growing test suite, you still need a safe place to test changes before they ship. That's what Layer 4 is for. Layer 4: Agent sandbox Most playgrounds are prompt playgrounds. You change a system prompt and rerun one LLM call. That answers the wrong question. The production question is, what happens to the entire agent graph when I change this. Opik's Agent Sandbox runs the fully instrumented agent end-to-end inside the UI. Change a prompt, swap a model, add a tool, and watch how the whole system responds across the full spanning tree. Every sandbox run produces a complete Opik trace. Non-developer stakeholders, PMs, domain experts, and QA can safely test configurations without touching git. The Flywheel in Practice The layers aren't independent features. They're one loop. Instrument with @opik.track. Declare an opik.Config. Something fails in production. Ollie reads the trace, reads your source, and proposes a fix. You approve. Ollie reruns the agent in the Sandbox against the original failing input. Fixes passes. Save it as a new Blueprint. The environment pointer promotes to staging. Original failure locked as a regression test. The next failure enters the same loop. Every cycle, the harness gets harder to break. ​Closing the Loop Observability that ends at the trace made sense when agents were simple. Once they hit production, the real work is everything after the trace, and that is the part Opik runs for you instead of leaving it on your plate. The whole stack ships in the open, Tracing, Ollie, Test Suites, the Agent Sandbox, a 6-algorithm Agent Optimizer, and 50+ framework integrations, with the project past 19.3K stars on GitHub. It self-hosts in three commands: The manual loop Cursor describes is the one Opik closes on its own, from a bad trace all the way to a locked regression test. It is worth a look if you are running agents in production. Check out Comet ML and Opik β†’ ( don't forget to star 🌟) What's the current state of observability in your agent stack, and where does the debugging loop break for your team right now? If you are building an open-source tool that AI engineers would love, reach out. We only cover tools that pass our own test, so we'll try yours first and write about it only if it holds up. Thanks to Comet ML for sponsoring today's issue. 6:28 PM Β· Jun 8, 2026 1.7M Views 40 211 1.6K 3.9K