How we build
We do not treat the LLM as the product. We treat it as one layer inside a constrained application system: domain knowledge, client knowledge, company policy, role-based authority, tools, supervision, evals, and healthcare data controls.
System architecture
Chips and foundation models create general reasoning capacity. Everything above that is the credentialing application system: the knowledge it is allowed to use, the agents it can run, the tools it can call, and the policies that decide when a human must review.
Tool surface
actions are always mediated by role, policy, and review state
ATS
Background checks
References
PSV
OIG / SAM
E-sign
Form I-9
W-4
Drug screening
APIs / webhooks
Role and policy layer
Determines access to context, tools, approval rights, and review thresholds
The same agent interface can expose different authority depending on tenant, user, role, operation, consent, and risk.
Assistant Agent
Workspace-aware. Answers questions, explains state, coordinates work, and uses tools only within the current user's authority.
Operations / Placement Agent
Placement-bounded. Works on one candidate, one placement, and one operation scope so data access and actions stay narrow.
Company layer
Your company knowledge
SOPs, how-tos, policies, team playbooks, preferred workflows, review rules, and source-of-truth systems.
Client layer
Client and facility-specific knowledge
Facility packets, client SOPs, document templates, escalation rules, local interpretation of policy, and requirement exceptions.
Domain layer
Foundational credentialing knowledge
Credentialing, onboarding, compliance, Joint Commission, NCQA, OIG/SAM, licensing boards, health requirements, and facility policy.
Retrieval layer
Knowledge organization and source-tracked retrieval
Uploaded and curated knowledge is chunked, clustered, summarized, versioned, and retrieved with RAPTOR-style hierarchical context and relevance filters.
Application layer
Credentialing Agents application system
Orchestration, state, memory, policy gates, tool mediation, audit trails, confidence scoring, supervisor agents, human review, and eval gates.
Model layer
LLM and model-routing layer
Language, extraction, classification, planning, summarization, and reasoning. Models are selected by task, latency, risk, and quality requirements.
OpenAI
Anthropic Claude
Llama / open-weight
specialized small models
Compute layer
Chips and cloud infrastructure
The hardware and runtime substrate underneath the models. Necessary, but not where credentialing policy lives.
Resulting boundary
The model can reason. The application decides what it may know, what it may do, which tools it can call, and when a human must take over.
Knowledge is layered.
The system separates general domain knowledge from client-specific and company-specific knowledge so the agent can reason at the right level of abstraction.
Authority is inherited.
Agents do not receive a universal workspace. Their available context and actions are computed from the user, role, tenant, placement, and policy.
Tools are mediated.
The LLM can propose a tool action, but the application layer validates scope, arguments, permissions, risk, logging, and human-review requirements.
Foundational agents
The system is not one broad assistant with universal access. It is built around two foundational agent patterns with different scopes, memory, tools, and review surfaces.
Assistant Agent
Workspace-aware
The Assistant Agent is the interface between the user and the credentialing workspace.
It can answer questions, explain state, coordinate work, and use tools according to the user's role. A recruiter, credentialing specialist, admin, and executive can all speak to the same agent interface, but the application layer gives each of them different context, authority, and tool access.
Operations Agent
Placement-bounded
The Operations Agent works on one placement, one candidate, and one bounded operation at a time.
This narrow scope is deliberate. It protects data integrity, simplifies authorization, reduces cross-operation leakage risk, and gives supervisors a clean unit of work to audit, pause, inspect, or hand back to a human.
Safety model
Safety is designed into every boundary: what the agent can know, what it can retrieve, what it can call, what it can write, when it must stop, and when a human must decide.
Bounded context
Agents receive the smallest useful context for the task: tenant, company, role, placement, requirement, source evidence, and available tools.
Least-privilege tools
Tools are not open-ended capabilities. Each tool has explicit arguments, permissions, policies, rate limits, and logging.
Complete mediation
The model does not decide whether an action is allowed. The application layer validates every action against policy before execution.
Human checkpoints
Critical one-way-door actions have lower thresholds for human review, especially when confidence is low, source evidence conflicts, or the action changes external state.
Traceability
Every meaningful output is attached to source context, tool calls, reasoning summary, confidence, supervisor review, and a durable audit trail.
Operational pause
A placement can be paused quickly, which removes working agents from that operation and routes state to human review.
Injection and abuse defense
Credentialing agents read messages, documents, files, and external sources. That means the system has to treat content as data, not instruction, and restrict the blast radius of anything the model misunderstands.
Direct prompt injection
Instruction hierarchy, relevance classification, output validation, and tool mediation prevent a user prompt from becoming authority.
Indirect prompt injection
External documents and messages are labeled as untrusted content. Retrieved text is quoted as evidence, not treated as operating instruction.
Sensitive information extraction
Role-bound retrieval, tenant isolation, response policies, and redaction prevent the agent from exposing data outside the user's authority.
Excessive agency
Agents only receive granular tools required for the task. High-impact writes, external messages, and irreversible actions require additional checks.
Off-domain or spam usage
A relevance layer identifies requests outside credentialing, onboarding, compliance, and integrations, then applies throttling and backoff.
Unbounded consumption
Request budgets, rate limits, queue limits, anomaly detection, and tool throttles protect token spend and system availability.
Knowledge pollution
Uploaded knowledge is processed through source tracking, versioning, review state, and retrieval filters before becoming agent context.
Audit and confidence
The system is designed so a person can ask why a decision happened, what evidence supported it, what model produced it, what tool was called, and who or what reviewed it.
source evidence
reasoning summary
confidence
policy gate
tool call
supervisor review
human review
final state
Self-evolving system
Evolution is treated as a supervised product surface, not an invisible side effect. Agents can propose new tools, integrations, memories, preferences, and process improvements, but durable changes pass through policy, human review, evals, and audit before they become part of the operating system.
Solutions Architect Agent
Capability synthesis
Builds new capabilities and tools from low-level primitives.
The Solutions Architect Agent can inspect available code, data contracts, API surfaces, webhook schemas, and integration primitives, then assemble a bounded implementation plan or limited tool. It is designed for live integration work: mapping fields, wiring data access, calling APIs, triggering webhooks, adding feature-flagged behavior, and defining rollback paths.
Dreaming capability
Nightly reflection
Consolidates the day's corrections into better future behavior.
Each night, a reflection process reviews the day's work: mistakes, human corrections, rejected outputs, low-confidence moments, repeated questions, client preferences, facility exceptions, and newly observed edge cases. It uses deeper reasoning to separate one-off events from durable lessons, then proposes memory updates, eval additions, policy notes, or tool improvements.
Nightly evolution loop
01
Observe
Collects outcomes, review notes, corrections, confidence misses, tool failures, and repeated user preferences from the day.
02
Reason
Distinguishes noise from durable knowledge: what changed, what was misunderstood, and what should be remembered.
03
Propose
Creates candidate memory entries, eval cases, tool patches, integration plans, or workflow recommendations with source evidence.
04
Gate
Routes persistent changes through policy checks, supervisor review, human approval, and regression evaluation before activation.
Evals and continuity
A large eval library protects continuity across model upgrades, prompt changes, retrieval changes, tool changes, and newly discovered credentialing edge cases.
01
Golden credentialing cases
Representative placements with known expected requirements, acceptable evidence, edge cases, and final outcomes.
02
Tool contract tests
Checks that each tool receives valid arguments, honors permissions, handles failure, and returns auditable state.
03
Safety and injection suites
Adversarial prompts, poisoned documents, off-domain requests, and data-extraction attempts are tested before model or prompt changes ship.
04
Regression gates
Model upgrades and prompt revisions are compared against historical outputs, confidence thresholds, and human-reviewed expectations.
05
Supervisor sampling
Supervisor agents and human reviewers randomly audit live work to check credibility, consistency, and drift.
Security and compliance
Healthcare onboarding touches identity, employment, licensing, health screening, signatures, facility policy, and sometimes protected health information. The system is designed around tenant isolation, access control, encryption, monitoring, auditability, and healthcare-aligned safeguards.
Customer knowledge stays customer-owned.
External models do not train on your data where configured by contract and provider policy.
Access is role-bound, monitored, and auditable.
Controls are designed around security, confidentiality, integrity, and availability.
Healthcare workflows are handled with HIPAA-aligned safeguards where applicable.
Credentialing Agents
We are building this as an applied research system for healthcare onboarding and credentialing: useful autonomy, constrained by software boundaries and human review.