CredCall AI

CredCall AI uses CALL-E to investigate stalled provider-enrollment cases by phone, identify the root cause, and determine the exact next action needed to move them forward.

Comment

Inspiration

Healthcare provider-enrollment applications can remain stalled for weeks or months even when a credentialing team already has a submission confirmation, supporting documents, previous call notes, a payer status, and an application number.

The difficult part is usually not making another phone call. It is figuring out what is already known, what conflicts, what needs to be learned from the payer, and what exact action will actually move the application forward.

That led me to a simple question:

What if an AI agent could investigate a credentialing exception instead of merely making a scripted status call?

I built CredCall AI, an Autonomous Credentialing Exception Investigator.

A typical voice agent is given a call to make. CredCall AI is given an unresolved case to investigate. It analyzes the existing evidence, identifies the highest-value unresolved question, uses CALL-E to gather the missing evidence by phone, reconciles that evidence against the case, and either produces an actionable resolution or safely escalates the investigation.

A typical voice agent completes a call. CredCall AI uses CALL-E to complete an investigation.

What it does

CredCall AI investigates stalled or contradictory provider-enrollment cases.

A case can contain provider and practice information, payer details, application and submission data, previous follow-up notes, supporting documents, known status information, and explicit disclosure restrictions.

CredCall first analyzes that evidence and identifies known facts, unknowns, contradictions, and hypotheses.

For example, the primary demo case has been pending for 74 days. The payer says the provider's malpractice certificate is expired, but the credentialing record contains a current certificate valid through December 31, 2026.

Rather than asking CALL-E for another generic application status, CredCall generates a focused investigation objective:

Determine which malpractice certificate is actually attached to the active application, what expiration date the payer sees, how the correct document should be submitted, whether the original queue date will be retained, when the team should follow up, and what reference number applies.

The phone result becomes new evidence in the case.

CredCall then reconciles that evidence against what was already known. In the demo scenario, the payer is found to be reviewing an older certificate expiring December 31, 2025. The contradiction is resolved and CredCall returns the root cause, exact corrective action, responsible team, follow-up timing, payer reference, supporting evidence, and confidence.

The system can also stop safely. A separate scenario demonstrates a payer requesting restricted verification information such as a full SSN. CredCall does not fabricate or disclose that information; it attempts permitted alternatives and routes the case to human review when the investigation cannot continue safely.

The result is not simply:

Application incomplete.

It is an evidence-backed explanation of why the application is stuck, what proves it, and exactly what should happen next.

How it was built

I built CredCall AI around one central abstraction:

An investigation is a stateful sequence of goal-driven CALL-E phone tasks.

CredCall owns the investigation state: case evidence, facts, contradictions, hypotheses, disclosure policy, phone objectives, call results, resolution criteria, and human escalation.

CALL-E provides the real-world phone capability: executing adaptive phone tasks, handling the conversation, and returning the transcript and call outcome.

The investigation loop is:

Case evidence → contradiction → phone question → CALL-E investigation → new evidence → reconciliation → resolve or escalate.

CALL-E is therefore not an optional notification channel. It is how CredCall acquires evidence that is unavailable in the existing case record.

I built the application end to end in TypeScript using Next.js and React for the investigation workspace and a fully serverless AWS backend. AWS Lambda, API Gateway, Step Functions, DynamoDB, S3, SQS, CloudFront, and CDK provide execution, orchestration, persistence, evidence storage, and deployment. Amazon Bedrock provides the reasoning layer for case analysis, contradiction detection, investigation planning, transcript extraction, and evidence reconciliation.

Step Functions persists the investigation lifecycle across analysis, phone-task preparation, execution, result processing, reconciliation, resolution, and human-approval states.

The AI layer is deliberately bounded by deterministic controls. Model output is schema-validated before it can affect state, evidence references are checked against actual case records, and an investigation cannot become RESOLVED unless it has a root cause, supporting evidence, a corrective action, an owner, a follow-up expectation, sufficient confidence, and no unresolved material contradiction.

One of the most important technical discoveries came from integrating CALL-E itself.

CALL-E's REST API supports a custom result_schema, but the MCP tools I used for the deployed live-call integration—plan_call, run_call, and get_call_run—do not expose that capability. MCP returns the call transcript and CALL-E's own result metadata rather than an application-specific structured result.

To solve that, I built a Bedrock-based extraction layer that converts the real CALL-E transcript into a schema-validated CredCall result. That result is then stored as evidence and fed back into the investigation.

I validated the complete flow with genuine CALL-E outbound calls: call execution, adaptive conversation, transcript retrieval, structured extraction, evidence reconciliation, and final investigation resolution.

