Quick read · 8 min read
You can connect decades-old mainframe systems to modern cloud services without replacing them, if you design the agent layer for auditability, safe retries, and human oversight from day one.
Key takeaways
- Agents work best as translators and coordinators between old and new systems, not as replacements for either.
- Every agent action on a mainframe needs a clear audit trail and a way to undo it if something goes wrong.
- Reading screens directly is brittle; wrapping old programs as callable services and reacting to message queues are more reliable.
- High-risk actions need human approval built into the workflow, not bolted on after an incident. <!-- omnithium-quick-read:end -->
Agentic middleware can bridge your mainframe and modern systems without rip-and-replace. It works if you design for auditability, idempotency, and human escalation from day one. Don't treat the agent as a chatbot or an RPA bot. Treat it as a governed translation and orchestration layer.
Your mainframe isn't going anywhere. The CICS transaction that processes account inquiries has run for 30 years without an unplanned outage. The COBOL batch job that closes the general ledger at 2 AM has never missed a cycle. Mobile teams ship every two weeks. Fraud models run in the cloud. Customers expect real-time responses. The gap between these worlds is a translation problem, not a technology problem.
Rip-and-replace died in the boardroom when someone calculated the risk. API wrapping stalled because exposing a CICS program as a service means touching 40-year-old COBOL copybooks. Screen scraping works until a BMS map changes and the parser breaks at 3 AM. The mainframe stays isolated. Every integration becomes a one-off project with a six-figure price tag and a three-month timeline.
The real problem is the translation layer. Modern systems speak JSON, GraphQL, and event streams. The mainframe speaks CICS transactions, IMS segments, MQ messages, and 3270 screen flows. Someone has to sit in the middle and translate, coordinate state, and enforce policy. That used to be a team of integration engineers writing custom adapters. Now it can be an agentic middleware layer.
Architecture that holds up
The agent has three roles: protocol adapter, state coordinator, and policy enforcer. It speaks CICS on one side and REST on the other. It tracks transaction boundaries across both worlds. It checks every action against your security and compliance rules before execution.
Agentic Middleware as a Translation and Policy Plane
Click through the layers to see how agentic middleware sits between mainframe transaction systems and modern APIs, translating protocols and enforcing policy without bypassing legacy integrity.
The layered architecture separates concerns. At the bottom, you have the mainframe integration surface: CICS regions, IMS databases, MQ queues, batch job schedulers, and RACF or ACF2 security boundaries. At the top, you have modern systems: mobile APIs, cloud services, event streams, and data platforms. In the middle sits the agentic middleware plane: protocol adapters, a policy engine, and a state store that tracks in-flight transactions and their compensation paths. We wrote about this control plane pattern in The Agent Control Plane Is the Product.
Translation patterns aren't one-size-fits-all. API wrapping works when you can expose a CICS program as a service with a stable contract. Event-driven bridging works when you need to react to MQ messages or batch job completions asynchronously. Screen scraping is the fallback when neither is available. It's the most brittle option because 3270 and BMS screen layouts change without warning.
Mainframe Translation Patterns: Trade-offs
Compare API wrapping, event-driven bridging, and screen scraping across reliability, maintainability, security, performance, and ease of implementation to choose the right approach for your integration.
Transaction semantics are where most architectures fall apart. A two-phase commit across a mainframe and a cloud database doesn't work reliably. You can't hold a CICS transaction open while a cloud API call times out. Instead, you need compensating transactions. If the cloud call fails after the mainframe commit, the agent executes a defined undo action. Every agent-initiated transaction needs an idempotency key so retries don't duplicate orders, payments, or inventory updates.
Hybrid Transaction Flow with Compensation and Audit
Trace a mobile request through agent translation to a CICS transaction and back, including failure handling that triggers a compensating action and logs every step.
Where teams fail
The most common failure is treating the agent as a black-box RPA bot and bypassing existing transaction integrity. The agent fires off a CICS transaction, the cloud call fails, and no compensating action is defined. You get a partial commit: the mainframe thinks the order shipped, the cloud thinks it didn't, and reconciliation takes a week. Define a compensating transaction for every cross-system write before the agent goes live. Add idempotency keys to every agent-initiated call so retries don't duplicate orders, payments, or inventory updates.
Over-permissioned credentials are the second failure. If the agent holds a RACF account with broad authority, a prompt injection or compromised agent can issue privileged commands. Use least-privilege session management. The agent gets scoped credentials for specific transactions, nothing more. Log every session, including the exact CICS transaction ID, input parameters, and return codes.
Batch windows are another trap. Agents that trigger online transactions during batch cycles create lock contention and deadlocks. Your mainframe team knows the batch schedule. The agent must know it too and respect it. Implement a batch-aware scheduler that blocks or queues agent-initiated transactions during critical batch windows.
Screen scraping deserves special caution. It is not equivalent to API integration. When a BMS map changes, hidden fields shift, or a new screen is inserted, the parser breaks. Use explicit schema mapping from COBOL copybooks, not fuzzy parsing. Run regression tests against a mainframe test region every time a screen changes. Version the screen maps alongside the agent code.
The final failure is autonomy without escalation. If the agent can approve high-risk actions without human review, you've built a compliance violation generator. High-risk actions need human approval thresholds built into the policy engine, not bolted on after an incident. We covered this pattern in depth in our piece on high-stakes decision making.
Measuring progress
Measure the agent layer with three signals: adoption, risk, and cost.
Adoption: count the number of CICS transactions, MQ queues, and batch jobs the agent mediates. If that number stays flat after six months, the architecture isn't earning its keep. Track not just total count but the percentage of new integration requests that go through the agent layer instead of a custom adapter.
Risk: track how many agent actions required human approval, how many were denied, and how many compensating transactions fired. A healthy system shows a small but nonzero approval rate for high-risk actions, typically 1 to 5 percent of total actions. The compensating transaction rate should match your cloud API failure rate. If compensations never fire, either your cloud dependencies are unusually reliable or the agent isn't actually tracking failures. Log every compensation with the original transaction ID and the undo action taken.
Cost: measure the time from integration request to production. Before agentic middleware, a new mainframe-to-cloud integration took months. With a working agent layer, the same integration should take weeks, because protocol adapters and policy engine are already in place. Track cycle time per integration, not just total count. A healthy target is under three weeks for a new CICS-to-REST bridge.
Observability ties all three together. Correlate agent actions with mainframe SMF and RMF data, and propagate OpenTelemetry context across the legacy boundary. Without that correlation, you can't tell whether a slow transaction is the agent's fault or the mainframe's. Add a trace ID to every CICS transaction the agent initiates, and log it in both the agent's state store and the mainframe's SMF records.
Operating model
The operating model matters more than the technology. Who owns the agent policies? Who reviews translation mappings when a COBOL copybook changes? Who decides when a human approval threshold gets raised or lowered?
The answer is a joint team. Mainframe engineers own the integration surface: CICS regions, MQ queues, batch schedules, RACF profiles. Cloud engineers own the modern side: APIs, event streams, policy engine configuration. Neither team can own the agent layer alone, because the agent sits exactly where their domains meet. Define a change review board with representatives from both sides. Every translation mapping change requires sign-off from a mainframe engineer and a cloud engineer.
Change management for agent behavior is a production discipline, not a development afterthought. Every change to a translation mapping, a policy rule, or an approval threshold needs a versioned rollout with rollback. Store agent policies in version control, and deploy them through the same CI/CD pipeline as the agent code. We wrote about this lifecycle in Agentic AI Lifecycle Management.
When the agent misbehaves, you need a defined response, not a postmortem three weeks later. A red card system pauses the agent, quarantines affected transactions, and routes them to a human operator. Define the red card criteria in advance: more than N compensating transactions in a 10-minute window, or a policy violation on a high-risk action. We covered that pattern in Red Cards in Agentic AI.
Agentic middleware, designed with auditability, idempotency, and human escalation from day one, can make legacy and modern systems mutually intelligible. That's the bridge. Build it carefully.
