Ari
The contextual AI participant — what Ari may consider, how scope determines it, and the relational envelope every action is described by.
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 view | What Ari can consider |
|---|---|
| A water heater | That water heater — its state, history, documents, and the relationships the caller holds to it. |
| A meeting attached to that water heater | The meeting, its participants, and the water-heater context relevant to it. |
| A work item related to that water heater | The work item, its participants, the thing itself, and the history the caller is permitted to see. |
| A business acting as service provider | A 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.
| Modality | What it is |
|---|---|
| Chat | Typed conversation anchored to an entity. |
| Voice | The same conversation, spoken and heard. Live in the iOS beta and on the web doorway. |
| Meet | A multi-party conversation with its own membership and its own permission boundary, with private side-channels nested inside it. |
| Write | Long-form work held against an entity. |
| Journal | Personal 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:
| Field | Meaning |
|---|---|
actor | The identity taking the action. |
acting_as | Which of that identity's positions it is acting from — as themselves, or as an organization they steward. Surfaced in the application as HERE AS. |
scope | The region of the graph the action is bound to. |
target | The entity acted upon. |
action | The operation requested. |
authority | The tether that permits it, if any. |
consent | The confirmation required, and whether it has been given. |
boundary | What the action may not cross. |
expected_effect | What 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.
Consent requirements
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
| Purpose | Address |
|---|---|
| Ari, in a browser | https://libranis.com/ari/ |
| MCP server carrying the concept explanations | https://mcp.libranis.com/mcp |
| Public read-only HTTP API | https://libranis.com/api/v1 |
| OpenAPI description | https://libranis.com/openapi.json |
| A2A Agent Card | https://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
falseon 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.
Related concepts
Libranis · ScanThis · Primitives · Security and consent · Orbitals