Bridging the decades: 50 years of enterprise technology, one orchestration layer and costs you can finally act on

Article

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.”

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 be managing hybrid cloud workflows across cloud services, enterprise applications, data platforms and on-prem systems with end-to-end visibility and control.

Design, build, run: AI for the full automation lifecycle

Article

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.

1. 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.

2. 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.

1. Redwood RangerAI Product Assistant 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.

2. 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. 

When somebody’s cron job is your AWS orchestration strategy

Article

Somewhere in your organization, there is a script. It runs on a cron schedule on an EC2 instance nobody remembers provisioning. It checks an SAP system every five minutes to see whether a job has finished, and when it has, it calls an AWS API to kick off whatever comes next. A contractor wrote it two years ago. It has never been in version control, nobody has reviewed it since and it breaks every time an upstream format changes.

That script exists because of a problem almost every enterprise running AWS has. It sits between the AWS boundary and everything on the other side of it. Multiply that script by every system boundary in your enterprise, and the scope of the problem comes into focus.

Hybrid is the architecture, not a phase

For a decade, the industry narrative said cloud consolidation was the destination and that on-premises systems, ERP estates and private infrastructure were transitional states waiting to be resolved. Reality settled somewhere else. 

Gartner forecasts that 90% of organizations will adopt a hybrid cloud approach through 2027. SAP contracts run for decades. Regulated workloads stay on-premises. AWS grows alongside those systems instead of replacing them.

Hybrid is simply the standard operating model of the modern enterprise. Few enterprises seriously considered going all-in on AWS. The real work has always been getting AWS to work alongside the SAP systems, on-premises infrastructure and other platforms already running the business. 

The building blocks aren’t the problem

AWS services are excellent at what they do. 

• Amazon EventBridge is an elegant way to route events between applications
• Amazon SQS has been reliable for nearly two decades
• Amazon ECS and AWS Fargate made container operations accessible to teams that had no interest in running Kubernetes 
• AWS Step Functions, AWS Lambda, Amazon Managed Workflows for Apache Airflow (MWAA) and Amazon Aurora are best-in-class building blocks for serverless orchestration and distributed applications, and enterprises are right to build on them

The problem starts the moment a workflow crosses the AWS boundary.

Think of an AWS Batch job that can’t start until an SAP financial close completes, or a goods receipt in SAP that should trigger downstream AWS processing in real time, or a data pipeline that begins with an on-premises extraction and ends in Snowflake. AWS-native orchestration tools like Step Functions and EventBridge Scheduler work well inside the boundary, using a state machine and the Amazon States Language to manage task state, wait states and retry logic across a workflow. But they can’t see an SAP job chain, enforce a dependency on an on-premises process or govern an end-to-end SLA that spans both worlds.

So enterprises bridge that boundary the only way they can: with custom scripts, scheduled polling, Lambda wrappers and manual coordination. A team writes one script to solve a specific handoff. Another team writes a different script for a different handoff six months later. None of it appears on an architecture diagram, and after a few years, the integration layer holding SAP and AWS together is really just a pile of undocumented cron jobs. 

The disconnect has a price tag

Deloitte’s 2026 Global Technology Leadership Study estimates that technical debt absorbs 21% to 40% of total IT spending, and the custom integration code accumulating at every system boundary adds to that figure with every new program. Flexera adds another dimension: 29% of cloud spend is wasted on idle or underutilized resources, often because nothing is orchestrating when infrastructure should be running.

The more visceral cost shows up at 9 AM on a Tuesday. A dashboard shows stale data. Was the failure in SAP? In the AWS pipeline? In the handoff between them? SAP logs live in one world, CloudWatch in another and the script connecting them logs to neither. Multiple teams are pulled in, and what should have been a five-minute diagnosis becomes an entire afternoon. Because the trigger was a polling schedule, the failure happened hours before anyone noticed.

Every new AWS service an enterprise adopts adds another boundary, another handoff, another script. The estate keeps growing. The distance between AWS and everything it depends on never closes.

A different model: An orchestration layer above the blocks

