AI Agents in PeopleSoft in Weeks, Not Months

Everyone is looking at AI agents right now. Every vendor demo includes one. Every executive briefing mentions them. Every IT roadmap has a slot for “AI integration” somewhere on the next page. The version of that question I keep getting from PeopleSoft customers is the practical one: how do we actually let an AI agent work with PeopleSoft, without turning it into a year-long custom development project?

The answer is a lot less painful than most teams expect. This is the exact use case that the SWS (Simple Web Services) integration product excels at. SWS is the PeopleSoft-aware API layer that sits between your data and any consumer — whether that’s a mobile app, a partner integration, or an AI agent. It handles all the PeopleSoft-specific logic so the thing on top can just ask for the data it wants and get clean JSON back.

Sometimes the agent in question is Claude. Sometimes it is Copilot. Sometimes it is an in-house tool a team built for itself. The name changes, but the question does not. It changes every week! The good news is that the pattern for connecting an agent to PeopleSoft is pretty stable, and SWS fits into that pattern nicely. You can have a working agent integration in a matter of weeks, not months.

Here is the honest answer: an agent can’t talk to PeopleSoft directly, and you wouldn’t want it to. An agent doesn’t know what an EMPLID is. It doesn’t know that JOB is effective-dated and sequence-numbered. It doesn’t know that the description for a service indicator code lives in an SRVC_IND_CD_TBL table. What agents do know how to do is call tools — small, well-defined functions that return JSON. The protocol they use to find and call those tools is MCP, the Model Context Protocol.

So the real question is not “can we connect an agent to PeopleSoft.” It is: how quickly can you stand up the tools an agent needs, keep the security sane, and avoid turning every new use case into another long project?

That is what this post is about. And yes, I am biased because I built SWS and I am actively looking to sell more licenses. Still, I think the answer in 2026 is genuinely much better than it was even a year ago.

What MCP Actually Is

If you haven’t paid attention to MCP yet, here’s the one-paragraph version. MCP is an open protocol Anthropic published so that AI agents can discover and call external tools in a standardized way. An MCP server is a process you run that advertises a list of tools (think: lookup_student, check_holds, get_gl_balance) and a JSON shape for each one. The agent picks the right tool, fills in the arguments, and your server runs the call. The server talks HTTP/JSON to whatever backing system it wraps.

The backing system is your problem. MCP doesn’t know anything about PeopleSoft. It just expects you to give it clean JSON when it asks.

The Part That’s Always Hard: PeopleSoft

Anyone who has ever tried to expose PeopleSoft data to a “modern” REST consumer knows the list. Effective dates. EFF_STATUS. Sequence numbers. XLAT codes. Prompt-table descriptions. Parent-child key inheritance. Row-level security tied to permission lists.

For a human staring at a PIA page, all of that is invisible. The page does it for you. The moment you try to expose the same data over a REST endpoint, that invisible work becomes your problem. You write PeopleCode to filter for the current effective-dated row. You write more PeopleCode to decode XLAT values. You write joins to pull descriptions from prompt tables. You build pagination. You write tests. Multiply by every record you want to expose, and you are months into a project before any agent has seen a single byte. The development lifecycle can be long as I have documented in SWS Alternatives — and that is just for the first cut. Every time you want to tweak the data shape, add a new field, or fix a bug, you are back in PeopleCode. That is the kind of project that ends an AI pilot.

You often need to iterate quickly on the data you expose to an agent. You don’t always know in advance what the right shape is, and you want to be able to adjust on the fly as you see how the agent uses it. If every change requires a PeopleSoft development cycle, that iteration is going to be slow and painful. SWS can help speed up that cycle dramatically.

Why SWS Is the Right Spine

SWS is the PeopleSoft-aware layer that keeps this from turning into a custom coding exercise. The important thing for this conversation is that SWS is configuration-driven, not code-driven. New web services aren’t written — they’re defined in a configuration table using a syntax called PsoftQL . You describe what records you want, how they relate, and any filters; SWS reads PeopleSoft metadata at runtime and handles the rest. You can see a range of PsoftQL examples in the SWS docs — joining records, filtering, sorting, scoping fields, and so on.

