Two engines, and a clear line between them
An agentic system over data operations needs five layers: observation, reasoning, supervision, action, audit. On JetStore, four of the five already map to code that runs — the deterministic layers are the platform. The reasoning layer is what the agentic work adds, and the line between it and everything else is the design.
-
Observation
DeterministicThe execution record is the platform's own: run status, per-node detail, metrics, results, process errors, the input and session registries. It is a near-complete record of what a pipeline did and a partial record of what went wrong with it — and what gets built on top is designed against that difference rather than around it.
-
Reasoning
CognitiveAn inference server on GPU, and a pipeline operator that calls it once per record. Around them sits the runtime this work was built for: the tool registry, the domain-model contracts, the tier enforcement point, the evaluation harness, and a propose–verify–repair loop. No agentic framework is a dependency of any of it.
-
Supervision
SharedUsers, roles and per-capability checks are in the API server today, and agent authority is designed to ride on that same capability model: an agent identity is a user with a capability set, so what it cannot do is a property of the access model rather than of its instructions. The agent-facing half — where an autonomous step is graded and approved — is what the agentic work adds.
-
Action
DeterministicCompute Pipes DAG execution, workspace compilation, orchestration. A step with one correct answer is computed here rather than inferred, at the volume the data actually arrives in. No model sits in this path.
-
Audit
SharedA dedicated audit logger whose call sites write before the access check and before the action, onto a log stream that cannot be edited after the fact. Making that record durable across a crash, outcome-carrying, and queryable by the product itself is named work with a plan behind it — not a finished feature, and we would rather say which.
Nothing in that list asks a model to do a compute platform's job. The expensive, error-prone part of working with claims data is not the prose — it is assembling a correct, deduplicated, coded, adherence-computed longitudinal view out of raw feeds. Rules do that, deterministically. What is left for the model is rendering an input that is already correct, or reasoning where no deterministic answer exists.
The model is an operator in the pipeline
Inference is not a service the pipeline calls out to and hopes for. It is a step in the DAG, with the same configuration surface, error handling and cost controls as every other step — and it is built and tested rather than planned.
-
Per-record inference, with the plumbing already around it
Prompt templates with column and whole-record placeholders, compiled at build time. JSON-schema structured output. Dot-path mapping from the response back into the record, with typed casting. A worker pool, retry with backoff, a dedicated error channel — and a hard cap on input count, so a run cannot quietly cost more than it was authorized to.
-
One compiled domain model, not a copy per prompt
Entity classes are declared once with typed properties and base classes, and compiled into the workspace database and the platform's registries. The same definition emits the artifacts an agent works against, including the JSON schemas that constrain what it may return — so a schema and a table cannot drift apart by hand.
-
Schema-constrained on the way out, validated on the way in
One JSON Schema both constrains the model's output and validates the response that comes back. A model that ignores a format instruction is a known failure mode, and client-side validation against the same schema is what catches it instead of a downstream table.
-
A deterministic renderer, where a template is the better answer
Sometimes the finding is that inference is not the right renderer at all. A configuration-driven render step applies a template to a record inside the running pipeline, and every failure that engine admits is a build failure rather than a run one. That is a finding the platform can act on rather than argue with, and it is the finding behind AgentBrief.
The compiler is the reviewer
Almost nobody building an agentic product has a free, deterministic, high-signal verifier for the artifacts their agent is supposed to author. A rule compiler and a pipeline-configuration validator are exactly that. Designing the whole model strategy around them is the difference between a demonstration and something you can put in front of an engineer.
-
An output contract
Every artifact an agent authors — a pipeline configuration, a domain model, a rule file — goes through a compiler that decides whether it is well formed. Quality is measurable from the first day, with no golden-case library, no historical incident data and no evaluation function to invent first.
-
An inference-time repair signal
Generate, compile, feed the compiler's own error text back as a structured repair prompt, retry within a bounded iteration count. The messages work as repair prompts because they were written for people: name a column a template does not have, and the build error lists the columns it does.
-
Verification runs in parallel, so generation can too
Both rule engines validate concurrently with session isolation, so a batch of candidates can be checked at once. Sampling several and keeping the ones that compile is usually a better use of a fixed token budget than several repair turns on a single candidate, because the failures are independent draws rather than one fixable mistake.
-
Authoring is machine-verified before a human sees it
Rules and pipeline configurations are written with a copilot whose output passes the compiler first, so a reviewer spends their attention on whether the logic is right rather than on whether it parses. Human review is structural here — a property of the workflow, not a control designed on top of it.
-
One tool catalog, two consumers
The tool boundary is MCP — a wire protocol under the Linux Foundation's Agentic AI Foundation with a v1 compatibility guarantee on its Go SDK, adopted as a protocol rather than as a framework in the runtime. One registry of named tools, typed against domain entities, serves a frontier model while the work is being designed and the in-house model when it runs.
Graded against the code on 2026-09-11, two of the verifier's three roles are built: the output contract and the repair signal. The third — the same compiler used as a training signal for the in-house model — is a dependency away rather than a decision away, and we would rather name it than count it.
Inference you host, and a seam where you need something else
ArtiSoft recommends JetStore Agentic AI: the reasoning layer runs on inference you host, so no external LLM provider is required and PHI never leaves your VPC.
Where a client's requirements call for a different or external model, the inference layer sits behind a backend interface, so the model is a per-agent configuration choice rather than a rebuild.
-
Vendor neutrality is the product, not a setting
No external LLM provider. PHI never leaves your VPC. That is most of the answer to a security review, and it is the reason the reasoning layer was built to run on inference you host — a framework from a large vendor sitting in the runtime is an answer you have to give in every review, for a capability you could have written yourself.
-
A frontier model teaches; your inference serves
The frontier model's place here is upstream — designing the rules, the prompts, the templates and the golden cases, where its output is reviewed before it runs rather than after. Because the catalog is exposed over MCP it can do that work against the real tools, and the artifacts transfer to the local model without a rewrite.
-
The backend is a seam, and the seam is shipped
The shared inference plumbing — worker pool, retry, error channel, response mapping — was extracted behind a common backend interface, so a serving stack is a configuration choice at one boundary rather than a change threaded through the pipeline. Because agents run as pipeline steps, two branches can run over the same data and be compared as a measurement instead of argued about.
-
Scoped, and explicit about the scope
A self-hosted small model will not match frontier reasoning on open-ended root-cause analysis, and this platform does not claim that it does. The design scopes the local model to the tasks where a verifier exists, and is explicit about which tasks stay with a person. That is a narrower promise than parity and a much more defensible one.
What ships is the interface. Which model, which serving stack, and which steps stay human are scoping decisions for your deployment — we would rather work those out against your data and your review process than put a checkmark beside them here.
It runs in your environment, inside the scope you already maintain
JetStore deploys into your own cloud account. Data under your control stays there, and no protected health information reaches ArtiSoft — which is what makes the compliance conversation short.
-
Your compliance scope, not a second one
Because JetStore runs inside your environment, it operates within the controls and the audit scope you already maintain. We support customers who maintain HITRUST CSF certification, and JetStore runs inside that scope like the rest of their stack.
-
ArtiSoft holds no HITRUST certification, and does not need one
Certification covers an environment that handles the data. ArtiSoft does not handle yours: no PHI is transmitted to us, so there is no ArtiSoft-side scope for a certification to cover. Any vendor telling you otherwise is describing a different architecture.
-
No external model provider in the path
The reasoning layer runs on inference you host. Nothing in a run is sent to a third-party model API, so there is no processor to add to a data-flow diagram and no egress to justify.
-
Access is enforced by capability, per action
Users, roles and per-capability checks are in the API server today, and agent authority is designed to ride on that same capability model rather than on a parallel one.
This describes where the software runs and what it does not receive. It is not legal advice, and your own compliance team owns the conclusion for your deployment.