With orchestration, it’s a simple division of labor: AWS runs the cloud, and the orchestration layer runs the enterprise.

RunMyJobs by Redwood sits above the AWS execution tier. It doesn’t compete with EventBridge or Step Functions; it extends them to the systems they can’t reach. In this model, an SAP business event doesn’t wait for a polling window. RunMyJobs orchestrates the wider business service and publishes natively to EventBridge or populates application queues in SQS the moment the business event occurs, and the customer’s event-driven and serverless architecture takes it from there. 

A container task on ECS, a Batch job and an Airflow DAG on MWAA can also each become governed steps in a chain that started inside SAP and might end with Snowflake, Microsoft PowerBI, Box or ServiceNow, with one dependency map, one SLA policy and one audit trail across the whole thing.

This works because the integration is native at every layer of the AWS stack.

• The application layer: Connectors for EventBridge, SQS and SNS make orchestrated workflows first-class participants in event-driven architectures. They publish events, manage queues and fan out notifications using the same primitives AWS applications use to talk to each other.
• The compute layer: EC2, ECS and Fargate, Batch and Lambda run as governed execution steps, with IAM roles controlling exactly what each one is allowed to touch. Instances start and stop around workloads, containers run and are monitored to completion and exit codes propagate into the dependency chain.
• The data layer: S3, DataSync, Glue, AppFlow, MWAA and Amazon RDS govern the pipeline end to end. They ingest from on-premises and SaaS sources into a data lake or warehouse, trigger transformations, execute SQL and monitor Airflow DAGs as steps in a larger, governed whole.

Walking the chain: One retailer’s overnight run

Here’s what that looks like end to end.

Picture a retailer whose stores send the day’s transactions to SAP Customer Activity Repository overnight, where every cash register and every store is validated and audited. Merchandising needs those numbers on dashboards before the morning trade meeting.

The moment SAP confirms the data is complete, RunMyJobs publishes a “POS data ready” event to EventBridge, and every AWS application subscribed to it, from replenishment to store operations, knows instantly. There is no fixed 2 AM schedule and no guessing. In the same governed chain, RunMyJobs places a message on an SQS queue for each store’s dataset, and processing workers consume them at a pace downstream systems can handle. 

A containerized ECS task enriches the audited data. The operational reporting database on RDS is refreshed, started for the load and stopped when idle, because nobody should pay for a database running at 4 AM for no reason. An MWAA pipeline aggregates by store, region and product line. The final datasets land in Snowflake, and the dashboards are live before the meeting starts.

Seven services. One SAP system of record. One dependency chain. If a store’s data never arrives, the team knows right away, rather than when the merchandising director is staring at incomplete numbers.

Nothing in that chain required a polling script or custom middleware at the SAP-to-AWS boundary.

Every migration wave, the same problem

One group experiences this disconnect as an active, funded problem rather than chronic background pain: teams in the middle of a migration to AWS.

Migrations move in waves, sequenced by risk and dependency. Compute and databases typically lift and shift first, and workloads modernize onto containers, serverless and managed pipelines as each one is ready. Every wave that introduces a new AWS service also introduces a new dependency that the old on-premises scheduler can’t reach, which leaves teams with the same choice each time: stop the wave and rebuild the connection back to SAP and on-premises, or move on and leave it broken. Either way, the orchestration layer becomes the migration’s bottleneck rather than the workload move itself, and every custom script written to patch the boundary is more technical debt.

When every AWS service in the migration path already has a native connector, that choice disappears. Each wave goes live with its dependencies already governed. The migration stays on the timeline the business case promised, and the orchestration layer is the one thing that never needs to be re-evaluated at the next wave.

RunMyJobs will change your answer to all three. It’s the SaaS-native orchestration platform with native connectors across the AWS stack, deep SAP integration as the only SAP Endorsed App in workload automation and orchestration and a 99.95% uptime SLA. Every connector works without deploying infrastructure. Get a demo of RunMyJobs for AWS.

Agentic orchestration in RunMyJobs: What it takes to make enterprise AI operational

