A city wants its GenAI permitting agent to look up parcels on a legacy mainframe without giving the agent a direct mainframe session. Which enterprise integration approach best fits?

Enterprise GenAI integration with legacy municipal systems should front the mainframe with a controlled modern API—for example, exposing parcel lookup through Amazon API Gateway—so the permitting agent calls a tool rather than holding a direct mainframe session. That pattern keeps green-screen transactions and host security models intact while giving the GenAI agent a least-privilege, auditable contract for parcel data. API Gateway with authentication, throttling, and logging becomes the polite front door between the agent and decades-old civic systems of record. Embedding mainframe green-screen macros inside the foundation-model prompt fails because prompts are not a reliable or secure terminal automation layer; it also leaks operational coupling into unstructured text. Exporting the entire mainframe nightly to public S3 and letting the agent read raw dumps fails confidentiality and freshness: parcel data is sensitive or regulated in many jurisdictions, public buckets are inappropriate, and nightly dumps lag live permitting needs. Granting the agent unrestricted SSH into the mainframe LPAR fails least privilege and change control—agents must not receive ad hoc host access to core municipal systems. Exam caveat: an API façade still needs authoritative data mapping, caching rules, and clear error semantics when the host is down. Tool-calling agents can hallucinate parameters; validate inputs server-side at the API, not only in the prompt. Prefer read-only parcel lookup first before any write tools. Operational check: Confirm the agent’s tool definition points only at the Gateway parcel API; enforce IAM and auth on the API; log agent tool calls for audit; throttle per agent identity; and verify the mainframe account behind the façade is scoped to lookup operations required for permitting.