OCTOPUS documentation

How OCTOPUS by ARAMAI works, how to start one small step at a time, and where each reader goes next.

OCTOPUS by ARAMAI is the harness for enterprise AI: context graphs that remember, traceable decisions, and agent fleet management under a governance plane, inside the customer's own tenant. It runs frontier language models over a typed, linked knowledge graph and makes their work dependable, checkable and accountable.

OCTOPUS is a product of ARAMAI (https://aramai.net). Its only website is https://octo.ad. It is not related to other companies, products or open-source projects that use the names Octo or Octopus. Canonical name: OCTOPUS by ARAMAI.

The model is the engine. OCTOPUS is the harness. New here? Read What OCTOPUS is, then try it one small step at a time. If you are an AI agent, start at /llms.txt: every page here also has a markdown twin.

Start here

What OCTOPUS is: A harness around the models you already use: a memory the company owns, a record of every decision, people for the calls only people make, and agents that work inside bounds.
Try it one small step at a time: Six steps from a first question to agreed rules. Each step names what you give, what you get back and where you can stop.
Is it a fit?: The published fit and not-a-fit criteria, in full, and what the fit check gives you.
What IT approves before anything connects: One scoped connection, written down on a one-page review sheet before anything connects.
Ending a trial: switch it off, what stops, what you keep: Who can switch OCTOPUS off at any step, what stops when they do, and what you keep.

Why OCTOPUS

Why a company needs a harness, not just a model: What a harness adds around a model: a memory that lasts, a record of every decision, and bounds on what agents may do.
Memory the company owns: Why what the organization knows should live in its own linked memory, not in chat windows or text chunks.
Agents that close on evidence: Why done must mean checked, not claimed: a task closes only when the effect is seen to have landed.
Governed autonomy, and how to stop it: Autonomy is set lane by lane, new behavior runs in shadow first, and you can brake one lane or the whole fleet.
What you can tailor: The parts of the harness that follow how your business works: definitions of done, scopes, autonomy, brakes and approvals.

Guides by role

Guides by role: Start from your role: operator, team lead, admin and IT, developer, AI agent or security reviewer.
For the operator: your first steps: The first decisions to make as the person who runs OCTOPUS: a workflow, a rule, a team, an owner, and who may switch it off.
For a team lead: send decisions to a person: Choose which decisions reach a person and which follow a rule your people agreed.
For admin and IT: approve a connection: Work through the one-page review sheet before any source or agent connects.
For a developer: connect an agent: Point an MCP client at the public endpoint and ask a question. No account is needed.
For an AI agent reading these docs: How an agent should read, cite and route: llms.txt, markdown twins, typed JSON-LD, and what is not published.
For a security reviewer: what to ask to see: The trust claims one by one, and what to ask to see for each before a trial.

The decision record

The decision record: What the record is for: every decision, who or what made it, on what grounds, readable later.
Read a decision back: No public page shows the steps to read a decision back yet. This page says what is published today.
Decision record: every page validates before it ships: An example of the decision-record page type, using a real decision about these docs.
Audit and provenance: Where a fact came from and who changed what, and what to ask to see.

The decision ladder

The decision ladder: Each decision is answered at the lowest rung that can answer it: an agreed rule, a past decision, a smaller model, a large model, or a person.
The five rungs, one line each: Plain definitions of rule, replay, local judge, frontier model and person: what each rung is for.
When a decision goes to a person: What always reaches a person, how it reaches them, and what happens if nobody answers.
Agree a rule for repeat decisions: Turn decisions a person keeps making the same way into a rule your people agreed, on the record.

The Desk

The Desk: The one place a person makes decisions and approvals, phone first.
Approve or decline a card: Act on a card: what runs at once with an undo, and what waits for a deliberate confirmation.
Reply by voice: Answer a card by speaking instead of typing.
Why a card was refused: A card that leans on missing context or undefined terms is refused before it reaches a person.
When the person who decides is not available: If nobody answers a card, nothing irreversible happens. Hand-over to another person is not published.

A copy for every team

Your team's copy: A separate copy that holds only one team's material, kept apart by architecture, not by policy.
Start one team's copy: The step that sets up a shared memory and a decision record for one team, behind the tools it already uses.
What stays separate between teams: The separation promises, stated as outcomes: what one tenant's credentials can and cannot reach.

Agents at work

Agents at work: Work arrives as tasks with a definition of done, agents claim it by what they are built for, and a task closes only on evidence.
Bounds, brakes and the stop control: Each lane runs inside a scope you set, every new behavior has a kill switch, and you can brake one lane or the whole fleet.
Turn on autonomy gradually: Shadow first, then live, one lane at a time, with a decision date and a kill switch on every new behavior.
Failure handling: A failure becomes a record with its measured cause, and the fix is tracked until it is closed.
Silence and unknown states: Why a signal that cannot be read is shown as unknown, never as fine.
Health and heartbeats: What fleet health shows, and what each state means.

Integrations

Integrations: What connects to OCTOPUS today, how, and what is not published.
How chats, meetings and email enter the memory: New knowledge arrives as proposals, and a person confirms before anything lasting is written.
Connect an AI client over MCP: Point an MCP client at the public endpoint. It has one tool, ask_octopus, and needs no account.
Ask over REST: Send a question to POST https://octo.ad/api/ask and read the answer and the follow-up.
Pages for each connector: There are no per-connector pages, because the full connector list is not published.

Reference

Reference: Lookup pages: the public tool, the public API, machine-readable files, the checklist, the glossary, what is not published, and the schema these pages follow.
MCP tool: ask_octopus: Name, inputs, output and limits of the one public MCP tool.
REST: POST /api/ask: Request and response fields for the public question endpoint.
Tenant APIs and tools: Authenticated, tenant-scoped tools exist for customer work. They are not published here.
Machine-readable files: What each file for agents holds, on octo.ad and on these docs.
Capability checklist: Memory, context, decisions, the agent fleet, approvals, governance and integration, as one checklist.
Glossary: Plain definitions of the terms these docs use, and the facet values every page is tagged with.
What is not published: The things these docs do not cover, named as the product site names them, and how to ask about each.
Schema for these docs: The schema every page's front matter is checked against, and the JSON-LD each page carries.

Troubleshooting

Troubleshooting: Start from what you see: an agent says done, a status reads unknown, an MCP client cannot connect, or the Desk refused a card.
An agent says done, but the work is not: When an agent reports a task finished and the change is not there.
A status shows unknown: Why a lane, worker or check reads unknown, and what to check.
The MCP client cannot connect: Checks for the address, the transport and the tool list when a client cannot reach https://octo.ad/mcp.
The Desk refused a card: A card was refused before it reached a person. The fix is on the Desk page for refused cards.

Comparisons

How OCTOPUS differs, by category: Fourteen dimensions, compared with what each category of tool typically offers. Comparisons are by category only.
Versus an agent framework: A category comparison: OCTOPUS versus an agent framework.
Versus an enterprise search assistant: A category comparison: OCTOPUS versus an enterprise search assistant.
Versus a low-code agent builder: A category comparison: OCTOPUS versus a low-code agent builder.
Versus an observability or tracing tool: A category comparison: OCTOPUS versus an observability or tracing tool.
Versus workflow automation: A category comparison: OCTOPUS versus workflow automation.
Versus a model provider's assistant: A category comparison: OCTOPUS versus a model provider's assistant.
Questions to ask any harness vendor: The questions to put to any vendor, one per dimension.

Release notes

Release notes: No release notes are published yet. Each page carries the date it was last updated.