Your Friend's Guide to Agentic Engineering

Agents, Harnesses & Tooling Overview

We’ll start with some quick definitions so you know what I mean when I say ‘harness’ or ‘agent’. There is some conceputal overlap between the two.

Understanding the fundamentals of these concepts is valuable for a few different reasons, to my mind:

• We’re still ‘early’ on agents for software production, AI’s native domain. You might think of writing agents as fruitless when there are already so many harnesses; I would argue with tools like OpenCode as a starting point, there is tremendous upside: and we’ll discuss companies doing exactly this (building on OpenCode) in the Harnesses section.
• We have barely started writing harnesses for purposes outside of software production, which is where e.g. YCombinator is investing heavily in now.
• Knowing the fundamentals helps you evaluate your options and understand flaws in today’s harnesses, the tool you’re probably going to be writing the majority of your code with.

Building your own agent is not the equivelant of scaling a mountain. Thorsten Ball (working on Amp at SourceGraph) provides a great illustration of just how easy it is to implement (a simple version) for yourself, in How To Build An Agent.

With this context, it probably isn’t a surprise to learn that the harness you use impacts the quality of the agent output, measurably. There are consequential, opinionated decisions being made on what reaches the model at this layer of the cake.

We don’t have to sit in wonder as to what a production implementation might look like, OpenCode is fully open source and very popular (~650k users and growing nearing 1M MAU now).⁴

Harnesses: Codex, Cursor, Open Code, Amp, Claude Code

As a litmus test to tell how familiar you are with the state of harnesses, consider the below quote. I don’t necessarily endorse it, but it’s also not an extreme viewpoint (it was probably a deliberately provocative comment to hype a video):

There are a number of harnesses worth discussing, but we’re going to start with OpenCode as it’s open source & model agnostic, which we can take advantage of to understand it’s constituent parts. Now that OpenCode are slowly rolling out their own token subscription plans (OpenCode Black - but very limited availability atm)⁵ it’s firmly becoming my #1 recommendation.

OpenCode

Open SourceFree ModelsModel AgnosticDefault Recommendation

OpenCode has two great clients to use, a TUI based on the team’s (also open source) OpenTUI, and the Desktop app (Windows, Mac, Linux) alongside extensions for VS Code, Cursor, Zed, Windsurf, VSCodium.

The below visualisation is intended to illustrate the core loops of the harness, needless to say there is some abstraction.

There’s some really nice decoupling of the harness from not only models, but also the client. To interface with models, OpenCode utilises Vercel’s AI SDK. As a decoupled interface to the client side, OpenCode runs a HTTP server, Hono, to expose harness sessions to potentially multiple clients. This is great for flexibility: running OpenCode on your own machine, or a VPS, affords the ability to share sessions between your IDE, terminal, or likely a phone client (in the future), ideally over a VPN like Tailscale.

The HTTP server is implementing the open source Agent/Client Protocol to achieve client agnosticism, which specifies generic capabilities of both agent and client. OpenCode is implementing the ‘agent’ side:

• initialise,
• new session,
• load session,
• new prompt,
• setModel,
• setMode (plan/execute).

Putting the architecture aside, OpenCode often provides access to decent, free models to work with. At the time of writing this included:

• Big Pickle,
• GLM-4.7,
• Grok Code Fast 1 &
• MiniMax M2.1.

It’s important to keep in mind that you can bring your Claude* or Codex subscription to OpenCode, and use the subscription’s models (Opus, Sonnet, GPT 5.2 etc depending on subscription) via the OpenCode harness. OpenCode is agnostic to models (besides recommending some that integrate particularly well) unlike Claude Code and Codex.

Aside from folks regarding the OpenCode harness on par with Claude Code & Codex, the value proposition of having a hackable harness is tremendous. Ramp wrote up their approach to this to produce Inspect.

Hacking on it isn’t solely the domain of large companies; one dev went ahead and spent $24,000 worth of tokens to build oh-my-opencode. My favourite feature of this plugin, borrowing conceptually from Amp perhaps, is the agent specialisations (a handful with a different purpose / system prompt) to best answer your prompt - elaborated on in the Amp harness section.

To summarise: OpenCode is a harness you’ll want to be across. As an open source solution it’s likely to scoop up other harnesses’ features (and has been, e.g. thread sharing from Amp), the free models are pretty good, and the opportunity to hack on it is a killer feature for dev teams to build a platform on.

