Most of the AI we've put into healthcare so far lives entirely in text. It reads a note and writes a summary. It reads a chart and drafts a code. It reads a message and suggests a reply. Useful work, but all of it happens inside the document. The AI never touches the building.
Roberto Cruz
July 9, 2026
Originally published on LinkedIn

A hospital is not a document. It's a physical system: analyzers on a lab bench, scanners in imaging, pumps and monitors on the floor, reagents that expire, machines that drift out of calibration, queues that back up at 7am and empty out by noon. The intelligence that matters most in that environment isn't the intelligence that can describe the building. It's the intelligence that can act in it, sensing the state of a physical asset and changing what happens next.
Here's the part we tend to forget: healthcare AI has always been physical. Its raw material was never just words. It's the pixels of an MRI or a pathology slide, the numeric output of a lab analyzer, the telemetry of an infusion pump or a bedside monitor, the continuous stream from a wearable on a patient's wrist, the readings from IoT sensors scattered across the building. Every one of those is a physical measurement of a physical thing. Imaging, labs, devices, wearables, IoT: the sensing half of physical AI has been in hospitals for years.
So the real shift from digital AI to physical AI isn't about giving AI physical senses; it's always had those. It's about giving it the other half, the ability to act back on the physical world instead of stopping at a paragraph of text. And that is the reason we built Hydra the way we did.
The missing half of most AI systems
Think about what an agent actually needs to be useful in a hospital, as opposed to useful in a chat window.
It needs a nervous system, a way to sense what's happening across dozens of incompatible systems in real time: the lab information system, the PACS, the pharmacy, the device fleet, the scheduling engine. And it needs hands, a way to change something in the real world: place an order, reroute a sample, open a maintenance ticket, hold a machine offline before it produces a bad result.
Most AI products have neither. They have a language model and a text box. They can reason beautifully about a problem and then do absolutely nothing about it, because they were never wired into the systems where the work lives.
Hydra was built from the other direction. The platform starts as an integration backbone: Hydra Connect speaks HL7 v2, FHIR R4/R5, X12, DICOM, CDA and custom protocols, in real time and in batch, across EHRs, PACS, labs, pharmacy and connected devices. That integration layer isn't a feature bolted on for the AI. It is the nervous system and the hands. Once an agent sits on top of it, sensing and acting are not aspirations. They're API calls.
This is what "physical AI" means in practice. Not a robot walking the ward. An agent that can perceive the live state of the physical hospital and take a real action inside it, safely, and with a human in the loop.
A concrete example: the agent that decides which machine runs the next test
Let me make this tangible with a problem every hospital lab already has, and no AI scribe will ever touch.
A clinical lab runs a fleet of analyzers. On paper they're interchangeable. In reality they never are on a given morning: one is mid-calibration, one is low on a reagent, one has quality-control values quietly drifting toward the edge of its acceptable range, one has a scheduled maintenance window in forty minutes, and two are carrying most of the queue while the others sit idle. A tech holds all of this in their head and makes routing decisions on instinct, dozens of times an hour, on top of everything else they're doing.
Now put a maintenance agent on Hydra into that picture.
The agent isn't reading a chart. It's watching the fleet. Through Hydra's connectors it sees, continuously and in one place: each analyzer's calibration status, its QC trend, its reagent levels, its current queue depth, its error history, and its scheduled service windows. When the next batch of tests arrives, the agent reasons over that live state and decides which machine should run it, steering work toward the analyzer that's calibrated, stocked and free, and away from the one that's about to go down or whose QC is trending out of tolerance. When it sees an analyzer drifting, it doesn't wait for a failed run and a repeat draw; it flags the machine for service and reroutes the workload before a bad result is ever produced.
Notice what kind of decision this is. It's an operational decision about throughput, uptime and asset health, not a clinical judgment about a patient. That distinction is deliberate, and it's where physical AI can move fastest and safest: the agent is optimizing the machinery of care, not making the call about the care itself.
And notice what the agent needed to be able to do it. It needed to sense the physical state of a dozen devices across systems that don't talk to each other. It needed to reason over that state as it changes minute to minute. And it needed hands, the ability to actually route the sample and open the ticket, not just recommend that someone else do it. That full loop of sense, reason, act is exactly the loop Hydra closes.
How Hydra closes the loop
Under the hood, the pattern generalizes far beyond the lab. It's the same architecture whether the physical asset is an analyzer, a scanner, an infusion pump, or a whole imaging suite.
Sense. Everything Hydra connects to emits events onto a shared, real-time event stream, a single backbone that every connected system publishes to and every agent can subscribe to. New results, device status changes, orders, drift signals: they all flow into one place the agents can watch. Hydra even discovers systems it wasn't explicitly told about. Its discovery engine can observe traffic on the hospital network, identify FHIR, HL7 and DICOM endpoints, reconstruct their APIs, and register them as connected sources, so an agent's field of perception grows as the hospital's does, without a six-month integration project for every new device.
Reason. On top of that stream sits the Hydra Agentic Platform, a no-code builder for AI agents and multi-agent workflows. This is where the maintenance agent lives, alongside agents for documentation, coding, quality, risk and the rest. Because building an agent doesn't require an engineering team, the people who actually understand the workflow can build the thing that runs it. In one flagship deployment, a clinician-built agent went live in a single day.
Act. The same connector layer that lets an agent read the hospital lets it write back to it: placing an order, updating a record, routing a sample, raising a ticket. That's the half most platforms are missing, and it's the half that turns an insight into an action in the physical world.
Stay drift-aware. Physical systems change. Reagents get swapped, firmware updates, an interface gets reconfigured. Hydra continuously validates the integrations it depends on and detects drift, whether a changed endpoint, a new schema, or a broken contract, and heals the connection before an agent starts acting on stale information. In a system that touches physical assets, that self-correction isn't a nicety. It's a safety property.
The guardrails are the point
Putting AI within reach of the physical hospital only works if the constraints are as serious as the capability. Three principles are non-negotiable in how Hydra does this.
A human is always in the loop. Agents surface decisions, propose actions and prepare the work. People retain authority over anything that matters. The maintenance agent reroutes and flags; a person stays accountable for the fleet. We are deliberate about this line: Hydra agents optimize operations and prepare clinical work, but they do not make autonomous clinical decisions.
Patient data stays home. For anything that spans multiple sites, Hydra Mesh runs each step of a pipeline where it's allowed to run and lets only de-identified, derived results cross a boundary. Raw patient data never leaves the site that owns it. A network of hospitals can share the intelligence of a fleet-optimization agent without any of them sharing a patient record.
You own the whole thing. Hydra runs on-prem or in any cloud, with no third-party dependency, HIPAA-aligned, and agents run under explicitly scoped access, so they can reach only the systems and data they're supposed to. The hospital owns the platform, the data and the agents acting on it.
Those three constraints are what make physical AI acceptable in a hospital rather than merely impressive.
Why this is the direction
We didn't arrive here from a whiteboard. Hydra is deployed across flagship European hospitals, where it solved in a week what larger vendors couldn't in months, and where it's been validated by strategics across integration, imaging and life sciences and is available on the Epic Marketplace. The integration foundation is real and in production. Physical AI is what that foundation was always for.
The industry spent the last few years teaching AI to read and write the hospital. The next few years are about teaching it to sense and act in the hospital: carefully, operationally, with a person in command. A hospital where the machinery quietly optimizes itself, where work is routed to the analyzer that's ready, a drifting instrument is pulled before it fails, and a fleet maintains its own uptime so the people can spend their attention on patients instead of on plumbing.
That's not a chatbot with a medical vocabulary. It's an operating layer for a physical building full of physical machines: agents with a nervous system and hands, and a human holding the reins.
That's the hospital Hydra is built for.
Roberto Cruz
CEO, TietAI — makers of Hydra, the AI infrastructure layer for healthcare.
hello@tiet.ai


![[background image]](https://webflow-prod-assets.s3.amazonaws.com/image-generation-assets/7aec9f70-e14f-43e7-a4bf-4098f770209d.avif)



![[interface] image of blockchain security setup](https://webflow-prod-assets.s3.amazonaws.com/image-generation-assets/d2c14179-5aa8-462e-9856-7fed1e5a0e72.avif)