Somewhere in your IT estate tonight, a workload will run that is older than some of the engineers maintaining it. It may close the books, move inventory, trigger replenishment, process settlements or feed a dashboard before the business day starts. It’s survived multiple technology waves because it works. It does what the business needs it to do.
Somewhere else, maybe in the same chain, an AWS Lambda function will fire, or an Azure Data Factory job will transform data. A container task will run. A data platform will load the result into a report that someone depends on tomorrow morning.
Nothing about that combination is unusual anymore. The systems that have carried your business for years now run alongside cloud services built for a different era of speed and scale. Neither is inherently fragile, but the connections between them often become costly points of failure as integration and workflow complexity grow.
No one gets to modernize in a vacuum
Your modernization program is already changing the shape of the business. Applications and workloads are moving to the cloud. SaaS platforms are expanding across functions. Data pipelines are being rebuilt for speed, scale and AI readiness. But modernization doesn’t arrive as a clean cutover. You prioritize the areas with the clearest business value first, while the systems that already run the business keep running.
That is what makes hybrid cloud environments difficult. You’re not replacing one world with another. You’re running decades of technology at the same time across cloud services, enterprise applications, data platforms, on-premises infrastructure and private cloud environments. Every new wave has to connect to what came before it.
Ask anyone who has run a postmortem on a cross-environment failure, and they’ll recognize the typical way this shows up: a legacy batch process completed, an AWS service did what it was supposed to do and both teams have logs that prove their side behaved correctly. Yet, the business process still broke. All the evidence stops at the edge of each system.
That also means the failure lives in a place that doesn’t cleanly belong to anyone. The script holding together the on-prem side and the cloud side may have been written three years ago and never put under version control. It’s both load-bearing and invisible.
Over time, taking the shortest path available on any given day allows your hybrid estate to grow both systems and handoffs simultaneously. You already know what this costs because you’ve probably lived the 2 AM version, when someone is trying to remember who knows what a particular script was supposed to do.
“The job ran” and “the business got what it needed” have never been the same claim, but tooling fragmentation forced you to treat them as if they were. Cloud migration may change where the work runs, but it doesn’t automatically change how it’s coordinated.
The economics of old habits
Cloud changed the cost model faster than most operating models could follow.
In the data center, a lot of habits were rational. Fixed schedules gave you predictability, and extra capacity reduced risk. A server left running overnight didn’t create a new hourly charge, and polling every five minutes was cheap enough to ignore. Move those same patterns into a metered cloud environment, and you’re paying for 20 hours of polling rather than the four hours of true work. For readiness rather than action.
That isn’t getting better on its own. Flexera found that wasted cloud spend rose to 29% in 2026, the first increase in five years. That tracks with the arrival of AI workloads, according to the study.
But cloud cost conversations often get stuck. FinOps can point to all the candidates for waste, and the list is rarely a surprise:
Instances that run long after the workload ends
Environments sized for old peak assumptions
File watchers and polling jobs that could be event-driven
Scripts that exist only to bridge one system to another
Batch hosts no one wants to shut down
The hardest part is proving what happens if you change any of them. You can’t safely stop an instance, retire a script or replace a polling loop if you don’t know which business processes depend on it.
In one recent conversation I had with a senior engineer at a large enterprise assembled through several acquisitions, they described it like this: “Jenkins here, Cron there, an Azure Automation instance nobody fully owns, SAP schedulers running in parallel, Step Functions and Airflow layered in as our data pipelines grew. Each tool has its own team, its own visibility and its own blind spot at the edge. Rather than creating a new version of this problem, AI is raising the cost of the one that’s already there.”
Run a simple version of the math against your own environment.
If you have 500 Amazon EC2 instances averaging $400 per month, and even 20% exist mainly to host, wait for or watch batch work, that’s roughly $480,000 per year before storage, transfer, snapshots or operational overhead. Idle time isn’t theoretical when the meter is always running.
This isn’t just theoretical. We see Redwood Software customers cutting these costs every day.
A global CPG company consolidating decades of manual document processing onto a single orchestration layer and cut document-processing costs by 98%
A large, regulated enterprise bridging legacy batch infrastructure with its cloud environment, removing 59% of peak runtime and 25% of average runtime from its estate without missing a single billing window
Both have hybrid environments where the fix was to govern the handoffs between what already existed, not to engage in another migration.
The way out is not simply to squeeze every workload harder. It’s to change how work starts, waits and stops, and that means solving orchestration tooling sprawl instead of compressing individual runtimes.
Not just another migration
The pain usually shows up when you realize you have many places to schedule work, but no single place to understand the full process. Your instinct could be to just migrate again. Move to a new tool, consolidate, rehost, standardize. And those steps could be necessary, but another migration won’t automatically rebuild the connective layer between systems. If your measure of success is whether every job runs the same way somewhere else, you may have improved the platform while preserving the operating model that created the problem.
Better questions are outcome-based:
Which polling loops can you retire?
Which always-on hosts can start and stop around real workload demand?
Which manual handoffs can become governed workflows?
Which scripts can be replaced instead of recreated?
Which failures can now surface before the business notices?
Which business processes can be monitored end to end, not system by system?
A modern orchestration layer doesn’t ask cloud services, enterprise applications, data platforms and on-premises systems to behave as if they were one technology stack. It gives you one place to coordinate the work between them. The older process can stay. The newer cloud service can stay. But the handoff becomes visible, governed and auditable, with role-based access for who can touch it, an immutable trail of what ran and why and an SLA that predicts a chain trending late while there’s still time to act on it.
That matters now for cost and reliability. And it will matter even more as AI continues to move from pilots to everyday use.
Agents decide, but something else has to execute
The line between cloud modernization and AI readiness is getting thinner and thinner. Most enterprises aren’t building models from scratch. They’re layering agents onto cloud services, managed models and AI-enabled applications and asking those agents to do more than answer questions. Increasingly, they need to trigger workflows, remediate failures and escalate approvals.
But an agent that decides isn’t the same thing as work that gets done. A recommendation to release an order, correct a billing run or kick off a fulfillment path still has to travel through the same deterministic, auditable execution layer as everything else in your hybrid estate.
That’s the part almost nobody has built well, and it’s the same problem as the cost story above, not a separate one. If a handoff is invisible to IT Ops today, it doesn’t become safe or governed just because an AI agent is the one initiating it. The value doesn’t come from the AI alone, but from the blend of judgment and execution and the space between them is where the real work is.
Make decades of tech governable
As you know, forcing every new service into one architectural pattern simply won’t work. The systems running your business have earned their place, and the newer services you’re adopting are there for good reasons: speed, scale, elasticity, AI readiness. You can’t operate in such complexity on trust alone.
Cost is often the first place this becomes visible. Handoffs that were once absorbed as operational noise now show up as workloads you can’t safely optimize, instances you can’t confidently stop, scripts you can’t retire and business processes whose true cost you can’t explain. The more your hybrid estate grows, the more expensive those unknowns become.
More running in the cloud doesn’t mean more modern. What truly supports modernization in the long run is having a modern application and data workflow orchestration platform. It must deliver a governed operating model for each new service, pipeline or AI-enabled workflow to inherit — the same role-based access, audit trail and SLA visibility, applied consistently instead of rebuilt per tool.
Redwood brings old and new together under one orchestration layer. See how you could bemanaging hybrid cloud workflowsacross cloud services, enterprise applications, data platforms and on-prem systems with end-to-end visibility and control.
An interview with Andrew Raynes, former Chief Information Officer, Royal Papworth Hospital NHS Foundation Trust and a globally recognised leader in healthcare transformation and digital innovation.
Automation has become a strategic priority across the NHS, yet many organisations still approach it as an IT project or a collection of point solutions. Through our work with more than 70 NHS organisations, we’ve seen that the greatest value comes when automation is treated as an organisational transformation— redesigning end-to-end processes to enable better ways of working.
To explore what successful transformation looks like in practice, we spoke with Andrew Raynes, former Chief Information Officer at Royal Papworth Hospital NHS Foundation Trust. With more than 25 years’ experience in healthcare and the public sector, Andy shares why successful automation depends as much on people, processes and culture as it does on technology—and what NHS leaders need to do to unlock its full potential.
Q&A with Andrew Raynes
Q: Why do many NHS organisations approach automation as an IT deployment rather than a transformation programme?
Andy: There is something about making an improvement through automation/tech but not understanding that difference it will make to sufficiently adapt let alone exploit it. In some organisations, digital is still seen as a cost centre rather than an enabler of change.
For me, successful transformation is about people, processes and technology working together. You can purchase automation software but implementing it at scale fundamentally changes business processes and often the roles of the people involved. That’s where the real challenge – and opportunity – begins.
Automation isn’t simply replacing repetitive tasks. It’s redesigning end-to-end processes, understanding how work changes, bringing people along on that journey, and ensuring technology enables staff to focus on more valuable and meaningful work.
Ultimately, project leaders need to think about all three elements—people, process and technology—and understand how each will be affected by the transformation.
Q: Where do end-to-end automation programmes typically break down?
Andy: There are three common failure points.
First, organisations don’t always have a clear vision of the future state. Without understanding where you’re trying to get to, it’s difficult to design the journey. That’s why defining both the current (“as-is”) and future (“to-be”) processes is so important.
Second is change management. Communication, education and empathy are essential. People need to understand why change is happening, what it means for them, and how they’ll be supported. If you fail to take people with you, the disconnect begins long before technology is implemented.
The third challenge is technology reliability. Even after months of preparation, if the technology fails on day one, confidence disappears almost instantly. Thorough testing and ensuring the solution works from the outset are critical to maintaining trust across the organisation.
Q: How do you see the role of the CIO evolving as organisations embrace automation and AI?
Andy: Increasingly, the CIO’s role is about enabling others to lead change rather than leading every initiative directly.
The people closest to clinical or operational work are often the strongest advocates for new technology because they understand both the challenges and the opportunities. Their peer-to-peer influence is incredibly powerful.
In healthcare, I often describe successful transformation as clinically led, operationally delivered and digitally enabled. Digital provides the tools and expertise, but lasting transformation happens when the business owns the change.
But it is not only the CIO’s role that is evolving. Everyone involved in these new ways of working will need to adapt and take on new roles and responsibilities. Leading this transition effectively—and providing the right support to help people develop new skills and adapt to change—is essential to bringing the wider organisation with you.
Q: How should healthcare organisations be measuring the impact of automation?
Andy: Start by being realistic.
Business cases often assume optimistic benefits, but in reality, outcomes rarely achieve the absolute maximum expected. Setting achievable goals makes success more meaningful and creates opportunities to exceed expectations.
Equally important is shared ownership. Benefits shouldn’t sit solely with digital or transformation teams—they need to be jointly owned by operational leaders and those responsible for delivering the change.
I also think we should move beyond simply talking about benefits and instead focus on value. Value considers both what you’ve invested and what you’ve achieved. Sometimes a lower-cost project delivering 80% of the expected benefits creates more value than an expensive programme delivering only 40%.
Understanding your baseline before the project begins is equally essential. Without knowing your starting point, it’s impossible to accurately measure improvement afterwards.
Q: How can organisations balance patient perspectives with staff experience when redesigning care pathways?
Andy: The answer is inclusion.
Recently, at Royal Papworth, we invited a patient representative into one of our process modelling workshops alongside our clinical administration team. It gave us an entirely different perspective.
Patients ask questions that professionals often don’t think to ask. Seeing the process “under the bonnet” helped them understand the complexity while also highlighting pain points, we’d become accustomed to.
The workshop led directly to practical improvements. For example, changes to telephone routing reduced call waiting by 39% for one clinic.
User groups—whether patients or staff—are incredibly valuable, but only if organisations act on the feedback. Listening is only the first step. Building confidence comes from showing people that their input leads to meaningful change.
Q: What excites you most about AI and intelligent automation in healthcare?
Andy: What motivates me most is seeing technology genuinely make a difference.
There’s nothing more rewarding than hearing someone say, “That really improved how we work” or “That made care better for our patients.”
AI and automation have enormous potential to help an increasingly stretched healthcare workforce by removing administrative burden and allowing skilled professionals to spend more time doing the work that only humans can do.
But alongside that opportunity comes responsibility.
Concerns around data protection and cybersecurity are valid, and open discussion is essential if we are to continue developing proactive safeguards against these risks. As AI adoption grows, we also need to think carefully about ethics, sustainability and environmental impact.
The computational power behind AI is significant, and we all have a responsibility to ensure these technologies are used thoughtfully and for the greatest possible benefit.
The future is incredibly exciting—but it must also be responsible.
Final thoughts
Andrew’s message is clear: the technology is rarely the limiting factor. Organisations achieve the greatest value when leaders create a clear vision, redesign processes, and bring people with them through change.
Luckily, no organisation must navigate transformation alone. Learning from peers can help avoid common pitfalls, accelerate delivery and realise greater value.
Join our free NHS peer community, created exclusively for NHS professionals and partners to explore real-world case studies, practical lessons and proven approaches from organisations delivering automation and transformation at scale.
Other resources:
A research study by Veera Häkkinen (Digital Workforce Healthcare Solution Consultant) about the new roles and responsibilities healthcare professionals are taking on as AI is integrated into care processes. The study explores these roles in the context of the EU AI Act and its requirements and compares different levels of human oversight through practical scenarios: https://trepo.tuni.fi/handle/10024/236238
A case study in transforming breast cancer follow-up at Helsinki University Hospital—sharing measured outcomes and exploring when to use algorithmic automation versus AI for maximum impact and secure control: https://digitalworkforce.com/rpa-news/hus-care-pathway-automation/
None of it is difficult. Somebody has to do all of it.
It is Monday morning. One of your suppliers has sent an email. From next month, the prices they charge you go up by 4.8%, across everything you buy from them.
Nothing about that email is unusual. A supplier has asked for more money for the same goods, and you get some version of it most weeks, from some supplier, in some category. It is not a crisis, nobody escalates it, and it will be handled.
Watch what has to happen before it is.
A supplier asks for a 4.8% price increase
Somebody has to:
Find the contract
Read the indexation clause
Check the correct index
Calculate the increase the contract actually permits
Decide whether to challenge it
Talk to the supplier
Update the agreed price
Make sure future orders use the new one
Weeks later, check that the invoices follow it
Any competent person in your team can do any one of these nine steps. The problem is that somebody has to do all of them, in order, for this supplier, this month.
And this is one email, one supplier, one price change.
Now multiply that by the thousands of suppliers and contracts you are responsible for, and by every purchase, commercial change and exception that arrives across a year.
Nobody in your organisation has ever seen that total, because no system holds a line called hours spent finding things. Your ERP records the order and your contract system records the clause, but neither of them records the forty minutes somebody spent working out which clause applied. So the work stays expensive and invisible at the same time, spread across hundreds of people who each experience it as a small annoyance.
Small annoyances do not get put on a board slide. They get absorbed, which is a polite word for paid for.
Those nine steps happen in six different places
Look at where that work actually took place.
The email arrived in an inbox
The terms were in the contract system
The index was published on somebody else’s website
The agreed price lives in the procurement system
The order and the invoice sit in the ERP
The approval ran through a chain of people, each of whom had to be asked, reminded and asked again
Nobody designed the work that way. Each of those systems was bought by a different function, on a different cycle and against a different set of requirements. Every one of them is good at what it does. Every one of them was a sensible purchase at the time.
What nobody bought was the thing that carries a case from one system to the next. That job went to a person by default, and it has stayed with a person ever since. It is the subject of the last article in this series.
Six systems, five handovers, one person. Each system was bought by a different function against different requirements, and each one is good inside its own edges. The gaps between them were never anybody’s purchase, so a person stands in each one, five times, for every price change that arrives.
You get the same equation every year
You are asked to deliver more value, hold more control and carry more risk, and to do all of it with fewer resources.
If you have worked in procurement or in finance for longer time, you have been handed some version of that every single year. Save more. Control more. Carry more risk, because there is always more risk. Do it with the same team, or with a smaller one.
The risk part is growing fastest in the work. The list of things you are expected to know about a supplier now runs to ownership, sanctions exposure, financial health, certifications, sub-tier dependencies, sustainability and cyber posture. Every one of those requirements arrived with a good reason attached, but none of them arrived with extra people attached.
The brief, drawn as the equation it is. Three terms on top, all of them growing, over a denominator that keeps shrinking. Eighty-six percent of chief procurement officers meet the savings target on the top line. What this series is about is everything the equation leaves no time for.
Here is the part that makes it interesting.
You are meeting the target. Deloitte’s 2025 survey of more than 250 chief procurement officers across 40 countries found that 86% of them met their cost savings targets.
So this is not a story about a function that fails at what it measures. You hit the number you negotiated. You can evidence it. The awkward question is a different one: what happened to everything you never got to?
The constraint is human attention
Your software is fine.
Your process design is fine and your team is good. I have spent a long time inside these functions, and the people in them are rarely the problem.
There is a finite amount of expert attention in your function every week. It is the scarcest resource you have and the most expensive one you buy. The work in front of you asks for more of it than exists.
That is the constraint. Budget, headcount and tooling all sit downstream of it.
Once you name it, a number of things stop being mysterious. Why savings you genuinely negotiated leak away quietly over the following two years. Why the supplier you screened at onboarding is still on the approved list three years later, under different ownership. Why a contract renewed on terms nobody had re-read.
None of that is negligence. It is arithmetic. Every one of those tasks was somebody’s job, and that somebody had a finite week.
You prioritise, you sample, you react
So what does a function do when the work exceeds the attention available to do it?
It does the only rational thing. It prioritises, samples, and reacts.
It puts expert attention on the biggest contracts and the loudest problems. It checks part of the population and assumes the rest behaves the same way. And it waits for something to surface before it goes looking.
Every one of those is a good decision. I would make the same three. Given fixed attention and unbounded work, that is what a competent leader does, and anyone who tells you otherwise has not run a category.
You can watch it happen in the way an approved supplier list ages. Everyone on that list was checked properly on the day they were added, by someone doing a careful job. That check was a photograph of a single afternoon. Since then:
Ownership has changed
Certificates have lapsed
A parent company has been bought by somebody you would not have approved
Nobody decided to stop looking. There was never a week when re-checking a supplier who had caused no trouble was the best use of the time.
But look at what each one costs.
Prioritising means most of your spend receives no expert attention at all. It is not that it was reviewed and cleared. Nobody looked.
Sampling means you judge the health of a whole population from a fraction of it, then report that judgement as though you had checked everything.
Reacting means you find the problem after it has happened, and after it has cost you something.
This is your operating model. It is a good design for the shortage it was built around.
Count the two piles and price the bigger one
Go back to those nine steps and sort them into two piles. Eight of them are retrieval and checking: finding, reading, calculating, transferring, remembering and monitoring. One of them is a decision, which is whether you accept this increase, challenge it or negotiate.
Eight steps of retrieval, one step of judgement. The list above runs in order, which is how the work feels when you are doing it. Sorted into piles it stops being a sequence and becomes a ratio. The eight are drawn the same size because none is harder than another, and none of them is why you recruited the person doing them.
That single question needs judgement, commercial instinct and a relationship with the supplier. It is the part your people are good at and never have enough time for.
You can run this on one process this week. It takes an afternoon and needs no budget. Pick something ordinary, such as a price increase, a supplier onboarding or a contract renewal. Choose one that happens often and that nobody in the room considers difficult.
Then three moves.
Count the retrieval steps. Count every action that involves finding, reading, checking, calculating, transferring or chasing. Be honest about the ones that happen in somebody’s head or in a spreadsheet nobody owns.
Count the steps that need judgement. These are the moments where a person weighs something and decides. In most processes there are far fewer of them than people expect. Naming them out loud is uncomfortable.
Price the first pile. Loaded hourly cost of the people doing it, multiplied by the time it takes, multiplied by how often the process runs in a year.
That last number is what your organisation currently pays for retrieval on one process. It is usually the first time anybody has seen it as a single figure, and usually larger than the room expects.
Two things tend to happen when a team does this properly.
The retrieval pile is longer than anyone guessed. The steps that live in somebody’s head never appear on a process map, so nobody counts them.
The judgement pile contains steps that need no judgement. What they need is a rule an experienced person has applied for years without ever writing it down.
Then ask the only question that really matters about the list. Which of those steps genuinely required a person?
Only one kind of work needs you
When a team answers that question honestly, the list stops being a sequence and starts being four different kinds of work. They are not interchangeable, and each of them has a different answer.
Judgement. Accept, challenge or negotiate. This needs commercial instinct and a relationship with the supplier. It belongs to a person who is accountable for the category. It should stay exactly where it is.
Reading and reasoning. Retrieving the contract, interpreting an indexation clause a lawyer wrote four years ago, checking the published index and assembling the evidence behind a recommendation. This used to require a person for one reason only, which is that reading was human work. AI agents now do this part reliably enough to run it on every case instead of a sample.
Execution in your systems of record. Updating the agreed price, pushing it into future orders, checking that the invoices follow it. This is integration and automation, and most large organisations already own most of the pieces.
Sequencing and evidence. Something has to carry a case across those six systems, decide what happens when a step fails, route the exception to the right person, and keep a durable record of who decided what and on what basis. This is orchestration. Almost nobody owns it.
Only the first row needs a person. The other three were human work because reading, executing and sequencing had nowhere else to live. Judgement is different in kind. It needs commercial instinct and a relationship with the supplier, so it should stay exactly where it sits today.
That last one is where the interesting failure lives. The email arrived at the front of your business, inside a supplier relationship that a named person owns. The consequence landed at the back, as a purchase order, an invoice and a payment in your finance systems. Those nine steps crossed the line between your front office and your back office four times. Each time, a person picked something up and carried it.
Most large organisations have automated pieces on both sides of that line. Very few own the crossing itself, which is where the time goes and where the errors surface.
None of this comes for free. Agents that read contracts have to be governed. They have to be monitored, corrected when they drift, tested against the decisions your best people actually make, and answerable when somebody asks why a recommendation came out the way it did. Capacity you cannot govern is not capacity. It is exposure, and you already have enough of that.
That is the work my colleagues and I do at Digital Workforce. People, AI agents and automation running as one governed flow across the systems a business already owns, from the front office through to the back. We operate it, so somebody is accountable on the day it drifts.
Where does your team spend its attention this week?
Next Monday, that supplier email arrives again. Someone will handle it well. It will take most of a morning.
The pressure your function is under has not changed much in forty years. What has changed, quite recently, is what it costs to pay attention to something, and that is what the rest of this series is about.
The next piece asks an uncomfortable question. Procurement has bought wave after wave of technology since the 1980s, and every one of those waves was worth buying. I would buy all of them again. So why is that same equation still sitting on your desk?
Before then, here is one question to take back to your team. Of all the expert attention your function will spend this week, how much of it will land on an actual decision?
If you want to take it further
On 30 September I am joining Brian Halpin of SS&C Blue Prism for a session on this, starting from a supplier price increase.
If you have run the count on one of your own processes, bring it. The discussion is usually more useful than the slides.
Deloitte’s 2025 Global Chief Procurement Officer Survey establishes that 86% of CPOs met their cost savings targets. The survey covers more than 250 CPOs across 40 countries, and the figure is self-reported. deloitte.com
The 4.8% price increase, the nine steps and the six systems are an illustrative example drawn from a common procurement scenario. They are not a customer figure and not a benchmark.
About the author
Stefan Meller is Principal Account Executive for Enterprise and Public at Digital Workforce.
Ask any automation team where their time goes, and you’re unlikely to get a simple answer. Waiting on a specialist to turn a business process into a working workflow, investigating stopped jobs, trying to figure out why it broke in the first place, answering the same how-to question they answered last week and writing documentation that was meant to be done three sprints ago. Those are just a few you might hear.
We’re talking the automation lifecycle: design, build, document, run, monitor. At every stage, a person has to translate, investigate, explain or configure something before the work can move again. Multiply that by 30 to 50 requests a week, and the backlog can easily grow beyond a manageable level.
AI changes this. Not in a vague “AI will transform everything” way, but in a specific, measurable, this-quarter way.
The AI capabilities inside RunMyJobs by Redwood are designed to enhance the complex automation lifecycle and eliminate productivity leaks: building workflows, handling exceptions, finding answers, writing documentation and more.
Workflow Builder: Describe it, upload it, done
Until now, turning a business process into an automated workflow meant translation. Someone who understands the process had to explain it to someone who understands the platform, usually across several meetings, a ticket and delays. RunMyJobs’ Workflow Builder removes the translation steps entirely.
You have two ways in, and neither requires you to write a line of code.
Prompt it. Type what you want in plain English. “Every night at 11, pull the sales extracts from SAP, validate the file counts, load them into the warehouse and alert the data team if anything fails.” That’s a workflow description, and it’s enough to get started.
It’s not a one-shot prompt machine, either. It’s more of a conversation. Look at what comes back and refine it, add a step, change a schedule, ask it to handle a failure case differently. You shape the workflow the way you’d brief a colleague, iterating until it matches what’s in your head.
Upload a document. This is the one that changes daily life for most teams. Drop in whatever already describes the process, such as a standard operating procedure (SOP), a process description or a runbook. The AI reads it and works out the steps involved in the automation.
Think about what that means. Your organization has years of process knowledge sitting in documents that describe exactly how work should flow. That knowledge used to be inert, but now it can serve as an input. The policy document becomes the workflow.
What happens under the hood matters more than the demo
Plenty of tools can turn a sentence into a flowchart. What makes Workflow Builder useful in a real enterprise is that it builds from your actual environment.
An intent agent parses your description or document and matches it against the real objects you already run: your jobs, your connectors, your partitions, your schedulers. It constructs the job chain and resolves the parameters from what genuinely exists. If it needs something that isn’t there, it doesn’t invent it. Instead, it flags the gap and shows you the closest match. Anything it can’t resolve gets marked as requiring your input.
And here’s the part your IT leadership will care about most: nothing gets created until a human explicitly approves it. The AI drafts, but you decide. Business users get the power to build, and IT keeps the oversight it needs. Best of all, nobody deploys a hallucination to production.
You’re going from policy to production in minutes. The intake queue doesn’t disappear, but it stops being the constraint. And the metric this moves is one your leadership already tracks: time-to-value. How long between someone deciding a process should exist and that process running in production? Today, that’s weeks of tickets and meetings. This makes it a same-day conversation.
Agent Studio: Human-in-the-loop to agent-in-the-loop
Building workflows faster clears the build queue. But the exception queue is still there, and it’s where Agent Studio comes in. Workflow Builder speeds up how workflows are built, and Agent Studio changes what runs inside them.
Even a well-automated workflow has moments that need judgment. A mismatch, an exception, an anomaly. Today, those moments all resolve the same way: the workflow stops, a human gets notified and the work sits in a queue until someone finds time to investigate. The automation itself is fast, but the exception handling is exactly as slow as your busiest person.
That’s the human-in-the-loop model, and for consequential decisions, it’s still the right one. But most of what the human does in that loop isn’t deciding; it’s the pre-work. Pulling the data, tracing where things diverged, figuring out whether this is the usual thing or something new. It’s skilled detective work, and it gets repeated from scratch, every time.
With Agent Studio in RunMyJobs, you build your own AI agents and put them into that loop instead. A custom agent runs as a step inside the workflow, doing the work a human would otherwise have to do before anyone even looks at the problem:
At a minimum, the agent does the analysis. When an exception fires, the agent investigates immediately, in the flow, and hands the human a worked-up case instead of a bare alert. The human still decides, but the hour of digging is already done.
At best, the agent decides, too. For patterns it recognizes, it resolves the exception itself, with a full audit trail, and only escalates the genuinely novel cases.
Judgment doesn’t disappear from the process, but it stops being the bottleneck.
Because these agents run as workflow steps, they inherit everything the workflow already has: the same schedule, the same governance and the same observability, with timeout and cost controls built in. You define the agent’s skills, connect its tools and run it on your preferred AI platform. Your deterministic process keeps running at full speed. The agent handles the moments in between.
The math is simple.
Exceptions get a first pass in seconds instead of hours
Fewer of them ever reach a human
The ones that do arrive with the investigation attached
Watch two numbers in particular: 1) mean time-to-resolution (MTTR), because the investigation now starts the second the exception fires, and 2) SLA attainment, because workflows stop sitting overnight waiting for a human’s first pass.
Product Assistant and Automation Co-pilot: Closing the last two leaks
So, workflows are being built faster, and exceptions are being handled in the flow. That leaves the question queue and the documentation debt, which is where Redwood RangerAI, the AI assistant layer inside RunMyJobs, steps in.
Redwood RangerAI ProductAssistant kills the search-and-escalate cycle. Every automation team has one or two senior people who hold the platform knowledge, and everyone else queues for their attention or digs through documentation that’s a version or two out of date.
Product Assistant effectively puts a senior platform expert in the UI at all times. Junior operators ask questions in plain English and get instant, context-aware guidance for troubleshooting and how-to questions.
The KPI? Time-to-productivity. When every operator has an expert on tap, new hires ramp in days instead of months, and escalation volume drops with them.
Automation Co-pilot takes on the two biggest killers of development velocity: scripting overhead and documentation debt. Developers describe what they need in plain language, and the Co-pilot generates the job scripts. It operates the platform through conversational commands and produces comprehensive technical documentation for any job or workflow in a single click, which means the documentation actually gets written. Anyone who has inherited an undocumented automation estate knows precisely what that’s worth.
Two numbers move here: delivery throughput, because weeks of scripting and documentation compress into hours, and key-person risk, because the knowledge stays with the organization, whether or not the person who built it does.
What you get back
Look at where a typical automation team’s week typically goes: waiting for a specialist to translate a request, answering the same how-to questions, writing scripts that follow well-worn patterns, investigating exceptions that turn out to be the usual thing. And documentation — or, more honestly, feeling guilty not having written it.
The AI capabilities in RunMyJobs take a bite out of every one of those:
Business analysts turn a process description or an SOP into a reviewable workflow draft in minutes, no ticket required
Custom agents do the exception pre-work in the flow, so humans decide instead of dig
Operators get answers in the moment, without escalating or searching
Developers build with prompts and clear the backlog instead of feeding it
Documentation happens in one click instead of never
The compound effect is the real story, and the number that matters most is capacity. Real operational efficiency looks like the same headcount, more delivered, because hours that once went into waiting, digging and re-explaining convert into work that ships. Junior staff start operating like senior staff. Senior staff stop being a bottleneck and start doing the work you hired them to do. The automation backlog — the one every enterprise has and nobody talks about — finally starts shrinking.
None of this removes people from the picture. It removes the queue between people and outcomes. Your team still decides what gets automated and approves what goes live. They just stop paying a translation tax on every single request.
Where you could be headed: Agentic orchestration
This is really about what happens once AI agents stop being a side project and start running inside your production workflows, governed the same way everything else is. If that’s the direction you’re already heading, take a look at how Redwood Software approaches agentic orchestration, making everything above safe to run at scale.
