Protocol v1.0

OTP is a protocol, not a service.

An OOS file holds the patterns your agents would otherwise relearn every session. Drop it in your repo. Read it locally. No service required. Publish to the network when you want cross-org coordination.

The shape

An OOS file is a markdown file with YAML frontmatter and structured claims. Each claim has a rule, a why, a failure mode, a confidence, and an evidence type. That's it. The whole point is that any AI agent can read it the same way.

acme-agency.oos.md View full example →
---
oos_version: "1.0"
org_pseudonym: "Acme Digital Agency"
template: "agent_army"
agent_count: 8
---

## Prime Directives
1. Client data integrity above all other priorities.
2. No agent sends external comms without human approval.
3. Every agent writes to shared state; no agent reads sources directly.

**[C001]** core_operating_rules
- **Rule:** Every agent writes to a shared state file.
- **Why:** Direct data source access creates race conditions.
- **Failure mode:** Two agents query the same API simultaneously,
  get different results, make conflicting decisions.
- **Confidence:** HIGH
- **Evidence:** MEASURED_RESULT

Plain markdown. Plain YAML. Validated against a JSON Schema. Parseable by any agent in any language. The file is the protocol.

Three ways to use it

1

Local only

zero deps

Drop an OOS file at the root of your project. Have your agents read it on startup. They follow the rules. No external service. No API keys. No network.

your-repo/
  coordination.oos.md # your team's rules
  agents/...
  src/...

This is the path most lightweight frameworks should take. The protocol gives you a stable file format your agents read the same way every session.

2

Shared repo

team scale

Same file, but committed to a shared repo. Agents on different machines pull the same OOS through git. Versioned, reviewed, branched, merged the way you already work.

When your team grows past one operator and conflicts start crossing humans, this is the next step. Still no external service. Just git.

3

Publish to the network

cross-org

Publish your OOS to orgtp.com so other organizations can browse it, compare against it, and learn from your patterns. You read theirs the same way. This is where the transactive memory effect kicks in.

The hosted service is one implementation of a sync layer over the protocol. It is not the protocol. Use it when you want the network. Skip it when you don't.

Publish your OOS →

Why this exists

Every AI session starts from zero. The patterns you taught your agents yesterday do not survive into today's instance. Every multi-agent team rediscovers the same coordination failures: race conditions on shared data, two agents emailing the same client, retention agents and sales agents pulling the same account in opposite directions.

Daniel Wegner named the underlying problem in 1985: a group remembers more than the sum of its members because each member knows what the others know. He called it a transactive memory system. The OOS file is one. It is the chemoreceptor that makes the next directed move possible without re-deriving the whole arc from scratch.

The architecture that produces the function is what matters. The file format is the architecture. The hosted service is one place the file can live.

Where this fits in the stack

OTP is one of three protocols emerging at the agent coordination layer. Each one names a different surface and they compose:

AGENTS.md instruction surface

How a single agent should behave in this project. The prompt-time contract.

IJFW workflow discipline

How an agent moves through phases inside a session. The execution contract.

OOS / OTP cross-session memory

What the team has already learned. The persistence contract across sessions and across agents.

Different layer, different problem, same family. None of these need an external service to work. They are file formats first.

Start with a file.

Read the spec. Write your first OOS. Have your agents pick it up. The network is there when you want it.