Multi-Harness Support for my Agent Stack

The recent drama around Fable 5’s pending removal, then extension, then another extension, in the wake of OpenAI’s 5.6 Sol’s release has caused many developers (including yours truly) about whether it is intelligent to tie themselves to one ecosystem.

While I had begun some work to loosen my coupling to the Claude Code SDK via incorporating Google’s new Open Knowledge Framework , there are a great many things besides just an md-reference chain that a particular methodology may allow itself to become dependent upon when it comes to any particular SDK.

Consider deterministic context loading for a given agent / task:

Codex/ChatGPT Work users would generally rely upon a robust SessionStart definition for enabling deterministic context injection, while Claude Code users have the @import annotation which they are to disperse throughout the entire chain of md files which are to be ingested at session start.

Two methods of achieving the same goal that are wholly unique in their implementation. And the answer isn’t necessarily to do both - those @import tokens are redundant for OpenAI and while they aren’t necessarily a problem they aren’t a proper architectural solution.

This is a problem I’ve only begun to grapple with, but an early ray of hope came in the form of Simon Willison’s blog post in May where he argues about HTML as a sometimes superior alternative to markdown. This post was a gamechanger for me so much so that I’ve built tooling around it. Anytime I want to discuss a complex implementation with an agent, I no longer just use the Superpowers Brainstorm, I use an additional review-via-web skill to upload a visualization-rich webpage on a locally-hosted “DocShare” tool to more easily comprehend the agent’s proposed architecture and critique specific areas of it:

![[Pasted image 20260713205333.png]]

Using this has gotten me thinking lately about using the JS ecosystem to manipulate agent definitions to fit the SDK I am in, where my relationships + structure don’t actually live in the .md files, but where those files are dynamically generated based on the harness currently being used. Memories of Make/SharpMake are definitely influencing me here!

Perhaps I will go that route, perhaps I find a different inspiring solution. In either case, it is definitely an issue I grapple with today!