Latest from DarkhorseOne

Across industries, AI adoption is increasingly narrated through a single lens: headcount reduction. Having spent the past couple of years advising SME leadership teams on their AI strategies, I think this is a costly category error — efficiency and empowerment are not the same outcome, and most organisations are quietly choosing the wrong one. This article sets out the real distinction between cost-cutting AI and capability-building AI, and why only one of them holds up over time.

As AI agents become more capable, the real challenge is no longer intelligence alone. The harder problem is governance: how to make agents reliable, auditable, and safe in real work. This is why harness engineering matters. It is not simply a set of prompts or workflow tricks. It is the emerging discipline of building the operational doctrine around agents: rules, procedures, evidence standards, validation paths, exception handling, and audit trails. In that sense, harness engineering resembles the logic of the British legal system. It does not rely only on abstract rules. It learns from cases, formalises procedures, manages exceptions, and continuously refines the system through practice. This article argues that the best way to understand harness engineering is not as a productivity hack, but as the beginning of a rule-of-law framework for autonomous systems.

After resubscribing to Claude Code Max 20x, I encountered a result that challenged a long-held belief: that experience can compensate for tool limitations. Despite using advanced models like GPT-5.4 xhigh in Codex, a critical system issue remained unresolved for nearly a week—even with precise guidance on suspected root causes. However, when the same problem and prompt were presented to Claude Code with the Claude Opus 4.7 model, the issue was diagnosed and resolved in a single interaction. This experience forced a reassessment: the gap between AI tools is not marginal—it is decisive. In the era of AI-driven development, choosing the right tool is no longer about cost optimisation or pride. It is about execution efficiency and outcome certainty.

As AI coding workflows become more deeply embedded in day-to-day software development, a new operational problem is starting to appear: usage management. For many developers, the standard Plus plan is not enough for sustained Codex usage, while the Pro plan can feel excessive for their actual workload. The practical middle ground is often to use multiple accounts, but that creates a new layer of friction around monitoring quota, checking reset windows, and repeatedly logging out and back in to switch accounts. This is exactly the problem that led us to build show-codex-usage. It is a lightweight local shell tool that monitors Codex usage across multiple ChatGPT-authenticated accounts, keeps a local auth pool updated, and allows instant account switching through a simple terminal interface. Instead of treating account management as a manual and disruptive process, the tool turns it into a fast local workflow. This post explains the problem, why existing workflows are clumsy, how the tool works, and why small utilities like this matter more than they may first appear.

DarkhorseOne has released a new Model Context Protocol (MCP) server that enables AI agents to retrieve structured information about members of the UK Parliament. The UK Parliament Members MCP Server provides programmatic access to data about Members of the House of Commons and the House of Lords, exposing this information as MCP tools that AI agents can call during reasoning or task execution. Project repository: https://github.com/DarkhorseOne/mcp-servers/tree/main/servers/uk-parliament-members This release is part of our ongoing effort to build a collection of MCP servers that bridge AI agents with real-world public data systems.

Over the past decade, most software has been built around interfaces — menus, dashboards, forms, and workflows designed for humans to operate step by step. Just six months ago, we were building PrimeForge in exactly this way: a traditional SaaS platform for SMEs, enhanced with AI features running quietly in the background. But the rapid emergence of AI agent frameworks changed the equation. When systems can understand natural language intent and autonomously execute tasks, the role of traditional software interfaces begins to disappear. The AI input box is quickly becoming the primary entry point for software, while agents orchestrate tools and services behind the scenes. PonyBunny was born from this realization. Rather than continuing to evolve a traditional SaaS product, we began building a platform designed for the agent-first era — where software is no longer written primarily for humans to operate, but for AI agents to execute on behalf of users. The goal is simple: make AI-driven task execution reliable enough for real-world business use, especially for small businesses and solo founders who need powerful automation without complex systems.

Today is 28 February, the final day of a month that has fundamentally changed how I think about AI agents. After weeks of intense development, PonyBunny has finally reached a critical milestone: it can now understand user intent, automatically define objectives, break them down into executable sub-tasks, and coordinate sub-agents to complete the work. The system then collects the outputs, evaluates them using an internal scoring mechanism, and only returns results that meet predefined expectations. Human-readable outputs are generated automatically, while the artifacts produced during execution are preserved locally for delivery or future use. Most importantly, every step of the process is recorded through a complete audit log, making the entire workflow traceable and inspectable. For the first time, PonyBunny feels less like an experiment—and more like a real operating system for AI agents.

By early February 2026, the tool once known as ClawdBot had been renamed twice and finally emerged as OpenClaw. Meanwhile its GitHub repository exploded past 200,000 stars, and suddenly it felt like everyone in the developer world was talking about it. I was one of them. After two weeks of intense, hands-on use, a deeper conclusion became unavoidable: the software industry may be approaching a structural shift. Software is no longer primarily built for humans to operate, but increasingly for AI agents to orchestrate. Complex menus, dashboards, and command memorisation begin to lose relevance when agents can plan and execute workflows themselves. For companies like DarkhorseOne, whose products were originally designed as SaaS tools for human users, this realization forces an urgent strategic decision: adapt immediately—or become obsolete.

In January 2026 I stumbled upon a tool that genuinely unsettled me: ClawdBot, At first glance it looked like yet another AI agent wrapper. But once I started using it with GPT-5.2, the implications became difficult to ignore. Tasks that previously required carefully designed automation pipelines—especially the sort of multi-step workflows I would normally build in n8n—were suddenly completed through a single conversational instruction. Data retrieval, reasoning, tool usage, and execution were orchestrated automatically. What shocked me was not just the efficiency. It was the realization that the traditional paradigm of software—menus, dashboards, forms, and automation builders—might be quietly collapsing. This post describes my first encounter with ClawdBot, the technical shift it represents, and why it left me both excited and deeply uneasy about the future of software.