*See Claude section below for why Claude is striken through. Even though OpenCode circumvented the Anthropic block, doign so with your account is a TOS violation.

Codex

Default RecommendationOpen Source

If you don’t want to read more about harnesses, but want access to a leading model, ideally have your employer pay for Codex Pro, install it in your terminal of choice and you’re ready to go.

The primary reason I suggest this to get started, aside from the strength of the underlying model, is that the ~$200 plans are tremendous value once you start chewing through tokens on long-running tasks, especially running tasks in parallel. The price you are paying for these is far lower than the equivelant token capacity via API consumption pricing, assuming decent consumption of your limits, which is why power users subscribe to multiple plans.

Comparing strictly lab’s model/harness offerings: Claude and Codex seem to leapfrog each other regularly, but the underlying models are now good enough that you don’t need to spend time deciphering which one is ‘best’ month-to-month anymore, you can achieve what you need to do with either. If you simply must know the best option right now, a recent review of Codex with GPT 5.2 by Peter Steinberger would seem to put it ahead of Claude, for the moment.

Additionally, many ecosystem tools are now built to use your Claude Code Codex subscription to leverage the model on your behalf, at less than the API pricing of token consumption. Standout examples include:

• Conductor which we discuss later on in Orchestration,
• OpenCode as discussed earlier,
• Clawdbot by Steinberger (wrote the Codex review just above) which is sort of like an open source Poke leveraging Claude/Codex in your chat apps (SMS / WhatsApp / Signal etc). We discuss Clawdbot further below at the end of this chapter.

I also enjoy Claude Island as a sort of HUD living in my Macbook’s notch for when Claude Code needs input or is done, until my cancelled subscription expires, but there’s a fork for OpenCode too.

Cursor

Full IDEModel AgnosticVisual Editing

Probably doesn’t need much introduction given how Cursor took off in 2025. It’s the most prominent VSCode fork, and still the solution I use to review large amounts of code, and to write code by hand (albeit not for learning new languages, for that I use Zed with AI turned off) as Cursor’s autocomplete seems to be better than any other.

Like OpenCode, Cursor is model agnostic. Cursor also has clients for mobile, Slack and issue trackers, and they recently acquired Graphite (code review AI). I admittedly haven’t used the visual editing features recently released as I mostly work from Claude Code in Ghostty & Conductor.

If you’re most comfortable in an IDE, Cursor is what I’d recommend with the caveat that any harness offering model consumption via the models APIs’ (as opposed to a lab-specific subscription) is seemingly absurdly expensive.

Amp

Best ResultsMulti-Model

Boy do I feel bittersweet about this one; opinions incoming.

Throughout 2025 Amp, for mine, was/is the harness producing the best output from coding models. I genuinely believe the folk at Amp are ahead of the competition in thinking about how to leverage the mechanics of the harness and different model’s strengths.

The crux of differentiation with Amp is that you don’t select a single model to answer your prompt. The Amp team, through their own usage and probably some automated evaluations, maps models to ‘roles’ used to answer your prompt, the most prominent of these probably being ‘the Oracle’ - a sort of deep thinking role. This feature is already being incorporated elsewhere, e.g. oh-my-opencode plugin for OpenCode, but also the ever-productive Peter Steinberger’s Oracle.

Everything about Amp’s approach, to me, feels ‘correct’. I don’t want to spend my time figuring out what models to use, and I definitely don’t want to figure out granularly what role each model is best at, whilst fully accepting that a mix-of-models approach is probably superior to a universal model approach.

The reason I’m not using Amp is ‘only’ because my personal monetisation strategy, and that of any company I’ve worked for, isn’t Mitchell Hashimoto’s for Ghostty,⁶ who incidentally does use Amp to build Ghostty.⁷ Pricing is the issue. Akin to what I mentioned re: Cursor, it feels like harnesses consuming model’s API pricing are at a structural pricing disadvantage that is really hard to overcome.

We can’t discuss Amp without mentioning their thinking on threads. Look how far they’re iterating on this; treating threads as an addressable harness entity is taste in harness development. Shareable threads are important to help your team understand the power of good prompting, but I think there’s so much more to explore here. If you’re operating in an regulated industry, surely we need to see threads re-played through the lens of risk/auditing/training model roles (similar to the Oracle!) the same way business calls to customers are recorded for training staff, and for legal. Can Amp capture that value? Possibly via SDK!

