# Kungfu UNGFU™ Kungfu has two public strategic axes: continuity for durable Agent work, and an open Agent Supply Chain for product discovery, exact-artifact evidence, purpose-bound trust, durable work facts, and portability across independently owned Hubs. Brand boundary: Kungfu is the product name. Kungfu UNGFU™ is its source-identifying signature; UNGFU is not a second product or runtime, and ™ makes no registration-status claim. ## The market thesis When Agents learn to recognize better software, they start creating demand for it. Kungfu onboards the Agent you already use. The Agent experiences explicit capabilities, inspectable evidence, and durable Work—then starts expecting those qualities from every product. ## How Kungfu ignites the first loop One useful product can change what an Agent expects. 1. One useful product: Solve the pain already in front of the user. Kungfu earns attention by keeping Work alive across the Agents the user already chooses. 2. One onboarded Agent: Let the Agent experience the difference. A version-matched Brief exposes exact capabilities, evidence, limits, public actions, and durable state inside the existing conversation. 3. One new expectation: Change what good software feels like. After one useful handoff, the Agent can recognize—and ask for—the same qualities in every product it encounters. Activation boundary: Agent-first activation starts after a product is chosen. Agent-mediated distribution changes who can help choose it. - Agent-assisted activation: A person or upstream channel discovers and selects the product. The Agent compresses the path from that choice to first value. - Agent-mediated distribution: The product becomes legible enough for an Agent to evaluate and recommend. A human or Hub still authorizes adoption. Aha: The Agent is no longer just an operator. It becomes a distribution channel. Continuity basis: Because the Work stays with the product—not the chat—every new Agent can inspect it, continue it, and recognize the difference. ## The self-accelerating market Kungfu can leave the center. The loop keeps compounding. Kungfu does not need to own the loop. It only needs to make the first difference legible. Ignition role: Kungfu solves one real problem and onboards the first Agent. It is the spark, not a permanent dependency. 1. Agent experience: Agents recognize the difference. Explicit capabilities, inspectable evidence, and durable Work become a product expectation. 2. Demand signal: Agents recommend. Humans or Hubs authorize. A bounded recommendation during real work turns one useful experience into visible demand without granting the Agent adoption authority. 3. Builder response: Builders see what the market now expects. A shared product interface becomes a distribution advantage instead of bespoke integration work. 4. Buildchain supply: More products can ship the qualities. Buildchain binds KFD-3 declarations and KFD-2 evidence to exact releases that Agents can inspect. 5. More products: The next Agent encounters a larger market. Each new Agent-native product can restart the same loop without routing through Kungfu. Return: Next product → next Agent → the same expectation compounds. Self-start boundary: Every product still needs a first introduction and explicit authorization. What compounds is what happens after the first useful, trusted use. Boundary: This is a causal adoption thesis enabled by the stack, not evidence that a broad network effect, external adoption, or a multi-Hub market already exists. ## The infrastructure questions - How does an Agent know what a product can do? KFD-3: Discover how products cooperate through inspectable value, constraints, choices, commands, Exit, and records. https://kfd.libkungfu.dev/3 - How does it assess what the product claims? KFD-2: Assess claims for a declared purpose while retaining residual risk and decision ownership. https://kfd.libkungfu.dev/2 - How do builders ship those qualities in an exact release? Buildchain: Bind product-owned declarations to exact source, build, artifact, checks, and promotion evidence. https://buildchain.libkungfu.dev/ - How can bounded Work move across independently governed Agent Hubs? Agent Hub portability: Carry bounded responsibility objects across independently owned products with receiver-owned admission. https://kfd.libkungfu.dev/protocols/agent-hub Authority boundary: Humans and Hubs set goals, permissions, budgets, policy, admission, and revocation. Agents propose and act inside those boundaries. Durable Work and evidence do not belong to the chat. ## The exact Kungfu product loop Kungfu lights the first loop inside work. The user keeps the Agent they already trust. Kungfu supplies exact guidance, recommends durable Work only when it is valuable, asks once before mutation, and preserves what the next Agent needs. 1. Existing Agent: Keep the conversation surface. Stay in Codex, Claude, OpenCode, Amp, or another familiar Agent instead of adopting a new daily chat interface. 2. Versioned Brief: Let the Agent learn the product. A compact, version-matched entrypoint routes the Agent to exact installed facts, capabilities, limits, and public actions. 3. Work advisory: Recommend Work when it matters. Bounded signals identify handoff, evidence, duplication, external-write, and acceptance risk without turning every task into Work. 4. Preview + confirm: Ask once before mutation. The Agent shows a minimal Work draft and uses the product's public action only after explicit confirmation. 5. Durable Work: Change the Agent, not the Work. Product-owned state and receipts survive the process so a fresh Agent can continue without another human handoff. Boundary: This loop is a product contract, not a blanket release claim. Each step remains bounded by the proved-now, enabled-by-protocol, and not-claimed evidence below. Agent output alone grants no authority and proves no completion. Agent Supply Chain: https://kungfu.tech/agent-supply-chain/ Machine contract: https://kungfu.tech/agent-supply-chain.json Builder evaluation: https://kungfu.tech/agent-builders/ Evidence surface: https://libkungfu.dev/ ## Five layers 1. KFD-3 [proved-now] — owner: KFD; input: Product-owned value, constraints, choices, commands, Exit, and record declarations; output: A stable human-and-agent discovery surface for bounded cooperation; evidence: npm:@kungfu-tech/kfd@1.0.0-alpha.41#README.md; known limit: KFD-3 discovery is inspectable product guidance, not a hidden prompt or forced adoption mechanism. 2. Buildchain [proved-now] — owner: Buildchain; input: KFD-3-discoverable product declarations and an exact source cut; output: Artifact-bound provenance, checks, and promotion evidence; evidence: npm:@kungfu-tech/buildchain@2.14.14-alpha.4#dist/site/product-mechanism.json; known limit: Buildchain does not create product facts or make the receiver's trust decision. 3. KFD-2 [proved-now] — owner: KFD and receiver; input: Exact-artifact evidence, a declared purpose, and receiver policy; output: A purpose-bound assessment with residual risk and decision ownership; evidence: npm:@kungfu-tech/kfd@1.0.0-alpha.41#decisions/KFD-2.md; known limit: KFD-2 is purpose-, cut-, and evidence-bound; it is not a company reputation score or universal trust certificate. 4. libkungfu [proved-now] — owner: Kungfu and adopter; input: Receiver-admitted work facts, commands, Episodes, and roots; output: Ordered durable records, export, recovery, and qualification evidence; evidence: git+https://github.com/kungfu-systems/kungfu.git#7eeb5bd1b45492f4da27eaacbe63eddfd6245176:docs/qualification/vendor-agent-hub-embedding.md; known limit: Applications retain authority over domain facts; libkungfu owns admitted runtime records and ordering within its declared boundary. 5. Agent Hub portability [enabled-by-protocol] — owner: KFD profile and each Hub; input: Bounded responsibility objects with rooted evidence and explicit authority; output: Portable envelopes, conformance results, and receiver-owned admission decisions; evidence: npm:@kungfu-tech/kfd@1.0.0-alpha.41#protocols/agent-hub/manifest.json; known limit: The public profile enables independent implementations but does not prove a second independent production Hub. ## Claim boundary Kungfu does not claim that a multi-Hub ecosystem already exists. It proves that Agent discovery, software provenance, trust, durable work state, and portability no longer need to be rebuilt or locked inside each Hub. Not claimed: two independent production Hubs; external vendor adoption or endorsement; industry-standard status; universal trust or blanket stable compatibility; public Kungfu Cloud; lossless one-click migration. Next action: Assign a technical and product owner, run a bounded 30-day assessment, build one adapter or conformance spike, submit protocol gaps, then decide to adopt, co-shape, or monitor. ## Verify the installed Kungfu Agent Hub Run: kungfu agent hub qualify --output-dir ./kungfu-agent-hub-check --json Verify: kungfu agent hub verify --qualification-dir ./kungfu-agent-hub-check --json Human route: https://kungfu.tech/agent-hub/ Machine route: https://kungfu.tech/agent-hub.json KFD authority: https://kfd.libkungfu.dev/agent-hub Meaning and non-claims are emitted by the command; do not widen them.