This post was written by Sasi Mukkamala, Chief Technology Officer at Redox.
A follow-up to LLMs, MCPs, and Agentic AI — Oh My!
In December 2025, I wrote that interoperability was moving toward a world where integrations are shaped, monitored, and repaired by AI agents that understand intent and can act on it. At the time, that was a thesis. Here at Redox, we had an MCP server running internally, a set of design principles, and a bet that natural language would become a legitimate interface to healthcare integration infrastructure. We forecast that by June, we’d have some betas to test with customers, targeting general availability (GA) in late 2026.
Instead, in June 2026, we shipped it. Our MCP server and the AI Assistant Suite became generally available, and customers began using them against production integrations. In fact, customer adoption has exceeded targets. The only thing outpacing customer adoption is customer enthusiasm for these new features. In just a few short months, the systems and tools that interop runs on have fundamentally changed in unexpected ways. Some things got easier. Some did not. The questions ‘who does the work?’ and ‘how much work gets done?’ now have very different answers. Some of our theses were validated. Some were sharpened. All of these learnings have shaped our current thinking and roadmap. Let’s dig into it.
What has gotten easier, and what hasn’t
Getting customers to want to use AI features got easier. When we opened the MCP beta in late 2025, we had to go find participants. There was a long list of candidates, but only a handful of customers willing to actually give it a try. Interest was real, but abstract; few had a specific plan for or understanding of what they would do with it. In the months between beta and GA, the conversation has completely changed. Customers now see the value of our MCP server easily, often because they are already running agents somewhere else in their stack. The usefulness of our AI Assistant Suite speaks for itself, and customers are eager to turn those features on as soon as possible. (Shameless plug: find our MCP server in the Anthropic Connector Marketplace!)
Making AI features safe did not get easier. Developing our MCP server is fairly straightforward. Exposing a healthcare integration platform through it is not. What limits an agent operating on this infrastructure is whether it can see the right state, whether it is permitted to change what it is being asked to change, and whether that change is reversible and attributable afterward. Meeting privacy and security requirements for healthcare data is something on which we will never compromise. Over the last two quarters, we’ve spent as much time on authorization scoping, tool annotations, org-context resolution, and audit surfaces as we did on prompt and context engineering. All this work resulted in us delivering a robust and secure experience for users interacting with our AI features and MCP on a daily basis.
What has changed
Consider this: config modifiers have historically required knowing our DSL (domain-specific language), which means a project manager or business analyst who understands the clinical requirement perfectly needed a Redoxer to help make the changes. With the Config Modifier AI Assistant, that same customer simply describes the mapping and gets a working schema back within minutes. We have watched customers map full HL7 segments for message types they had never touched, including conditional logic that depended on whether a FHIR resource was present, and then apply the same logic across multiple subscriptions. Elsewhere, operations staff now make their own config and HL7 changes safely instead of relying on an engineer.
That is the actual transformation, and it is not “engineers got faster.” The set of people who can safely make a change got a lot broader.
The second-order effect is one I did not predict, and we now hear a version of it from most customers who have been using these tools for a few months: AI tooling generates more backlog, not less. When the cost of proposing an integration change falls, more changes get proposed. Capacity freed on the implementation side is absorbed almost immediately by work that was previously not worth writing down. If you’re measuring your AI investment by headcount avoided, you are measuring the wrong thing. Measure how much more your team ships against the same constraint. It’s a version of Jevons paradox: making something cheaper to do increases how much of it gets done, not how much free time you get back.
The third effect redirected our roadmap. When we asked customers what still hurts, they did not lead with error volume. They led with invisible failures. A queue quietly retrying below an alerting threshold. A source-side feed that changed shape upstream and went unnoticed until downstream data looked wrong. One integration lead described his troubleshooting to us this way:
“Sometimes it’s really looking for a needle in a haystack. Something to help me know what shape of haystack I’m looking for would be a great step in the right direction.”
That is the problem worth solving. The expensive part of an integration failure in healthcare is rarely the cost of the fix. It is the cost of bad data or no data exchanged in the interval between when something broke and when someone realized it.
In a recent webinar, our SVP of Customer Success Kalyn Gigot told the story of a healthcare organization that went six weeks without sending a single result. The organization was working with an integration platform with no alerting or monitoring in place. No one noticed the lack of traffic until someone asked why billing had gone quiet, because in that workflow, no result meant no invoice. Six weeks of silence, at a business doing close to a billion dollars a year, is not a rounding error. It is real revenue that has to be chased down after the fact.
That gap between the break and the discovery is where the real damage happens. It can turn into a churned contract or a soured customer relationship long before anyone even finds the root cause.
How we are thinking about AI tooling now
Here’s what we took away from the last six months: adoption was simple, but safety was the real work; freed-up time turned into more backlog work instead of less; and the failures that hurt most were the ones nobody saw coming.
As we look to the future, we’re organizing investment into three areas, because they carry different risks and different burdens of proof:
- The MCP server — typed, permissioned tools any MCP-compatible client can call. This enables agentic self-service using the tools our customers already use
- Assistants in the dashboard — the in-context layer, for someone already looking at a log, payload, or config editor inside our dashboard
- Agents in the background — intelligent processes running continuously against your environment that tell you something you did not ask about but you should know about
For the second half of 2026, we are focusing on:
Agents that watch
We are starting with error identification, triage, and remediation, ahead of the more specialized data quality work. The reasoning is coverage. A data-cleaning agent is a precision instrument, enormously valuable to a subset of customers. An error agent is a smoke alarm — every building needs one.
Concretely, we are looking to catch the failure modes that sit below today’s alerting floor. Queues stuck in retry loops. Silent source-side failures. Connectivity degradation visible in logs and nowhere else. Customers deserve proactive notification instead of a dashboard someone has to remember to open. We are starting with aggressive thresholds and tuning false positives down over time rather than the reverse, because an under-sensitive alert teaches people to ignore it, and that damage is hard to undo.
Alongside it, drift detection. When an upstream EHR changes the shape of a feed, the signal is often already sitting in the errors we collect. The work is connecting those symptoms to a cause and surfacing it as a change in the world, not as a list of individual failures.
Self-service, end-to-end
The second investment is completing the path from intent to a live integration through MCP. Our own implementation teams now run implementations end-to-end through the MCP server — the internal proof we wanted before opening it further. The phrase we are using internally is “Do it yourself, but not by yourself.” Meaning that customers can utilize self-service features when it makes sense to do so, but they can rely on the Redox team for guidance and support. In this case, the goal is for a customer to be able to stand up a connection entirely on their own, if they want to.
This is not only a speed argument. When implementation cost drops structurally, the economics of small connections change: the clinic that was never worth the integration effort becomes worth connecting. That reaches further into healthcare than any efficiency gain.
Another shameless plug: follow us on Linkedin, or sign up for our monthly newsletter to see what new features we ship each month!
What has not changed
The governance posture is the one we shipped in June, and it will not loosen as agents become more capable.
PHI does not train models. Prompt data follows a defined retention and de-identification path, and clinical data processing remains governed by the same integration protocols it always was. Inference runs on a HIPAA-compliant engine with enforced data boundaries. AI features stay off until an organization owner turns them on and accepts the terms — we have never enabled them by default for anyone.
For agentic work specifically, three rules hold. 1) Read access expands before write access. 2) Every agent action is attributable and auditable. 3) Nothing changes in your environment until a human says so.
This is a constraint we embrace, not one we resent. Autonomy over healthcare infrastructure has to be earned incrementally, in production, against evidence.
Where this goes next
The vision has not changed: interoperability as programmable infrastructure, with intent as a first-class input and a closed loop where the same layer that stands up a configuration watches it, explains it, and repairs it.
What has changed is that I now know which part is hardest. It is not standing up the integration. It is the long, unglamorous middle — the years a feed runs in production while the systems on both ends quietly evolve underneath it. That is where trust in healthcare data is actually won or lost, and it is where we are pointing our agents next.