Self-improving Agents !! In an earlier post, I shared how I designed agent harness around a simple principle: “treat model as intelligence provider”. A model can reason, generate, and make decisions, but how we make agents responsible for the quality of their own work? One of the core capabilities I’ve implemented in harness is a self-improvement loop: Generator → Examiner → Correction → Re-examination With examination and correction built into the agent workflow, quality no longer depends entirely on getting the best possible result from a single model invocation. Models can be swapped or upgraded while the agent maintains the same quality contract. Here, - model supplies intelligence. - agent uses that intelligence to execute tasks and meet a defined quality bar. - harness provides the execution environment, permissions, isolation, observability, and handoffs. That’s how I’m building trust with increasingly capable agentic systems.

In knowledge work (ex: dealing with documents), model output can differ on every run. I ensure reliability by verifying whether the output holds semantic relevance and represents necessary facts, using Evals. When quality is not met, output is routed to a correction loop, or SME review. How are you ensuring reliability of your agent output?

Architecturally, LLMs have inherent gaps compared to traditional software, but they are closer to how humans operate. Agents must be designed to emulate systems that strive for the best-quality outcomes, rather than necessarily being 100% correct every time.

Treating the model as an insider risk is exactly how we built our agent harness. - The model is an intelligence provider, swappable at any time - Access is governed by explicit, scoped permissions - Arbitrary execution runs in a sandbox, never on the host - Every action is observed through OpenTelemetry - Outcomes are evaluated, with correction built into the loop Build trust with Super Intelligence !

Lately, I’ve been captivated by how much @OpenAI Dots can actually get done. I think there’s a massive opportunity emerging for companies building specialized services as ChatGPT plugins. It reminds me of the early days of the iPhone App Store. Developers didn’t need to build their own distribution platforms. They focused on building great apps. ChatGPT could create a similar ecosystem, except this time, companies won’t necessarily need to build their own apps, chat interfaces, or AI harnesses. They can focus on their domain expertise and expose it as services that AI agents can use. The App Store distributed software. ChatGPT could distribute intelligence and execution. I think we’re still underestimating how big this could become.

Spent the last few hours working with ChatGPT Dots on product and project management. I’m genuinely excited about this. I connected it to GitLab, Slack, Outlook and Teams, then asked it to understand two projects from the actual repos, specs and ongoing work. We set up three GitLab boards. Took a feature spec and turned it into an epic with stories, acceptance criteria and dependencies. Found stale issue descriptions and separated code that had merged from work that still needed deployment or validation. A lot of this happened over voice. I talked through what I wanted, challenged the structure, changed the scope, and reviewed the results in GitLab. What stood out was the follow-through. We could move from discussing a product direction to having concrete, linked work for Codex to pick up. There were setup hiccups, and I’m still testing how far the implementation coordination can go. But this already feels useful as part of how I run product and engineering.

Brag your @OpenAI ChatGPT/Codex usage. Posting mine.

I tested @OpenAI’s GPT-6 Luna on a long, source-heavy agent task. In this run, it followed an assigned workflow: → investigate sources → produce structured output → hand it to a separate examiner → make a targeted correction → re-examine. The final result was accepted with no outstanding findings. * Time: 13m06s * Input: 3,597,234 tokens * Cached: 3,478,016 tokens (96.7%). * Output: 24,095 tokens, including 7,255 reasoning tokens. * Estimated cost: $0.059 One run isn’t a benchmark, but it shows Luna can preserve a multi-stage workflow through tool calls, independent feedback, and correction. At this level of workflow capability and cost, what is the moat for self-hosted models?

Completed issues since I posted about this.

Stop benchmarking models in isolation. Benchmark the model + harness. I’ve been testing GPT-5.6 Luna xhigh through Codex on a fairly complex agentic workload. The Codex harness uses separate Planner, Generator, and Evaluator agents. For the Luna/xhigh run: - Runtime: 9m42s - 4 independent sessions: coordinator + - Planner + Generator + Evaluator - 10 agent messages - 9 collaboration calls - 1.88M tokens processed - 94%+ input tokens cached - 14.7K output + reasoning tokens - Total cost: $0.074 More importantly, it worked really well. The model matters. But the harness determines how much of that model you actually get. With Context engineering, Caching, Tools, Evaluation and Retries, a good harness can make a smaller, cheaper model punch well above its weight. Nice work, @OpenAI.

Agent skills have a distribution problem. Today, harnesses often need skills to be packaged, installed, or pulled from a separate registry. Skills Over MCP offers a cleaner model. It serve skills as MCP Resources and let the harness discover them dynamically. ChatGPT Plugins already support this natively. MCP as a distribution layer for agent skills is the right direction. Ref: aaif.io/blog/skills-over-mcp

Reviewing reasoning traces reveals a lot about how context, skill and instructions can influence coding agent performance . So, before blaming a model for poor outcome, check what you are feeding it.

OpenAI ’s Codex on ChatGPT app has changed how much I can get done from my phone, without sitting in front of a computer. With Astra’s computer use capabilities, Codex manages end-to-end SDLC: building, testing, reviewing, and deploying. Phone is becoming my daily driver. Agents handle the execution while I steer the work. @OpenAIDevs how has been your experience? My week’s usage stats:

There’s huge excitement about GPT-6 Astra’s capabilities. Astra at low reasoning does the work I used GPT-5.6 Sol high or extra. @OpenAI‘s own evals show stronger results with fewer output tokens. I default Astra to low effort, and raise effort only when the eval says so. Why does it matter? Reasoning tokens are the model’s internal chain-of-thought computation, but they are not exposed as readable output. They are generated internally before visible output, and billed at the model’s output-token rate. Higher effort generates more reasoning output. So if usage reports: { "output_tokens": 11860, "output_tokens_details": { "reasoning_tokens": 10524 } } you pay for all 11860 output tokens, including the 10524 hidden reasoning tokens. At Astra’s pricing if $10 per 1M input tokens and $50 per 1M output tokens, higher effort can burn through your budget sooner. #Tokenomics_101 Astra is stronger at general instruction following. It is recommended to align AGENTS.md and Skills as per prompt guidelines before using Astra in your agents. developers.openai.com/api/do…

The model isn’t the system. The coding agent isn’t the system. They are part of the solution. Your agentic workflows shouldn’t go down with them. Recent Grok and Claude outages, along with OpenAI’s planned cutoff for Cursor, highlight why portability matters. I have been building an agent platform where a harness coordinates a pool of ephemeral workers. Each worker can run a different coding agent and model combination: Claude | Codex | Grok | Muse. Run state, traces, and artifacts are persisted in object storage across workers. The harness owns the outer loop: scheduling, execution graphs, state management, retries, evaluation, reassignment, and multi-agent coordination. The worker owns the inner loop: a coding agent capable of spawning its own subagents to complete the assigned task. This came in handy recently when I switched from Grok to Muse Code without changing the rest of the workflow. As builders, we should be designing for this from day one. Build the harness, own the workflow, and treat models and coding agents as replaceable parts.