Teaching agents to take responsibility.

The problem begins after delegation

When I delegate a job, I want the agent to understand what makes the result useful. Sometimes that means building software. Sometimes it means making a decision, shaping a document, investigating a failure or helping me discover what I actually want. The standard comes from the work and the person who will use it.

Repeated use exposed two opposite failures. An agent could act beyond the authority I had given it, or ask me to decide ordinary details I had already entrusted to it. It could stop at a successful test while the product remained unusable, or keep checking long after another check could improve the result.

My contribution: the working model

I shaped Charter around three commitments: make the work useful, exercise judgment within real authority, and give a truthful account of what was done and checked. I also made unnecessary process a first-class failure. More planning, more research and more delegation do not automatically mean better work.

This is product direction as much as prompt writing. I decide which recurring difficulties belong in general guidance, which need specialist knowledge and which are defects in a particular tool. Otherwise every incident becomes another permanent rule, and the instruction system grows harder to use than the problem it was meant to solve.

One architecture, different working environments

Charter separates enduring principles from the mechanics of each AI environment. Shared guidance describes professional behaviour. Environment-specific instructions explain the tools and constraints actually available. Project guides hold what is true about a particular workplace. Specialist skills bring depth when the subject calls for it.

Those skills cover work such as product design, architecture, causal diagnosis, evaluation and communication. They are meant to change what an agent notices and how it judges a problem. A specialist contribution should help the work; it should not introduce a compulsory committee or another ritual before anything can happen.

The same source is delivered through the native instruction mechanisms of Codex, Claude Code, Grok Build and Pi. I chose to preserve the strengths of each environment rather than force them all through an identical lowest-common-denominator file.

A distinction should change a decision

One example is the difference between preparing something and publishing it. An agent commissioned to redesign a website can make and inspect a local result. That does not make a production deployment its decision. Within the local work it should use initiative; at the publication boundary it must respect the person’s authority.

Another is the difference between an observation and an inference. A passing build establishes that the code builds. It does not establish that the interface is understandable. The useful next check is to use the interface, not to make the build report more elaborate.

The result is behaviour in actual work

Charter is installed in my own working environment and continues to evolve through concrete failures and corrections. Its deployment machinery can establish that the intended instructions are present. It cannot establish that a model follows them well, and written boundaries are not a technical sandbox.

The test I care about is whether the next piece of work is better: fewer avoidable questions, better decisions, a result that survives use and an account I can trust. That remains a judgment about complete work, not a claim that one prompt makes every model dependable.