To round this out, if you’re willing to spend hundreds to thousands per month per developer (ie you’re not price sensitive at that level) then Amp is probably going to provide you the best output. Does it make cost/value sense, I’m less certain. But you’d be supporting Thorsten, and you can’t not love Thorsten.

Claude Code

did us dirty

I originally wrote a section which both Codex and ClaudeCode shared as default recommendations, then Anthropic pulled the pin on OAuth usage. This whole bloody post was littered with my preference for Claude Code.

• It is a great harness. This blog post from Ado Kukic is great for scooping up non-obvious features.
• Not open source
• Can’t use your subscriptions outside of Claude Code.
• Aside from above, the $150 plan is great token value (but Codex lets you use other tools with their plan).
• VScode/Cursor etc extension leaks memory like wild (it happened to me repeatedly before I found the referenced GitHub issue, and moved to TUI) and has done for ~5 months.¹¹
• But the folks iterating on Claude Code at Anthropic and posting on X are great value to follow. I seriously doubt they steered or necessarily agreed with Anthropic’s decision re: OAuth use, it would be great to see them cop less flak.
• I’m not writing more about Claude Code, except the below drama summary.

RABBIT HOLE

If you want to know more about the Anthropic/Claude Code subscription plan drama

It’s not a secret that Claude Code and Codex plans are heavily subsidised, and are likely loss-leaders, which makes it understandable that Anthropic doesn’t want to subsidise the experience of other tools.

What’s going to hurt Anthropic’s reputation here, amongst developers, is the manner in which they’ve shut this off; by claiming it’s purely a matter of other tools not submitting the usual telemetry to make ‘abuse’ cases manageable.¹² All this after folk had already built widely consumed tools ontop of this mechanism (it was left open for months), such as clawdbot.

You might think this is all a storm in a tea-cup, but it doesn’t look that way to me.¹³ OpenCode is nearing 1 million MAU.¹⁴ How many on Clawdbot, Conductor, N other tools leveraging Claude? This was a loss of subscription value broadcast WIDELY.

The Claude Code team have mentioned having ‘DMs open’ for other harnesses to discuss relaying the required telemetry, but…surely you’d just publish the requirements, even privately? We’re talking a few DMs to Dax & Co to cover 1M MAU, many of whom would be using Claude. It feels disingenous.

Co-incidentally there are reports, in the same week, of Anthropic cuting-off xAI’s staff specifically from using Claude within Cursor.¹⁵ That’s API pricing, not subsidised, so maybe this is categorically different.

Codex is now enjoying the fruits of this fumble, openly declaring intent to allow exactly what Anthropic prohibited.¹⁶ OpenCode can now leverage Codex tokens with OpenAI’s blessing. My employer’s subscriptions will be moving there or to OpenCode Black, as well as my personal one.

At the end of the day Anthropic are entitled to put & enforce whatever they want in their own terms of service, but I can’t imagine this was worth the consequences. I would struggle to consider building an LLM wrapper of any kind on Anthropic’s ecosystem now, and I doubt I’d be alone in that sentiment. It’s too hard to shake the mental image of a jealous incumbent, stricty offering service if it’s in their best interest (and makes you wonder what they’d use SDK data collection for, even though the other labs are probably similar).

I don’t think we’ve arrived at the last chaper of this story, especially if other labs/models obtain enough training data from consumers to no longer derive value from subsidised tokens. But even if that’s the end point: Anthropic blinked too hard, too early.

Typing -> Voice Prompting

Coding via voice isn’t necessarily new, but adopting it previously was a high-friction exercise involving learning verbal shortcuts to navigate your machine, all of which is documented (exceptionally!) by Josh W Comeau.

Coding via voice with agents is frictionless to adopt: you simply dictate English to be ‘pasted’ into your terminal or IDE’s agent input textbox, which is then post-processed by an LLM to tidy it all up. My tool of choice currently is Wispr Flow, which seems to have the most momentum in the market. Gergely Orosz has a great write-up on devs using Wispr Flow at their offices with insight on adoption rates, microphones to use etc.

If you’d prefer a free option, I’ve heard good things about Spokenly.