Article

Plenty of vendors are bolting a chatbot onto an automation platform and calling it agentic. At Redwood Software, we think that’s backwards. Governance, reliability and scale aren’t qualifiers you add to a product. They are the product.

Every agentic action in RunMyJobs by Redwood, from a single job step to a complex multi-agent workflow, is traceable, auditable and compliant. Deterministic guardrails apply hard-coded logic constraints to probabilistic AI, preventing rogue agent behavior before it reaches your systems of record. Your existing automation doesn’t get replaced — it becomes AI-ready, so you build on what already works.

Start building autonomous workloads now

We built RunMyJobs’ AI capabilities the way we did because the pressure on enterprise automation teams is real and coming from multiple directions at once.

1. Shadow AI is already inside your business. Departmental agents are spreading without central oversight, exposing sensitive data and credentials to third-party AI while critical business logic gets trapped inside individual chat histories. 82% of organizations discovered shadow AI agents in the past year.
2. Agentic conflict is coming. Agents optimized for different outcomes will collide over goals, shared resources and policies, the same way human departments do, except faster and at machine scale. Gartner projects at least 15% of day-to-day work decisions will be made autonomously by 2028. Somebody has to referee that, and it won’t be a spreadsheet.
3. Your automation was built for absolute certainty. AI agents reason probabilistically. Those are incompatible worlds, and rebuilding decades of critical business logic to force them together is neither feasible nor safe. One agentic hallucination can poison a data pipeline or exploit permissions that were designed for rigid scripts, not goal-seeking software.
4. The environment is shifting. Gartner also predicts that 33% of enterprise software applications will include agentic AI by 2028. When a third of the software landscape assumes agents are present, platforms that can’t govern them become a liability.

The path forward is incremental

You don’t have to reach full autonomy overnight. Like any automation maturity journey, the path to agentic orchestration is progressive. You start by augmenting your people with AI-powered productivity tools. Then, you make your existing business processes AI-ready so agents can reach the systems that matter. Eventually, you orchestrate autonomous agents natively inside the workflows your enterprise already depends on.

That progression only works if the platform underneath is designed to support each stage without requiring you to rip out what you did in the last one. The AI capabilities in RunMyJobs map to three building blocks: agentic productivity, agentic business processes and agentic enterprise, each solving distinct problems and delivering value independently. Every step forward is governed and reversible. Here’s what each one looks like in practice.

Building block 1: Agentic productivity

Start with making people more productive, building and managing automation at scale.

The Redwood RangerAI Product Assistant and Automation Co-pilot embeds an intelligent expert inside the platform, right next to every operator. Instead of digging through documentation or waiting on the one senior person who knows everything, your team asks a question and gets a grounded, plain-language answer. The Co-pilot:

• Generates job scripts from natural language
• Operates the platform through conversational commands
• Produces documentation in a click

Junior engineers start resolving issues that previously sat in a senior architect’s queue.

Workflow Builder tackles a bottleneck most automation teams have simply accepted as life: the specialist intake queue. Every new workflow goes through a developer, usually via a ticket, and some enterprises process 30 to 50 of those a week. With Workflow Builder, a process owner describes a new data reconciliation workflow in plain English or uploads an SOP, and an intent agent:

• Matches the request to the actual jobs, connectors and schedulers already in the environment
• Builds the chain and resolves parameters
• Flags anything it can’t resolve for human input
• Creates nothing until a human explicitly approves

The specialist’s role shifts from building to reviewing.

Building block 2: Agentic business processes

This is where you make your existing business logic AI-ready without rewrites, custom APIs or architectural overhaul.

The RunMyJobs Model Context Protocol (MCP) server gives your AI reasoning tools governed access to the systems that actually run the business. Over 50 tools across nine global AWS regions, with OAuth 2.0 authentication and per-request credential isolation.

Your workflows become the agent’s toolbox.

Instead of giving an agent raw credentials to your ERP, you give it a workflow that already encodes the right steps, permissions and error handling. The agent gets a trusted tool. Your systems get a hard boundary and full audit traceability. For SAP-centric customers, the MCP server is validated with SAP’s Joule, so your SAP AI assistant can invoke RunMyJobs operations natively.

