For creators
Package the harness you have refined, describe what it needs, publish versions, and remain the source of truth.
A distribution hub for AI harnesses
Your AI “brain” deserves better than a README.
Creators are assembling remarkable Codex and Claude environments from agents, skills, plugins, instructions, and Markdown. Harness Hub is designed to turn that configuration into a versioned package people can deploy to their own workstation—and keep aligned with its creator.
- Creator-owned configuration
- Runs on the user's workstation
- Codex first, provider-neutral by design
The invention already exists
The missing layer is distribution.
Many so-called AI “brains” are thoughtfully organized Markdown, agents, skills, plugins, hooks, and settings in a GitHub repository. That is not a weakness. It is the configuration.
But how does someone else get a faithful, working copy?
For communities
Give a squad, method, or “brain” one canonical release instead of a repository plus an expanding setup guide.
For users and teams
Choose a harness, review what it contains, and deploy an approved copy into a local environment on the workstation.
Creator to workstation
Publish once. Install with intent.
- 1
Create
Build the agents, instructions, skills, plugins, and provider configuration that make your harness useful.
- 2
Package
Turn the non-secret configuration into a versioned Harness Image with requirements, provenance, and explicit exclusions.
- 3
Publish
Store the release in Harness Hub so followers, clients, or an organization can select a known definition.
- 4
Deploy locally
The Workbench Client prepares an isolated Harness Host on the user's workstation and binds credentials only after deployment.
- 5
Stay recognizable
Compare the installed configuration with the selected release, explain differences, and offer controlled updates or rollback.
A different category from Coder
The Hub distributes the harness. It does not host the work.
The clean boundary
Configuration in the Hub. Runtime on the workstation.
If you need centrally provisioned development environments, platforms such as Coder address that category. Harness Hub addresses how a creator's AI configuration reaches someone else's local environment and remains a recognizable copy.
What travels—and what does not
Share the brain, not the identity behind it.
The reusable package contains the creator-approved, non-secret harness definition. User and client identity is bound locally after deployment.
Can travel through the Hub
- Agents and Markdown instructions
- Skills, plugin, hook, and MCP declarations
- Provider and compatibility requirements
- Version, provenance, and update policy
Must remain local
- Credentials and provider authentication
- Client repositories and source content
- Sessions, memories, and attachments
- Machine identity and runtime state
The configuration is the product
Codex first. Claude next. Community-created harnesses at the centre.
A harness can be a focused solo workflow, a squad of agents, a professional method, or an organization's approved baseline. The Hub does not need to invent the “brain.” It gives that brain a reliable way to travel.
Direct answers
Questions about AI harnesses and the Workbench.
Clear definitions for creators, prospective users, teams, and organizations evaluating how portable AI configuration should work.
- What is an AI harness?
- An AI harness is the working configuration around an AI provider: agents, skills, plugins, instructions, hooks, tool declarations, compatibility requirements, and operating policies that make a repeatable way of working.
- What is AI Harness Workbench?
- AI Harness Workbench is a planned Harness Hub and local deployment client. The Hub will distribute creator-approved, versioned harness definitions; the Workbench Client will prepare and manage an isolated Harness Host on the user's workstation.
- Does the Hub run my AI work in the cloud?
- Not in the first MVP. The Hub stores approved configuration and governance information. Runtime compute, credentials, repositories, sessions, memories, and client data remain in the assigned local Harness Host.
- Which AI providers will it support?
- Codex in dedicated WSL is the first MVP provider and host pairing. The contracts and product boundary are intended to remain provider-neutral, with Claude and other harness configurations able to follow.
- Is AI Harness Workbench generally available?
- No. The product is currently in architecture and contract validation. Creator design-partner conversations and the installation wait-list are being used to shape a bounded first deployment path.
- What information can be shared through the Hub?
- Only creator-approved, non-secret harness configuration should travel through the Hub. Credentials, authentication, client repositories, source content, sessions, memories, attachments, machine identity, and runtime state must remain outside the reusable package.
Clear about maturity
Defining the package, Hub, and first local deployment path now.
AI Harness Workbench is in architecture and contract validation. The first MVP pairs Harness Hub with a Workbench Client that deploys a Codex harness into dedicated WSL on a workstation.
The creator publishing flow, catalogue, entitlement model, deployment client, and alignment checks are product direction being shaped through bounded design partnerships—not generally available product claims.
Creator and design-partner conversations
Already building a “brain”? Start there.
Bring one real GitHub-distributed squad, harness, or configuration. We will map what belongs in its package, what must stay local, and what a faithful workstation deployment would require.
Talk to Richard about distributing itPrefer email? Send Richard what you have built. Creator conversations remain separate from the installation wait-list.
What we will learn together
- The smallest honest unit of a portable harness
- How the creator expresses prerequisites and updates
- What the recipient should review before installation
- How to prove the deployed copy still matches its release