The governed AI layer

An AI action either passes the gate or does not happen.

A registry of every agent, a run record carrying its citations and its dollar cost, and one write-back gate that can refuse — with an AI-influenced adverse decision unable to land without a named human reviewer holding the authority the decision required.

Book a demoSee the platformInteractive demo
app.aegisnow.ai/console

Cortex Control Plane

Live

Agents

12

Mutate

9 / 241

Actions

219

Costed

100%

Governed AI calls, last 12 hours

Trend

Cortex AI is the governed AI layer the other modules call. Agents are registered with framework, version and a champion or challenger role; every run stores the model used, the inputs it read, its citations, its output, and its token and dollar cost. Model-informed writes pass through a single evaluation that can refuse them, shared across claims, underwriting and actuarial rather than reimplemented per feature. An AI-influenced adverse decision cannot be written without a recorded human review by someone holding the same capability the decision required. On the actuarial side the layer runs twelve named agents across 241 defined steps, of which nine can change anything, classified against one registry of 219 capabilities and enforced when the module loads. Stated plainly: the AI run ledger is not hash-chained, there is no RAG, and there is no prompt-injection screening.

nine stepsof 241 can change anything — the rest read and propose

Illustrative outcome. We will map Cortex AI to your own data, frameworks and targets in a working demo.

Why teams choose it

The case for Cortex AI

AI that drafts and assists across insurance — but never decides ungoverned.

Permitted, not merely logged

A model-informed write passes one shared gate or does not happen. Logging an action after it occurred is not governance; refusing it is.

AI influence is detected, not declared

Omitting the run identifier does not make a decision AI-free — governed runs citing the same claim are found anyway.

No weaker ladder for AI

An AI-influenced denial is held to the authority standard of the denial. The reviewer must hold the capability the decision itself required.

Cost attributable to the work

Tokens, latency and dollars are recorded per run, so AI spend traces to the job that caused it rather than arriving as one invoice line.

Unclassified reads as unclassified

Governance attributes default to unclassified rather than to a benign value, because an unassessed system should not read as low-risk.

Nine of 241 steps can change anything

Twelve actuarial agents, 241 defined steps, and the classification is enforced when the module loads — a misspelled action cannot reach a running system.

Four outcomes that never collapse into two

Computed, found no data, no executor bound, held for approval. "We looked and there is none" and "we did not look" are different facts and are reported as such.

Limits on the page, not in the demo

No hash-chained AI ledger, no RAG, no injection screening — named here rather than discovered during an evaluation.

Inside the module

Capabilities that ship on day one

Every capability runs on the shared data fabric, the governed Cortex brain and the evidence ledger — so Cortex AI compounds with the rest of the platform.

Agent registry with champion and challenger

Every agent registered with framework, version, line of business and role, so what is in force is a fact.

Learn more

Governed runs with citations and cost

Every run records its inputs, citations, output, confidence, latency, tokens and dollar cost.

Learn more

The write-back gate

A model-informed write either passes the gate or does not happen.

Learn more

Human review, and adverse decisions that require it

Reviews are recorded against runs — and an AI-influenced adverse decision cannot land without one.

Learn more
app.aegisnow.ai/console

Cortex Control Plane

Live

Agents

12

Mutate

9 / 241

Actions

219

Costed

100%

Governed AI calls, last 12 hours

Trend

Twelve actuarial agents with a published step plan

241 defined steps across twelve agents, of which nine can change anything — and the classification is enforced at import rather than reviewed by hand.

Learn more

Model routing with fallback

Tasks route to a primary model with a declared fallback, so a provider outage degrades rather than stops.

Learn more

Rate limiting on AI endpoints

AI routes carry their own rate limit, enforced as middleware rather than per handler.

Learn more

Where this module ends today

Stated rather than implied: RAG, prompt-injection defence and the hash-chained AI ledger are not built.

Learn more
Capability detail

What each capability actually does

Each section below is directly linkable, so a specific answer can be cited on its own rather than buried in a page.

Capability 01

Agent registry with champion and challenger

Every agent registered with framework, version, line of business and role, so what is in force is a fact.

Agents are registered rather than deployed and forgotten. Each carries its framework, version, domain, status and a champion or challenger role, so the question "which model is actually in force for this decision" is answered by a record instead of by asking whoever deployed it.

Promotion between roles is an audited action and the history stays visible rather than being replaced, which is what lets you reconstruct which agent was live when a particular decision was taken.

The registry also carries the governance attributes a regulator asks about — decision role, consumer-impact tier, provenance, vendor, accountable owner, testing interval. Those default to unclassified rather than to a benign value, because a system that has not been classified should read as unclassified, not as low-risk.