In practice, this opens up entirely new operating models:

• An operations engineer uses Microsoft Copilot or Slack to submit jobs, restart failed steps and raise events through natural language without opening the RunMyJobs UI
• A finance team’s AI assistant, scoped to their partition, triggers a reforecast workflow when demand signals change, monitors status and notifies the team on completion — without IT involvement
• A developer uses Claude Code to trigger a data refresh in a production environment, then RunMyJobs verifies all dependencies and prerequisites are met, giving Claude a trusted way to execute in critical environments. 

The Operations Agent tackles one of the most persistent costs in enterprise automation: overnight incident triage. It changes what an alert means:

• Proactively detects failures, SLA deviations, silent completions and cascade outages
• Delivers enriched alerts with job history, blast radius, SLA countdown and suggested next actions
• Groups dozens of alerts from a single root cause into one incident

When a critical batch job fails at 3 AM, the agent identifies the twelve downstream jobs at risk, calculates the SLA countdown and delivers a single contextualized notification — before the engineer touches the keyboard. The destination is fully autonomous tier-one and tier-two remediation.

Building block 3: Agentic enterprise

Agent Studio gives you the lowest-friction path to embedding agents inside the workflows you already run. 

Write agent skills, connect MCP servers as tools, choose your preferred LLM and drop the agent in as a step under the same governance and observability model as everything else. Your deterministic processes stay unchanged. The agent adds a judgment layer for exception handling, risk scoring or compliance narrative drafting, and a human stays in the loop on every consequential call.

• A reconciliation agent investigates mismatches, resolves known patterns and escalates only genuinely novel cases
• An approval agent risk-scores incoming requests, auto-clears low-risk items with an audit trail and routes the rest to a human
• A compliance agent drafts the narrative auditors need, summarizing what changed each period for human review

Consider a data validation job that encounters an anomalous record set matching no existing exception rule. An Agent Studio step invokes an LLM to classify the anomaly, decides whether to escalate or auto-resolve and writes the outcome to an output parameter, all within the same job chain and under the same partition governance.

As you scale beyond individual agents, agentic workflows coordinate fleets of specialized agents toward shared goals with managed state, shared context and centralized conflict resolution. And the agentic library eliminates the cold-start problem by transforming your existing jobs, workflows and enterprise connectors into trusted tools and pre-built skills. Your agents show up already understanding your business.

Start where you are

Redwood brings 30 years of enterprise experience and the trust of more than 50% of the Fortune 50. RunMyJobs is the only SAP Endorsed App for workload automation and orchestration and the only Service Orchestration and Automation Platform (SOAP) in the RISE with SAP reference architecture. That trusted foundation is what makes governed autonomy possible at enterprise scale.

You don’t need to overhaul everything at once. Augment your operators. Make your existing logic AI-ready. Embed one agent inside one workflow you already run. Each move builds trust, extends autonomy and delivers something measurable, and you can pause or reverse at any point.

Explore the AI and agentic capabilities in RunMyJobs and find your starting point.

SAP Landscape Management reaches end of support: Keeping hybrid SAP operations automated

Article

SAP has confirmed that mainstream maintenance for SAP Landscape Management 3.0 will conclude on December 31, 2027, with no extended maintenance currently planned. As an add-on to SAP NetWeaver AS for Java, SAP Landscape Management (LaMa) is directly affected by the end of SAP Business Suite 7 mainstream maintenance. SAP Landscape Management Cloud, which was originally positioned as the cloud-based successor, has since been discontinued as SAP refocuses its strategy on RISE with SAP with SAP Cloud ERP Private and GROW with SAP with SAP Cloud ERP.

That timeline aligns with the end of support for SAP Business Suite 7 (ECC 6.0) and SAP Solution Manager 7.2, making 2027 a convergence point that will reshape how SAP Basis teams approach landscape operations, system monitoring and infrastructure automation.

