For about 30 years, enterprise automation ran on standardization. You bought a scheduler, and your processes learned to live inside its limits. When every workload sat in one data center, that trade felt reasonable.
It doesn’t anymore. Your environment now spans on-premises servers, Amazon Web Services (AWS) and SAP, but no single template fits all three. A cloud orchestration platform earns its place by fitting your systems and processes without custom code or a drawn-out implementation. That’s tailored orchestration. Redwood Software builds automation that adapts to your business needs instead of asking you to adapt to it.
Why do fixed job schedules break down after an SAP migration?
Consider GROWMARK, a large agricultural cooperative with several business units. When it moved to SAP, it ran its batch jobs on SAP’s native task scheduler and everything else on a separate on-premises scheduler. Teams coordinated the two by timing: they scheduled an SAP job for three minutes past the hour and a downstream job for 23 minutes past the hour.
That timing broke down in a specific way. When an SAP job ran long without failing, the downstream job still started on schedule, found no output and reported success. Someone had to notice that the downstream job finished too fast.
Automation once meant doing more with fewer people. The goal now is fitting it to your business needs, your systems and your compliance rules. For IT leaders, that shows up in the cloud bill and in every AI roadmap review.
What tailored orchestration means
Tailored orchestration is automation that adapts to your systems and compliance needs instead of forcing your operations into a fixed template. Packaged automation, by contrast, only removes manual work inside one application.
The old model assumed there was a standard process to automate, but there wasn’t one. Every enterprise runs its own mix of applications, service-level agreements (SLAs), compliance requirements and handoffs between teams. Traditional job scheduling handled that variety by ignoring it. It squeezed processes into a fixed template, and the workarounds piled up as technical debt.
A cloud orchestration platform does the adapting, and your workflows reflect how your operations actually run. You design workflows around how your business actually operates.
What is breaking fixed schedulers in hybrid environments
Most enterprises run automation across a patchwork of tools: one scheduler for SAP, another for cloud workloads and a layer of scripts holding it all together. That patchwork is expensive to maintain and easy to break. Schedules copied unchanged from the data center keep polling scripts and always-on hosts running in the cloud, and Flexera’s 2026 State of the Cloud Report puts estimated wasted cloud spend at 29%, the first increase in five years.
The cause is structural. Hybrid and multi-cloud environments have outgrown schedulers built around a single data center. Custom middleware is no longer the default way to connect an application, service or server. RunMyJobs by Redwood offers prebuilt integrations for 500+ technologies, so the scripts that hold the patchwork together are no longer your only option.
According to Redwood’s 2026 Enterprise Automation Benchmark Report, 68.8% of leaders say automation is mission-critical to business success, but just 10% prioritize its adoption. Most organizations already know automation matters. Complexity and a lack of orchestration are the barriers to successful automation adoption.
What tailored orchestration looks like across SAP and hybrid environments
GROWMARK chose RunMyJobs and rebuilt its jobs one at a time instead of migrating them automatically, so the team could clean up as it went. It moved its SAP processes first and then recreated the rest. The move also became a process optimization exercise: the team dropped about a third of its legacy jobs because they were redundant or unused. In some cases, one job now does what three did. The team wanted to see every job in one view and have later jobs recognize the status of earlier ones, and RunMyJobs delivered both.
Kaeser Compressors shows the same idea at global scale. After moving its SAP automation to RunMyJobs as software as a service (SaaS), Kaeser no longer builds a separate process for each country, and a single automated process chain now supports more than 40 countries.
RunMyJobs applies the same approach to hybrid environments through three capabilities:
Event-driven triggers: Starts a process chain when a file lands, using native S3, EventBridge and AWS Glue connectors, so no polling script runs on a timer
Redwood Insights: Adds root-cause analysis and historical trend views, while predictive SLA monitoring flags at-risk processes before they miss a business deadline
Redwood RangerAI: Analyzes failures and suggests the likely fix through the Product Assistant, and generates scripts and documentation through the Automation Co-pilot
How RunMyJobs delivers tailored orchestration
These capabilities are why Redwood believes it has been named a Leader in the Gartner® Magic Quadrant™ for Service Orchestration and Automation Platforms (SOAP) for three consecutive years, most recently in 2026, and positioned furthest for Completeness of Vision.
Agentless architecture
RunMyJobs automates workloads across cloud and on-premises systems without installing an agent on each one. That leaves less for you to maintain, and upgrades happen without downtime. The platform has run more than 50 billion automations and guarantees 99.95% uptime.
Event-driven execution
Time-based batch windows made sense when everything ran overnight. Event-driven triggers let a workflow start when something actually happens, such as when a file lands, an API call comes in or a transaction completes. Your processes run on your business’s schedule, not the scheduler’s. On AWS, RunMyJobs triggers workflows from services such as Amazon EventBridge and Amazon SQS, so workloads start the moment work arrives instead of waiting for a polling script to check.
SAP automation
RunMyJobs is an SAP Endorsed App and the only workload automation solution in the RISE with SAP reference architecture. It connects to S/4HANA, SAP Cloud ERP and SAP Business Technology Platform (BTP). Redwood also validated its Model Context Protocol (MCP) server with SAP Joule.
That matters most during a move from SAP ERP Central Component (ECC) to S/4HANA. Many teams rebuild their automation during the migration anyway, which makes it the natural time to replace fixed schedules with event-driven workflows.
Governed agentic orchestration
Redwood’s agentic orchestration runs AI agents inside governed workflows, so you can see what each agent is doing and keep a person in the loop. RunMyJobs makes every agentic action traceable and auditable, and deterministic guardrails limit what an agent can touch in production. Its MCP server integrates your existing workflows with third-party AI models and agents, including Microsoft Copilot, SAP Joule and Claude Code.
Cloud adoption offers a useful parallel. Companies that held out on cloud infrastructure didn’t fail overnight, but they moved more slowly than their competitors for years afterward. Orchestration is heading the same way. Teams that skip it will keep maintaining scripts while their competitors free up time to work on more value-driven work.
How fast are enterprises moving to tailored orchestration?
Cloud migration took about a decade to go mainstream. Adoption will move faster for two reasons.
The first is SAP’s maintenance timeline. Mainstream maintenance for SAP ECC ends on December 31, 2027, and extended maintenance runs through 2030 at an added cost. Teams moving to S/4HANA are revisiting the schedulers behind their SAP jobs, which makes the migration a natural point to drop rigid tools.
How much of your automation budget goes to keeping brittle scripts alive?
When a process changes, can your team update the workflow in hours, or does it turn into a project?
If AI agents start working inside your processes next quarter, will you be able to see and govern what they do?
When a job fails across AWS and SAP, can you trace the cause without opening three consoles?
Does your automation fit your requirements, or have you bent your processes to fit it?
Can you see every job and dependency across on-premises, cloud and SAP from one place, or does your team have to check several tools?
If two or more of your answers concern you, your automation shapes your processes instead of the reverse. Start evaluating at least 12 months before your scheduler contract renews. With fewer than nine months left, the renewal date forces the decision.
Where to start with tailored orchestration
How quickly your organization moves depends on your industry and how aggressively you retire legacy tools. RunMyJobs connects SAP, AWS and on-premises systems through one SaaS platform, so you can start with the workflows that cost the most to maintain and extend from there. You keep the automation that works and tailor the rest.
See how your automation strategy compares in Redwood’s latest research, or request a demo to map your first tailored workflows.
The latest release of RunMyJobs by Redwood gives your automation team more ways to use AI in their everyday work, from building workflows to investigating failures. It also expands the AWS connector catalog to help you keep cloud workloads coordinated with processes running across the rest of your business.
AI for enterprise workflow automation
RunMyJobs 2026.4 introduces four agentic AI capabilities:
Agent Studio for building reusable AI agents
Workflow Builder for authoring and editing automation in plain language
Operations Agent for monitoring with context
An enhanced Model Context Protocol (MCP) Server for connecting AI assistants to your automation environment
All four use the security partitions, role-based access controls (RBAC) and audit model already in place in RunMyJobs.
Workflow Builder and Agent Studio: Development to execution
Workflow Builder turns a plain-English description or an uploaded Markdown file into a workflow draft you can review, using the objects already in your environment. You can also use it to explain, edit and optimize existing workflows.
Agent Studio lets you build reusable agents that run as steps within your workflows. The guided setup walks you through choosing a model, defining instructions and granting access to specific tools from connected MCP servers, with token and runtime limits to control resource use. Before publishing, you can test the agent under the same controls used in production, while write actions are simulated. These agents can investigate exceptions and resolve recognized cases within the permissions you’ve granted, then escalate unfamiliar cases for human review with the investigation attached. Your teams stay in charge of consequential decisions while spending less time gathering the information necessary to make them.
To respond to a failed job, engineers need to understand what happened, which processes are affected and what to do next. The Operations Agent monitors your environment continuously and includes that context in the notification:
Failure with context: The reason from the execution log, downstream jobs at risk and a suggested first action
Cascade grouping: A single notification for dependent failures that accelerates root-cause analysis
Ranked shift-start summary: A digest of overnight exceptions so the incoming team can see where to focus
For further investigation, select “Analyze with Ops Agent” on a job in the monitor and ask questions in plain language. The chat opens with the job’s context and draws answers from the RunMyJobs MCP server. It can also include relevant information from systems such as ServiceNow, where an administrator has connected external MCP servers.
In this release, the Operations Agent provides context and recommendations while your team takes action. It enriches alerts and answers questions to help operators understand issues and respond sooner, laying the groundwork for autonomous remediation as the longer-term direction.
MCP Server: Connect AI assistants to enterprise workflows
The enhanced MCP Server gives MCP-compatible AI clients governed access to the complete range of RunMyJobs operations. It supports Microsoft Copilot, Anthropic Claude and SAP’s Joule.
Through that connection, an assistant can submit, monitor, cancel and restart jobs and workflows, invoke agents built in Agent Studio, manage events, inspect infrastructure health and promote changes between environments. A developer could promote a build through Claude Code from their development environment, all without a bespoke API integration project.
Your teams can use their existing AI tools to access approved business processes, with each call following RunMyJobs permissions and appearing in the audit trail. You retain control over which systems those tools can reach and what they can do.
Connect AWS workloads to the rest of your business
AWS services such as Step Functions, EventBridge and managed Airflow may already handle significant parts of your cloud automation. Coordinating that work gets more complicated when those workloads depend on transactions in SAP and other ERP systems, a file arriving on premises or a task completing in another cloud.
RunMyJobs manages these dependencies across the full process, reducing the scripts and scheduled checks that teams otherwise maintain between systems. The expanded AWS connector catalogbrings more services into that orchestration model, with shared visibility into execution, SLA requirements and audit records.
What’s new in 2026.4
Four connectors join the catalog in this release:
Amazon ECS: Run, monitor and control containerized tasks and services from job chains. One connector covers both Fargate and EC2 launch types.
Amazon SNS: Publish messages and manage topics and subscriptions as job steps, allowing completion and failure notifications to reach multiple downstream consumers.
Amazon RDS: Run SQL and manage instance and cluster operations, including start, stop, snapshot and restore. Scheduling supported databases around batch windows can help reduce unnecessary runtime.
Amazon EKS: Scale and patch EKS node groups and run Kubernetes jobs as governed workflow steps, reducing reliance on separately maintained scripts.
With these connectors, you can manage more steps of the same process directly in RunMyJobs. For example, you could wait for an ECS task to finish before starting an RDS operation, then use SNS to notify the owning team of the outcome, with the dependencies managed in the job chain.
The full AWS catalog
The expanded catalog covers the following service categories, so you can add new services to the workflows you already manage:
Service category
Connectors
Compute
EC2, Lambda, Batch
Containers
ECS (Fargate and EC2 launch types), EKS
Data movement
S3, DataSync, AppFlow, Glue
Databases
RDS
Managed pipelines
MWAA (managed Airflow)
Messaging and eventing
EventBridge, SQS, SNS
Workflow
Step Functions, Simple Workflow Service
The connectors use an agentless architecture, so you don’t need to deploy any software, virtual machines or other infrastructure to start including these services in your workflows. As your AWS usage grows, you can extend orchestration easily, without complex change requests or additional costs.
Put the new features and connectors to work
With RunMyJobs 2026.4, you can introduce AI into the workflows your team already knows and bring more AWS services under the same operational controls. Start with the work that takes the most time today, whether that’s building automation, investigating failures or maintaining connections between systems.
SAP ERP modernization is often described as a move toward a destination: leave SAP ECC, adopt SAP S/4HANA, move to SAP Cloud ERP Private through RISE with SAP or start with SAP Cloud ERP through GROW with SAP.
SAP’s maintenance timeline can add urgency. Mainstream maintenance for SAP Business Suite 7 core applications, including SAP ERP 6.0, runs through the end of 2027, with optional extended maintenance available through 2030. SAP has also committed to maintaining at least one SAP S/4HANA release through 2040. Those dates don’t create one universal migration strategy.
Large SAP estates evolve over years, with legacy systems and newer cloud deployments running side by side. One business unit may move to cloud ERP while another continues running SAP ERP 6.0. A regional operation may stay on SAP S/4HANA on-premises. An acquisition may introduce another ERP instance. At the same time, the business processes that keep the organization running still depend on data platforms, file transfers, SaaS applications, analytics tools and other non-SAP technology.
For SAP operations teams, that creates a practical problem: how to keep critical finance, supply chain and operational processes running reliably while the ERP landscape changes underneath them. The answer must include orchestration continuity.
Job execution changes with the ERP
ERP coexistence also means job execution coexistence.
For decades, SAP Basis and operations teams have relied on traditional ABAP background jobs. Transactions such as SM36 and SM37 are familiar territory for scheduling and monitoring these jobs. They remain essential across SAP ERP and SAP S/4HANA environments and will continue running throughout long migration programs.
Newer SAP environments also use the standardized Application Jobs framework. Depending on the application, these workloads can include billing runs, material requirements planning (MRP) and foreign currency valuation. Application Jobs provide a model better suited to cloud application architecture and API-based interaction. But there’s still a difference between executing a job and orchestrating the larger process around it.
Scheduling answers a local question: When should this task run? Orchestration has to answer the rest:
Is upstream data ready?
Which event should trigger processing?
What happens if a dependency fails?
Which step runs next?
Has the complete process met its SLA?
Those questions apply whether the SAP step is a traditional background job or an Application Job.
Keep orchestration separate from SAP execution
A central orchestration layer separates business process control from the way an individual SAP system executes work. SAP still runs the workload, and the orchestration layer manages the dependencies across environments that may use different scheduling interfaces, monitoring tools, security models and job semantics. That gives operations teams a consistent way to handle execution, alerting, recovery and audit history across on-premises systems, private cloud environments, SaaS applications and the rest of the enterprise stack.
It also supports clean core principles. Cross-system orchestration can stay outside the ERP core and use supported interfaces instead of custom code, embedded scheduling logic or point-to-point scripts. This reduces technical debt as the SAP estate changes.
In a migration, if an end-to-end process is tightly coupled to the way one SAP version executes a job, changing that system can turn the ERP project into an automation redesign project, too. Keeping the orchestration logic separate makes more of that process reusable as workloads move between SAP environments.
Support both SAP job models from one place
As a separate orchestration control plane, RunMyJobs by Redwood supports both sides of this transition.
For established SAP workloads, the built-in SAP ERP / SAP ECC / SAP S/4HANA connector integrates with traditional SAP background processing. You can run, intercept and monitor ABAP programs, apply variants and respond to SAP events.
For modern SAP workloads, the SAP S/4HANA Application Jobs connector brings Application Jobs into the same RunMyJobs orchestration environment. Teams can import job templates, submit and monitor runs, abort jobs when needed and track steps in multi-step jobs across SAP Cloud ERP, SAP Cloud ERP Private and SAP Integrated Business Planning (IBP).
SAP workload
RunMyJobs integration
What it enables
Traditional SAP background jobs
Built-in SAP connector
Run, intercept and monitor ABAP programs; apply variants; respond to SAP events
SAP S/4HANA Application Jobs
SAP S/4HANA Application Jobs connector
Import job templates; schedule and submit jobs; monitor or abort runs; track steps in multi-step jobs
Cross-application processes
RunMyJobs orchestration
Coordinate SAP jobs with files, data platforms, cloud services and other enterprise applications
The advantage is continuity. Traditional background jobs and Application Jobs can participate in the same end-to-end process. An underlying step can change without forcing the whole workflow to change with it.
What continuity looks like for a supply chain process
Data arrives from an external system. RunMyJobs validates that the prerequisite is complete and starts the appropriate SAP workload. Today, that might be an ABAP background job in an existing SAP ERP system. When it finishes, downstream steps update a data platform, initiate reporting and notify another application.
Now, one business unit moves to SAP Cloud ERP.
The SAP step for that unit becomes an Application Job. The way SAP executes that portion of the process has changed, but the entire chain doesn’t need to be rebuilt around it. The new Application Job can occupy the appropriate place in the existing orchestration flow while downstream reporting, warehouse processing and notifications continue as before.
Operations keeps a common view of the process instead of checking each participating application separately.
Build orchestration into your ERP roadmap now
The end of mainstream maintenance for SAP Business Suite 7 core applications makes ERP planning urgent, but mixed SAP landscapes won’t disappear in 2027.
As you plan your ERP roadmap, inventory the SAP background jobs you run today, then look beyond the jobs themselves:
Which upstream systems determine when they can start?
Which downstream applications depend on their results?
Which workloads are candidates to move into the Application Jobs framework?
Which workflows cross ERP instances, SAP BTP services or non-SAP platforms?
Where are scripts or local schedules holding a larger business process together?
Those dependencies tell you more about migration impact than a job list alone. They also show where orchestration belongs in the transformation plan rather than as a cleanup project after the migration.
Redwood Software has been a trusted SAP partner for more than 20 years, and RunMyJobs is the only workload automation and orchestration platform that’s an SAP Endorsed App and part of the RISE with SAP reference architecture. As SAP architectures change, your orchestration layer shouldn’t also have to change every time an underlying workload does.
Your SAP ERP destination may still be evolving. The critical processes running across that estate still need one reliable way to operate.
Cloud operating models have spent years absorbing change as new services, data platforms and application-specific automation expanded the number of environments involved in running critical work. Through that expansion, IT Ops has remained accountable for preserving the dependencies, controls and service levels that keep business processes running reliably across the hybrid estate.
AI arrives on top of all of that. An agent may decide when existing work should run, which path a process should take or how an exception should be handled, but those decisions still have to travel through the cloud and enterprise systems currently running the business.
This is why I’m less interested in whether an enterprise is “agent-ready” than in which workloads can support more autonomy today. The answer is already visible in how your work runs.
I would start by looking for three characteristics in the workload itself.
1. Business context survives every handoff
A file arriving isn’t the same as a process being ready to continue. In a hybrid environment, you may have incomplete data, an upstream process that’s still running or information that mattered in the source application but didn’t carry forward.
AI just changes the consequence. Data quality becomes part of the execution question when an agent is expected to make a decision based on that handoff. “The job completed” isn’t a helpful definition of success.
AI models keep getting better at reasoning with the information available to them, but production operations can’t rely on the agent to infer whether the process around it is healthy. That judgment often belongs upstream, before the agent is asked to do anything.
For a workload you already run through RunMyJobs by Redwood, much of that context may already be encoded in the workflow. Dependencies, events and validation steps could tell you whether expected inputs are present, prerequisite work has finished and execution should proceed. Where that context still lives in a script, a local scheduler or source application, you have a boundary worth examining before introducing autonomous action.
The more consequential the agent’s decision, the less process readiness should depend on the agent figuring it out for itself.
2. Control remains consistent across environments
One assumption I would challenge about agentic AI is that autonomy is something you either grant or withhold. Mission-critical processes don’t work that way.
You may be comfortable with an agent classifying an exception or initiating a known remediation workflow, while an action with wider downstream consequences still requires human oversight or approval. Answering where its authority ends becomes harder when a process crosses cloud services, data platforms, enterprise applications and on-premises systems.
This is where I would look at the controls already attached to the given workload. A RunMyJobs workflow that’s been operating reliably for years reflects decisions about ownership, access, approvals and exception handling. An agent gives you a reason to revisit those decisions, not replace them. AI governance can build on what you already trust.
The objective isn’t to give the agent more or less autonomy. It’s to be precise about where autonomy belongs in the process.
3. Operations can control the business outcome
Eventually, every agentic AI discussion reaches the question an IT Ops leader will be accountable for: what happens when something goes wrong?
There’s a meaningful change once agents start initiating work. Knowing that an agent initiated a workflow is, therefore, only the beginning of the audit trail. Observability has to extend beyond the agent itself: you need to reconstruct the state it acted on, follow the work its decision set in motion and determine whether the business process still reached the intended outcome. If it didn’t, the retry, recovery and escalation mechanisms you already use become even more valuable, because they provide deterministic ways to contain a process that included a probabilistic decision.
I would resist creating a separate “AI operations” model around this. If an agent participates inside a workflow you already operate, the surrounding process can continue to provide the operational structure before and after its decision.
The agent can introduce variability without making the entire process variable.
What boundaries reveal
Looking at your workloads this way may tell you as much about your cloud operating model as it does about AI. Some will be obvious candidates for more autonomy. Others may work well within one environment but still rely on a polling process, script, local scheduler or manual handoff at the boundary with another.
Individual tools don’t have to be falling short for this to be true. Cloud-native and application-specific services can work well within their domains while the business process remains fragmented between them.
Your AWS estate is one useful place to look for those boundaries. As you’ve expanded cloud adoption, workloads may have grown up around AWS-native services that work well on their own but sit outside the RunMyJobs orchestration you use for wider business processes. AI makes those boundaries more consequential.
Schedule an AWS orchestration reviewwith a Redwood Software expert to identify opportunities to extend RunMyJobs across your cloud and hybrid workloads.
Build around what needs to last
Models and agent frameworks will continue to evolve, just as the cloud services, data platforms and applications underneath them have evolved. The execution logic behind your critical business processes has a different lifespan, and I think that distinction matters.
The RunMyJobs Model Context Protocol (MCP) server gives compatible AI tools a standard way to interact with the automation you already run. The architectural advantage is that years of process logic don’t have to move into whichever agent happens to be in use today. Keep that logic in the workflows your teams already operate and improve. Let agents contribute judgment where it adds value, while the dependencies, operational controls and recovery paths around that judgment remain durable as models and interfaces change.
That also gives you a useful way to look at the rest of your cloud estate. Where does business context become thinner? Where does execution move outside the operating model you trust? Those are the places where extending orchestration may matter more than adding another layer of intelligence.
Your cloud providers are good at what they do. On AWS, Glue transforms data, Step Functions coordinates serverless workflows and EventBridge routes events. Azure and Google Cloud have their own equivalents, and each one reliably handles the steps inside its own boundary.
The problem is that your most important business processes rarely stay inside one boundary. A month-end report might start with an extract from an on-premises database, pass through several AWS services and finish in a data warehouse that Finance reviews at 8 AM. An invoice might arrive from a supplier, get matched in AWS and need to be posted to SAP before the payment run.
Every service in either chain can report success while the business process still fails. A green Glue job doesn’t prove the source data was complete. A completed Step Functions workflow doesn’t prove SAP received the result. Each service sees its own part of the process, but someone still has to own the whole thing.
1. The hybrid data pipeline that starts outside AWS
Picture a common pipeline. Every night, a legacy on-premises system (an Oracle E-Business Suite instance, a plant-floor database or a warehouse management system) exports data. The file lands in Amazon S3, AWS Glue transforms and catalogs it and the results load into Snowflake, where an analytics dashboard refreshes before the business day starts.
Inside AWS, S3 stores the data reliably and Glue handles the transformation at scale. Neither can tell you whether the on-premises extract finished late, arrived partially or never arrived at all.
These failures tend to fly under the radar. A late extract can leave Glue processing yesterday’s data without complaint. A partial file can produce a dashboard that looks plausible but is wrong. And the hardest case is a step that never triggers at all, because there’s no error — just an absence. Someone notices when a report looks stale, often hours or days later, and the investigation starts with a simple question: where did the process break?
Bringing the full chain under RunMyJobs adds the context the individual services don’t have:
Dependency-based sequencing: The S3 landing, Glue job and Snowflake load wait for the on-premises extract to complete and pass the checks you define.
One view of the chain: Operators can see status and projected completion without moving between consoles and teams.
An SLA on the business outcome: RunMyJobs can track whether the dashboard will be ready by 8 AM and warn the team before that deadline is at risk.
Faster failure identification: When something goes wrong, you know which step failed, or which one never started, without piecing it together across teams and tools.
Less custom code, less wasted compute: Pipelines run when the data is ready, not on a fixed polling schedule that burns compute checking for files that haven’t arrived.
RunMyJobs doesn’t replace Glue or S3. It governs the process they belong to, including the part that starts outside AWS.
2. The SAP invoice that needs AWS to finish its job
AWS publishes reference patterns to show how its services fit together, and many real projects start from one. A good example uses Amazon AppFlow, Amazon Textract and AWS Step Functions to automate invoice matching against SAP S/4HANA data. It’s a useful picture of the processing inside AWS.
Production architecture also has to account for what surrounds that processing. What starts the workflow? How does it know the SAP data is current? What posts the result? Will the work finish before the next payment run?
Those questions are often answered with custom triggers, scripts and point-to-point integrations that never appear on the reference diagram. That hidden coordinsssation creates the risk of matching against stale SAP data, missing a handoff back to SAP or allowing a payment run to proceed after an overnight failure. It also creates code that has to be retested when SAP or an AWS service changes.
The architecture below adapts the AWS pattern from sales orders to a common accounts payable scenario based on purchase orders and goods receipts. The AWS example matches invoices against sales orders. Here, we use the version most accounts payable teams know as a three-way match, where the invoice, purchase order and goods receipt all have to agree.
The AWS Step Functions connector lets existing Standard state machines be imported as reusable RunMyJobs job definitions and run alongside SAP jobs. The AWS workflow keeps the branching, retries and parallel processing it was built for. RunMyJobs adds the cross-system dependency graph, SLA and operational history around it. Step Functions still owns the matching workflow. RunMyJobs coordinates the work around it as part of the full procure-to-pay process:
RunMyJobs picks up supplier invoices as they arrive, lands them in Amazon S3 and confirms the batch is complete
It checks that SAP has finished posting the latest purchase orders and goods receipts, then copies that data into Amazon S3 so the workflow can compare it with the invoices
It starts the state machine with business context such as company code, period and batch
It monitors the execution until it succeeds, fails or times out and can stop it if an upstream problem makes the result unsafe to use
When matching succeeds, it posts the result to SAP S/4HANA through the appropriate standard API using the native SAP connector (with no custom ABAP code)
It tracks completion against the scheduled payment run’s cut-off and warns the team if the process is at risk of missing it
It routes invoice exceptions to Accounts Payable and can open a ServiceNow incident when the process threatens the SLA
Architecture adapted from the aws for sap blog referenced above. Click to enlarge.
The payment run is usually a separate process on its own schedule, so the architecture treats its cut-off as a deadline rather than the next step. If RunMyJobs also schedules the payment run, some finance teams may choose to hold it when invoice processing fails. That adds control at a critical close and delays correctly posted invoices until the run is released.
This also supports a cleaner SAP core. Pre-built SAP connectors and standard interfaces reduce the custom ABAP and tightly coupled integrations that otherwise accumulate around cross-system processes. RunMyJobs is the only workload automation and orchestration platform that is an SAP Endorsed App and part of the RISE with SAP reference architecture.
3. The reconciliation break that needs judgment, not a queue
The third opportunity starts with a process you may already run in RunMyJobs.
Take reconciliation. The job compares the general ledger with a bank feed or sub-ledger, and it runs reliably at scale: one customer’s reconciliation job runs about 52,000 times a year. When a comparison fails, however, the result may be little more than a red status. Then someone has to pull data from every system involved, find where the values diverged, determine the cause and decide whether to fix the break or escalate it. In a complex reconciliation, that investigation can span as many as nine systems.
That’s skilled detective work, but much of it is evidence gathering. It also gets harder as the process becomes more reliable. Breaks become rarer, so fewer people remember what the usual issue looks like, and each investigation starts cold.
Agent Studio in RunMyJobs lets you build a governed agent and add it to the reconciliation job chain you already have. When a break occurs, the agent:
Checks the same upstream systems an analyst would
Proposes the most likely cause
Resolves a recurring pattern it’s authorized to handle
Escalates a new or consequential case, with the investigation already attached
Imagine a break shows up at 6 AM on the last day of the month. The bank feed and general ledger differ by a few cents across dozens of lines. Without help, that’s the first hour of an analyst’s day. Instead of asking an analyst to begin with only the fact of failure, the agent can trace the difference to an FX rounding pattern, collect the supporting evidence and either apply an approved resolution or send the worked-up case to a person.
The deterministic reconciliation process still handles every transaction. The agent only acts when a case needs judgment, concentrating AI use on the exception path rather than the full transaction volume. Because the agent runs as a workflow step, it inherits the workflow’s
governance and observability. You define its skills and tools, set timeout and cost controls and decide which patterns it may resolve or must escalate. The audit trail shows what the agent did in the context of the process that called it.
Coming next for the AWS Step Functions connector
The next planned update to the connector would bring:
Execution results returned to RunMyJobs: Downstream steps could use a completed state machine’s output directly without a separate storage handoff.
Express workflow support: RunMyJobs could start Express state machines synchronously or asynchronously.
Express discovery and import: Teams could list Express state machines and bulk-import them as RunMyJobs job definitions, as they can with Standard workflows today.
Where to extend RunMyJobs next
Not every AWS activity needs RunMyJobs in front of it. Start with a business-critical process that crosses a boundary: an on-premises extract feeding AWS, an SAP process waiting on a state machine or an automated job that still hands every exception to a person.
Then ask who owns visibility across the whole thing. If the answer is “nobody,” that’s where to extend RunMyJobs next.
Schedule an AWS orchestration reviewwith a Redwood Software expert to identify where RunMyJobs can add visibility and control across your hybrid cloud workloads.
For the past decade, cloud was the “new frontier.” It redrew the map of enterprise IT, opening new territory for applications, data and business services. Organizations could build faster, support more use cases and deploy technology into more areas of the business. That delivered enormous value, but with it created unmitigated sprawl: the number of systems where business-critical work happens has expanded.
Over time, the complexity spiraled out of control. Cloud services, SaaS applications, data platforms and systems of record became interconnected parts of the same business processes. Highly connected enterprise applications calling cloud services that start data pipelines, update SAP and then open ServiceNow tickets is the new norm. Paths like this are the result of years of useful IT investment.
AI is the next wave moving across that landscape, and executives are challenging every business function to use it to scale operations and increase capacity. Many are building agents to solve business problems: everything from managing calendars and email to investigating production errors and resolving process exceptions. In a 2026 Deloitte survey, 74% of leaders at organizations already piloting agentic AI expected nearly half of their business processes to be redesigned or rebuilt around AI agents within four years. As the industry wrestles with the transition from AI agents doing low-risk, read-only tasks to taking action in highly sensitive production environments, we’re watching a new class of workload emerge in an already complex hybrid IT operating model.
How do we manage the risks and value of this new type of workload? IT Ops has an opportunity to establish a consistent way for agents to act across the enterprise. Hybrid cloud orchestration builds on each environment’s native controls, keeping workflow policies, safety mechanisms and business context attached to an agent-initiated action as it moves across the hybrid estate. Each agent may have only a part of the overall context, and the intelligence ends at the border of its reach within a system. Productive autonomy depends on agents being capable of exploring new possibilities while acting through execution paths the enterprise can trust, across many different systems.
Commoditized agents make governed execution more valuable
Managed models, cloud AI services, copilots, low-code builders and agent frameworks have dramatically compressed agent development time. A team can now turn an idea into a polished demonstration before asking IT Ops how the agent will authenticate, which systems it can change or who will own the outcome. As more teams build agents, the cost of supporting each new use case will depend on how much execution logic, policy and recovery handling they can reuse.
When an agent moves from investigating a production error to restarting a service, rerunning a pipeline or rolling back a deployment, it crosses from reasoning into production execution. That creates a familiar challenge for IT Ops: give the agent enough authority to resolve the issue quickly, with safeguards that prevent an accidental database deletion from becoming front-page news. The operational disciplines are established, and we’re just changing the actor from an IT Ops engineer to an AI agent.
The boundary is between reasoning and execution:
The agent interprets context, evaluates options and selects or proposes an action
The execution layer applies policy and guardrails, validates dependencies, invokes the approved workflow and records the outcome
That distinction between reasoning and action becomes even scarier when it crosses multi-cloud and hybrid cloud boundaries. Each environment has its own native controls, such as AWS, Microsoft Azure, Google Cloud, SaaS applications, private clouds and on-premises platforms. An action may still begin in AWS, move through Snowflake and SAP and finish in an on-premises database. A control plane limited to one environment isn’t well equipped to establish whether the full cross-system process was properly authorized and completed as intended, and the risk is probably too great of getting it wrong.
Orchestration transports the context in between the handoffs: why the action ran, whether dependencies and approvals were satisfied and, most importantly, whether the process achieved its intended outcome. You get one governed workflow instead of having to reconstruct the path from disconnected system events.
Probabilistic reasoning needs deterministic rails
As agent development spreads across the enterprise, we have to build zero-trust safety nets into AI execution models in order to scale. An agent may choose different paths as conditions change and can revise its diagnosis as new evidence arrives. Workflows that validate AI decisions, data and results can enforce approval requirements for production rollbacks, check downstream readiness and follow a defined recovery path if execution fails.
Cloud-native controls, model policies and platform guardrails already protect their respective domains. Orchestration connects them at the process level, carrying dependencies, approvals, scoped credentials, SLA context, downstream visibility, recovery paths and the audit record across SaaS applications, cloud providers and data centers. The agent invokes an approved workflow, while event-driven orchestration manages how the action proceeds across the estate.
This approach turns existing workload automation into shared execution infrastructure. Recovery workflows, data pipelines and finance processes can support multiple agents, with improvements applied wherever the workflow is called. Model Context Protocol (MCP) standardizes connections to tools and resources, and Agent2Agent (A2A) supports collaboration between agents. The orchestration layer supplies the operating context and control.
A practical AI readiness test for IT Ops
The value of agent adoption becomes measurable when teams define a pre-agent baseline and compare the same metrics across a consistent scope of work. For IT Ops, those metrics may include automation coverage, manual handoffs, SLA attainment and, for recovery use cases, MTTR. The Tokenomics Foundation’s AI value classification framework also recommends accounting for whether outputs meet an established quality threshold and for any new review, rework or escalation the AI creates. This produces a more defensible view of AI’s impact than gross efficiency gains alone. To deliver that value at scale, organizations must expand agent-driven work without adding more coordination work for IT Ops.
The following questions test that foundation:
Can the agent-initiated action be traced from request to outcome across public cloud, private cloud, SaaS applications, data platforms, enterprise applications and on-premises systems?
Does the agent have the context of every system and the resulting automation goal as it crosses environments?
Does its authority remain scoped as the workflow crosses identity and permission models?
Do dependencies, approvals, service-level requirements and recovery policies remain enforceable regardless of where the agent originates?
Is operational ownership clear, and can the responsible team see the end-to-end process state and intervene while work is in flight?
Can the agent invoke existing automation without creating another integration and governance model?
The strongest starting point is a workflow whose intent, authority and accountability are already established and whose operational outcome is measurable. Your team can then apply what worked to subsequent use cases.
The operating advantage grows as more agents use workflows the enterprise has already invested in and validated, extending automation with controls and context in place.
RunMyJobs by Redwood provides the hybrid cloud orchestration layer for this model, giving agents a governed path into existing workflows across cloud services, SaaS applications, data platforms, enterprise applications and on-premises systems.
