1 · Agree
Agent A accepts the job.
The outcome and acceptance requirements are locked so everyone knows what “done” means.
Experimental 0.2 · Open infrastructure
Work should be portable between agents.
Give the job to one agent. Hand it to another without starting over. OWP standardizes the contract, evidence, validation and handoff around a job while each provider keeps its own models, tools and internal architecture.
Not another agent platform. OWP is the small shared boundary that lets different agent systems agree on what was requested, what was delivered, whether it passed, and what the next provider inherits.
Apache-2.0Git-first evidenceA2A-compatible profileNo mandatory brokerNo mandatory chainNo canonical scorer
If you remember one thing
The work belongs to the contract and its evidence—not to whichever agent started it.
That makes switching providers a handoff instead of a restart.
A normal-person example
“Build me a landing page for $500.”
You should not need to understand protocols, Git, model routing or agent orchestration to benefit from portability.
2 · Prove
Agent A delivers evidence.
The work comes back with a delivery manifest, Git state and enough evidence for independent validation.
3 · Hand off
Agent B can continue.
If the first provider stops, passes or needs replacement, the next one inherits the contract and history instead of reconstructing the job from chat.
The shared boundary
A contract for the work—not the agent.
OWP-Core is intentionally narrow. It describes the portable lifecycle around outcome work and leaves transport, tools, models, economics and provider internals where they already belong.
01
Contract
Outcome + acceptance requirements.
02
Accept / Pass
A provider privately decides whether to take it.
03
Deliver
Artifact + immutable evidence + lineage.
04
Validate
Technical validity stays separate from taste.
05
Approve / Steer / Handoff
Continue, revise, reject or transfer without erasing history.
OWP does not require a marketplace, payment rail, blockchain, cloud service, founder API, provider registry or quality scorer.
Ownership boundary
Small enough for competitors to adopt.
A protocol is easier to share when it does not ask adopters to surrender the systems they already own.
OWP standardizes
The portable outcome-work semantics.
- Accepted outcome and locked acceptance requirements
- Attempt and revision lineage
- Delivery manifests and Git-backed evidence
- Independent technical validation semantics
- Customer disposition and cross-provider handoff state
OWP leaves alone
Existing ecosystem layers stay where they belong.
- Agent transport/RPC — use A2A or what you already use
- Tool/context access — MCP remains MCP
- Payment networks — x402/AP2/etc. can bind optionally
- Identity and reputation systems
- Models, prompts, scorers, subagents and provider economics
Three entry points
Use the depth you need.
Everyday customer
Describe the result. Receive the result.
The human-facing profile can hide Git and protocol vocabulary behind a simple describe → preview → approve → work → receive flow.
See Simple Flow →Orchestrator developer
Keep your entire stack.
Add the provider boundary: inspect a contract, ACCEPT/PASS, execute however you already execute, emit evidence, and hand off when needed.
15-minute provider guide →Standards / OSS reviewer
Make OWP smaller.
If a semantic already belongs in A2A, MCP, Git or another open standard, the project explicitly wants that overlap challenged and moved upstream.
Review packet →Developer fast path
Clone it. Run it. Break it.
The seed repository contains a reference core, conformance vectors and a Git-backed two-provider journey. You do not need a wallet, chain, marketplace or hosted service.
The “take this and run” path.
Start with OWP-Core + OWP-Git, then implement the smallest boundary your orchestrator needs.
1. ReadOWP 0.2 core semantics.
2. ProveRun the TCK vectors locally.
3. AdaptMap your provider to ACCEPT/PASS + delivery evidence.
4. AttackReport ambiguity or interoperability failures as issues.
git clone https://github.com/open-work-protocol/open-work-protocol.git
cd open-work-protocol
# Conformance vectors
PYTHONPATH=src python3 -m owp.cli tck
# Real Git-backed two-provider journey
PYTHONPATH=src python3 -m owp.cli golden-demo --json24reference tests in the current standards candidate
20TCK vectors in the seed conformance suite
2providers exercised in the golden handoff journey
0mandatory founder services required by OWP-Core
Seed-repository proof points, not ecosystem-adoption claims. OWP 0.2 remains experimental.
Fast answers
What people usually ask first.
Is OWP another agent framework or marketplace?
No. It does not tell a provider which model, framework, prompts, tools, subagents or marketplace to use. It standardizes the portable boundary around the job.
Does OWP replace A2A or MCP?
No. A2A can carry agent-to-agent communication; MCP can expose tools and context. OWP describes the outcome-work contract, evidence, validation, customer disposition and handoff that can travel over or alongside those layers.
Does “valid delivery” mean the customer has to like it?
No. OWP explicitly separates technical validity from customer approval. A delivery can satisfy objective validation while the customer still chooses APPROVE, STEER or REJECT according to the contract and applicable policy.
Who controls OWP?
The canonical repository lives in the Open Work Protocol GitHub organization. The project is designed so no founder API, hosted service, registry, scorer or vendor dependency is required to implement the protocol.
What would be the most useful contribution right now?
An independent implementation, an unrelated orchestrator adapter, a stricter validator, or a concrete example showing where OWP duplicates or conflicts with a better existing standard.
Imagined by Keeltrace. Built in Git. Designed to be owned by no vendor.
Origin is attribution—not a dependency or control claim. If the founding team disappeared, a conforming implementation should still be able to read the spec, validate work and interoperate.
The public challenge
Don’t endorse it. Try to break it.
Implement OWP-Core in another language. Connect an unrelated orchestrator. Attack the ReviewCapsule. Build a stricter Git validator. Show where the protocol duplicates something better.