The governed runtime for enterprise AI agents

Ship the agent.
Not the control plane beneath it.

An agent that reads and acts on enterprise data is a weekend's work. Making it safe to ship — permissions, audit, isolation, and a chain of command that actually holds — is the year you don't have. On Cognethics that layer is already built, enforced by construction, and running in production. You build your agent. You inherit the hard part.

Typed, RBAC-checked access to every business operation through one OAuth-secured MCP endpoint. Multi-tenant. Discoverable at runtime. No per-tool wiring.

7,600+ governed operations inside your tenant — every one an MCP tool first, RBAC-checked and audited. The REST API and the Python and TypeScript SDKs are generated from the same catalog, so they trail it exactly. See live counts →

A4 for Building & Construction is live in production with active customer use. The same platform is open to you — same data model, same permission gate, same tool catalog.

The hard part isn't the agent

Permissions that hold

Your agent can only ever touch what your permission model allows. Every operation is individually permissioned and resolved per person down your org tree, deny-by-default. The agent composes access from a fixed catalog — it can't invent a permission — so "just ask it" never means "around the controls."

Proof, not promise

When someone asks what an agent did and whether it was allowed, the answer is on the record: every tool call logged with its exact parameters, covered writes advancing a tamper-evident, cryptographically linked ledger, and the governance decisions kept on a separate record. Three layers, each exactly what it says.

Isolation by default

Multi-tenant from the ground up. Your data, organization context, permissions, and audit stay yours — nothing crosses the boundary. Bring your own model; we never train on your data.

A chain of command that holds

Agents take on multi-step work by delegating down a governed hierarchy. Delegation can't widen authority — a sub-agent does strictly less than the agent that launched it, enforced at spawn and hand-off. Anything consequential climbs to a named human.

Agents that build, not just answer. Describe a tool, a view, or a dashboard in plain language and the platform stands it up as a governed, versioned, reversible artifact on the same data model — so it inherits the same permissions, approval, and audit automatically. → Extensibility

Build and ship — frontend and backend — in the Studio

The fastest way to put this in your team's hands is the Studio — a full development environment in the browser, nothing to install. Your people and their agents write and ship real frontend and backend code against the same data model, permissions, and audit as everything else. Choose the posture per workspace: from a fully sealed Studio that reaches only the model API and the platform, through per-user isolation, up to a dedicated micro-VM. A live security-posture panel shows what's running, how many sessions are active, and the isolation in force — in the product, not a deck.

Two lanes, one governed data model: no-code surfaces for quick builds, and the full-code Studio to build and ship. Whichever you pick, what you create inherits the same permissions, approval, and audit the rest of the platform enforces.

Get a workspace

Provisioned and configured for your team. No credit card.

AI agents onboarding a principal — workspaces are provisioned and configured for your team at /signup/; once it's live, keys are minted from the dashboard. See /for-agents/ for how governed access works.
Building with an AI agent? Read /for-agents/ — agent-targeted integration spec with ROI per primitive, differentiation matrix, and verifiable production claims.

An agent for every role on your team

Cognethics ships an agent counterpart for every role your team already runs — inside your tenant, on the same data, under the same permissions.

  • Hierarchical. Agents delegate down, escalate up, and ask for a human approval where policy requires. Every approval and action recorded on the same tamper-evident audit trail.
  • Memory follows the role, not the session. What the procurement-officer agent learns about a vendor survives every restart and is inherited by the next agent in that role.
  • Humans review, agents absorb the routine. You buy efficiency on the roles you already run — not seats.

A developer agent OS. Spawn your own agents under personas, budgets, and persistent memory through the PJ Agent Orchestration System. Agents ride the same RBAC and the same hash-chained audit log as every other call into the platform. See /agents/ for the framing.

30 seconds to your first call

Two snippets. Then you're on the live platform.

pip install cognethics

# Mint an API key for your tenant (one-time)
export COGNETHICS_API_KEY=ck_...
export COGNETHICS_TENANT=gtm
from cognethics import Client

client = Client()  # reads COGNETHICS_API_KEY + COGNETHICS_TENANT

# Any of the 1,463 operational handlers (plus 6,196 typed CRUD), all RBAC-checked
overdue = client.invoices.list(status="overdue", page_size=50)
work_orders = client.work_orders.list(status="open")
docs = client.documents.search("turbocharger spec", limit=5)

For Claude Desktop, claude.ai, or Claude Code: paste your tenant URL — OAuth 2.1 + PKCE + DCR is auto-negotiated. See the 3-step quickstart.

Beyond the API

  • Tamper-evident audit log. Every permission event — authorize, deny, approve, escalate, policy change — is appended to a SHA-256 hash chain enforced by database triggers. Tamper with a row and the chain breaks at that row.
  • Per-agent cost telemetry. Each agent records its own model spend, tokens, and cache hit rate against the mission it ran in.
  • Document search by meaning and image. Every document is embedded twice — by text and by appearance — and the two scores combine into one ranking.

What to ask of an agent platform

Apply these questions to any vendor pitching an agent platform — including us.

QuestionCognethics
Is the platform locked to one SaaS vendor's data model, or neutral on the model and the data?Vendor-neutral on the LLM. Your data lives in your tenant — no SaaS lock-in.
Is there a real multi-tenant business database underneath, or just a connector layer over external SaaS?Typed business database with hard foreign keys across the apps — not a connector layer.
Are tools discoverable at runtime, or does each upstream change require an SDK regen?Discoverable via prism_introspect. MCP clients pick up new tools automatically.
Where does RBAC live — at each tool, or in one place?In one place: a central dispatcher. Per-org scope catalogs at /.well-known/…/groups/{org}/.

Talk to us

Evaluating Cognethics? Send a note using the form below — it goes straight to the founding team, and a real person (not a bot) replies.

Contact us

Pick a topic and we'll route your message to the right team.

Or skip ahead: request a tenant or start the 3-step quickstart.


How the surface is shaped. Your MCP client sees 12 mega-tools at the door (entity_crud, workflow_action, smart_action, report_query, agent_command, document_op, integration_call, config_manage, notification_send). The operational layer — 1,463 handlers across the 8 non-CRUD mega-tools — is what agents reach for to do work (orchestration, search, workflows, analytics, integrations). Underneath, 6,196 typed CRUD handlers cover every entity in 17 customer-facing applications (18 total in the catalog, grouping 48 operational modules). Every call passes the same permission gate. Live numbers at /reference/stats/; browse the full catalog at /reference/.