What the companies announced
Workday’s 13 October release describes Sana and Claude exchanging tasks through the Model Context Protocol, retaining Workday permissions and audit controls. Its availability section distinguishes an early-access Sana-in-Claude plugin, expected generally in late 2026, from Agent-Ready Tools available through Workday Extend AI.[1]
A separate Workday overview describes administrator controls for registered agents, permissions and action tracing. It also cautions that some capabilities are in early access. These are vendor descriptions, not findings from a Kooya deployment; each customer should verify the features enabled in its own environment.[2]
Kooya analysis: test the boundary between advice and action
A useful pilot should separate reading a record, recommending a change, preparing that change and committing it. These are four different permissions. An assistant that can explain an invoice exception should not automatically be entitled to approve payment. A demonstration should show the transition between stages, including what the person sees before confirming an action.
Build a small test set around ordinary mistakes. Ask for a change to the wrong employee, a request outside the user’s role, and an action that was already submitted. The expected response should be written before the test begins. This avoids treating every plausible answer as success and gives the procurement team concrete evidence about the workflow rather than general confidence in the model.
Kooya analysis: identity must survive a long workflow
A workflow may remain open while a person changes role or loses access. Buyers should ask when permission is checked: when the conversation starts, when information is retrieved or when the final action occurs. A cached answer and a live system change require different treatment. The responsible product owner should be able to explain that distinction without relying on the phrase enterprise security.
Test the same task with two roles and compare both the visible information and the permitted actions. Then revoke access during a test workflow and attempt to continue. This is a suggested acceptance test, not an allegation about the announced integration. Its purpose is to establish how the configured customer environment behaves before sensitive HR or finance work depends on it.
Use our AI agent development partner guide to develop the next set of practical questions.
Kooya analysis: require a readable action record
When something goes wrong, an administrator needs more than a transcript of the conversation. Ask for a record showing the requested operation, the relevant business object, the acting identity, the confirmation and the final system result. If a model proposes one change but the application executes another, the difference must be visible to the person investigating.
The pilot should also cover recovery. A cancelled request should stay cancelled; a timed-out action should not be repeated blindly. Establish how the system identifies an operation already completed and how a person can correct a mistaken update. Teams should practise these cases with synthetic records so that a successful demonstration does not depend on exposing real employee or supplier information.
A practical decision for Philippine enterprise teams
Begin with a narrow, reversible workflow whose owner already understands the source system. Establish the current completion time, error rate and review effort before introducing the assistant. Measure the same end-to-end task afterward, including exceptions. A reduction in typing is useful, but it does not by itself establish that a financial or personnel process has improved.
Finally, compare the commercial proposal with the release status and implementation plan. Record what is available today, what requires early access and what remains a roadmap statement. Ask who configures the integration, handles support and owns a failed action. This announcement is a reason to evaluate a governed workflow carefully, not a reason to bypass procurement checks.