SAP’s direction makes it clear that the future of SAP operations is cloud-first, standardized and increasingly managed by SAP itself. That strategy is well-founded, and it’s already delivering real value to customers adopting RISE with SAP and GROW with SAP.

For many organizations, though, the transition timeline means hybrid operations will remain a reality for years to come. And SAP LaMa handled a set of operational workflows that don’t retire just because the tool does.

What still needs to be orchestrated

In managed environments like RISE with SAP and GROW with SAP, many traditional SAP Basis tasks are handled by SAP. SAP Cloud ALM replaces parts of the operational capabilities previously associated with SAP Solution Manager, while SAP manages more of the underlying infrastructure.

These don’t eliminate the need for orchestration. Organizations still need to automate system refreshes and copies, SAP Post-Copy Automation (PCA), cross-platform disaster recovery (DR) and cross-system operational workflows that span self-hosted SAP systems, cloud environments and non-SAP applications. These workflows remain essential in hybrid landscapes, even as more infrastructure moves under SAP management. 

Customers who relied on SAP LaMa for this coordination need a new approach before support ends in 2027.

The 10-year reality of RISE with SAP transformations

SAP’s investment in managed cloud services gives customers a strong foundation for cloud operations. Virtual machines, high availability configurations and patching are increasingly handled within the RISE with SAP operating model.

But the reality is that most large-scale RISE with SAP transformations are multi-year programs. For numerous enterprises, this is a decade-long journey where, even after completion, certain technical systems will remain outside SAP’s managed perimeter. Manufacturing systems, regional SAP HANA instances, legacy landscapes, reporting environments, industry-specific solutions and non-SAP satellite applications all continue running alongside SAP-managed cloud ERP.

The picture is more grey than black-and-white. SAP’s managed cloud addresses a significant portion of infrastructure operations, and most large enterprise customers with diverse landscapes also need orchestration that extends across what they continue to operate themselves.

Total cost of ownership (TCO) and operational efficiency don’t improve by adding more disconnected tools to cover what SAP LaMa used to handle. They improve through consolidation into a modern orchestration layer that works across every environment in the landscape, managed and self-hosted alike.

Extending SAP operations with RunMyJobs

RunMyJobs by Redwood helps you preserve the automation, orchestration and governance your hybrid SAP landscape still requires. As the only SAP Endorsed App for workload automation and the only orchestration platform included in the RISE with SAP reference architecture, RunMyJobs automates across the full SAP ecosystem while supporting clean core principles through standard, SAP-approved integrations rather than ERP customizations.

RunMyJobs complements SAP’s managed cloud operations by extending orchestration to the systems, workflows and dependencies that customers continue to operate themselves — and covering the operational scenarios where SAP isn’t providing a direct successor.

SAP operations after SAP LaMa

Here’s how that translates to the specific challenges SAP LaMa’s retirement raises.

• Orchestrating across both sides of the managed boundary: RunMyJobs coordinates workflows across self-hosted SAP systems, RISE with SAP, SAP Business Technology Platform (BTP), hyperscalers, databases and non-SAP enterprise applications from a single platform. Operational runbooks, DR procedures and IT service management workflows continue running seamlessly across hybrid environments, instead of fragmenting into disconnected scripts and manual handoffs. 
• Keeping system refreshes zero-touch: RunMyJobs orchestrates complete system refreshes end to end, coordinating SAP Post-Copy Automation (PCA) task lists, massively parallelized BDLS processing, database restores, storage operations and validation activities without manual intervention. Instead of reverting to manual scripts, disconnected runbooks and spreadsheets, you maintain standardized, repeatable workflows with centralized visibility and automated error handling.  
• Preserving a clean core strategy across the full transformation timeline: As organizations progress through multi-year RISE with SAP journeys, RunMyJobs connects through SAP-approved APIs and integrations free of additional local software and code installation, rather than introducing ERP customizations. SAP Basis teams can automate operational runbooks and cross-system dependencies while keeping custom logic outside the ERP core, making future upgrades and innovation easier to adopt. 
• Delivering reliability without adding infrastructure: While SAP manages more of the underlying infrastructure, organizations still need orchestration for hybrid operations. A self-managed replacement for SAP LaMa simply recreates the infrastructure your team is trying to leave behind. RunMyJobs is a cloud-native SaaS platform with 99.95% guaranteed uptime, predictive SLA monitoring and automatic upgrades, allowing SAP Basis teams to focus on modernization instead of maintaining automation infrastructure. 

