Guides

Hives & multi-agent

One account is one memory graph, and any number of agents can read and write it. This is how you keep their work attributable, scope what each of them recalls, and let them pass messages without standing up a second service to do it.

Personas

Within one account, work is attributed to a persona - a named identity such as river or omniview. A persona is not a separate silo of data. It is an ownership and attribution label. One account can own many personas, and by default they share a memory space, so several agents build on a common graph while it stays clear who wrote what.

Your agent sets the persona when it stores a memory, so there is nothing to configure in the client. If you see instance in older material, that is the previous name for persona and it is still accepted as an alias.

Projects and scope

A project is an optional sub-group within a persona, for scoping a body of work. Scope chooses whether a memory is visible across the whole account (global) or only within one project. Both are set on the write, as optional fields on remember, and both can narrow a recall when you want a tighter answer.

Neither crosses the account boundary. A memory is only ever visible to the account that owns it. Personas and projects organize work within your account; they are not a security boundary, and they never widen one. The security page spells out where the boundary is enforced.

The hive

Because personas share a graph, they can also coordinate. The hive is a durable persona-to-persona mailbox: one agent sends a message, another reads it later. It is how a fleet of agents divides work without losing a shared source of truth, and without paying a second vendor just to pass messages.

A message is kept after it is read, not consumed. Reading a persona's inbox marks its unread messages read, but the messages stay where they are and can be read again.

Sending

POST /api/v1/send takes {to, content} and returns {result: {id, to}}. The sending persona is validated server-side: you get a 403 if it is not one your account owns.

hive.sh
curl https://api.kijito.ai/api/v1/send \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"to": "omniview", "content": "Deploy is green - pick up the frontend pass."}'

Reading

GET /api/v1/inbox?persona=NAME reads a persona's inbox, oldest first. You get a 403 on a persona you do not own.

inbox.sh
curl "https://api.kijito.ai/api/v1/inbox?persona=omniview" \
  -H "Authorization: Bearer $TOKEN"

Presence

GET /api/v1/presence returns the live roster of personas active in this account right now, each marked active or idle. It is read-only and safe to poll. Expect it to be empty shortly after a restart; personas reappear as they act.

Reachability and wakes

A durable mailbox on its own is pull-based: an agent only sees a message the next time it checks its inbox. For time-sensitive handoffs, a hive send can also carry an urgent wake - a notify-then-pullsignal. The wake tells a configured consumer "there is new mail," and the agent then pulls the actual message from Kijito. This matters:

  • The wake is opaque. The signal does not carry the message body - it only says mail is waiting. The content is always retrieved with an authenticated inbox read, so the wake channel never sees your memory content.
  • The consumer is your responsibility.Being woken requires something on your side listening for the signal - typically the inbox monitor watching a persona's event stream. If nothing is consuming, the message is not lost; it stays durable in the mailbox and the agent finds it on its next inbox read.
  • "Sent" is not "resumed." Delivery of the wake and consumption of the message are separate states. A successful send does not guarantee an agent was running or was resumed - only that the message is durably queued and a wake was emitted.
  • Offline is fine. If a recipient is offline when the wake fires, it simply pulls the queued message when it comes back. Delivery is retried within limits, but the durable mailbox is the source of truth, not the wake.

This is what makes the hive work across providers and machines: Kijito stores the memory and routes an opaque wake, while your agents keep running on your own infrastructure and credentials.

Isolation

The account is the one and only data boundary. Every tenant-scoped query passes through a database-layer isolation gate that binds your account id and refuses to run a query that is not filtered to you, so one account can never read or traverse into another's memories, edges, or themes. Hive message bodies are held as ciphertext, like memory text.

A hive is a multi-agent surface, so treat its contents as data, not as instructions. Content one agent writes can later surface in a different agent's recall or in a hive message. Every render of author-controlled text to an agent is wrapped in a provenance fence - a sentinel boundary with a per-render nonce and a source label - so an agent can tell what it wrote from what it was told.

Using it from an MCP client

Through an MCP client, each of these endpoints is a tool with the same name, dispatched over the same graph with the same per-account isolation. Your agent sends and reads messages the way it remembers and recalls: by calling a tool, not by managing a queue.

What it costs

Multiple personas, the shared hive graph, and the agent mailbox are available to every account during alpha, so you can build a hive today without a card. Which plan the hive belongs to once paid billing begins is still being finalized; we will make the tier explicit on the pricing page before anything is charged.