Agents that don’t resubmit the form that was denied
Prior authorization is a workflow with a memory problem. The payer’s rules change, the denial reasons repeat, and every submission starts as if the last hundred never happened.
A denial is a document, not a lesson
The information needed to not repeat a denial is generated every single time one happens, and is stored in a form nothing can learn from.
The cause of the denial is never recorded as the cause
The letter is filed against the case. Which combination of code, payer and missing attachment actually triggered it is inferred by a human, acted on once, and written down nowhere the next submission reads.
The payer changed the form and nobody told the agent
A required field appeared in June. The agent keeps submitting the May shape until enough denials pile up for someone to notice the pattern — and the pattern was visible after the second one.
The workaround leaves with the coordinator
Somebody worked out that this payer accepts the prior-therapy note as an attachment rather than inline. That knowledge is in one person's head and in no system.
Mostly episodic. Then three others.
Every application built on CortexDB is a different mixture of the same five memory jobs. That mixture is what makes this a different piece of software from the one next to it, even though the infrastructure underneath is identical.
Action, reasoning and outcome stay attached to each other
A submission, what it contained, and what came back are one memory rather than three records in three systems. That is what makes the hundredth attempt smarter than the first.
- The why is retrievable with the what.
- Denials return as experience, not as correspondence.
- Repeat work is recognised as repeat work.
Which rule the payer was on
Requirements change on dates. A submission judged against the version in force is a different question from one judged against today's.
Intake, benefits and submission
Three agents on one case, reading the same history instead of passing summaries.
A similar case is not the same payer
Selection weighs payer, plan and code — not how closely two cases read alike.
That is four of the five. The fifth — persistent memory, where an individual's preferences and corrections survive — leads for assistant and commerce agents instead. Same engine, different mixture.
The case history is spread across everything
Portals, faxes, the EHR, the thread where the coordinator asked a colleague. The workflow already touches all of it.
01 Wire the sources
Vendor connectors ship as extras on the connector package.
pip install 'cortexdb-connectors[slack,jira]'02 Write the denial and what fixed it
One memory holding the attempt, the rejection and the resolution — which is exactly the shape the next identical case needs.
curl -X POST http://localhost:3141/v1/experience \
-H 'Content-Type: application/json' \
-d '{
"scope": "ws:clinops/auth",
"modality": "observation",
"content": {
"kind": "text",
"text": "Payer denied J9299 for missing failed-therapy documentation. Resubmitted with the prior-therapy note as an attachment rather than inline; approved in two days."
},
"context": { "observed_at": "2026-08-27T09:14:00Z" },
"idempotency_key": "auth:case-44127:denial-01"
}'03 Recall before submitting
The pack comes back as what has already been learned about this payer and this code, not as a list of similar-looking cases.
from cortexdb.v1 import V1Client
client = V1Client(api_url="http://localhost:3141", actor="agent:prior-auth")
pack = client.recall(
scope="ws:clinops/auth",
query=submission_draft,
view="holistic",
include=["episodes", "facts", "beliefs"],
budgets={"max_tokens": 950},
)
reply = llm.respond(submission_draft, context=pack["context_block"])pip install cortexdbai
or npm i cortexdbai — both ship the same client.
Full endpoint reference in the
docs.
This is PHI, and that settles where it runs
Diagnoses, treatment codes, payer correspondence and patient identifiers. There is no version of this application where the memory can sit in a multi-tenant service outside the covered entity's control.
CortexDB is a single container. It runs on your own hardware, inside your VPC, or air-gapped — with the embedding and generation calls pointed at a local model if nothing may leave at all.
docker run -d --name cortexdb -p 3141:3141 -v cortexdb-data:/data cortexdb/cortexdb:latestDeployment options, model routing and the enterprise notes are on the download page.
The same infrastructure, a different mixture
Each of these leads with a different memory job, pulls from a different set of sources, and needs a different call. All of them, by job.
Bring the workflow that gets it wrong.
Not the demo. The one that answered from the wrong version, or asked a question it had already been told the answer to.