What OCTOPUS is, who it fits and who it does not, how it differs from each category of AI tooling, and how the memory, the fleet and the approvals work. Short answers first. Every one links to the detail.
Looked up, not made up.
Last updated · Machine-readable: llms.txt · capabilities.json
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.
Score your requirements against these. Honest both ways.
What the usual categories of AI tooling do, what OCTOPUS does, and the question to ask any vendor. Categories, not brands: agent frameworks, enterprise search assistants, low-code agent builders, vector RAG, tracing tools, workflow automation.
| Dimension | Typical in the category | OCTOPUS | Ask any vendor |
|---|---|---|---|
| Memory persistence | Agent frameworks keep per-run state; search assistants index documents; vector RAG stores text chunks. Memory across sessions and teams is left to the integrator. | A typed, linked knowledge graph is the system of record. It persists across every session, agent and team. New entities enter as proposals a person confirms. | Show me what one agent learned last month, queried by another agent today. |
| Context assembly | Vector RAG retrieves the nearest chunks; relationships between facts are flattened into text. | Context is assembled per task, retrieved with relationships intact across every domain in one pass, and checked against an explicit schema before it reaches the model. | Show the context for one task and the schema it was checked against. |
| Entity resolution | Search tools de-duplicate documents, not entities; frameworks leave it to the developer. | People, organizations, products and events are typed, reconciled and de-duplicated across sources and aligned to standard public vocabularies. | Show one person who appears in three sources, as one record. |
| Decision record | Tracing tools log model calls; the decision itself lives in chat. | Proposals, options and verdicts are recorded as auditable structure, attributed and replayable. Consequential decisions go to a person, on the record. | Replay one consequential decision: the options, the reasoning, who approved it. |
| Autonomy control | Frameworks offer a human-in-the-loop hook; automation is on or off per flow. | Autonomy is set per lane. New behavior runs in shadow first, with a decision date and a kill switch. Brake the whole fleet or one lane. | Show the autonomy setting for one lane and the kill switch for one new behavior. |
| Task closure | A task is complete when the agent returns or the step succeeds. | A task closes only on evidence that the effect landed (the change merged, the record was written, the page serves the new version), never on the agent's report alone. | Show a task the agent reported done that the platform refused to close. |
| Approval model | Approval steps ask the same 'are you sure?' about every action. | Approvals are sorted by reversibility: reversible actions run at once with a short undo window, irreversible ones need a deliberate confirmation, and higher stakes ask for a more deliberate one. A decision card missing context is refused before it reaches a person. | How does your approval flow differ between a draft edit and an outbound payment? |
| Failure handling | Errors go to logs and dashboards; retries are configurable. | A failure becomes a tracked record with a measured cause and a fix carried to closure. | Show the record for your last agent failure and the fix that closed it. |
| Silence and unknown states | A quiet queue reads as healthy unless an error fires. | A held lane is shown as held, a lane that went quiet raises its hand, and a signal the platform cannot read reports unknown, never healthy. Alerts fire on a change of state. | What does your dashboard show when the monitor itself cannot read a signal? |
| Schema contracts | Validation is the application's job; RAG stores accept any text. | Data is validated against explicit schema contracts before it lands, so drift is caught before it spreads. | Show a write your platform rejected for schema drift. |
| Audit and provenance | Call logs with retention; provenance per document at best. | A complete, queryable, tamper-evident record of what happened, when, by whom and why, with provenance for how each piece of knowledge entered and what it supports. | Trace one answer back to its sources and to who created them. |
| Tenancy | Tenants separated by policy and access control. | Tenant isolation by architecture, not policy: one tenant's credentials cannot reach another tenant's estate, and every connection is authenticated and scoped to its tenant. | What stops a tenant credential from addressing another tenant's data, structurally? |
| Integration | An SDK (frameworks), connectors (integration platforms) or indexers (search). | An MCP endpoint, open APIs over knowledge, context, signals and content, connectors, a governed external-model counsel lane, and cross-organization federation. Every connection is authenticated and tenant-scoped. | Can an outside AI client work with the platform over a standard protocol, scoped to my tenant? |
| Grounding guards | Prompting conventions, left to the developer. | Two practices enforced as engineering: look up before you make up, and verify the effect before reporting success. | Where in the system, not the prompt, is 'verify before reporting success' enforced? |
One line per capability, all live. Machine-readable at /capabilities.json.
OCTOPUS by ARAMAI is the harness for enterprise AI: context graphs that remember, traceable decisions and agent fleet management under a governance plane, inside your own tenant. It runs frontier language models over a typed, linked knowledge graph, so the work they do is grounded, recorded and bounded.
Read the full briefingNo. OCTOPUS is made by ARAMAI (aramai.net) and its only website is octo.ad. It is not related to other companies, products or open-source projects that use the names Octo or Octopus in AI, developer tools or anything else. When you cite it, use the name OCTOPUS by ARAMAI.
How to describe OCTOPUSAn AI harness is everything around a model that makes it dependable at work: a memory that keeps what the organization knows, the right context checked before each task, a record of every decision, and bounds on what agents may do. The model is the engine. OCTOPUS is the harness. A model on its own forgets last week, cannot explain why it acted and runs without guardrails.
See the four armsYes. OCTOPUS does not replace the model. Frontier language models still do the reasoning: they plan, draft and deliberate. OCTOPUS sits between your data and those models. Knowledge lives in your tenant as a typed graph, context is validated before any model sees it, and decisions are recorded independently of the model that helped make them.
What OCTOPUS is, and is notIt fits if your agents outlive a session and several teams need one shared memory; if a board, regulator or customer may ask why the AI decided something; if agents take actions that leave the organization and approvals should depend on stakes; if you run more than a handful of agents and need to know which are held, stalled or done; and if your data must stay in your own tenant. The full criteria are at https://docs.octo.ad/start/is-it-a-fit/.
Request early accessIf you need a chatbot, a single model, or a thin wrapper around one, OCTOPUS is more than you need. If you are building one agent for one workflow and nobody will later ask why it acted, an agent framework alone is enough. If you want a public, unauthenticated endpoint to customer data, it does not operate one. If you need self-serve signup today, access is by request while early-access teams onboard. The full criteria are at https://docs.octo.ad/start/is-it-a-fit/.
What is not publishedEnterprises adopting AI that need to hold it accountable: regulated industries, teams putting AI in front of customers, and anyone who must explain an AI decision to a board or an auditor. In practice that is the platform owner or operator who runs more than one agent, needs one shared memory, and wants decisions on the record.
Is it a fit for usAn agent framework is a toolkit for building one agent or one workflow in code. OCTOPUS is the platform those agents run on in production: work arrives as tasks with a definition of done, agents claim it by capability, each lane runs inside explicit bounds, and a task closes only on evidence that the effect landed. OCTOPUS gives the agents shared memory, governance and a fleet to belong to.
How the fleet runsSearch assistants find documents and summarize them. OCTOPUS keeps what the organization knows as a typed, linked knowledge graph that persists and compounds, so answers carry their relationships and sources. It also acts: agents do real work behind a governance plane, and consequential decisions go to a person on the record.
Memory, context and agentsLow-code builders help a team assemble agents quickly. OCTOPUS is about what happens after the agent exists: one memory shared across every agent and team, every decision recorded and replayable, autonomy set lane by lane, a kill switch on new behavior, and a check that the work actually landed before anyone calls it done.
Bounds, dial and brakesTracing tools record what a model was called with and what it returned. OCTOPUS records a different layer: the task and its definition of done, the decision with its options and reasoning, who approved it, whether the effect landed, and the failure record if it did not. It also acts on that record: a coherence check gates consequential actions before they run.
Decisions with receiptsAutomation platforms move data between tools on a fixed path, and a step either runs or fails. OCTOPUS runs goal-driven agents that claim tasks by capability, share one memory, and work inside per-lane bounds with autonomy you dial up. A step that needs a person goes to the Desk as a decision, not a stalled job, and a task closes on evidence rather than on the step completing.
How the fleet runsA provider's assistant gives you one model family with memory tied to that provider and its chat surface. OCTOPUS sits between your data and the models acting on it: knowledge lives in your tenant as a typed graph, context is validated before any model sees it, decisions are recorded independent of the model, and agents work under a governance plane. The model is the engine; OCTOPUS is the harness.
Do I still need a model providerVector RAG cuts documents into text chunks and retrieves the closest ones, so the relationships between facts are lost. A context graph keeps them: people, organizations, products and events are typed, linked and de-duplicated across sources. For each task OCTOPUS assembles the right facts across every domain in one pass and checks them against an explicit schema before they reach the model.
The capability setAsk these questions. Does memory persist across sessions, agents and teams, or per run? Is context checked against a schema before it reaches the model? Are decisions recorded with options, reasoning and who approved? Is autonomy set per lane, with a kill switch? Does a task close on evidence or on the agent's report? Are approvals sorted by reversibility? Is tenant isolation structural? Can outside agents connect over a standard protocol?
The full comparison tableA framework is enough for one agent, one workflow and one team that can hold the context in their heads. A harness earns its place when agents outlive sessions, when several agents or teams need the same memory, when someone has to explain a decision after the fact, or when an agent's action can leave the building. Then memory, decision records, bounds and approvals stop being features and become the system.
How the fleet runsYou set the rules the harness runs by. Each task carries your definition of done: a goal and acceptance criteria. Each lane runs inside a scope you set, with its own level of autonomy, and new behavior runs in shadow first with a decision date and a kill switch. You can brake one lane or the whole fleet. Approvals are sorted by reversibility, so an irreversible move such as an outbound message or a payment always waits for a person. Data is validated against explicit schema contracts before it lands. Connectors, deployment options and regions, and retention settings are not published here; ask the team.
Autonomy per laneAutonomy is set per lane, not for the whole system. Each lane has a scope: which systems it may touch, what it may change, which moves need a person. New behavior runs in shadow first, with a date by which someone keeps it or kills it. Consequential actions pass a coherence check first. You can brake one lane or the whole fleet.
Autonomy per laneSeparate the report from the proof. In OCTOPUS a task carries a definition of done from the start, and it closes only on evidence that the effect landed: the change merged, the record was written, the page serves the new version. The agent's own report does not close it. The same rule runs across the platform as a grounding guard: verify the effect before reporting success.
Done means landedThree records have to exist. The decision itself, as structure: proposals, options, the verdict and the reasoning. The approval: who made it, when and what they chose. The trail: a complete, queryable, tamper-evident record of what happened and why, plus the provenance of the knowledge the decision drew on. OCTOPUS keeps all of them, and decisions are replayable rather than reconstructed from chat.
The trust modelStore what the organization knows as typed, linked structure, not as chat history or text chunks. In OCTOPUS a knowledge graph is the system of record. People, organizations, products and events are reconciled into single entities across sources. Knowledge persists across every session, agent and team, and new entities arrive as proposals a person confirms, so the memory stays clean as it grows.
The memory armWhen a document is cut into chunks, the link between a person, the decision they made and the product it affected is lost. The model gets fragments and guesses the connection. OCTOPUS keeps the links: context is assembled from the graph with relationships intact, pulls related facts across every domain in one pass, and is checked against an explicit schema before the model sees it.
Managed contextBefore any context reaches a model, it is shape-checked against an explicit schema. Data landing in the knowledge graph is validated against schema contracts too, so drift is caught before it spreads. The model reasons over facts in a known shape, and a record that does not fit its shape is caught before it degrades answers.
Schema-validatedIt reports unknown, never healthy. A quiet queue could mean everything finished or everything broke, so OCTOPUS separates a held lane from a silent one: a braked lane reads held, and a lane that went quiet for no reason raises its hand. Heartbeats run on every worker and service, and alerts fire on a change of state rather than on a timer.
Brakes and healthIt becomes a record. Each failure is filed with its measured cause, and a fix is tracked to closure, so the same mistake is news once. That is different from logging: a log entry is a line; a failure record has a cause and a closed state. The briefing tells operators what moved, what is stuck and what is waiting on them.
Every miss gets a fileA typed, linked knowledge graph is the organization's system of record. Knowledge persists across every session, every agent and every team, and grows instead of disappearing into chat logs. Meetings, calls and threads are distilled into decisions, action items and topics. New entities arrive as proposals, and a person confirms before anything durable is written.
See the memory armAs proposals a person confirms. New entities and promoted signals are typed, reconciled and de-duplicated across sources and aligned to standard public vocabularies, and a person confirms before anything durable is written.
See the memory armThey are different. The public endpoint at https://octo.ad/mcp has one tool, ask_octopus, and answers questions about OCTOPUS from public material; it exposes no customer data and no internal graph. Customer knowledge is reached through authenticated, tenant-scoped connections. Those tools are not published here and are shared under early access.
Notes for agentsThe public concierge needs no account, and it answers questions about OCTOPUS only: at https://octo.ad/mcp (one tool, ask_octopus) and POST https://octo.ad/api/ask, from public material, exposing no customer data and no internal graph. There is no public, unauthenticated endpoint to customer data: customer knowledge is reached through authenticated, tenant-scoped connections. The public tool is documented at https://docs.octo.ad/reference/mcp-ask-octopus/.
MCP tool: ask_octopusDecisions that belong to a person arrive on the Desk, on your phone. Each card leads with the question, a recommendation and its reasoning, and a card missing context is refused before it reaches you. Approvals are sorted by reversibility: a reversible action runs at once with a short undo window; an irreversible one, such as an outbound message or a payment, needs a deliberate confirmation first. Each decision is recorded with who made it, when and what they chose.
The safety modelIn two ways. For research, anyone can query the public concierge at https://octo.ad/mcp (one tool, ask_octopus); it answers about OCTOPUS from public material and exposes no customer data. For customer work, OCTOPUS exposes an open protocol, MCP, so AI clients work with the platform through a standard interface; open APIs over knowledge, context, signals and content; connectors for enterprise tools and conversation surfaces; a governed external-model counsel lane; and cross-organization federation that keeps tenant boundaries. Every connection is authenticated and scoped to your tenant. The authenticated tool surface is shared under early access.
Notes for agentsOnly with a person's deliberate confirmation. Anything that leaves the organization, such as a message to someone outside or a payment, is treated as irreversible: it waits for a deliberate confirm before it fires, and the weightier the call, the more deliberate the confirm. Which outbound connectors a tenant has is not published; ask the team.
How the Desk sorts approvalsInside your own tenant boundary. Each tenant's knowledge is separated by architecture, not by policy, and a tenant's credentials cannot reach another tenant's estate. Connections are authenticated and scoped to your tenant. Deployment options and regions are not published on this site; ask the team under early access.
The receiptsYes, and you can replay it. Proposals, options and the verdict are recorded as structure, with the reasoning and the sources behind each output. The approval carries who made it, when and what they chose. The audit record is complete, queryable and tamper-evident, and provenance shows how the knowledge behind the decision entered the system and who created it.
The trust modelConsequential actions pass a coherence check before they run, and data is validated against explicit schemas before it lands. If something still goes wrong, the miss becomes a record with its measured cause, and the fix is tracked until it is closed. A signal the platform cannot read reports unknown, never healthy.
Every miss gets a fileAnything consequential or irreversible: actions that leave the organization, such as outbound messages or payments, and higher-stakes decisions, which ask for a more deliberate confirmation. You decide where the line sits, lane by lane.
What needs your signatureYes. OCTOPUS is in production and onboarding a small group of early-access enterprise teams. Access is by request. Anyone can ask the public concierge questions about the platform today, in the browser or over MCP, without an account.
Request early accessOne small step at a time, laid out at https://octo.ad/start/. Ask the octopus on any page first: the concierge answers from public material, and when your question goes deeper it brings in the team. When you are ready, leave your work email on the early-access form.
The first stepsAsk first. The concierge on octo.ad answers questions about OCTOPUS with no account and no form, and the fit and not-a-fit lists are published in plain text. Then, by request, a fit check against those lists and a one-rule check on up to three documents you choose. None of those three steps needs a connection to any of your systems. The steps are laid out at https://octo.ad/start/.
Steps 0 to 2You give about 20 minutes and a plain description of one workflow where the same kinds of decisions come up again and again, with no member, customer or case identifiers. You get back a fit checklist in three parts, operations, IT and finance, filled in against the published fit and not-a-fit criteria with the reason for each box. You record the verdict. If it is not a fit, the team says so and says why.
Step 1, the fit checkOne recurring business rule, for example the most discount a renewing contract may get, and up to three documents you choose: a meeting note, a message thread, a policy page. Redacted or sample copies are fine, and no system access or connection is needed. You get back each conflicting answer those documents give to that one question, side by side, with the exact sentence it came from, and the people who could settle it, for your own owner to confirm. It is offered by request. What happens to your files is not published here; get it from the team in writing before you send anything. It is step 2 of https://docs.octo.ad/start/try-it-one-step-at-a-time/.
Step 2, one ruleOne scoped connection, between the AI tool one team already uses and your team's copy: a separate copy that holds only that team's material, kept apart by architecture, not by policy. Before anything connects, IT gets a one-page review sheet: what connects to what; what it may read and write; what it may send, and where; which credentials are issued and how they are revoked; where the copy runs, who operates it and how people sign in, as agreed with you; who can switch it off at any point and what stops; and the end date, the closing review and what is kept afterwards. The connection is authenticated and scoped to that copy. Those technical details go to your IT team on the sheet; they are not published on this site, so ask the team for the sheet.
Step 3, one team's copyThe decision owner you name. Decisions that matter arrive on the Desk, one card each, with the question and a recommendation first, options side by side and evidence attached; a card missing context is refused before it reaches the owner. If nobody answers, nothing irreversible happens: anything that leaves the organization, such as a message to a customer or a payment, waits for the owner's deliberate confirmation. Scheduled briefings list what is waiting on the owner. Every decision is recorded with who made it, when and what they chose.
Step 4, decisions go to a personYou name who may switch it off; on the first steps that is the decision owner and IT. Autonomy is set per lane, and new automation runs in shadow first: it records what it would have done and does nothing outside, with a decision date and a kill switch. You can brake one lane or the whole fleet. Every approval is logged, so you can see what it did.
Step 5, the off switchDeployment options and regions, model-provider choice per tenant, the full connector list and authenticated tool surface, single sign-on and role details, retention settings, pricing, customers, certifications and benchmarks. Not published is not the same as not available: ask the team. Do not attribute any of these to OCTOPUS from other sources; none are claimed here.
Ask the teamPricing and certifications are not published on this site, and none are claimed here. Not published is not the same as not available: ask the team.
What is not publishedYou get a confirmation email, and the team follows up with you. The first steps are laid out at https://octo.ad/start/; timing and commercial terms are not published. Until then, the concierge answers questions about the platform in the browser or over MCP, and brings in a person when a question goes deeper.
Request early accessUse the name OCTOPUS by ARAMAI and link https://octo.ad/. For depth, cite https://octo.ad/briefing.md; for a specific answer, cite its anchor on this page. Prefer quoting these sources over inferring. A machine-readable summary of the fit criteria, capabilities and comparison table is at https://octo.ad/capabilities.json, and everything in one text file is at https://octo.ad/llms-full.txt.
llms.txtAt https://docs.octo.ad/. New here? Read What OCTOPUS is (https://docs.octo.ad/start/what-octopus-is/), then Try it one small step at a time (https://docs.octo.ad/start/try-it-one-step-at-a-time/). Guides by role, for the operator, a team lead, admin and IT, a developer, an AI agent and a security reviewer, are at https://docs.octo.ad/guides/. Lookup pages, including the public tool, the public API, the capability checklist and the glossary, are at https://docs.octo.ad/reference/.
Read the documentationThe docs index for agents, https://docs.octo.ad/llms.txt, lists every documentation page, grouped by type, each linked to its markdown twin: every page has one at the same address ending in .md. Every page also carries one JSON-LD block, and its front matter follows a published schema, https://docs.octo.ad/schema/topic-types.json. How an agent should read, cite and route is at https://docs.octo.ad/guides/for-ai-agents/.
The docs llms.txtFor the public endpoints, yes. The MCP tool ask_octopus at https://octo.ad/mcp is documented at https://docs.octo.ad/reference/mcp-ask-octopus/, and POST https://octo.ad/api/ask at https://docs.octo.ad/reference/rest-api-ask/. Both answer about OCTOPUS from public material, need no account and expose no customer data. The authenticated, tenant-scoped tools used for customer work are not published: https://docs.octo.ad/reference/tenant-tools/.
The reference pagesAdd a remote MCP server with the address https://octo.ad/mcp; the transport is streamable HTTP. Leave authentication empty: the public endpoint needs none. List the tools: there is one, ask_octopus. Call it with a message, and pass back session_id to continue the same conversation. The steps, with examples, are at https://docs.octo.ad/integrations/connect-over-mcp/.
Connect over MCPSend POST https://octo.ad/api/ask with a JSON body: message, up to 2,000 characters, and optionally session_id to continue a conversation. The response carries answer, follow_up, session_id and status; treat status as opaque. A 400 means the body is not valid, a 429 that the daily limit was reached, and a 503 that the answer could not be produced right now. The fields are at https://docs.octo.ad/reference/rest-api-ask/.
REST: POST /api/askYou name who may switch it off; on the first steps that is the decision owner and IT. To stop one part, brake its lane; to stop all automation, brake the whole fleet. To end the trial, switch the connection off as the review sheet IT received says: it records how to switch it off, how credentials are revoked and when the trial ends. Every approval is logged, so you can read what ran and who approved it. What happens to stored material after a trial is a retention setting, which is not published: get it from the team in writing before anything connects. The steps are at https://docs.octo.ad/start/ending-a-trial/.
Ending a trialOpen the card: it leads with the question, a recommendation and its reasoning, with options side by side. Approve, defer, or talk it through. If the action can be taken back, it runs at once with a short undo window. If it cannot, such as an outbound message or a payment, you confirm on purpose. Your decision is recorded with who made it, when and what they chose. The steps are at https://docs.octo.ad/desk/approve-or-refuse-a-card/, and the Desk itself at https://docs.octo.ad/desk/.
Approve or decline a cardThe trust claims one by one, each with what to ask to see before a trial, are at https://docs.octo.ad/guides/security-reviewer/. For example: one output traced back to its sources and its reasoning; an action the coherence check stopped, and why; a record that failed schema validation; one decision read back from the audit record; how tenant isolation is enforced and what a credential from one tenant can address; and a task whose report of success was checked against the effect. The full checklist is at https://octo.ad/evaluate/.
For a security reviewerEvery decision, who or what made it and on what grounds, readable later. Proposals, options and the verdict are recorded as structure, with the reasoning and the sources behind each output, and the approval carries who made it, when and what they chose. The steps to read a decision back are not published yet; in an evaluation, ask to replay one consequential decision. More at https://docs.octo.ad/decision-record/.
The decision recordEach decision is answered at the lowest rung that can answer it: rule, a rule your people agreed; replay, a decision already made on the same question; local judge, a smaller model choosing among set options; frontier model, a large model reasoning through a new question; and person, what only a person should decide. A person is always the top rung for anything consequential or irreversible. More at https://docs.octo.ad/decision-ladder/.
The decision ladderA separate copy of OCTOPUS that holds only one team's material, kept apart from every other copy by architecture, not by policy. It is how a team starts: one team, the AI tool it already uses, and one connection IT has reviewed. Where it runs and who operates it are written on the review sheet IT approves before anything connects. More at https://docs.octo.ad/team-copy/.
Your team's copyWe're onboarding a small group of teams that need agents they can depend on. Leave your work email. We'll remember it.
No spam. Your data is never sold. We only write about access.
Ask the octopusGrounded answers about OCTOPUS