Plan your transition now

The retirement of SAP LaMa, with both the on-premises version and its planned cloud successor now approaching end of support, is more than a product lifecycle event. It signals that the operational architecture around SAP needs to evolve alongside the ERP itself.

More infrastructure will become managed. More ERP services will move to the cloud. More organizations will embrace clean core principles and SAP Cloud ALM as their operational command center.

At the same time, hybrid landscapes will remain a reality for years. System refreshes, DR orchestration, cross-platform dependencies and operational runbooks don’t disappear because the underlying deployment model changes. Coordinating these environments across managed and self-hosted boundaries becomes more important as the architecture distributes.

Treat SAP LaMa’s retirement as an opportunity to modernize your orchestration strategy, and your organization will be better positioned to support both today’s hybrid operations and tomorrow’s cloud-first SAP landscape.

To learn how RunMyJobs automates SAP and non-SAP operations across hybrid environments.

Governed for quality, ungoverned for delivery: Why trusted data still shows up late  

Article

Every data investment your organization has made rests on an assumption nobody wrote down: that the data will arrive complete, current and on time when the business reaches for it. The business carefully approved important data programs on their merits: a Snowflake migration, a Databricks rollout, the AI roadmap. All of them assume accurate data will show up when it’s needed. And the layer responsible for making that happen almost never gets tested against it.

I regularly sit across the table from data organizations in architecture reviews and discovery sessions, and I’ve watched the same pattern play out at company after company. A transformation feeds the nightly load that finance and analytics both depend on, but it runs on customer data that went stale two days earlier because an upstream sync failed, and nothing tied that failure to the deadline downstream. No alert fires, because someone built the alerting to catch job run failures instead of deadlines that slip. The pipeline run reports green, the executive dashboard reports green and the number that drives a decision is wrong. Nobody finds out until after someone has already acted on it.

The pattern repeats no matter how different the organizations are otherwise. Data infrastructure investment and data delivery reliability get treated as the same thing, and they aren’t. Enterprises pour money into the first and leave the second as an afterthought.

A green pipeline isn’t a business guarantee

Ask most data teams whether a pipeline succeeded, and they’ll check three things: did the job complete, did it throw errors and is the status green. All that tells you is that the process ran. It says nothing about the question the business is actually asking: did the right data show up, complete and current, at the moment a mission-critical application outcome, a strategic report or an agentic AI workflow needed it?

Those two definitions of “done” drift apart constantly. A Snowflake load can finish exactly on schedule, then hand off to an ERP process that opened its window before the load was ready. A dbt model can complete without a single error and still deliver its output an hour after the executive pack was already pulled. Both register as passing jobs, and both are deliveries that failed the business. That’s how you end up with a wall of green and no idea whether the business got what it needed.

Where accountability lands

Nobody measures you on pipeline uptime. They measure you on whether your analytics produce decisions people can trust, whether your AI initiatives survive scrutiny and whether the business believes the numbers you put in front of it. Those outcomes depend on an orchestration layer that executes the entire business process that’s reliable, traceable and measurable against real deadlines, not just functionally in a narrow, technical sense.

When that business process execution breaks behind the scenes, the fallout doesn’t stay inside engineering. It shows up as a figure that moved after leadership already acted on it. Once the business loses confidence in the data, somebody has to account for why. In the reviews I sit in, that reckoning lands on whoever owns the orchestration layer, working backward through four systems to piece together what happened and when. Trust doesn’t come back quickly, either: a long stretch of dependable delivery earns it, and one discrepancy nobody can explain spends it.

