Building a deterministic agentic care platform on Amazon Bedrock AgentCore
Agentic AI, defined: an agentic AI system is one where multiple specialised AI agents, coordinated by an orchestrator, execute a multi-step business process rather than simply answering questions. Unlike a chatbot, it holds state across sessions, applies explicit rules, triggers time-based workflows and escalates to a human when required.
Key takeaways
- The orchestrator should be deterministic, not generative. Routing by rules against an explicit state model — rather than letting a language model decide what happens next — is the single highest-leverage decision in an agentic architecture.
- A state model is a product decision. Defining ~17 patient lifecycle states up front forced clinical and commercial rules into the open before a line of code was written.
- Not every agent needs a model. Moving wallet and notification flows to rule-based templates removed inference cost from the highest-volume path in the system, at zero LLM tokens.
- Ground every answer or escalate it. Each clinical response must cite a classical text, an active care plan or a doctor instruction; where grounding is unavailable, the query routes to a human doctor.
- Safety needs veto authority. Risk monitoring can suspend every other agent, so a commercial nudge cannot arrive in the middle of a health emergency.
Most enterprises building on large language models today have the same experience. The demo is spectacular. The pilot is promising. And then the thing hits production, and it turns out a model that can hold a conversation cannot reliably run a process.
That gap — between a chatbot that answers and a system that executes — is where agentic AI is actually being won or lost right now. We recently closed that gap for a fast-growing Indian digital health platform offering Ayurveda teleconsultations, and the engagement produced a set of architectural decisions we think are worth sharing, because they generalise well beyond healthcare.
The customer is not named here at their request. Everything below is architecture and approach.
The problem: the platform worked, but only in the moment
The customer operated an AI-powered patient engagement platform connecting patients with Ayurveda specialists across consultation, prescription and recovery. It was built on external LLMs, and it worked — for the length of a conversation.
What it could not do was hold a journey together:
- Patients abandoned before consulting. Intake, doctor recommendation and wallet top-up each leaked users, and there was no automated path to bring anyone back. Paid acquisition converted at a fraction of its potential.
- Nothing was deterministic. External LLMs drove the workflow with no state model and no routing rules. The patient experience varied run to run, and token cost was unpredictable.
- Wallet friction killed bookings at the last step. Payment failures, insufficient balance and abandoned top-ups were all handled conversationally — expensively and inconsistently.
- There was no follow-through after the prescription. Whether the medicine was bought, whether the pain score moved five days later, whether the patient quietly stopped responding — all of it depended on the patient remembering.
- Clinical risk signals went unread. Worsening symptoms mentioned in free-text chat had no monitoring path and no route to a doctor.
A general-purpose LLM chatbot can hold a conversation. It cannot be trusted to run a care journey, because it has no state, no rules, and no guarantee that a red-flag symptom ever reaches a human.
The principle we built on: the AI may talk, but rules decide
Rapyder designed and delivered an agentic care platform on AWS built around one architectural commitment: the orchestrator is deterministic, not generative.
A central orchestrator running on Amazon Bedrock AgentCore reads the patient’s current lifecycle state and activates exactly one specialised agent. It is a routing layer governed by rules — not a model deciding what should happen next. No agent self-triggers. No two agents run in parallel against the same patient.
Model-driven vs deterministic orchestration
| MODEL-DRIVEN ORCHESTRATION | DETERMINISTIC ORCHESTRATION |
Decides the next step | The language model | Explicit rules against a state model |
Journey state | Implicit, held in the prompt or context | Explicit — one of ~17 named states |
Concurrency | Agents can self-trigger and overlap | Exactly one agent active per patient |
Repeatability | Varies run to run | Same state and input produce the same route |
Token cost | Scales with every interaction | Rule-based paths run on zero tokens |
Auditability | Reasoning is opaque and hard to replay | Every transition, tool call and citation logged |
Safety | Caution has to be tuned into the model | Escalation state overrides all other workflows |
Reviewability | Business rules buried in prompts | Rules visible to clinical and commercial stakeholders |
The eight agents, and what each owns:
AGENT | RESPONSIBILITY |
A1 — Triage & Recommendation | Collects symptoms in 3–5 conversational turns, classifies urgency, screens for emergency red flags every turn, and returns a ranked specialist with availability, fee and a one-line rationale |
A2 — Wallet (rule-based) | Balance validation, top-ups, payment failures and refunds through deterministic templates — zero LLM tokens |
A3 — Drop-off Recovery | Re-engages patients who stall at intake, after recommendation or at wallet-pending, through time-gated workflows with a hard stop at Day 7 |
A4 — Medicine Adherence | Prescription confirmation, purchase nudging, delivery tracking, daily reminders, missed-dose handling and reorder workflows |
A5 — Recovery Tracking | Structured post-consultation check-ins — pain score, sleep quality, digestion, energy levels, side effects — feeding patient recovery graphs and doctor dashboards |
A6 — Risk Monitoring | Continuously reads adherence, recovery and free-text signals, with veto authority to pause every other agent when a red flag appears |
A7 — Reschedule & Continuity | Triggers follow-up consultations only on clinical justification — plateau, regression, chronic review or patient request — never on a retention schedule |
A8 — Companion Q&A | Answers diet, lifestyle, Ayurveda, medication and lab-report questions in the gaps between consultations, grounded in retrieval |
The state model: every patient sits in exactly one known place
Underneath all of it runs a ~17-state patient journey model. Every patient sits in exactly one state at any moment — from LEAD through INTAKEINPROGRESS, WALLETPENDING, CONSULTED, ONTREATMENT, RECOVERYTRACKING and on to CLOSED. The state determines which agent is permitted to act. One state, ESCALATIONREQUIRED, takes precedence over all others and suspends every commercial and reminder workflow until a clinician has reviewed the case.
This is where many agentic AI builds go wrong. Teams encode workflow logic inside prompts, which makes the process hard to test, hard to audit and impossible for business and clinical stakeholders to review. A state model turns hidden assumptions into visible product decisions, and forces the hard questions early: what counts as a drop-off, when should a reminder stop, which risk signals override commercial workflows, and when must a human be involved. Those are operating-model questions, not prompt-engineering questions.
How it fits together on AWS
The architecture spans two connected layers.
Layer one: turning unstructured clinical content into a knowledge base
Consultation audio, prescriptions, lab reports and classical Ayurveda references land in Amazon S3, which triggers modality-specific ingestion pipelines:
- AWS Lambda + Amazon Transcribe converts doctor–patient consultation recordings into searchable transcripts on upload.
- AWS Lambda + Amazon Textract extracts structured text and metadata from prescriptions, lab reports and scanned documents.
- An AWS Lambda embedding pipeline parses, enriches and semantically chunks every document, generating vectors with Amazon Bedrock embedding models.
- Amazon OpenSearch Service holds those vectors as the semantic retrieval layer powering all Retrieval-Augmented Generation.
The grounding rule is deliberately simple: every clinical answer must cite a valid source — a classical text, an active care plan or a doctor’s instruction. Where the platform cannot ground the answer, it escalates to a human doctor. The model generates language; the platform decides whether the answer is grounded enough to send.
Layer two: the agent runtime
Amazon API Gateway provides a secure WebSocket entry point with authentication, request validation and throttling. The Amazon Bedrock AgentCore Gateway routes each request into the agent runtime using standardised tool schemas, so tool invocation is deterministic rather than improvised. Amazon Bedrock (Claude Sonnet) supplies conversational understanding and grounded generation. Amazon EventBridge Scheduler drives every delayed and time-based workflow, and AWS Lambda with the Meta WhatsApp Cloud API delivers reminders and check-ins on the channel patients already use.
State lives in two places by design: Amazon DynamoDB for conversational state, workflow events, tool invocation logs, escalation records and retrieval citations; Amazon Aurora PostgreSQL for patient profiles, care plans, medication schedules, adherence records and longitudinal recovery metrics.
Every state transition, tool call and citation is logged with full provenance — which is what makes the platform auditable rather than merely observable.
Six lessons that transfer to any agentic AI build
These are the takeaways we’d carry into the next agentic engagement, in any industry.
Keep the orchestrator deterministic
Routing by rules against an explicit state model — rather than letting a model decide what happens next — is what makes a workflow repeatable and auditable. This is the single highest-leverage decision in an agentic architecture. A model can understand, classify and generate; it should not be the authority deciding which business process runs next.
Do not put a model where a rule will do
Moving the wallet and notification flows to rule-based templates removed inference cost from the highest-volume path in the system with no loss of experience. Ask of every agent: does this actually require reasoning, or does it require reliability?s
Treat the state model as a product decision, not a technical one
Defining ~17 patient states up front forced the clinical and commercial rules into the open before a line of code was written. Teams that skip this step end up encoding those rules implicitly in prompts, where nobody can review them.
Ground every answer or escalate it
Requiring each response to cite a classical text, an active care plan or a doctor instruction — and escalating to a human when grounding is unavailable — is a far cleaner safety rule than trying to tune a model into caution.
Give the safety agent veto power
Letting risk monitoring suspend commercial and reminder workflows is what prevents a sales nudge arriving in the middle of a health emergency. In a regulated domain, clinical priority has to be architectural, not aspirational.
Meet users where they already are
Follow-up completion depends far more on using WhatsApp than on the sophistication of the model behind it. Channel choice beat model choice on this metric, consistently.
Designed for production, not for demo
The engagement targets agreed before development began are worth stating plainly, because they show what the architecture was built to hold. These are pre-build design targets, not post-deployment performance results.
DESIGN TARGET | VALUE |
Agents | 8 specialised + 1 orchestrator |
Journey states | ~17, every patient in exactly one |
Delivery effort | 114 person-days, planning through governance |
Environments | 3 — development, UAT, production |
Red-flag recall | ≥90%, tuned to minimise false negatives |
P95 latency | <45 seconds for any patient-facing agent turn |
Designed capacity | ~45,000 interactions per month |
Languages | 3 — Hindi, Hinglish, English |
Funnel targets were set per agent before build — intake completion, doctor recommendation acceptance, drop-off re-engagement, prescription purchase within 72 hours, weekly check-in completion and clinically justified follow-up booking. Every agent carried a north-star metric it was accountable for. That discipline is what keeps an agentic platform from becoming a science project.
Production readiness came from the same place. Every turn, tool call, state transition and retrieval citation is logged to Amazon DynamoDB. Amazon CloudWatch covers execution status, failures and latency, with alarms on red-flag detections and human handoffs. Requests are validated at the gateway, patient-scoped access is enforced on every read and write, credentials are retrieved at runtime through AWS IAM and Secrets Manager, and consultation evidence is stored encrypted in Amazon S3. The platform never acts as an autonomous clinical decision-maker, clinically sensitive output remains subject to doctor review.
Because the design is serverless and consumption-based, run cost tracks patient volume rather than idle capacity, which matters a great deal when you are scaling an AI platform whose usage is genuinely unpredictable.
Where this agentic AI pattern applies next
Strip out the clinical vocabulary and what remains is a general blueprint for enterprise agentic AI:
- A deterministic orchestrators
- An explicit state model
- Specialised single-purpose agents
- Retrieval grounding with mandatory escalation
- Event-driven continuity on the channel the user already uses
- Full logging of every transition, tool call and citation for audit and governance
That shape fits loan origination, insurance claims, customer onboarding, field service, KYC remediation — any process where the conversation is the interface but the process is the product, and where “the model got it wrong” is not an acceptable outcome.
Rapyder is an AWS Premier Tier Services Partner, and this engagement drew on our combined expertise in Amazon Bedrock AgentCore orchestration, retrieval-augmented generation on Amazon OpenSearch, and event-driven serverless design — delivering a nine-component agentic platform with grounding, escalation and audit built in, end to end, in 114 person-days.
Frequently Asked Questions
Agentic AI is an architecture in which multiple specialised AI agents, coordinated by an orchestrator, execute a multi-step business process rather than answering questions in isolation. It holds state across sessions, applies explicit routing rules, triggers time-based workflows and escalates to a human when a defined condition is met.
A chatbot responds within a conversation. An agentic AI system moves a process forward across many conversations and days. The practical difference is state: an agentic system knows where the user is in a defined journey, which workflow is permitted next, and what must happen if nobody replies.
In our experience, no. Routing should be deterministic with explicit rules evaluated against a named state — so the same state and input always produce the same route. Language models are best used inside agents for understanding and generation, not as the authority deciding which business process runs next.
A state model enumerates every stage a user can occupy, with exactly one active at a time. It matters because it determines which agent is permitted to act, and because writing it down forces clinical, commercial and operational rules into the open where stakeholders can review them, instead of leaving them implicit inside prompts.
No. Agents that need consistency rather than reasoning — balance checks, payment retries, templated notifications run better as rule-based workflows. In this platform the wallet agent runs on zero LLM tokens, which removed inference cost from the highest-volume psath without changing the user experience.
Amazon Bedrock AgentCore is the AWS service layer used here to host the orchestration and agent runtime. Its Gateway routes requests into agents using standardised tool schemas, which keeps tool invocation deterministic rather than improvised by the model.
By making grounding a gate rather than a preference. Every clinical answer in this platform must cite a valid source — a classical text, an active care plan or a doctor instruction. If the answer cannot be grounded, the query routes to a human doctor instead of being generated anyway.
Log every state transition, tool call and retrieval citation with full provenance. Deterministic routing is what makes those logs meaningful: because the route is a rule and not a model judgement, any decision the platform made can be replayed and explained after the fact.