What it does

  • Register each agent with framework, version, domain, status and champion or challenger role.
  • Make role promotion an audited action with visible history.
  • Carry decision role, consumer-impact tier, provenance, vendor and accountable owner on the agent.
  • Default governance attributes to unclassified rather than to a benign value.

Implements

  • Champion / challenger roles
  • AI system inventory attributes

See it in the product

Open the registry and filter for systems with no current classification: they appear as unclassified rather than being absent from the list.

Capability 02

Governed runs with citations and cost

Every run records its inputs, citations, output, confidence, latency, tokens and dollar cost.

A run is a record, not a log line. It stores the provider and model actually used, the prompt version, the input references it read, an input summary, the output, a confidence, the status, and the write-back disposition — so an action taken on the strength of a model output can be traced back to the exact run that produced it.

Citations are part of the record rather than an optional extra. An agent run that cannot say what it read is not evidence of anything, which is why the citation table exists alongside the run and why the adverse-decision control can detect AI influence by finding runs that cite a claim.

Cost accounting is per run and real: input tokens, output tokens, latency and dollar cost are stored on every one. That is what makes AI spend attributable to the work that caused it rather than arriving as one line on a vendor invoice at the end of the month.

What it does

  • Record provider, model, prompt version, input references and input summary on every run.
  • Store citations alongside the run rather than inside the output text.
  • Capture output, confidence, status and write-back disposition per run.
  • Account input tokens, output tokens, latency and dollar cost on each run.
  • Make runs findable by what they cited, which is how AI influence on a decision is detected.

Implements

  • Run-level citation of inputs
  • Per-run token and cost accounting

See it in the product

Open any governed run: it names the model version, the inputs it read, what it returned, and what it cost in tokens and dollars.

Capability 03

The write-back gate

A model-informed write either passes the gate or does not happen.

Where an agent output leads to a real write, the write passes through one evaluation that can refuse it. This is the control the whole layer exists for: an automated action is not something that happens and is logged, it is something that is permitted or is not.

The gate is shared across domains rather than reimplemented per feature, which is what stops a second, weaker path appearing next to it. The claims side, the underwriting side and the actuarial side all call the same evaluation.

Refusal is specific. The caller is told which condition failed rather than receiving a generic denial, because a gate that cannot explain itself gets worked around.

What it does

  • Route every model-informed write through a single evaluation that can refuse it.
  • Share one gate across claims, underwriting and actuarial rather than one per feature.
  • Name the failing condition on refusal rather than returning a generic denial.
  • Record the write-back disposition on the run itself.

Implements

  • Single governed write-back path
  • Explicit refusal reasons

See it in the product

Attempt a governed write that violates its policy: it is refused with the condition that failed, and the run records the refusal rather than the write.

Capability 04

Human review, and adverse decisions that require it

Reviews are recorded against runs — and an AI-influenced adverse decision cannot land without one.

Human review is a record against the run rather than a step someone remembers. The reviewer, their verdict and their rationale are stored, which is what makes "a human checked this" a verifiable claim instead of an assurance.

For adverse decisions the review is mandatory and the standard is specific: the reviewer must hold the same capability the decision itself required, and a determinative model output escalates the review to supervisor. There is no separate, weaker approval ladder for AI — an AI-influenced denial is held to the authority standard of the denial, not to a lower one because software was involved.

AI influence is detected rather than declared. Omitting the run identifier does not make a decision AI-free, because governed runs citing the same claim are found anyway.

What it does

  • Record reviewer, verdict and rationale against the run.
  • Require a recorded human review before an AI-influenced adverse decision can be written.
  • Require the reviewer to hold the capability the decision itself required.
  • Escalate to supervisor when the model output was determinative.
  • Detect AI influence from citing runs rather than trusting the caller to declare it.

Implements

  • NAIC Model Bulletin on the use of AI by insurers (alignment, not certification)
  • Capability-matched reviewer

See it in the product

Attempt an AI-influenced denial with no review: 403 adverse_decision_review_missing. Have it approved by someone without claims authority: 403 adverse_decision_reviewer_unauthorised.

Capability 05

Twelve actuarial agents with a published step plan

241 defined steps across twelve agents, of which nine can change anything — and the classification is enforced at import rather than reviewed by hand.

The actuarial estate is twelve named agents — chief of staff, data certification, reserving, pricing, rate deployment, life valuation, IFRS 17 / LDTI, capital and solvency, reinsurance, model risk, regulatory radar and interrogate. Each is a definition rather than a prompt: a purpose, the triggers that start it, the inputs it cannot start without, its approval gates stated verbatim, its acceptance criteria, and an ordered list of steps. A run starts from that definition, so what an agent will attempt is readable before it attempts anything.

