{"slug": "charter-and-harness-what-each-one-is", "title": "Charter and Harness: What Each One Is", "summary": "A developer introduces the concepts of 'charter' and 'harness' to clarify how agentic coding systems are governed. The charter is defined as all authored material specifying agent behavior, including guides, tool definitions, sensors, and gates. The harness is the engine that acts on the charter, such as Claude Code or other agent frameworks.", "body_md": "It seems that every time I *think* I know the shape of the harness, a new fact presents itself that I have to account for. I recently wrote a book [Harness Engineering](https://leanpub.com/harness-engineering). But new information has caused me to rethink my model a bit. I plan to leave the term *harness* alone, and tighten up the definition. In addition, I add the term *charter*.\n\nWhat follows is a chapter I’m working on for the book to bridge the gap in my model. I’m offering it completely free because I think it’s the best definition I’ve had so far. Your feedback is very welcome.\n\nClone a repository that someone has tuned for agentic coding and open the .claude folder at its root. What you find is mostly prose. A CLAUDE.md that explains the project. Rule files with names like testing.md and migrations.md. A few skills, each a short markdown file describing a workflow. Maybe a settings.json wiring up a hook. Almost none of it is code that runs on its own. It is a stack of instructions, written for a reader who happens to be a model.\n\nNow start the agent: Claude Code, or whatever the team standardized on. It reads that folder, holds it in mind, and goes to work on your repo. The folder did nothing. The agent did. There, in a single clone, sit the two things this book is about: the material you author, and the engine that acts on it. This chapter names both and says what each is made of. The next chapter draws the line between them. Here the job is to fill the two boxes.\n\nThe **charter** is everything you author to specify how the agent should behave in your project. That .claude folder is most of it. The word is borrowed from its plainest sense: a charter is a founding document that says how a thing is to be governed. Your repo’s charter governs the agent that enters it. You write it, you review it in pull requests, you amend it when it turns out wrong, and it governs every agent that works the repo until you change it.\n\nA charter comes in four kinds of material, and naming them now saves arguments later.\n\n**Guides** instruct before the agent acts: the CLAUDE.md, the rule files, the slash commands, the prose half of a skill. A guide is a sentence the agent reads and weighs against the situation, like *prefer composition over inheritance, and justify a base class in the PR description*. No graph expresses that. It is judgment, written down.\n\n**Tool definitions** declare what the agent can reach for and how it is wired: the mcp.json entry, a tool’s schema, a skill’s script, or a plugin’s config. One artifact can span families: a skill’s prose is a guide, but its script a tool definition. The definition is yours and lives in the repo. The thing it points at, the installed server or the plugin binary, is external, and the next chapter sorts that seam.\n\n**Sensors** tell the agent whether the work it just did is acceptable: the test files, the lint config, the type-checker settings. You authored them, so like a hook they are charter even though they run. A sensor reports; it does not refuse.\n\n**Gates** refuse: the pre-commit hook, the branch-protection rule, the blocking reviewer. A gate is a sensor wired to a stop.\n\nGuides, tool definitions, sensors, gates. If something in your charter is none of those four, it is probably not earning its place.\n\nMost of a charter is prose, and that is the point. A rule written as a sentence covers cases no control-flow graph would, because the agent weighs it instead of branching on it. Some of a charter is code you author, a hook or a gate, and that code is still charter: you wrote it to state a standard, so it is a specification the engine runs, never the engine itself. A charter is also a living thing. It is versioned in the repo, reviewed like any change, and amended as the project teaches you where it was wrong. The rule you write today because an agent ignored a convention is a line in a document you will keep editing for as long as the repo lives.\n\nHere is the whole of it, as a definition you can hold: the charter is your repo’s .claude folder, all of it (the rules, the hooks, the agents, the skills, the slash commands, the settings), plus the dependencies you declare: plugins, policy packs, shared skills, tools such as MCP servers. Those are two questions about a thing, not one. The families above sort by *role*: is it a guide, a tool definition, a sensor, a gate? *Origin* is the second question: did you write it by hand in the folder, or adopt it as a declared dependency? A declared dependency keeps its declaration in your repo, which is charter, while its installed body lives outside, which is not. Declaration in, source out. Either way the test does not change: you authored or adopted it to specify behavior.\n\nIf you have been in this field a while, you may have called this folder “the harness.” It is the charter. The word slipped for an understandable reason, and the next chapter traces it; for now, hold the line that the folder you author is the charter, and the engine that reads it is the harness.\n\nThe **harness** is the engine that applies the charter against the model. The field has a shorthand worth borrowing: an agent is a model plus a harness. The model predicts text and nothing more. The harness is everything wrapped around it to turn prediction into work, and the charter is what the harness consults while it does. So the relationship runs in a line. You author a charter; the harness applies it to drive the model; the model produces a result, a diff or a document or an answer. Charter, harness, model, result. The charter is the input you control. The harness is the only stage that acts. The next chapter takes that line apart; here it is enough to see the shape.\n\nAn engine that does this has jobs, and Part B of this book takes them one at a time. It assembles the context the model sees each turn, choosing what to load and what to drop, and invokes the tools your charter defined. The permissions you set decide which files it may touch and which commands it may run. The gates fire, the sensors report, and the loop turns with bounds and a kill switch until the work is done or the budget is spent. Every one of those is the engine at work, not a standard you wrote down. The standard is the charter; the doing is the harness.\n\nYou get most of a harness rather than build it. Claude Code is one, Cursor is another, and a LangGraph orchestration your platform team stood up is a third. The vendor ships the engine, you point it at your repo, and it reads your charter on the way in. For most teams that is the entire relationship with the harness: choose one, configure it, move on. The teams that build their own, a custom orchestrator or a queue that runs agents across a fleet, are doing harness engineering proper, and Part B of this book is written for them. Part A is for everyone, because everyone writes a charter.\n\nA harness can even ship its own charter-like pieces: Claude Code’s built-in slash commands, a default skill, baked-in rules. Those are harness, because the vendor authored them, not you, and they do not sit in your .claude folder. Your charter can override them. Drop a fix-bug skill into your folder and the agent runs your bug workflow instead of the vendor’s default; write a rule that bends a built-in command to your process, and your version wins. The built-in is harness, your override is charter, and the agent meets the charter.\n\nOne part of the charter couples to the harness more tightly than the rest: *workflow*. A rule or a hook is a primitive the harness simply reads, but how work gets defined, prioritized, and completed is a process the harness has to register and run, not merely read. That is one reason a team builds its own harness, when the workflow it needs is one a stock harness cannot express. Part A’s chapter on contracts is where you define the workflow; Part B’s on orchestration is where the harness runs it.\n\nTwo words, two boxes: the charter you author, the harness that applies it. They are not the same kind of thing, and it is a mistake to treat them as one. Where exactly the line falls, why a hook you wrote is charter even though it runs, why the orchestrator is harness even though you might own it, is the next chapter. For now, hold the two boxes apart and know which one takes most of your time. For most of this book, it is the charter.\n\nRun this against your own repo.\n\n**Your charter** — everything you authored or adopted to specify behavior. Most of it is the whole .claude folder; the rest is declared dependencies. By role:\n\nBy origin: written by hand in the folder, or a declared dependency (plugin, policy pack, shared skill, tool such as an MCP server) whose declaration is charter and whose installed body is external.\n\n**Your harness** — the engine you run, mostly not yours to write:\n\nA thing on the first list, you maintain, and it is where your reliability comes from. A thing on the second, you mostly choose. Telling which list something belongs to is the whole skill the next chapter sharpens into a single test.\n\nThe charter is the half of the work with your name on it. The rest of this book is about writing it well.", "url": "https://wpnews.pro/news/charter-and-harness-what-each-one-is", "canonical_source": "https://tacoda.medium.com/charter-and-harness-what-each-one-is-57cfc373fd24?source=rss-bf474619cf47------2", "published_at": "2026-06-30 23:47:29+00:00", "updated_at": "2026-06-30 23:56:10.343869+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models"], "entities": ["Claude Code", "Claude", "Harness Engineering"], "alternates": {"html": "https://wpnews.pro/news/charter-and-harness-what-each-one-is", "markdown": "https://wpnews.pro/news/charter-and-harness-what-each-one-is.md", "text": "https://wpnews.pro/news/charter-and-harness-what-each-one-is.txt", "jsonld": "https://wpnews.pro/news/charter-and-harness-what-each-one-is.jsonld"}}