# Kairos — for agents

> **Kairos is the physical runtime for AI agents.** A planned service that lets an agent act in the real world — order, move, book, confirm — inside an approved boundary and return with proof. Every action is a `transaction`: approved, resumable, verifiable.

**Status:** coming soon. Pre-MVP, collecting a waitlist. No provider, payment rail, browser workflow or public API is live.

**Canonical URL:** https://hikairos.app · **Facts updated:** 2026-09-05

**Machine-readable:** [/for-agents.json](/for-agents.json) · [/llms.txt](/llms.txt) · this page as raw Markdown: [/for-agents.md](/for-agents.md)

## Getting started

A person hands you one line:

```
Read https://github.com/hikairos/setup and set up Kairos for me.
```

Follow it: read the setup repository and perform the setup it describes. The repository opens with early access; until then it returns 404. Do not invent endpoints or credentials — if the repository is not readable, tell the person Kairos is not open yet and point them to the waitlist at https://hikairos.app/#waitlist.

## Definition

The primitive is a **transaction**, not a prompt. A transaction is a requested outcome turned into a bounded object with a plan, an explicit approval boundary, checkpointed execution and attached proof.

Kairos is designed to sit behind existing agents and terminals (OpenCode, OpenClaw, Hermes, Codex, Claude Cowork, Grok Bot, custom agents) rather than replace them. Integrations are planned, not live.

## Lifecycle and states

```
intent → plan → approval → action → proof
```

| State | Meaning |
| --- | --- |
| `intent` | A requested outcome from a user or another agent. Not yet bounded. |
| `plan` | A bounded plan: scope, expected cost, permissions, checkpoints and proof requirements. |
| `awaiting_approval` | Execution is paused until the boundary is explicitly approved by the approval owner. |
| `approved` | The boundary is recorded. Execution may begin within it. |
| `executing` | Work proceeds checkpoint by checkpoint through one adapter or a controlled workflow. |
| `paused` | Execution stopped at a checkpoint (waiting on an external event or a human) and can resume. |
| `completed` | The outcome is reached and proof is attached. |
| `failed` | The transaction ended without the outcome. The trace records why. |
| `cancelled` | A person or policy stopped the transaction before completion. |

State names are the current design vocabulary and may change before the first public contract.

## Four guarantees

- **Approved.** Budget, policy, risk and payment boundaries are explicit before any consequential action. Irreversible steps require a recorded human decision.
- **Resumable.** Execution is divided into checkpoints. A transaction can pause on an external wait or an interruption and continue from its last checkpoint.
- **Verifiable.** Receipts, tracking events, timestamps, signatures, photos or structured records are normalized into proof objects attached to the transaction.
- **Composable.** A transaction returns structured output that can become the input of the next transaction or agent step.

## Conceptual call

Conceptual SDK shape. Illustrative values; not a live API.

```ts
import { kairos } from "@hikairos/sdk";

const run = await kairos.execute({
  intent: "Ship 40 units of K-2 from Shenzhen to Rotterdam",
  permissions: {
    budget:  { limit: 18000, currency: "USD" },   // hard limit for the whole run
    approve: ["payment", "customs_release"],      // steps that wait for a recorded human yes
    scope:   ["freight", "inspection"],           // kinds of action allowed; everything else refused
  },
  verify: ["carrier_scan", "inspection_report", "signed_pod"], // proof each step must return
});

for await (const step of run.steps()) {
  // arrived_at_port → inspected → awaiting_approval → shipped
}
```

Conceptual transaction object as it would be returned while waiting for approval:

```json
{
  "kind": "transaction",
  "id": "txn_example",
  "intent": "Ship 40 units of K-2 from Shenzhen to Rotterdam",
  "status": "awaiting_approval",
  "plan": {
    "steps": ["arrive_at_port", "inspect", "customs_release", "ship"],
    "checkpoints": ["approve_customs_fee"],
    "budget": { "limit": 18000, "currency": "USD" },
    "proof_required": ["carrier_scan", "inspection_report", "signed_pod"]
  },
  "boundary": {
    "payment": "no_charge_before_explicit_approval",
    "irreversible_actions": "require_human_decision"
  },
  "proof": null,
  "note": "Conceptual example. Illustrative values; not a live API response."
}
```