Across all twelve there are 241 defined steps, and every step's action resolves to a classification in one registry of 219 capabilities — 165 read, 36 propose, 18 mutate. Nine of the 241 steps mutate. That is the number worth knowing about an agent estate: not what it can do, but how small the column is that changes anything, and whether it is enforced or aspirational. It is enforced at import — a definition whose step names an unregistered action throws when the module loads, so a misspelled action cannot reach a running system rather than silently defaulting to mutate and holding forever.

A step ends in one of four distinct states, and the platform never collapses them: computed, no data, unbound, or held for approval. "The executor ran and this tenant holds nothing to report" and "no executor is bound to this action" are different findings from each other and from zero, and each becomes a stated limitation on the evidence pack rather than a silent gap. The certification gate added a fifth — refused — recorded as its own outcome rather than as an error, because a step stopped because its data was uncertified did not fail; the platform worked. Filing that under "error" is how a control gets tuned out as noise by the third week.

What it does

  • Define twelve actuarial agents with purpose, triggers, required inputs, approval gates and acceptance criteria.
  • Start a run from the definition rather than from an ad-hoc request.
  • Classify all 241 steps against one registry of 219 capabilities.
  • Hold all nine mutating steps for a named approver.
  • Throw at import when a step names an action nobody registered.
  • Keep computed, no-data, unbound and held as four distinct step outcomes.
  • Record a gate refusal as its own outcome rather than as an error.
  • Turn no-data, unbound and held steps into stated limitations on the evidence pack.

Implements

  • Declarative agent definitions with published step plans
  • Import-time classification enforcement
  • Read / propose / mutate capability registry

See it in the product

Open the agent catalogue: each agent lists its step count and its read, propose and mutate split, and the mutating steps are named. The interactive demo renders that table from the same definitions the runtime executes.

Capability 06

Model routing with fallback

Tasks route to a primary model with a declared fallback, so a provider outage degrades rather than stops.

Routing is declarative: each task type names a primary model and a fallback, so the choice of model for a job is configuration rather than something buried in a call site. Changing which model handles reserve estimation is a routing change, not a code change.

The fallback is what makes a single provider a dependency rather than a single point of failure — a task whose primary is unavailable runs on its declared alternative.

Local and hosted providers sit behind the same interface, so a carrier that needs a model to run inside its own boundary can have that without the calling code knowing.

What it does

  • Declare a primary model and a fallback per task type.
  • Keep model choice as configuration rather than embedded in call sites.
  • Present local and hosted providers behind one interface.

Implements

  • Declarative task-to-model routing
  • Declared fallback per task

See it in the product

Read the routing table: each task names its primary and its fallback, and changing the assignment does not touch the code that calls it.

Capability 07

Rate limiting on AI endpoints

AI routes carry their own rate limit, enforced as middleware rather than per handler.

AI endpoints are rate limited by middleware applied at the route prefix, so the limit holds for every handler under it including ones added later. A control applied per handler is a control that eventually gets forgotten on the next one.

Combined with per-run cost accounting, this gives two independent brakes: how often AI can be called, and what each call actually costs.

Stated honestly: this is rate limiting, not a full policy-as-code layer. There are no model allowlists, no configurable spend caps that halt work when breached, and no content filters — those are described below rather than implied here.

What it does

  • Apply rate limiting as middleware at the AI route prefix, covering handlers added later.
  • Track cost per run independently of the rate limit.

Implements

  • Route-prefix rate limiting

See it in the product

Call an AI endpoint past its limit: the middleware refuses it, and the refusal applies to every route under the prefix rather than the one that happened to implement it.

Capability 08

Where this module ends today

Stated rather than implied: RAG, prompt-injection defence and the hash-chained AI ledger are not built.

The page claimed a tamper-evident hash-chained ledger of every AI action, grounded RAG chat returning cited answers, prompt-injection defence, model allowlists, cost caps, content filters, and provider health monitoring. Four of those are not implemented and one is implemented somewhere else.

The AI ledger is NOT hash-chained. `ai_agent_runs` has no previous-hash or chain-hash column; runs are stored, not chained. Hash chaining does exist in this platform — the actuarial audit log computes `sha256(prevHash + canonical)` from a GENESIS root — but it protects actuarial API mutations, not AI actions. Describing the AI ledger as tamper-evident borrowed a property from a different table.

There is no RAG. Retrieval is SQL ILIKE over claims, notes and stored document text; the endpoint's own note says "no embeddings, no LLM", and the graph search carries a FIXME recording that relevance scoring should come from embeddings and does not. There is no prompt-injection screening — the only mention in the codebase is a comment noting jailbreak as a risk. And of the policy-as-code list, rate limiting is real; model allowlists, enforced cost caps and content filters are not, nor is provider health monitoring, though declared fallback is.

What it does

  • Name the absent controls rather than leaving them among the implemented ones.
  • Distinguish the actuarial hash-chained audit log, which exists, from the AI run ledger, which is not chained.

