AI Agent Integration

Using SWS to expose PeopleSoft data to AI agents, chatbots, and RAG pipelines — field hiding, auto-descriptions, throwaway services, and identity flow patterns.
Tags:
Categories:

AI agents, chatbots, and Retrieval-Augmented Generation (RAG) pipelines need clean, structured data from systems of record. PeopleSoft is the system of record, but the path from PeopleSoft data to an LLM-friendly response normally goes through a development project — gather requirements, write a bespoke web service, migrate the code, encode the response, ship it. By the time the agent team gets the data, the prompt has moved on.

SWS shortcuts that loop. The data layer becomes configuration, and the agent team can iterate without an Application Designer migration for every change.

Why SWS fits agent use cases

  • Clean REST + structured JSON — what agent harnesses and tool-call frameworks expect.
  • Auto-resolved descriptions — codes like EFF_STATUS = 'A' arrive as Active so the model does not have to guess what A means.
  • Configuration-driven — agent teams can iterate on which fields and joins they need without a code change, in any environment including production.
  • Permission-list scoped — endpoints are gated by PeopleSoft security so an agent service account only sees what it should.
  • Standard PeopleSoft IB technology — no new runtime to operate, no new credential store, no new outbound dependency.

Make responses LLM-friendly

Hide fields you do not want the model to see

PeopleSoft tables routinely carry thirty to a hundred fields. Most are administrative (LAST_UPDATE_OPRID, audit timestamps, undocumented user-defined fields with leftover staging data). When an LLM sees those, it will often latch onto whatever looks important and reason about it — even when the field is irrelevant or wrong.

PsoftQL lets you list the fields to include, or explicitly exclude fields by name. Keep the response narrow. The model will be more accurate, the prompt will be cheaper, and the next person debugging a bad answer will not have to wonder where the model got the idea. See PsoftQL syntax for the include/exclude options.

Let auto-descriptions do the work

For every field that SWS recognizes as having a prompt table or translate value, the JSON response includes the resolved description alongside the raw code. The LLM gets "EFF_STATUS": "A" and "EFF_STATUS_DESCR": "Active" in the same payload. You do not have to teach the model your XLAT values; the data is self-describing.

For records where the default prompt resolution does not point at the right table — a custom staging table, an unusual setup record — an explicit prompt table override is on the SWS roadmap.

Stand services up cheaply, throw them away cheaply

Agent teams discover what data they actually need by trying things. SWS is suited to that loop because there is no migration overhead per endpoint. Build a PsoftQL configuration, expose it on a test path, point the agent at it, see what the model does with the response, change the configuration, retry. When the experiment is done you delete the configuration row — there is nothing to roll back.

This same pattern is what makes SWS useful for short-lived integrations more generally: conversion projects, one-off audit pulls, partner integrations that only need data for a quarter.

Reference architecture: chatbot with user identity

Most agent integrations need to scope answers to the end user. “What is my expense status?” must return my expense status, not the CEO’s.


@startuml

actor "End User" as user
participant "Chatbot UI" as ui
participant "Agent Server\n(trusted)" as agent
participant "SWS / IB" as sws
database "PeopleSoft" as ps

user -> ui: Question\n("what is my expense status?")
ui -> agent: HTTP + SSO token
agent -> agent: Resolve SSO\n→ EMPLID / OPRID
agent -> sws: GET /sws/.../expenses\nBasic Auth: service account\n?oprid={user_oprid}
sws -> sws: Auth service account\nBind :oprid → end user
sws -> ps: SQL with WHERE EMPLID = :oprid
ps -> sws: Rows
sws -> agent: JSON (with descriptions)
agent -> agent: LLM reasons over JSON
agent -> ui: Natural-language answer
ui -> user: Answer

@enduml

The pattern in one paragraph: your agent server is a trusted server. It authenticates the end user through your existing SSO, knows that user’s PeopleSoft OPRID (or can look it up), and then calls SWS as a single service account, passing the end-user identity as a request parameter. The configured SQL or PsoftQL binds that parameter (for example :oprid) to scope the query to that user. The full mechanics, including when to reach for PS token minting instead, are documented in Identity Flow & User Context.

What SWS does not do

SWS is the data layer. It is intentionally not:

  • An agent harness or tool-call framework. Use Claude, OpenAI, LangChain, your in-house framework — whatever fits your stack.
  • An LLM router or model hosting layer.
  • An embedding generator or vector store. For RAG, generate embeddings from SWS responses in your own pipeline.
  • A general-purpose write path. SWS focuses on GET endpoints. Writes to PeopleSoft remain a deliberate, audited concern handled through other Integration Broker patterns.

Keep SWS narrow on purpose. It exposes PeopleSoft data over REST cleanly enough that the agent layer above it can be anything you want.