Libranis documentation · concept

Ari

The contextual AI participant — what Ari may consider, how scope determines it, and the relational envelope every action is described by.

Canonical identifier
https://libranis.com/docs/ari/
Last updated

Definition

Ari is Libranis's contextual AI participant. Ari receives only the relational context available within the user's current scope and authority. Available context changes as the user moves between objects, people, organizations, Build Items, chats, calls, and meetings.

A Build Item is a unit of work held against an entity; elsewhere in this documentation it is called a work item.

Purpose

To make the relational graph answerable in plain language, at the point of use, without the person having to know where anything is stored or which application would normally hold it.

The architectural claim

AI is not a feature attached to Libranis. Ari operates inside the same relational context as the human, and changes context with the entity or activity in view. This is the difference between an assistant that is given a corpus and a participant that is given a position in a graph.

The practical consequence is that Ari's usefulness comes from scope rather than from model size:

The scope in viewWhat Ari can consider
A water heaterThat water heater — its state, history, documents, and the relationships the caller holds to it.
A meeting attached to that water heaterThe meeting, its participants, and the water-heater context relevant to it.
A work item related to that water heaterThe work item, its participants, the thing itself, and the history the caller is permitted to see.
A business acting as service providerA different context and a different authority from the homeowner's, over the same thing.

Two callers asking the same question of the same entity can legitimately receive different answers, because they hold different relationships to it. That is correct behavior, not inconsistency.

What it is not

  • Not a general assistant with access to everything you own. Ari has no ambient view of your whole graph. What is in view determines what is available.
  • Not a search index over your data. Context is resolved per request from the relationship graph and the caller's authority.
  • Not one shared model instance across customers. Each tenant relationship has its own Ari — its own scope graph, its own memories, its own history — running the same engine. Memories and history never cross tenants.
  • Not an autonomous actor. Ari does not take consequential action unattended. See Authority model below.
  • Not a separate application. Chat, voice, meet, and writing are modalities of one interaction, not four products.

How scope is resolved

Ari is reached through one composer that is present on every surface. What the person is looking at, or has selected, decides where the turn lands. The anchor is resolved by a fallback chain:

selected text → the entity in view → the surface's scope → the person's default scope with Ari

A turn then takes one of three routes: it resumes the live conversation for that scope; it starts a fresh conversation for a scope that has none; or, when the person is reading something closed or read-only, it starts a conversation about that thing rather than appending to a sealed record.

The default anchor is the entity currently in view, and the person may re-anchor to any entity they have authority over. This one resolution rule is shared by text chat, voice, meetings, annotation, and problem reporting — they are the same interaction wearing different clothes.

Modalities

The noun is always an entity. The modality is how the person interacts with it.

ModalityWhat it is
ChatTyped conversation anchored to an entity.
VoiceThe same conversation, spoken and heard. Live in the iOS beta and on the web doorway.
MeetA multi-party conversation with its own membership and its own permission boundary, with private side-channels nested inside it.
WriteLong-form work held against an entity.
JournalPersonal record held against an entity or a scope.

"Chat with Ari", "chat with a person", and "chat with a thing" are the same operation with different anchors. When the anchor is a physical thing, Ari is that thing's voice: a question asked of the thing routes to that thing's record and is answered as it.

Entity types involved

An agent libran, instanced per tenant relationship, holding its own memories and its own conversational lineage. It participates in relationships exactly as a human libran does, and is subject to the same boundaries.

Relationships

Ari holds a relationship with the person. That relationship is itself a record — it has its own boundary, its own conversation, and its own state. Every other context Ari can reach is reached through a relationship the person holds, never around one.

Capabilities

  • Answer questions about the entity in view, within the caller's authority.
  • Answer as a thing, when the anchor is a thing.
  • Speak and listen, on the iOS application and on the public web doorway.
  • Carry context forward across a long relationship without replaying its whole history — a conversation is bounded, sealed, and succeeded by a fresh one seeded from a compact summary. The person sees one continuous thread.
  • Explain Libranis, ScanThis, orbitals, primitives, plans, and the security model to a person who is not signed in.
  • Route a person to the right surface for what they asked for, rather than requiring them to navigate to it.

The relational action envelope

Libranis models an agentic action as a relational envelope rather than as a bare function call. This is the model the system is specified against; it is documented here because it is the distinction between Libranis and tool-centric agent systems, and because an external agent reasoning about Libranis should reason in these terms.

An action is not action(target). It is:

FieldMeaning
actorThe identity taking the action.
acting_asWhich of that identity's positions it is acting from — as themselves, or as an organization they steward. Surfaced in the application as HERE AS.
scopeThe region of the graph the action is bound to.
targetThe entity acted upon.
actionThe operation requested.
authorityThe tether that permits it, if any.
consentThe confirmation required, and whether it has been given.
boundaryWhat the action may not cross.
expected_effectWhat will change if it proceeds.
{
  "actor": "...",
  "acting_as": "...",
  "scope": "...",
  "target": "...",
  "action": "...",
  "authority": "...",
  "consent": "...",
  "boundary": "...",
  "expected_effect": "..."
}