For judging, the application also provides a clearly labeled Demo Replay using deterministic synthetic conversations, so the full workflow can be demonstrated without waiting several minutes for a live phone call. A separate passcode-gated Live CALL-E path allows an authorized tester to trigger a genuine call after explicit confirmation.

All demonstration data is synthetic. The prototype uses no real patient data or production PHI.

Challenges encountered along the way

One early challenge was keeping CALL-E central to the product. My first design included dashboards, record management, document processing, and call automation, but that risked turning CALL-E into just another integration. I redesigned the system around phone-native investigations: existing evidence creates a question, CALL-E investigates it, and the answer changes the case.

Another challenge was discovering the difference between CALL-E's REST and MCP result surfaces. I initially expected to request an application-specific structured result directly, but MCP does not expose result_schema. Building a validated extraction layer from the real transcript solved that problem and became useful beyond CredCall itself.

Stateful serverless execution also exposed several issues that local tests did not. Separate Lambda invocations could not rely on in-memory provider state, Step Functions failures needed to be reconciled back into domain state, and live-call polling initially selected the wrong provider after execution. Running genuine investigations against the deployed infrastructure surfaced these failures and led to regression tests for each one.

Amazon Bedrock introduced another subtle issue: when retrying an invalid structured result through the Converse API, a tool_use response must be followed by the corresponding tool_result. A normal text retry was rejected by the API. Fixing that interaction produced a more robust structured-output layer.

Finally, healthcare-adjacent phone workflows require bounded autonomy. I needed to make restricted disclosures, uncertain evidence, invalid state transitions, and human escalation deterministic controls rather than instructions that a language model could choose to ignore.

Accomplishments

I am most proud that the finished application is not a "voice call plus summary" demo.

A phone result becomes a first-class evidence item. CredCall compares it with existing documents and case history, tracks unresolved contradictions, and only closes an investigation when deterministic resolution criteria are satisfied.

I also built and deployed three distinct investigation paths: a document-version contradiction, a misassociated application, and a restricted-information safety path. The same investigation engine can resolve a case or intentionally stop and create a human-review item.

The system has also been tested beyond mocked API calls. I completed genuine CALL-E investigations end to end against the deployed AWS environment and built a separate, explicit live-call path into the product.

Another accomplishment came directly from the CALL-E integration work. I generalized the MCP transcript-to-structured-result solution into a standalone TypeScript contribution for CALLE-AI/awesome-phone-call-agents. It went through multiple rounds of review and security hardening and was ultimately merged into the official CALL-E repository.

That contribution means one of the technical problems I encountered while building CredCall became a reusable pattern for other CALL-E developers as well.

Learnings

The biggest lesson was that phone calls become much more valuable when they are treated as part of a persistent evidence process rather than isolated interactions.

A status such as "pending", "under review", or "incomplete" can be technically correct and still operationally useless. What matters is understanding why the status exists and what action will change it.

I also learned that CALL-E is most powerful when each call has a meaningful goal derived from context. The system should not make more calls simply because it can. It should determine what evidence is missing and use the phone only when the conversation can answer a meaningful unresolved question.

Another lesson was that uncertainty should remain visible. If the evidence does not establish a fact, CredCall keeps it unknown. If two sources conflict, the contradiction remains open. If confidence is insufficient, the system escalates instead of manufacturing certainty.

Finally, autonomous reasoning works best when paired with deterministic controls. I use models to analyze evidence and propose actions, while application code controls disclosure rules, state transitions, evidence references, resolution requirements, human approval, and stop conditions.

What's next for CredCall AI

The hackathon version focuses on three synthetic provider-enrollment exception scenarios. The next step would be expanding the investigation library to cases such as missing documents, applications that cannot be located, incorrect provider or group associations, duplicate submissions, payer handoff failures, effective-date delays, and applications that have exceeded stated processing timelines.

I also want to extend the stateful investigation model across multiple payer departments. A future case could contact credentialing, learn that the application was transferred to contracting, contact contracting with the evidence from the first call, and continue until it identifies the actual operational failure.

Longer term, CredCall could add payer-specific investigation strategies, credentialing-platform integrations, inbound callback handling, organization-specific disclosure policies, automated follow-up scheduling, investigation analytics, and historical payer turnaround intelligence.

CredCall AI is not intended to replace credentialing management systems. It is designed to sit beside them as an exception-investigation layer.

Existing systems can identify which applications are stalled.

CredCall AI uses CALL-E to determine why they are stalled and what needs to happen next.

A typical voice agent completes a call. CredCall AI uses CALL-E to complete an investigation.

Built With

Share this project:

Updates

Submission history