Simplifying Integrations With Agents
Agents are changing what integrations are for. This module resets our point of view - what we keep building, what we stop building, and how we tell customers.
Welcome
Integrations have been the connective tissue of every Workday programme we have ever delivered. That does not stop being true - but the shape of the work is changing. Agents are absorbing a meaningful slice of what customers used to ask us to integrate.
This module is for the people closest to that shift. It sets out where agents legitimately remove integration need, where they do not, and how to have the honest conversation with a customer who is mid-programme and starting to wonder whether they still need what they signed for.
Learning objectives
The integration paradigm today
For twenty years we have been solving the same problem three ways. Each pattern exists for a reason. Each also carries cost the customer has learned to accept as normal.
Point-to-point
Bespoke pipes between Workday and a named downstream - payroll provider, benefits carrier, ticketing tool. Fast to deliver, expensive to own.
Scheduled batch
Nightly or hourly extracts feeding data warehouses, BI platforms and operational reports. Reliable, but always a step behind the business.
Custom middleware
An iPaaS or bespoke layer brokering between Workday and a landscape of systems. Flexible, but another platform to run, patch and pay for.
These patterns were necessary because Workday could not answer the question the downstream system needed to ask, and the downstream system could not ask Workday directly. So we moved data. A lot of data. Most of it read-only, most of it consumed by a human in another tool, most of it stale by the time it was read.
A sizeable fraction of the integrations we have built exist to get Workday data in front of a person who could not or would not log in to Workday. That premise is the one agents most directly challenge.
Where agents reduce integration need
Not every integration. Specific patterns. The common thread: the integration exists to deliver Workday information or light workflow to a human, and an agent can now do that job inside Workday's trust boundary without the pipe.
The test is simple. If the integration's real customer is a human who wants an answer, an action or a summary, an agent is a credible replacement. If the integration's customer is another system, it isn't.
Where integrations remain essential
Be clear with customers, and be clear with yourself. The following categories do not go away. They are the backbone of a running enterprise and agents are not a replacement for any of them.
Core masters of record
Worker, organisation, position, cost centre flowing to downstream systems of record. If another system needs the authoritative value to operate, you still need the integration.
Regulatory & statutory reporting
Payroll submissions, tax filings, pension and benefits providers, statutory returns. These are contracts with external bodies on defined schedules and formats. Agents do not replace them.
Finance postings
GL journals, accounts payable flows, subledger-to-ledger movement, intercompany. The books have to balance; the integration has to be deterministic and auditable.
Identity & access lifecycle
Joiner, mover, leaver events into IdP, directory, entitlement systems. Latency, completeness and auditability matter more than elegance. Keep the pipe.
High-volume transactional flows
Time, absence, expense and payroll transactions between Workday and operational systems at scale. Agents do not move millions of rows - integrations do.
Inbound systems of record
Recruitment applicant flows, learning completions, external HRIS sources during M&A. If Workday needs the authoritative record, you need the inbound integration.
When in doubt, ask: is the customer of this integration a human, or another system? Human → agent is in scope. System → integration stays.
How to re-scope a live SOW or pipeline
The uncomfortable reality is that some of what is in our SOWs today should not be delivered as written. It is better we raise that than a customer steering committee does three months in. Use a simple three-column frame.
Drop
Read-only integrations to portals and intranets; bespoke BI extracts with low-frequency consumption; HR-ticket bridges into ITSM; "manager dashboard" pipelines; chat-bot knowledge pipes. Replace with the equivalent agent.
Keep
Payroll, finance postings, identity lifecycle, regulatory feeds, high-volume transactional flows, inbound systems of record. Deliver to the standard the customer originally bought.
Add
Managed agent enablement: configuration, guardrails, adoption, measurement. If we are removing an integration because an agent now does the job, we are accountable for the agent landing well.
A worked example - HR service-desk integration
Original scope: bi-directional integration between Workday and the customer's ITSM tool so HR tickets could be triaged, routed and resolved outside Workday. 40 days of integration build, 20 days of run.
Re-scoped: deploy the Case agent inside Workday to triage and resolve tier-1. Retain a minimal outbound integration for the residual tickets that genuinely belong to the ITSM team (tier-2+ and cross-function). Add 15 days of managed adoption to land the agent with HR operations, measure deflection, and refine response templates.
Net: the customer spends roughly the same money, solves the same problem better, and ends with less integration estate to run next year. We spend ours on adoption, which is where the outcome actually lives.
The customer conversation
Picture a customer twelve weeks into an integration programme. Their CIO has just been to a Workday event. They come back and ask the awkward question: "Do we still need half of what we're building?"
Answer honestly. The worst outcome is that we deliver scope we quietly knew was no longer needed, and they discover it six months later. That damages the relationship for a decade.
How the conversation goes
- Acknowledge the shift. Yes, agents change the picture. Do not pretend otherwise.
- Separate the portfolio. Walk the customer through their current integration list and mark each one: human-consumer (candidate to drop or replace), system-consumer (stays).
- Offer a re-scope, not a re-sell. Bring a concrete drop / keep / add to the next steering committee. Do not open up the SOW without one.
- Be clear on value, not just cost. This is not a discount conversation. It is a better-outcome conversation. Adoption is the deliverable; integrations are a means.
- Hold the line on what stays. Regulatory and finance flows are not candidates for debate. Say so.
Customers who want to use "agents replace integrations" as a cost-saving narrative without the adoption investment. That ends with an agent nobody uses and an integration they turned off too early. Our job is to make sure both halves of the trade are done properly.
Commercial implications for Kainos
Let's be direct. Fewer bespoke integrations sounds like a smaller services pie. It isn't. It is a different pie, and the slice we should be eating is larger, not smaller - if we move our centre of gravity.
What reduces
Build-and-run days on the integration patterns agents absorb - portal feeds, light BI extracts, ticket bridges, chat-bot data pipes. Expect this line to soften over the next 18-24 months.
What grows
Agent enablement, configuration and adaptation. Change management and adoption. Data-readiness work so agents can ground well. Managed services around the agents we have helped land.
What stays
The essential integrations. Core tenant deployments. Flex-credit architecture conversations. The bespoke build work where Use and Adapt don't fit and Build genuinely does.
What we should say
Internally: this is a shift in shape, not volume. Externally: Kainos reduces what you don't need and is accountable for landing what you do. That is a better story than "we'll integrate anything."
This is what Use, Adapt, or Build looks like in the integrations lane. Use the agent when it covers the job. Adapt configuration and adoption around it. Build the integration where the job is system-to-system, regulated, or transactional at scale. The Kainos AI Navigator is our way of making that call consistently.
Check your understanding
Three questions. Each explains why every answer is right or wrong - the reasoning matters more than the score.
Next steps
- Architects: Module 5 - Flex credits & AI architecture. Agents and integrations sit inside the same architecture conversation; do not have one without the other.
- Customer-facing & delivery: Module 8 - Adoption playbook. If we are removing an integration because an agent does the job, adoption is the deliverable that makes it true.
- Integrations consultants: Module 11 - When to build. The sharper your Use / Adapt / Build instinct, the better your re-scope conversations.