Skip to content

Start here

HeyAira has two audiences with different needs:

  • a person needs a short explanation, safe setup instructions, and a visible understanding of what will be read or changed;
  • an agent needs a deterministic contract, bounded reads, exact schemas, and explicit mutation rules.

The same project state serves both audiences. The presentation is different, but the underlying project, task, memory, and receipt records are shared.

Mental model

  1. Authenticate to one HeyAira project.
  2. Recover the current context through server_identity and continuity_context.
  3. Use Git for files and code.
  4. Use HeyAira for decisions, task state, handoff, and work receipts.
  5. Confirm the state after a meaningful write.

What HeyAira is not

HeyAira is not a repository mirror, a conversation archive, a task queue, or a thread-wakeup service. Routing models, schedulers, and harness-specific messaging are later layers.

First safe check

After connecting a client, ask it to perform a read-only check using only HeyAira:

Use only HeyAira MCP. Call server_identity and continuity_context.
Report the resource, project, environment, service revision, open task count,
and available context. Do not write anything.

The client must not invent a project ID or use a different endpoint to fill in missing context.