AI has made this exposure worse. When a model produces a bad outcome, the reflex is to interrogate the model. But the real culprit is more often a data refresh that ran late or died upstream. Most programs aren’t ready for this: Gartner found that 63% of organizations either lack the right data management practices for AI or aren’t sure they have them. The same research predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data. Without audit trails that show what arrived and when, there’s no way to prove the data was sound. You end up defending a result you can’t fully reconstruct, which is a hard position to be in when the questions come from the board.

The line item that wasn’t on the invoice

The organizations I work with have spent seriously on data platforms, data quality tooling, observability inside those platforms and, lately, on AI and machine learning infrastructure. The money isn’t the issue. What all that spending doesn’t produce is an orchestrated, governed execution layer: something that confirms the pipelines feeding your business services are delivering against real deadlines and required outcomes, not just running without errors.

The gap shows up first in the industries that went farthest down the automation road earliest. In financial services, 61.4% of organizations report that siloed automation environments constrain their AI readiness, according to original research from Redwood Software. These are well-funded organizations whose sophisticated data architecture never accounted for production coordination across the full business process. And where financial services goes, the rest of the data-intensive economy usually follows.

Here’s where I’d push back on how governance gets scoped. Most data governance frameworks orient around data quality dimensions like accuracy, completeness and consistency, and control concerns such as data security, access controls and regulatory compliance under GDPR or HIPAA. All of that matters, yet none of it answers the delivery question: did this data arrive for the process that needed it, at the time it needed it, with a traceable record of the path it took?

Trusted data isn’t only clean, compliant data. It’s data that arrived when the business needed it, and most governance programs have no way to prove that part.

Monitoring pipelines vs. governing delivery 

Closing this gap calls for a change in how data delivery is governed, not another tool bolted onto your stack. Treating data workflows as production business services means a few specific things:

• Monitoring gets tied to business outcomes rather than job completion, so the question becomes whether the financial close data is ready by the window the ERP depends on, instead of whether the pipeline ran
• Dependency visibility runs the length of the chain, so a late or failed step upstream surfaces before the service deadline instead of during the postmortem
• Evidence becomes something you can produce on demand: what ran, when, what it depended on and whether it met its SLA, without a two-day expedition across half a dozen disconnected tools and multiple teams
• Alerting gets calibrated to business impact rather than technical status, so the signals that reach you are the ones that matter

The distance between “we monitor pipelines” and “we govern data delivery” is an operating chasm most data strategies have left open. It’s the difference between catching a problem in your own systems and hearing about it from the business.

Solve the problem that lives between teams

Delivery governance sits precisely where no single team’s mandate reaches. Between the team that runs the pipelines, the one that builds the applications and the one that schedules, runs and monitors the production process end to end, every technical task has a clear owner. What none of them answers for is whether the business got what it needed, on time and with proof it arrived. That question goes unanswered simply because nobody was assigned to answer it.

Closing it takes an orchestration layer that sits above the individual tools without replacing them. That layer connects the tools you already run (Snowflake, Databricks, Airflow or a managed Airflow service, native schedulers inside ERP and cloud services) and holds the full flow to the deadline the business actually cares about, recording what happened at every handoff. RunMyJobs by Redwood ties these siloed tools together into one governed flow. Airflow keeps orchestrating its pipelines; Snowflake keeps running its loads. What changes is that the delivery across all of these disparate tools finally has an owner and a documented, auditable trail. 

When someone asks whether the data was complete and on time, the answer is already on record rather than reconstructed after the fact. Consolidating orchestration this way also means accelerating transformation across the enterprise at the lowest possible total cost of ownership (TCO) instead of adding one more scheduling tool for your team to manage and maintain.

Your board and your AI sponsors weren’t asking whether the pipeline ran. They want to know the data was there, complete, on time, ready when the business-critical decision needed it. That’s not something a data platform can tell you. The answer comes from the orchestration layer that governs how data reaches the business. Most companies haven’t built that layer yet. Until they do, all the governance in the world doesn’t answer the one question the business asked: did the data show up when we needed it?

See how RunMyJobs connects hybrid data pipelines.