Implements

  • Capability disclosure

See it in the product

Inspect the ai_agent_runs columns: there is no previous-hash field. Then inspect the actuarial audit log, where the chain is real — the contrast is the honest version of the claim.

Built for the people who own the risk

Made for your team, aligned to your frameworks.

Cortex skill-agents draft the work, cite their sources and write every action to the evidence ledger — so Cortex AI accelerates the people accountable for it without putting your audit posture at risk.

Who it serves

  • Chief Operating Officers
  • Innovation & AI leaders
  • Compliance & conduct teams
  • Underwriting & claims leaders
  • IT & data executives

Aligned to

  • NAIC AI model bulletin
  • Colorado SB 21-169
  • EU AI Act
  • NIST AI RMF
  • ISO 42001
CortexAI reasoning copilot
Grounded

Shared device fingerprint with the ring94
Repair shop tied to a prior SIU case87
Loss pattern matches the closed cluster81
SourcesPolicy ledgerClaims graphSIU casebook
Confidence94%
Works better together

Pairs with the rest of the platform

Cortex AI shares one core with every other module — combine it to extend coverage without adding integration debt.

Underwriting Workbench

Rate, decide and refer on one governed underwriting desktop.

Smart Claims

Every decision on the file has an author, a rule and a record.

Customer 360

One view of every policyholder, household and interaction.

Actuarial Platform

Every assumption versioned, every run reproducible, every sign-off logged — and uncertified data refused.

For your industrySee how Cortex AI works in regulated sectors.
Life, annuity & retirement carriers

Life & Annuities

From accelerated underwriting to automated death claims.

Explore Life & AnnuitiesPersonal & commercial lines carriers

P&C Insurance

Quote-to-claim on one core, with the combined ratio in view.

Explore P&C InsuranceMGAs, MGUs & coverholders

MGAs & Program Administrators

Bind inside authority, report on time, win more capacity.

Explore MGAs & Program Administrators
FAQ

Cortex AI FAQ

What evaluation teams want to know before a demo — answered plainly.

That a model-informed write passes through a single evaluation which can refuse it, and that the refusal names the condition that failed. The gate is shared across claims, underwriting and actuarial rather than reimplemented per feature, which is what stops a second and weaker path appearing beside it. Logging an action after it has happened is not governance.

By detection rather than declaration. A caller who omits the agent run identifier does not thereby make the decision AI-free, because governed runs citing the same claim are found anyway. That is the difference between a control and an honour system, and it is why citations are stored as records rather than left inside output text.

No, and the page previously said it was. `ai_agent_runs` has no previous-hash or chain-hash column — runs are stored, not chained. Hash chaining does exist in this platform: the actuarial audit log computes sha256(prevHash + canonical) from a GENESIS root. But it protects actuarial API mutations, not AI actions, and the old claim borrowed a property from a different table.

No. Retrieval is SQL ILIKE over claims, notes and stored document text — the endpoint's own note reads "no embeddings, no LLM" — and the graph search carries a FIXME recording that relevance scoring should come from embeddings and currently does not. Answers can cite the rows they read, but this is keyword retrieval, not vector search.

Not implemented. The only occurrence of the concept in the codebase is a comment noting jailbreak as a risk to be aware of. There is no input screening and no content filtering. A carrier exposing AI features to untrusted input should treat that as work to do rather than a control it has.

Rate limiting, and it is applied as middleware at the AI route prefix so it covers handlers added later rather than being remembered per handler. Per-run cost accounting is also real — tokens, latency and dollars on every run. Model allowlists, enforced spend caps that halt work when breached, content filters and provider health monitoring are not implemented; declared per-task fallback is.

Nine steps out of 241. Twelve named agents each carry a published step plan, and every step's action resolves against one registry of 219 capabilities — 165 read, 36 propose, 18 mutate. The nine mutating steps hold for a named approver. That classification is enforced at import: a definition whose step names an unregistered action throws when the module loads, so a typo cannot reach a running system and silently default to mutate.

It is recorded as no-data, which is not the same as zero and not the same as unbound. Four outcomes are kept distinct — computed, found no data, no executor bound, held for approval — and each of the last three becomes a stated limitation on the evidence pack rather than a silent gap. A dashboard that renders "we looked and there is none" as 0 is asserting a measurement nobody took. The certification gate added a fifth outcome, refused, recorded as its own state rather than as an error, because a step stopped by a working control did not fail.

See Cortex AI on your data

Book a working session and we will map your sources, workflows and frameworks onto Cortex AI — and show Cortex reasoning over them live.

Book a demoExplore the platformInteractive demo
Cortex AI — AI that drafts and assists across insurance — but never decides ungoverned. | AegisNow Insurance