Just bear in mind coding via voice isn’t equivelant to navigating your machine via voice, so we’re not invalidating the tools (Talon et al) covered by Josh.

Prompting on your phone

Prompting from your phone can be done simply, or a little more involved to have better control over the sessions. The simplest version: probably downloading Omnara with your Claude Code subscription (seems to be limited to Claude Code currently). The quickstart is super straightforward and the only drawback, if you can call it that, is the need to pay for sessions beyond 10 a month.

Be aware as of 09/02/26 Claude has started cracking down on subscription use with other apps, Omnara probably needs to move off Claude!

At the cost of only a little more effort, you can just SSH into your laptop from your phone over a VPN like Tailscale. See the guide from Nicholas Khami, who has a blog post covering this.

Personal Assistant: Clawdbot

If you’re looking for a personal assistant that can utilise a browser, check your emails and messages generally, manage your calendar and a hell of a lot more: Clawdbot is seriously worth a look. Folk usually run it on their own machines (a VPS is fine too of course, especially with Tailscale) but I’d definitely consider segregating it from anything important, whether physically or with sandboxing (I need to add a general security chapter at some point).

If you want to know what can be done with it there is a showcase. Like Poke, the ability to leverage MCPs for additional functionality really opens up a ton of possibilities here. There’s a site listing published open source skills for your clawdbot agent here utilising npm for distribution. I’d think about having a coding model audit the source code of these depending on what you’re exposing.

Having had a look at the community Discord, the recommendation seems to be to use a cheaper model with Clawdbot. There are a few of these: Minimax, Z.ai and KimiK2 for instance, which are all (I believe) models from China. If you’re okay with this, the recommendation seems to be Minimax at the moment, with plans starting at $3AUD monthly (promo pricing). This is a referral link that knocks 10% off all plans. If you’re more security conscious, it can integrate with local models via e.g. Ollama or LM Studio.

Practice & Techniques

Context Window Management

For most of 2025, those building harnesses and writing about it emphasised the importance of using sessions liberally to keep the context use minimal (quality degrades as the context window fills). Today, most harnesses have a compaction mechanism in-built, automatically compressing the context window to keep the model focused. In addition to this, it’s common for a harness to use sub-agents (a dedicated context window with a purpose-specific prompt) to isolate token use incurred in e.g. searching code, or interviewing the user to clarify the true prompt intent, with the results fed back into the main context window.

I would argue that context management is still a critical skill, and it becomes more important the more complex your underlying task is.

Amp have a great blog post about this and the key takeaway is that when you have a thread of messages in a session, each additional message (including the model’s replies) have to be re-interpreted each time:

I’m not sure if there’s a phrase for this: I don’t mean the runtime complexity. More accessibly, it could be conveyed as a sort of token re-intepretation tax. In any case you can start to see why sub-agents (really even just sub-context windows) and new windows are important.

When, for example, you ask an agent to search your codebase, it’s often producing tokens to explain what it’s searched and what it’s doing next in addition to all the code it’s adding to the context window. Similarly, bash tool use is often producing tokens for the agent to consume to understand what’s happening in response.

Worth pointing out we’re using extremely basic examples in these animations with tiny token counts. When I used AI to fix up this article’s indexes (linking to the section titles), 3 sub-agents used up 85k tokens. My blog with one post is obviously not as large as your codebase.

Skills, MCP & Progressive Disclosure

Modern Context Protocol is a specification detailing how an AI client can connect to a server to consume tools, resources and prompts.

Aside from leaving auth entirely out of the spec, the biggest problem with early MCP implementations was that enabling them loaded their tool definitions into the context window by default and ate a ton of tokens. I’ll defer to Geoffrey Huntley who summarises the whole thing excellently here if you’re interested.

Anthropic then came along with ‘Skills’. For what skills are, best just to read the Anthropic engineer blog post.

Why were skills superior out of the box? In a nutshell: because their specification accounted for lazy loading the tool definition instead of eagerly loading. The skill description acts as an ‘index’ for the agent to know when it should read the relevant skill.md file, saving a bunch of context when a skill isn’t needed. Skills were originally a Claude thing, but given the mechanical advantage, it’s not suprising OpenAI adopted them per Simon Willison. Claude Code’s system prompt and skills are here if you’re curious what Anthropic’s look like.

The core takeaway here is the primitive of progressive disclosure, it’s a generically useful concept for managing the context window.