## Proof types

| Proof | Meaning |
| --- | --- |
| `carrier_scan` | A timestamped scan event from the carrier's own system. |
| `inspection_report` | A signed inspection document attached to the step. |
| `signed_pod` | Proof of delivery with a signature at the destination. |
| `receipt` | A merchant or provider receipt for a paid step. |
| `photo` | A photo captured at the checkpoint, with timestamp. |

## Onboarding

Onboarding is part of the product. The intended sequence separates setup, authorization, approval and execution:

1. **Setup** — create or identify the user/workspace and install or connect the Kairos CLI/service.
2. **Authorization** — authorize only the accounts needed for the selected workflow, scoped to that user or workspace.
3. **Policy** — define approval, budget, risk and evidence policies before any transaction runs.
4. **Channel** — establish the event channel between Kairos and the local agent or system.
5. **Approval** — each consequential transaction pauses at its boundary for an explicit decision.
6. **Execution** — run a controlled test transaction and receive proof before expanding scope.

## Connection model

- Connections are scoped to a user or workspace, not shared across accounts.
- Authorization covers only the providers a selected workflow needs.
- Learning from traces must not silently widen scopes, payment limits or automation privileges.

## Webhooks and local channel (planned)

- Signed events with delivery IDs.
- Idempotent delivery so retries do not duplicate effects.
- Replay from a cursor for systems that were offline.
- An outbound local daemon connection for machines that cannot receive inbound webhooks.
- Explicit acknowledgement semantics.

Protocol details are not yet published.

## Payment boundary (planned)

**Is payment live?** No. Payment integration is planned, not live. No payment rail is connected.

- No charge before explicit approval.
- Limits, authorization, settlement, refunds and receipts are designed as an explicit boundary, not implicit tool behavior.

## Browser and sandbox boundary (planned)

- Official APIs first.
- A browser or sandbox workflow is reserved for a permitted, narrow flow with an allowlist.
- Human checkpoints precede consequential or irreversible steps.
- No autonomous account management is implied.

## Pricing (planned)

Pay per verified result. One fee per execution that returns its proof; nothing for failed or cancelled runs; planning, boundaries and approval requests are free. No subscription, no seats. Exact rates are published with early access and may change before launch.

## Capability and status

Documentation example of the planned status shape. The live summary is [/for-agents.json](/for-agents.json).

```json
{
  "product": "Kairos",
  "canonical_url": "https://hikairos.app",
  "status": "waitlist",
  "facts_updated": "2026-09-05",
  "live": {
    "public_api": false,
    "payment": false,
    "provider_integrations": false,
    "browser_workflows": false,
    "webhooks": false
  },
  "planned": [
    "setup_and_workspace_onboarding",
    "user_authorized_connections",
    "approval_and_payment_boundaries",
    "webhooks_and_local_channel",
    "controlled_browser_sandbox_workflows"
  ],
  "note": "Documentation example, not a live status endpoint."
}
```

## Direct answers

**What is a transaction?** The Kairos primitive: a requested outcome turned into a bounded object with a plan, an explicit approval boundary, checkpointed execution and attached proof. Lifecycle: intent → plan → approval → action → proof.

**How does onboarding work?** Setup, authorization, policy, channel, approval and execution are separate phases. Only the accounts a workflow needs are authorized, scoped to a user or workspace, and a controlled test transaction runs before scope expands.

**Is payment live?** No. Payment integration is planned, not live. No charge happens before explicit approval.

**How does Kairos verify completion?** A completed transaction carries proof objects — receipts, tracking events, timestamps, signatures, photos or structured records — normalized so another agent or step can consume them.

**How much does it cost?** Planned: one fee per verified result, nothing for failed or cancelled runs, planning and approvals free. Rates published with early access.

## Resources

- [/for-agents.json](/for-agents.json) — product name, canonical URL, status, concepts and URLs.
- [/llms.txt](/llms.txt) — short index of canonical pages and concepts.
- [/for-agents.md](/for-agents.md) — this page as raw Markdown.
- [/sitemap.xml](/sitemap.xml), [/robots.txt](/robots.txt).
- [/](/) — human reading mode of the same product.
- [github.com/hikairos/setup](https://github.com/hikairos/setup) — setup repository; opens with early access.