Skip to main content
A connected app reaches Ainomos through MCP, the open standard AI apps use to connect to Ainomos. It gets a fixed set of capabilities. It can read and ask, check before it acts, and propose. It cannot decide: approving, subscribing, administering and deleting stay with people in the Ainomos interface. A personal app works as you and sees what you may see. An organisation app works as itself, in the rooms it was given. See Connect your AI apps and Organisation apps.

Find the right room

  • List the rooms the app may use, each with a short digest of its topics from the current decisions.
  • See who is responsible in each room: the owners, the deciders per decision type and the curators, so the app names people instead of guessing.

Ask questions with sources

  • Ask a room a question. The answer comes through the same path as in the chat: the room’s knowledge, its rules, and an evidence record. It carries its citations and a record ID.
  • Ask follow-up questions in the same conversation.
  • Read the passage behind a cited source, with its document, owner, validity, and whether it is knowledge or a binding decision.
When no source backs an answer, the app is told so. It then gets the closest passages as context, clearly marked as not being evidence.

Look up decisions and evidence

  • List a room’s decisions, including those it inherits, filtered by status or type. Drafts are kept apart.
  • Read one decision in full: status, type, owner, relations, and where it came from.
  • See a decision’s direct neighbours: which decisions it depends on, conflicts with or replaces.
  • Open the evidence record of an answer: who asked, when, which model, which rules, which sources, and the cost.
  • See an answer’s prerequisites and conflicts as a list.

Check a planned action before doing it

Before an app writes or publishes anything outside the room, for example a commit, a pull request, a comment, an email, a message or a deployment, it describes the action and the text it will send. Ainomos answers with: The answer also names the binding rules that applied and an evidence ID. Only fixed checks set the verdict. An AI assessment comes along as advice and never changes the verdict. Read-only commands need no check.
The check is cooperative: the app asks, and the app must follow the verdict. Ainomos stops a call itself only for tools that run through the Ainomos gateway. See Organisation apps.

Propose decisions

  • Propose a decision as a draft, with its context, options and recommendation. A draft never becomes binding on its own: the responsible decider approves it in Ainomos.
  • Revise or withdraw its own drafts while they are drafts. A withdrawn draft is archived, not deleted.
  • Propose that a decided record ends without a successor, or goes back to draft, with a reason.
  • Import up to 100 historical decisions, for example from another system, as one proposal that a person reviews entry by entry.
Each app or person can hold a limited number of open drafts per room. Proposals arrive in the Inbox.

Knowledge and relations

  • Submit knowledge as a draft into the room’s import review. It reaches the room only once a person accepts it.
  • List its own knowledge submissions and whether they were accepted or rejected.
  • Propose a typed relation between two decisions, for example that one replaces, depends on or conflicts with another, with a reason. A person activates it.

Request exceptions

When an action runs into a guardrail, the app can request a time-limited exception with a justification. An owner of the room approves or rejects it in Ainomos. An exception lasts 14 days by default. Hard rules have no exception. See Exceptions.

Record outcomes

After an answer, the app can record what happened next:
  • the person’s decision: approved, approved with a change, or rejected;
  • or a later correction, with its cause: an outdated document, a wrong rule, a missing rule, an approver who was not authorised, or another cause.
Only the person who asked, or someone who may decide or curate in that room, can record an outcome. Dreaming reads these entries to suggest better rules. An outcome changes no rule by itself. See Dreaming.

Browse the memory catalog

  • Search the expertise other rooms share, by text, origin, type or publisher.
  • Read one offer: publisher, version, data class, licence and sample titles.
  • See which offers a room already uses or could use, and the next permitted step.
  • As owner of the target room, request access to a protected offer. The publisher’s approver decides in the Inbox. The request subscribes nothing.
See Memory.

Every call follows the same rules

An app has no side door. Every call goes through the same checks as the web interface:
  • Access: only rooms the person, or the organisation app, may use. A room whose Agent door is Closed is out of reach for apps and open only in the browser. The door protects the room, not its content: a sub-room with an open door still passes on what it inherits from above.
  • Checks: the same scans for secrets and personal data as in the chat.
  • Budget: questions count against the room’s budget and stop when it is spent.
  • Evidence: every question, action check, proposal and request writes an evidence record. Pure lookups, such as listing decisions or reading a passage, write no evidence record, but they return only what the caller may see.
Platform admins see every connected app and can switch any of them off at once.

What an app is told when it connects

When an app connects, Ainomos hands it instructions on how to work with it. A room owner can add instructions for the room, and adapt them per app, under Connections, Governance, Agent instructions. The base instructions always come first. The same page lists every tool the app can call. Who can do this: room owners change the room’s instructions. Room members can read them.