As healthcare organisations rush to integrate AI into data migration, a critical bottleneck is emerging: how do we use probabilistic systems to deliver trustworthy outcomes? While engineering a recent healthcare data transformation pipeline, I got a frontline view of this problem and its solution.
The programme involved improving and transforming data used in healthcare. The data migration pipeline was built on AWS Bedrock, Lambda and other services, using Strands Agents to manage the agentic loops. That context matters, but the more reusable lesson was the way we combined conventional data processing, agentic investigation and transformation, encoded validation, confidence-based routing and human review - all key elements of a trustworthy data assurance process.
Data migration is only part of the problem. The harder question is whether the result is complete, consistent, explainable and safe to approve.
Traditional validation is strong when a rule can be expressed precisely. Code can compare record counts, validate a schema, check allowed values and test referential integrity. It is fast, repeatable and comparatively inexpensive.
However, not every assurance question is a simple assertion. Investigating an anomaly, or producing the transformation it calls for, can require context from several sources, interpretation of descriptions, comparison with domain rules and a recommendation about what should happen next. This is where an agent can add value.
By working on the agentic data migration, I learned that the power of the deterministic code does not go anywhere - it is the basis of the work, a way to keep control of the decisions in our hands.
The design principle I took from the work is simple:
Keep deterministic work deterministic. Use an agent ONLY when the task benefits from contextual reasoning.
In practice this means the deterministic approach should always be the default first option for every step in the migration pipeline. Only once deterministic checks have exhausted what they can establish should an agent be introduced.
For example, deterministic code handles the baseline validation of an organisation code, and only if it fails the current format is an agent invoked, receiving exclusively the legacy context needed to map the correct value. We care about keeping that control in deterministic hands because agents can hallucinate, agent calls can be expensive, and, most importantly, in a healthcare setting data accuracy is not negotiable. The rest of this article looks at how we can further manage each of those concerns in practice.
Prompting alone does not make an agent reliable. Instructions are not the same as enforced controls. The diagram below shows the key layers we relied on, some of them covered using the Strands toolkit for building agents.
Nonetheless, strong prompting is essential. Explicit grounding and fallback instructions shape what the model attempts before any other layer is reached. For example, instructing an agent to explicitly output "I don't know" when tool data is missing may prevent it from improvising.
In Strands, the tools available to an agent are what actually constrain what it can know and do, regardless of what the prompt says. A tool should perform one bounded operation, accept a small, validated set of inputs, and expose only the capability the agent needs, not broad access to underlying services or data.
Structured output is defined with a Python Pydantic model, which Strands exposes as a tool and validates the model's arguments against. An agent can produce an answer that sounds convincing while omitting a required field or returning an unsupported value. Validation turns that into a detectable error rather than a silently accepted output, and on failure the error is passed back through the agent loop so the model can correct and resubmit. This narrows the acceptable output space but does not eliminate hallucination: structural validation is distinct from semantic validation, which still may need separate checks and evidence.
These layers do more than prevent hallucinations in the agent response. They also help control the cost and make failures more explicit, observable and recoverable. I wouldn't recommend building agentic systems without them.
Depending on the data you work with, you may find that after vigorous testing and tuning, your agentic system can be trusted to handle a large proportion of the assurance automatically. However, it is most likely that you will need the human-in-the-loop (HITL) process to review, modify and sign-off the final data transformation result - if not for all cases, then at least for some.
In our experience, we didn't send every transformation to a human. If deterministic checks passed and the agent's confidence threshold was met, the system saved the data automatically. Human review was reserved for the cases that did not meet that bar: lower-confidence recommendations or failed deterministic checks.
This only works because the threshold itself was not a guess. It was calibrated against evaluated examples, tested and agreed with domain experts, and set deliberately conservative where the consequences of an incorrect automated transformation were harder to reverse. The accountability did not disappear from the automated path - it moved upstream, into the decision about where the threshold sits and what evidence must be true before an agent is trusted to save without review.
For the cases that do reach a human (and for those that don't), the system has stored and can display the evidence and reasoning when proposing a transformation. The reviewer needs enough information to understand what the agent found, what rules were applied, what evidence supports the recommendation and where uncertainty remains. This way, we can keep the accountability in the right place: the human reviewer is responsible for the final decision, but the agent can help them make it faster and potentially with more evidence than they could gather manually.
Hopefully, you would have chosen the agentic system path because
it should save costs and time in your business area. Nevertheless, agent calls introduce token costs, latency and additional operational complexity.
LLM agents are a highly inefficient substitute for ordinary code. Handling all deterministic processing upfront shrinks the data sent to the model, reserving the agent's reasoning allowance for ambiguous cases where it actually adds value. It certainly improves quality too because the model receives a smaller, more relevant context.
Similar to setting timeouts, with Strands we can also apply a per-request tool-call limiter: the runtime tracks how many times an agent calls a given tool, and once a configured limit is reached it stops further calls and fails the task and sends it to human review. This stops a run from looping or burning resources without progress.
Selecting the right model is crucial too. In our project, we started with something lighter while building the infrastructure and had to adjust later to reach performance and accuracy targets. The right model is the one that balances cost, latency and accuracy for your use case.
Sometimes we face a use case where the sheer amount of manual work required to assure the data naturally guides us towards an agentic process like this one. Thankfully, established patterns now make responsible implementation possible: deterministic preprocessing improves focus, encoded validation catches errors, audit trails guarantee traceability, and human review keeps accountability in the right place.
Building this has made me more confident in using agents for high-impact fields like healthcare. That is because I am aware now of a pattern that allows us to use the powerful tools of AI, whilst leaving the final call to the expert in the field, equipped with the right audit data and research. I am already seeing similar opportunities in other healthcare work I started. The implementation may differ, but the boundary remains useful.