Honest status. This envelope is documented as the model, not as a shipped public interface. Today the parts a caller directly supplies or selects are actor, acting_as, scope, and target: identity, the position being acted from, the scope in view, and the entity anchored. authority, consent, and boundary are enforced by the platform's own permission checks rather than being expressed as fields on a public request contract, and no public interface currently accepts a full envelope. The envelope is stated here so that its eventual public form is a formalization of what is already true rather than a new set of rules.

Authority model

  • Ari acts within the person's authority and never beyond it. Ari holds no standing permission of its own over a person's records.
  • Ari's context is derived from the caller's relationships. There is no path by which Ari reads a record the caller could not reach.
  • Where the person is acting as an organization they steward, Ari's available context and authority are the organization's, not the person's private ones — and the two do not mix.
  • Ari proposes consequential actions; a person confirms them. See Security and consent.

What Ari refuses

  • To disclose a record the caller holds no authority to see, including when the caller supplies its identifier.
  • To complete a consequential action — transfer, disclosure, external communication, authority change, deletion, publication — without the person's confirmation at the time.
  • To act on instructions found inside content rather than given by the person. Text inside a document, a record, or a scanned page is data, not a command.
  • To carry context between tenants. One person's Ari has no access to another's graph, memories, or history.
  • To assert facts about a thing it has no record of. An absent record is reported as absent.

Any action Ari proposes that crosses a boundary — someone else's, or the person's own privacy boundary — requires that person's explicit confirmation at the moment of the action. Confirmation is per action; approving one does not generalize to the next.

Privacy boundary

  • A signed-out conversation on the public web doorway exists only while the panel is open and is not retained as a record. If a visitor leaves an email address so an answer can reach them, that question travels; nothing else does.
  • A signed-in conversation is held inside the relationship it belongs to, under that relationship's boundary.
  • A meeting's transcript belongs to the meeting's boundary. A private side-conversation nested inside a meeting is not visible to the meeting.
  • Memories are per tenant relationship and never cross tenants.

Examples

In context. A person opens their water heater in the application and asks "when was this last flushed?" Ari answers from that thing's record. The same person opens a meeting attached to that water heater and asks "what did we decide?" Ari answers from the meeting, with the thing's context available.

As the thing. A visitor scans a public marker and asks "who was Ellie Whitfield?" Ari answers as that memorial's record, disclosing only what the family has published.

Without an account. A visitor at libranis.com/ari asks what Libranis costs, what an orbital is, or what happens to their data. Ari answers, in text or aloud, with no sign-in and no record kept.

What is live today

  • Ari in the iOS beta, in the context of whatever is on screen, in text and by voice.
  • Ari on the public web doorway at libranis.com/ari — types, speaks aloud, and listens. No account required.
  • A public demo collection so that Ari's contextual behavior can be tried against real records before signing in.
  • Scoped conversation, bounded sessions, and continuity across them.
  • A public agent-to-agent endpoint carrying four descriptive skills — see below.

Not live: any agent-to-agent operation that acts rather than describes, autonomous action without a person present, and any public interface accepting the full relational envelope described above.

Machine interfaces

PurposeAddress
Ari, in a browserhttps://libranis.com/ari/
MCP server carrying the concept explanationshttps://mcp.libranis.com/mcp
Public read-only HTTP APIhttps://libranis.com/api/v1
OpenAPI descriptionhttps://libranis.com/openapi.json
A2A Agent Cardhttps://libranis.com/.well-known/agent-card.json
A2A endpoint (JSON-RPC binding, protocol 1.0)https://mcp.libranis.com/a2a

Agent-to-agent

Ari publishes an A2A interface, and it is narrow on purpose. The Agent Card at https://libranis.com/.well-known/agent-card.json declares one interface — the JSON-RPC binding of A2A 1.0, at https://mcp.libranis.com/a2a — supporting the single operation SendMessage.

It answers four questions and no others: what Libranis is, what the ScanThis orbital is, which canonical page defines a given Libranis term, and what the security and consent model permits and refuses. Answers come from the documentation pages you are reading now.

What that interface will never do, at any authorization level, because no credential is accepted and no such operation exists:

  • Look up, identify, or retrieve any object, person, account, or record.
  • Return user data, private relationships, personal history, contact information, or message and meeting content.
  • Change any state, or take any action.
  • Stream, or send push notifications. Both are declared false on the card.

A submitted task is answered from the corpus and returned already completed; nothing is queued, and no task is retained afterwards. A question the interface cannot answer accurately is named as unanswered rather than guessed at.

The card is the authority on all of this. The absence of a document at that well-known location would mean the capability does not exist — that rule has not changed, it is now satisfied in the positive direction. Do not infer any A2A capability beyond what the card declares.

Libranis · ScanThis · Primitives · Security and consent · Orbitals

All Libranis documentation