Clinical AI’s Next Test: Taking Action Without Taking Control
Clinical AI becomes a different kind of software when it can do more than produce a note. Retrieving information, preparing changes, and writing into an electronic health record introduce a new question: not just whether an answer is accurate, but whether the resulting action is appropriate, authorized, and traceable.
The October 22, 2026 announcement of ORBIS Buddy by Dedalus and Corti brings that distinction into focus. Built into Dedalus’ ORBIS electronic health record, Buddy introduces clinician-directed workflows with natural-language interaction and confirmed actions inside the clinical system. The announced rollout begins in DACH - Germany, Austria, and Switzerland - before expansion into other European countries.
For healthcare organizations and software teams, the significance is not autonomous care. It is the move from generating clinical text toward governed execution within existing hospital workflows.
From Documentation Support to Workflow Execution
The partnership’s starting point was narrower. On July 3, 2025, Corti and Dedalus announced their collaboration around ORBIS Speech Assistant. Its focus was recognizing medical speech, structuring information, and producing concise clinical documentation. Reducing workload and improving documentation were stated objectives, not independently demonstrated outcomes.
Buddy extends that direction. The launch describes early use for natural-language access to patient information and structured documentation with write-back into ORBIS. It also describes a broader vision that includes preparing orders over time. Clinicians remain responsible for confirming each step, while the vendors describe actions as validated, auditable, and traceable.
The important distinction is between three levels of assistance:
Information retrieval: Finding and organizing relevant material.
Content preparation: Producing a summary, documentation draft, or proposed change.
Workflow execution: Applying an approved change inside the clinical application.
These levels should be evaluated separately. A useful summary does not establish that an agent can safely update a record. Equally, successful documentation write-back does not demonstrate readiness for every downstream clinical workflow.
The practical opportunity is to connect these steps without removing clinical control.
What an Agent Coordinates Inside the EHR
Buddy’s architecture centers on coordinated specialist agents rather than a separate chatbot interface. Dedalus describes requests that can involve analyzing documentation, incorporating findings and medication data, consulting integrated knowledge resources, and assembling context-specific responses. Thieme and Elsevier ClinicalKey are identified as knowledge resources.
Corti’s accompanying framework announcement explains the execution infrastructure: a central orchestrator maintains context and coordinates specialist agents and connectors. The platform also provides human approval mechanisms, trace APIs for investigating failures, and evaluation tooling. These are framework capabilities, not evidence that every possible workflow is configured or deployed in Buddy.
The architectural implication is clear: the model is only one component. The surrounding software must manage how information is retrieved, which tools can run, when approval is required, and what happens after execution.
For implementation planning, teams should separate those responsibilities:
Context management: Establish the correct patient, encounter, and task.
Retrieval: Collect the information needed for the request.
Preparation: Produce an answer or proposed record change.
Authorization: Check whether the requested operation is permitted.
Confirmation and execution: Present the change for review, then apply the approved operation.
Verification: Confirm the resulting application state and preserve a trace.
This is a recommended design pattern, not a claim about Buddy’s complete internal implementation. Its value is that each stage can have its own tests, permissions, and failure handling.
Auditability Must Be an Engineering Requirement
Corti’s framework describes typed tool inputs, explicit schemas, approval pauses, isolated contexts, and replayable traces. These controls provide concrete mechanisms for governing agent behavior, beyond instructions placed in a prompt.
A hospital implementation should test how those mechanisms behave under real workflow conditions. The phrase “human in the loop” is not specific enough to serve as an acceptance criterion.
Make approval meaningful
Before permitting record changes, require the interface to show:
The patient and encounter affected.
The exact proposed change.
The supporting information needed for review.
A clear distinction between a draft, an approved action, and a completed action.
Approval should authorize a defined operation, not an open-ended sequence whose scope can change afterward.
Design for incomplete execution
Test what happens when a clinician approves a change but the receiving system times out. Require the integration to distinguish a failed request from an uncertain result, check the final state, and prevent a retry from creating a duplicate entry.
Also test interrupted sessions, changed permissions, unavailable knowledge sources, and attempts to continue work in the wrong encounter.
Make the trace useful
Require enough information to reconstruct the workflow: the request, retrieved context, proposed action, approval, tool invocation, and execution result.
The objective should be operational accountability. Reviewers need to understand what the system did and why the application changed, without relying only on the agent’s final explanation.
Measure Completed Work, Not Launch Ambition
The announced capabilities and the longer-term roadmap need a firm boundary. Dedalus describes documentation-completeness checks for coding and reimbursement as future work. Coordination of beds, staffing, capacity, and resources is also presented as an intended direction, rather than proof of established deployment.
The reviewed launch materials do not provide quantified time savings, deployment counts, independent safety evaluations, or demonstrated clinical-outcome improvements. They establish a product direction and describe early use, not a proven return on investment.
A sensible pilot should therefore begin with a bounded workflow and explicit acceptance criteria. Measure:
Total task time: Include review, corrections, and exception handling.
Completion accuracy: Check whether the intended change reached the correct location.
Review burden: Track how often clinicians edit or reject proposed work.
Failure recovery: Test whether interrupted operations can be resolved safely.
Cost per accepted task: Include processing, integration, support, and human review.
Treat clinical outcomes as a separate evaluation question. Faster documentation alone should not be used as evidence of better care.
Commercial planning should follow the same discipline. Ask for cost measurements across realistic record sizes and workflow complexity, rather than estimating operating expense from the length of the final answer.
ORBIS Buddy offers a concrete example of the next clinical AI design challenge: connecting natural-language requests to useful work inside an established EHR while preserving clinician authority. The next milestone should not be a longer list of agent capabilities. It should be evidence that bounded, auditable workflows reduce effort without weakening control.
For healthcare technology leaders, that is the more durable innovation strategy: prove the workflow, then expand its scope.
