Case: Toss
Analyze Toss's harness approach through executable SSOT, domain layers, frictionless adoption, and HITL.
Key takeaways
- Toss reads harness adoption as an organizational problem: raising a team's productivity floor, not just one expert's ceiling.
- Rules are layered into global (shared floor), domain (performance), and local (task context) so context stays aligned without giant rule files.
- Executable SSOT means rules must become commands, templates, skills, and human gates, since passive wiki pages and meeting notes do not shape behavior.
- Domain HITL ties approval cost to risk, with distinct gates for payments, security, platform, and AI product work.
- The rollout must stay frictionless; if the workflow is slower than personal habit, the team falls back to chat and memory.
Toss is useful because it reads harness adoption as an organizational problem: how do you raise the productivity floor of a team, not just the ceiling of one expert?
Problems Solved
- Good usage patterns stay inside one person's head.
- Rules live in docs but do not shape execution.
- Approval points are implicit.
- Domain-specific risk is treated like generic coding work.
Core Mechanism
| Layer | Contains | Why it matters |
|---|---|---|
| Global | Shared security, style, release, approval | Gives everyone the same floor |
| Domain | Product/team rules, approval conditions, risk patterns | Creates domain performance |
| Local | Ticket, current branch, temporary context | Keeps the agent aligned to the task |
Executable SSOT
The strongest Toss lesson is that SSOT cannot be passive. It must be executable enough to shape behavior.
| Weak form | Stronger harness form |
|---|---|
| Wiki page | Command or workflow |
| Meeting note | Template or checklist |
| Senior engineer habit | Skill or runbook |
| Approval custom | Human gate with criteria |
The more critical the domain, the more the SSOT must become workflow.
Domain HITL
Not every team should use the same approval policy. But approval rules cannot be entirely personal either.
Examples:
| Domain | Human gate trigger |
|---|---|
| Payments | Pricing, refund, settlement, ledger rules |
| Security | Auth, token, key, policy, network boundary |
| Platform | Shared package, migration, release gate |
| AI product | Model, prompt, tool permission, safety policy |
Rollout Pattern
Create shared AGENTS.md, verification commands, and approval vocabulary.
Move domain risks from docs into commands, templates, and gates.
If the workflow is slower than personal habit, the team returns to chat and memory.
What to Borrow
| Borrow | Why |
|---|---|
| Global/domain/local split | Prevents giant rule files and disconnected context |
| Executable SSOT | Makes rules affect work |
| Domain HITL | Aligns approval cost with risk |
| Frictionless default path | Sustains adoption |
What Not to Copy Blindly
- Do not make every rule a workflow.
- Do not add human approval where risk is low.
- Do not put domain-specific rules into global docs.
- Do not rely on docs if the actual work path ignores them.
References
- Toss,
Software 3.0 era: raising the organizational productivity floor through Harness, 2026-02-26 https://toss.tech/article/harness-for-team-productivity