--- title: 'What Flagridge is: a runtime for Claude Code, Codex and OpenCode — Flagridge' description: 'Flagridge is not another coding agent. It is the soft harness that gives Claude Code a correct runtime, with Codex and OpenCode coming soon.' url: 'https://flagridge.com/blog/what-flagridge-is' type: 'post' template: 'blog-post' language: 'en' date: '2026-11-09' --- # What Flagridge is: a runtime for Claude Code, Codex and OpenCode > Flagridge is not another coding agent. It is the soft harness that gives Claude Code a correct runtime, with Codex and OpenCode coming soon. Primary action: [Talk to us](https://flagridge.com/enterprise#contact) When we show Flagridge to a team, the first question is usually which agent it replaces. The fair answer is none. Flagridge does not replace Claude Code, Codex or OpenCode. It gives them a correct runtime. The confusion comes from the word "harness", which covers two different things. The hard harness is the application that runs the loop of interaction with the model: Claude Code, Codex, OpenCode. It takes the request, calls the model, runs the tools and shows the result. The soft harness is what that application works with: the definitions of agents and skills, and the tools that a plugin gives. On this blog, "harness" means the soft one. Flagridge is a soft harness. Today Flagridge runs on Claude Code. Support for Codex and OpenCode is coming soon. The split stays the same with each application: the loop with the model belongs to the hard harness, and the rules of the work belong to the team. Inside, Flagridge has four role harnesses: Business Analyst, Architect, Developer and Quality. Each one is a set of agent and skill definitions for one kind of work. The roles pass work to each other as artifacts, and the main artifact is the work package: one ID that every role opens, checks and adds to. The Business Analyst harness starts from a raw request: a change request, a new feature or a bug report. It keeps the original words apart from their interpretation, reads the existing requirements, business rules and acceptance criteria, and prepares a bounded story with its acceptance criteria. A person approves the write. The result is the work package that the rest of the team commits to. The Architect harness opens that package under the same ID. It records the technical decisions and contracts for the scope, and it writes each non-functional budget as a number and a way to check it. When the design shows a missing requirement, the Architect asks for review. It does not quietly rewrite the business scope. The Developer harness checks the package and its referenced files before it changes code. A missing or stale input is reported first. Then it implements only the bounded scope and records which checks ran, which failed and which it skipped. The Quality harness reviews that one result against its package and its evidence, reports findings and a verdict, and previews how the result would be applied. Applying it and delivering it with Git are separate steps, each with its own approval. A person still reviews and merges the change. Under the four roles sit two shared parts. Core defines the contracts of the artifacts, so each role can continue the work of the previous one. The Flagridge Runtime is a local MCP server that gives the role harnesses their tools. It works on one selected project folder at a time and does not copy or sync other repositories by itself. Claude Code talks to the model; the Runtime gives it the tools of the work. Flagridge also does not start from an empty page. It pulls in **the skills and rules that a team already keeps in its repositories**. The role harnesses then follow the conventions, the checks and the decisions that the team made before Flagridge came. The experience of the team stays the source of the rules; Flagridge works together with it. People retrain slowly, so the harnesses work in two modes. In the first mode, each person gets the harness of their own role. The analyst works with the Business Analyst harness, the architect with the Architect harness, and the team keeps the structure it already has. In the second mode, all four harnesses work as one conveyor for one person, the [product engineer](https://flagridge.com/blog/who-is-product-engineer), who takes a change from the requirements to the check. A team can start in the first mode and move to the second at the pace of its people. ![Left: an analyst, an architect, a developer and QA each run their own harness, and the work package, design package, code change and review verdict pass down to a release. Right: one product engineer runs all four harnesses and reaches the same release.](https://flagridge.com/media/blog/what-flagridge-is/loops/two-modes.mp4) Why does a hard harness need a runtime at all? The common view is that bad agent output is a defect of the model, and a better model or a better prompt fixes it. We see the cause in the rules around the model. Even one person on a small project needs a harness as soon as they plan work several days or weeks ahead, at least as rules that record what they want to do, because code is still written slowly. With a second person, the two start to get in each other's way. Only a harness holds the shared requirements, decisions and rules of a team. The hard harness runs the loop; Flagridge gives it the rules that this team agreed on. Flagridge itself is our first case. A team of two people built the Flagridge plugin and platform in two weeks, with the four role harnesses, the Core contracts and the local Runtime in place. That is the lesson we take from it: product engineers with agents and harnesses can build a whole product with a very small team. The limit is plain. Flagridge does not run the loop with the model and does not choose the model; that stays the work of the hard harness. And today that hard harness is Claude Code. Codex and OpenCode come next. The loop belongs to the application. The rules belong to the team. --- HTML: https://flagridge.com/blog/what-flagridge-is Markdown: https://flagridge.com/blog/what-flagridge-is.md