A great example of progressive disclosure is Cloudflare’s recent MCP server, teased by Matt Carey, using only 1000 tokens to dynamically expose an API spec equivelant of 2.3 million tokens. The implementation is really clever: your agent’s context window is given essentially type hints as to how to query the Cloudflare API spec or the API itself. Think similar to exposing only a library’s type declaration but not the actual library code, as the latter would be context heavy. Claude generates code using those type hints, the code is sent over the wire to a worker, and the worker then executes the actual code with access to entire API spec locally, or queries CloudFlare API directly and returns results. The technique is based on the Code Mode school of thought which Vercel’s recent article on orienting agents around filesystems seems to echo: the gist being to get agents working in a domain they’ve been trained on thoroughly: code and filesystems.

Feedback Loops

Feedback loops are absolutely critical to course correcting agents on failing coding tasks, it’s really not a lot different than tests. Failure is often novel information. Frequently the hard part is ensuring the agent has access to feedback in its context window.

One of the best course corrections I’ve experienced so far was during the process of building an Electron app on my Macbook. As you might imagine, the Windows version was littered with niche errors that were proving extremely expensive (time-wise) to send across to Claude Code on my MacBook. The solution: a Windows VM, not running Claude itself, but open for Claude on my Mac to SSH into (using tailscale machine name) to run the Windows Electron app directly and receive error output. This enabled Claude to make changes for Windows, test on Windows, then test on Mac to verify no breaking changes.

Sunil Pai wrote a great blog post recently adapting Steven Johnson’s ‘Where Good Ideas Come From’ as a mental model to apply to crafting the context itself, and I particulalry love the emphasis placed on how much impact the process of using errors as a feedback loop makes.

Tooling wise, Graphite and CodeRabbit are popular AI review tools, I prefer the latter. But I also wonder if something like this would act as a faster feedback loop.

We’ll discuss deeper use of feedback loops in the next blog post on long-running (hours) tasks.

Orchestration

Build multiple features for one repo concurrently (Git Worktrees & VMs)

When you’re working on a repository, an instance of the repo in your filesystem can only be on one branch. This can make utilising multiple agents tricky, you usually want each to have a clean copy of the repo to work on and be able to commit changes without overlapping (stashing and hence interupting) other agent’s work. There are some alternative approaches that keep all the work within the same filesystem and rely on agents cross-communicating (locking) files and so on, but it’s very nascent and (in my opinion) not established enough as viable for non-greenfield work streams.

Git Worktrees are a solution that entail separate copies of the repository on the filesystem, each on a different branch.

The problem with Worktrees is that they’re not ergonomic to manage using git. The folks at CodeRabbit have a CLI to make it a lot easier, however, my team and I have really enjoyed using Conductor. With the Conductor GUI, you get a nice list view of all the repositories you want quick access to and their worktrees, affording quick switching across sessions with good diff views. It may not have entirely liberated me from the IDE, but it’s very good.

If you prefer operating out of the terminal entirely, a similar option is using a terminal with split-pane capability (like Ghostty) and prompting your agent to utilise CodeRabbit’s CLI above.

Using either option, I’ve been able to comfortably drive ~5-8 agents in parallel across a handful of repositories, where the bottleneck becomes my capacity to review the changes.

I’d soon expect to see most/all coding agents, like Claude Code & Codex do currently, offer the ability to work on codebases in a cloud VM (ie the web version). This also opens up friction-free concurrency, and the creator of Claude Code, Boris Cherny, has a must-read thread on Twitter describing how he uses Claude Code instances locally + web version simultaneously, and moves sessions between them.

Who to Follow

I thought about segmenting this into blog/twitter but most bloggers have twitter so here we are.

The below is to keep up with AI engineering from those writing about it. I’ve made a list of every account mentioned here + some extra, then I put myself on it for sport. I did promise cheek.

Here you go: https://x.com/i/lists/2009825440207340023

Write In!

If you’re a bit of an authority on these topics and want to correct the record or offer insight, feel free.

author@abrown.blog

Next Blog Post: Executing Huge Tasks with Agents

In the next blog post I cover a piece I had to segregate from this article, which essentially disaggregates the ‘Ralph Wiggum’ technique you’ve probably heard about. We cover when it’s actually useful, and what parts of it apply more broadly.

Expect it within the next two weeks!