Once a service is configured, SWS exposes it at a standard REST URL with query string parameters. Anything that can make an HTTP call can use it:

GET /PSIGW/RESTListeningConnector/PSFT_CS/CHG_SWS_PSOFTQL/student_profile?emplid=KU0001

No PeopleCode. No new Integration Broker service operation per endpoint. The URL is uniform across services, the response is JSON, and the same endpoint can be called by a browser, a curl command, an MCP shim, or a mobile app.

That is the part that matters for MCP. New tools stop being mini-projects. You add a configuration, test it, tweak it, and move on. If the first cut of a tool is close but not quite right, you adjust the config and try again. That kind of short feedback loop matters a lot when you are figuring out what agents are actually useful for.

The same security model that protects everything else in PeopleSoft protects this: an OPRID with a permission list, a service operation, and optional row-level filters.

The Pattern: Agent → MCP Server Shim → SWS → PeopleSoft

Before we get to the three examples, it’s worth being precise about why this needs to be a layered architecture — and specifically why PeopleSoft can’t just be the MCP server itself. I get asked this a lot, so let’s walk through it.

Here’s what the full stack looks like:

  flowchart LR
    Agent["AI Agent<br/>(Claude, Copilot,<br/>in-house)"]
    MCP["MCP Server<br/>Go binary"]
    SWS["SWS"]
    PS["PeopleSoft<br/>System of Record"]

    Agent <-->|"MCP protocol<br/>JSON-RPC"| MCP
    MCP <-->|"HTTP / JSON<br/>Basic Auth"| SWS
    SWS <-->|"PsoftQL<br/>metadata-aware"| PS

Three layers between the user and the data. Each one is doing exactly one job.

Why PeopleSoft can’t serve MCP directly

You can absolutely build REST endpoints on PeopleSoft. That is not the question. The question is whether PeopleSoft is a good MCP server. I do not think it is, and the reasons are pretty practical.

MCP is not just “some REST calls.” It has an initialize handshake, a tool catalog, and a call pattern built around a long-lived server process. Depending on how you deploy it, it may also want stdin/stdout or Streamable HTTP with server-sent events. Those are normal MCP primitives. They are not normal Integration Broker primitives.

Could you force that into PeopleSoft with custom PeopleCode? Probably. I would not. You would be building protocol glue in the slowest place to iterate, and you would own that glue forever. Worse, you cannot really lean on agents to help you write PeopleSoft code yet, which makes that path even less attractive.

MCP servers are long-lived processes. The MCP runtime wants to start the server once, keep the connection around, and reuse it across many calls in a session. PeopleSoft’s request model is still request-by-request into the app server. The two models do not line up naturally.

Co-deployment matters. Agents often want the MCP server to run near them, sometimes literally on a developer laptop as a subprocess and sometimes in a sidecar container next to the agent host. You do not want every one of those protocol details living inside PeopleSoft.

Identity is different. An MCP server holds one service identity that it presents to the backing system. PeopleSoft’s auth model is session-per-OPRID. Bridging that gap is doable, but it’s friction you don’t want sitting at the protocol layer. A seperate MCP shim can do more sophisticated credential handling if you need it, without forcing you to build that logic into PeopleSoft itself.

The mismatch is not fatal. If you really wanted to shoehorn MCP onto Integration Broker, you probably could. I just think it is the wrong fight. The cleaner architecture treats PeopleSoft as the data and lets a small, modern process handle the protocol. Stack of responsibilities:

  flowchart TB
    subgraph A["Agent runtime"]
        A1["Decides what to ask<br/>Picks tools<br/>Composes answers"]
    end
    subgraph S["Protocol shim (Go)"]
        S1["Speaks MCP to the agent<br/>Speaks HTTP to SWS<br/>Holds service credential"]
    end
    subgraph D["Data layer (SWS)"]
        D1["Understands PeopleSoft metadata<br/>Effective dates, XLAT, joins<br/>Permission-list security"]
    end
    subgraph P["PeopleSoft"]
        P1["System of record<br/>Actual data"]
    end
    A --> S
    S --> D
    D --> P

