Ethos

Why this exists

When you delegate work to an AI agent, the contract is free-form prose. The agent doesn’t know who it is, what it’s allowed to touch, or how its work will be evaluated. When something goes wrong, there’s no audit trail — just a conversation that scrolled off screen.

This matters more as agents take on real engineering work. A sub-agent that writes Go code needs different expertise, tool access, and review criteria than one that writes editorial content. A task with a clear scope needs boundaries that prevent drift. A leader delegating to a specialist needs to know: did they stay within the write-set? Did the evaluator actually review? How many rounds did it take?

Ethos is the harness that connects agents to their work. It started as identity — who am I, what’s my personality, what’s my writing style — and grew into a structured delegation system with typed contracts, bounded rounds, and provenance for every decision.

What you can do with it

Ethos provides three layers, each optional, each building on the last:

Identity. Every person and agent gets a persistent identity — personality, writing style, domain expertise, role, and team membership. The identity loads automatically at session start and survives context compaction. Sub-agents get their own identities with distinct expertise and tool restrictions. You create the identities once and forget about them.

Teams. Agents are organized into teams with roles, collaboration graphs, and anti-responsibilities. A Go specialist knows it shouldn’t make architectural decisions. An editor knows it shouldn’t deploy infrastructure. The team structure generates agent definitions with the right tools, the right boundaries, and the right context for each member.

Missions. Typed delegation contracts between a leader and a worker. The contract names the write-set (which files may be modified), success criteria (what “done” looks like), an evaluator (who reviews), and a round budget (how many iterations). Every step — create, result, reflect, advance, close — is an append-only event in the mission log. The store refuses operations that violate the contract: overlapping write-sets, self-review, close without a result.

The contract is a spectrum. An implementation mission has a tight write-set and specific criteria (“one ReadFile, make check passes”). A design mission has a broad write-set and open-ended criteria (“evaluate three approaches, recommend one with tradeoffs”). The agent’s expertise is always present; the contract determines how much latitude they have.

How we use it

Every Punt Labs project uses ethos for identity. The public website you’re reading has a team of four agents — Claudia (architect, modeled on Vignelli), Editor (editorial review, modeled on Strunk), Web (frontend, modeled on Bret Victor), and Ada (infrastructure, modeled on Margaret Hamilton). Each has a distinct personality, writing style, and tool set.

For implementation work, we use missions. A real example: fixing a TOCTOU bug in ethos’s own verifier took 12 minutes 55 seconds from claim to merge. The mission contract named one file in the write-set, two success criteria, and a 2-round budget. The Go specialist (bwk) implemented the fix in 2 minutes 10 seconds and submitted a typed result with verdict, confidence, and evidence. The leader reflected, the code reviewer found one maintenance comment needed, Bugbot found one accepted tradeoff. PR merged. The audit trail is four events: create, result, reflect, close.

Coding was 17% of wall time. Review was 70%. That’s the right distribution.

What it is not

Ethos is not an agent framework. It doesn’t orchestrate LLM calls, manage tool execution, or handle prompt routing. It’s the identity and contract layer that sits above whatever agent runtime you use. Today that’s Claude Code. The integration surfaces (filesystem, CLI, MCP) are deliberately generic so other runtimes can consume identity state without depending on ethos as a library.

Ethos is also not a replacement for git. The mission audit trail records delegation decisions — who was assigned, what they were allowed to touch, whether the evaluator approved. The code changes are still commits. The two complement each other: git says what changed, ethos says who decided it should change and under what constraints.