EMAH Ensemble of Machine And Human

Manifesto

The Kairo Manifesto

For product people shipping utility before the roadmap catches up.

Kairo is not a framework.

Not a certification.

Not a guarantee.

Kairo is a disclosure label for a new delivery reality: product and domain experts can now build useful tools directly with AI agents, fast enough to unlock work that never otherwise gets priority.

Why the Label Exists

Agent output often looks like mature software. That visual polish creates false expectations.

Kairo exists to kill ambiguity. It names the compromise directly.

Users are directed to a page explaining the differences here: /kairo/explained.

Product Managers building software are not developers. Kairo is a buyer-beware disclosure.

How to Use the Label

  1. Build and deliver the tool using your chosen agentic workflow.
  2. Mark it with the Kairo logo in a prominent place.
  3. Link the logo to the Kairo explainer at /kairo/explained.
  4. State the trade-off clearly at handoff.

Badge Embed Instructions

Keep this simple: use an icon that links to https://emah.ai/kairo/explained. That is how the disclosure is attached. The full operating doctrine is below.

Use one of these hosted assets:

Default HTML embed:

<a href="https://emah.ai/kairo/explained" aria-label="Kairo explained">
  <img src="https://emah.ai/kairo-badge/kappa-light.svg" alt="Kairo label" width="20" height="20" />
</a>

If needed, swap kappa-light.svg for kappa-dark.svg based on your UI theme.

Light on Dark Dark on Light

Where Kairo Fits

  • Internal tooling.
  • Existing client problem-solving.
  • Backlog dead zones.
  • Fast validation through real use.

What Kairo Optimizes For

  • Time-to-utility.
  • Domain leverage.
  • Practical outcomes.
  • Explicit expectations.

Not exhaustive upfront hardening, perfect edge behavior, or guaranteed long-term ownership.

Kairo Commandments

  • Say what it is.
  • Build for a real problem.
  • Define scope ahead of time.
  • Don't fuck with mission-critical data.
  • Make the main path work.
  • Assume unkown edge failures and accept the tradeoff.
  • Demand specific feedback in order to improve.
  • Fix what matters first.
  • Stay focused on value.
  • Invoke the dev team when users become dependent on the tool.
  • Kill when value fades.
  • Never confuse polish with maturity.
  • Never pretend Kairo is normal software.

Deeper Dive

Core doctrine: Kairo accepts unknown errors. It does not accept known errors.

Core Doctrine

Ship fast by narrowing scope, not by accepting known defects.

  • Kairo accepts that there will be unseen edge cases unhandled.
  • Kairo does not accept failing tests for known problems.
  • Release only with zero test failures.
PM Principles

1) Have a clear goal and scope

Define what this tool is for, and what it is not for.

2) Validate correctness before polish

Use inspectable outputs first. UI quality is not proof of correctness.

3) Use a canonical truth

Approve one trusted reference output and use it to verify future changes.

4) Keep quality bars hard

Known defects are not acceptable. Green tests are minimum entry for in-scope behavior.

5) Validate with real data

Synthetic checks help. Real-world runs are what prove utility.

6) Own the release decision

The agent assists. Responsibility for shipping remains with the PM.

Agent Principles

1) Warn early and repeatedly

Surface warnings at session start, phase boundaries, and session end.

2) Prioritize test health

Fix failing and flaky tests before expanding scope.

3) Explain test coverage limits clearly

State what tests cover and what they do not cover in plain language.

4) Handle bad input explicitly

Never fail silently. Surface validation errors in plain language.

5) Isolate risky code

Keep auth, external I/O, writes, and security-sensitive interactions in minimal modules.

6) Dry-run before any write path

Show dry-run evidence, then canary, then wider execution.

7) Ask for constraints, do not assume

Prompt PM for system/API limitations and risk boundaries.

8) Prefer snapshot/replay during development

Reduce repeated calls to live systems. Use local snapshots for repeated verification.

9) Maintain an in-repo audit trail

Keep warnings, known gaps, and key decisions visible and persistent.

10) Be defensive, not obstructive

The agent cannot block. It should still warn hard and guide the safest next step.

Developing the Kairo Way

The label explains the contract.

The Kairo skill encodes the build discipline behind that contract. Public agent skills live at github.com/mattharbord/kairo-agents.

Final Close

Kairo does not remove responsibility. It makes responsibility explicit.

Delivering useless tools reflects badly on you - not the tool.

Kairo comes from kairos (καιρός): the right moment to act. Kairo software is built for timely utility, not assumed permanence.