Why a shim, and why I usually pick Go

The shim is the adapter in the middle. It exists because the agent speaks MCP and the backend speaks HTTP, and somebody has to translate. Its job is short:

• Advertise a tool catalog when the agent asks for one
• Accept tool invocations from the agent
• Build the right URL and GET it against SWS
• Hold the SWS service credential
• Hand the response back up to the agent

That is almost the whole story. There is no business logic here. There should not be any real PeopleSoft knowledge here either. It is just a protocol translator.

You do not have to use Go. Python, Node, or .NET can all do this job. I usually reach for Go because it makes this kind of small, long-lived utility pleasantly boring. The standard library already handles HTTP and JSON well. The output is a single binary. It starts fast, runs anywhere, and does not come with much runtime baggage. That is a nice fit for MCP servers, especially when agents are spawning them locally.

A reasonable MCP server on top of SWS is not very large. Most of the code is just tool definitions. The part that actually calls SWS is tiny.

Why SWS Sits Behind the Shim

The shim handles the protocol. SWS handles the data. More importantly, SWS handles the part that would otherwise pull you back into custom PeopleCode: effective-dating, parent-child key joins, XLAT decoding, prompt-table lookups, pagination, caching, and the security stack we talked about earlier. The shim does not need to know any of that. It builds a URL and reads JSON back.

This separation is the part I find most useful in practice. Once the data API exists in SWS, the same SWS endpoints can power:

• MCP servers for agents
• Mobile apps
• Partner integrations
• RAG indexing pipelines
• Internal dashboards in whatever stack your team likes
• Future protocols that don’t exist yet

You are not building “the MCP layer.” You are building one data API and several thin protocol shims — one per surface — and the protocol shims are short, boring, and replaceable.

What a Single Call Looks Like

Concretely, here’s what happens when an advisor asks an agent “what holds does Maria have?”:

  sequenceDiagram
    actor User as Advisor
    participant Agent
    participant Shim as Go MCP Server
    participant SWS
    participant PS as PeopleSoft

    User->>Agent: "What holds does Maria have?"
    Agent->>Shim: tools/list
    Shim-->>Agent: catalog of student tools
    Agent->>Shim: student_search(last_name: "Garcia")
    Shim->>SWS: GET /compass/person/search?...
    SWS->>PS: PsoftQL on PERSON + NAMES
    PS-->>SWS: rows
    SWS-->>Shim: nested JSON
    Shim-->>Agent: tool result
    Agent->>Shim: student_holds(emplid)
    Shim->>SWS: GET /compass/student/{emplid}/holds
    SWS->>PS: PsoftQL on SRVC_IND_DATA + XLAT
    PS-->>SWS: rows, descriptions decoded
    SWS-->>Shim: nested JSON
    Shim-->>Agent: tool result
    Agent-->>User: "Maria has two holds: ..."

The agent decides what to ask. The Go shim translates each ask into an SWS URL. SWS does the metadata-aware query against PeopleSoft. The response flows back up the stack, getting progressively closer to natural language as it goes. None of the layers know what the others are doing internally, and they don’t need to.

With the pattern out of the way, here are three places it pays off.

Example 1 — Campus: An Advising MCP Server

This is the easiest one to picture because I’ve already built most of it as a demo. There’s a reference application called Compass — a staff-facing student-success board — that I use to show what SWS can do for Campus Solutions. Every backing call Compass makes is exactly the kind of call an MCP server would make.

Wrap those same SWS endpoints with an MCP server and you have something like this set of tools:

