---
title: "How OCTOPUS differs, by category"
description: "Fourteen dimensions, compared with what each category of tool typically offers. Comparisons are by category only."
url: "https://docs.octo.ad/compare/"
id: "compare"
type: "reference"
audience: "operator"
dateModified: "2026-11-06"
keywords: ["comparison", "category"]
---

# How OCTOPUS differs, by category

> Fourteen dimensions, compared with what each category of tool typically offers. Comparisons are by category only.

These comparisons are by category, never by product.

| Dimension | What the category typically offers | What OCTOPUS does |
|---|---|---|
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |

- [Versus an agent framework](/compare/agent-frameworks/): A category comparison: OCTOPUS versus an agent framework.
- [Versus an enterprise search assistant](/compare/enterprise-search/): A category comparison: OCTOPUS versus an enterprise search assistant.
- [Versus a low-code agent builder](/compare/low-code-builders/): A category comparison: OCTOPUS versus a low-code agent builder.
- [Versus an observability or tracing tool](/compare/observability-tools/): A category comparison: OCTOPUS versus an observability or tracing tool.
- [Versus workflow automation](/compare/workflow-automation/): A category comparison: OCTOPUS versus workflow automation.
- [Versus a model provider's assistant](/compare/model-provider-assistant/): A category comparison: OCTOPUS versus a model provider's assistant.
- [Questions to ask any harness vendor](/compare/questions-to-ask/): The questions to put to any vendor, one per dimension.