• student_search — fuzzy search by last name plus last four of SSN
• student_profile — PERSON with NAMES, EMAIL_ADDRESSES, PERSONAL_PHONE
• student_enrollment — STDNT_CAR_TERM with STDNT_ENRL as a child, current term auto-selected
• student_holds — SRVC_IND_DATA with the reason codes already decoded
• student_milestones — STDNT_MILESTONE filtered to outstanding items

The advisor asks the agent something like “What’s blocking Maria from registering next term?” The agent calls student_search, then fans out to student_holds and student_milestones on the EMPLID it got back. Two SWS calls. Both come back as clean JSON with the indicator reasons in plain English instead of three-character codes. The agent composes the actual answer in advisor-friendly language. The advisor reads it and acts on it.

The important part is how little ceremony there is behind the scenes. Nobody had to build a custom REST endpoint for each of those calls. Every backing call is an SWS configuration row, which means adding the next tool is usually fast too.

Example 2 — HR: A Manager Self-Service MCP Server

The HR use case is structurally similar, with a different cast of records. Tools you’d want:

• employee_profile — PERSON with current JOB row as a child
• direct_reports — JOB filtered by SUPERVISOR_ID
• position_data — POSITION_DATA with effective-dated history
• compensation_history — current and prior compensation rows
• benefits_summary — active benefit elections, decoded

A manager asks the agent “Show me my team’s tenure and most recent comp action.” The MCP server pulls direct_reports for the manager’s EMPLID, then iterates compensation_history for each report. SWS handles the effective-date logic so the agent doesn’t have to. The agent formats the result as a table.

The security story is where this gets interesting. The MCP server’s OPRID is scoped by permission list to only see employees the manager has access to under your existing row-level security rules. If the OPRID can’t see a row through SWS, the MCP server can’t return it, and the agent can’t speak about it. You don’t write any new security code to enforce this — you reuse the same controls you already use for your HR self-service.

Example 3 — Finance: A Ledger and Budget MCP Server

Finance has a different shape from the first two examples. Most of the interesting Finance queries are aggregations across the ledger or commitment-control tables — sums by chartfield, variance against budget, open commitments by department. That’s a better fit for SWS’s SQL-based services than for PsoftQL’s parent-child nesting. SWS supports both.

A reasonable starter tool set:

• gl_balance — period balance for an account / department combination
• budget_vs_actual — variance from KK_BUDGET versus posted ledger
• cost_allocation — distributed costs by cost center
• open_commitments — outstanding POs by department
• account_lookup — chartfield description lookups

An analyst asks the agent “What drove the variance in cost center 5100 last quarter?” The MCP server runs budget_vs_actual for that cost center, then pulls the top contributing accounts through gl_balance with paginated results. The agent aggregates and explains in plain English. The analyst spends thirty seconds on a question that used to be a half-day query exercise.

Finance is also where pagination and caching matter most. SWS handles both at the configuration level. You are not writing paging code by hand, and you can cache the slow-changing reference tables so the MCP server is not paying for them on every call.

Where This Leaves You

MCP is not going to be the last protocol that matters for AI. It is just the one the major agents speak today, and it is the one more teams are about to ask for by name.

If your PeopleSoft data is locked behind a pile of hand-built services, every new MCP server becomes a project. If it sits behind SWS, each new MCP server is mostly a thin shim and a handful of configurations. That changes the conversation. You stop asking, “Do we have time to build another service?” and start asking, “What tool do we want to try next?”

That gap adds up quickly.

If you want the broader argument for an API-first strategy on top of PeopleSoft, I wrote a longer post about it earlier this year. If you want to see what SWS actually does in detail, the SWS documentation is the place to start.

My advice is simple: pick one workflow, build one MCP server, and watch what happens. If the data layer is configuration-driven, that first experiment is much cheaper, and every follow-up iteration gets easier.

If you want to talk through how this would work in your system, or if you want to see a demo of SWS in action, reach out and we can set something up. The SWS team is actively looking for new customers and pilot projects, and we’d love to show you how it works.