In customer service, every AI agent — in chat, on the phone, by email, or an external assistant calling in over MCP — has to know what your business means: what makes a customer “eligible”, a case “resolved”, a request “urgent”, a delivery date “promised”. Writing that down as a formal ontology is slow and costly, and in customer service you rarely need to: most of it already exists in your service journeys. A customer service journey executed as Pega cases is an operational ontology: it names the intents, types the data, and defines the states, next valid moves, constraints, commitments and evidence. Agents can stay thin and read that meaning instead of carrying their own copy. You don’t need to build a separate knowledge model first. You need journeys that are “ontology-grade” — and at the end of this post there is a way to test yours in one afternoon, by letting an AI assistant interrogate your Pega Blueprint over MCP, before a single rule is generated, then import it into Pega Customer Service™. I ran it on a real Customer Service for Financial Services Blueprint — it works out of the box, and the result is below.
Where does the meaning live?
To resolve a customer’s request — a lost card, a disputed payment, a change of address — a customer service system has to know what “eligible”, “resolved”, “urgent” or “promised” means in your business. Every generation of customer self-service had to teach a machine that meaning. What changed is where the business logic lives, and how much of it you have to rebuild for the conversational agent.
- Intent-based bots (NLU chatbots, IVR menus). The bot team rebuilds the service logic inside the bot: intents and training phrases, dialog flows, API integrations, and a re-coded copy of the business rules. Every new use case is a new flow, and anything off-script ends in “Sorry, I didn’t get that.”
- Standalone GenAI agents (an LLM with instructions, RAG and tool calls). Language is no longer the problem, but the logic gets rewritten once more, this time as prose: eligibility in the instructions, policy in the knowledge base, actions as tools, limits as guardrails. Each agent carries its own copy, the copies drift from the real policy, and every change means re-prompting and re-testing each agent.
- Agentic journeys. The customer journey your contact center already runs — intents, data, rules, approvals, SLAs, audit trail — is the agent’s playbook. The conversational agent only has to understand and speak; the business logic is already there, natively, and it is the same one your advisors work with. Nothing to rewrite for self-service, and one place to change it.
That is the idea behind thin agents, thick journeys. A journey is more than a workflow: it follows the customer’s request end to end, across channels, agents and advisors, from the first message to “resolved”. An agent is a skill: understand a message, speak to a customer, read a document, call a partner. The journey holds what the business decides. Agents never hand over to each other; they hand over through the case.
Two kinds of ontology
An ontology is a shared, explicit model of a domain: its concepts, their relations and the rules that constrain them. Enterprise ontologies and knowledge graphs are useful, but they take time to build, and they describe the world rather than the work.
A customer service journey is a different kind of ontology: an operational one. It knows what the business works with — data objects with typed properties in the case’s data model — and it also knows what may happen in this case now — the current stage and the flow actions available from it — who may decide (personas and access roles), and what was promised (service-level agreements).
Here is what each ontology building block becomes in a Pega journey:
| Ontology building block | In a Pega journey | What the agent gets |
|---|---|---|
| Vocabulary | Case type, stage and step names and descriptions | The words to map a request to an intent |
| Classes and attributes | Data model, data objects, embedded data | Typed facts: card, transaction, amount |
| Relations | Parent and child cases; references between data objects | “This dispute belongs to this lost-card case” |
| States | Stages, steps, case status | Where we are, and what “done” means |
| Actions | Flow actions; steps exposed as tools (for example via MCP) | The closed list of next valid moves |
| Constraints | When rules, decision tables, validations | What must be true before acting |
| ★ Roles · authority | Personas, access roles, approvals, routing | Who may decide what |
| ★ Commitments · time | SLAs: goals and deadlines | What we promised, and by when |
| ★ Provenance · evidence | Case history and audit trail | Who did what, when, and on which evidence |
The last three rows matter most. Classic ontologies rarely model authority, time or evidence, and agents that act need them more than anything else.
A simple example: a stolen card
On Saturday night, Léa’s wallet is stolen. She opens her bank’s chat. The chat agent maps her message to the Report lost or stolen card journey, blocks the card and orders a new one. She points out a €212 payment she didn’t make, so it opens a Dispute transaction child case, and the journey’s rules grant a provisional credit.
On Sunday morning, Léa calls the bank. The voice agent has never spoken to her and shares no memory with the chat agent. It doesn’t need to, because it reads the case:
The voice agent knows nothing about the bank’s card policy or fraud process. It only reads what the case holds for the current step, and says it in plain words. Each part of its answer can be traced back to the case: the delivery date comes from the commitments, the credit from the related dispute, and the offer to change the address from the next valid moves. What it must not do, such as reverse the credit or close the dispute, is also written in the case, not left to a well-crafted prompt.
That is what “thin agent” means in practice: its knowledge is the journey’s, scoped to the step it is working on.
Why an operational ontology suits agents that act
- It is prescriptive. A descriptive model tells the agent what a card is. The journey tells it the three things it may do with this card now. At each step the agent works in a small, closed world, and that is where predictability comes from.
- It is executed, so it cannot quietly drift. A modeling document can go stale without anyone noticing. A case type is the running system, so if it is wrong, cases fail visibly and someone fixes the journey.
- It carries time and evidence. SLAs give agents commitments they can keep. Case history gives every agent, auditor and human expert the same account of what happened.
What the journey doesn’t know, and the minimum to add
A journey is not a complete enterprise ontology, and it doesn’t need to be. Three light layers cover most gaps:
- A glossary in the descriptions. Customers say “the machine ate my card”, not “ATM card retention”. Give each case type and step a use when / do not use when description. Agents read these descriptions to choose what to do, including external agents that discover your workflows via MCP.
- Links between journeys. Which journeys lead to others (a lost card can lead to a dispute), expressed as parent and child cases or handoff rules. For cross-domain questions, rely on shared data services, not a new ontology program.
- Reference knowledge. Fee schedules and policy wording belong in Pega Knowledge and Knowledge Buddy. The journey says what to do; knowledge says what is true.
Journeys plus these three layers make a minimum viable ontology. You build it one journey at a time, as a by-product of work you already do.
Is your journey “ontology-grade”?
Six checks before you put agents on a journey:
- Intents have boundaries. Each case type has a use when / do not use when description that a new colleague could apply.
- Data speaks business. Fields are typed and labeled with business words, not technical codes.
- “Done” has one definition. Each stage has clear exit criteria, and resolution statuses mean the same thing everywhere.
- Risk lives in rules. Every eligibility check, threshold and approval is a when rule or a decision table, never a condition hidden in a prompt.
- Promises are SLAs. Anything an agent may promise a customer has a goal or a deadline in the case.
- Actions are described. Every step an agent can take is exposed with a clear name and description.
Try it: interrogate your Blueprint over MCP, before a single rule exists
There is a quick way to score these six checks at once: give a new colleague only the journey — no training, no wiki — and see if they can answer Léa. Pega Blueprint is where business and IT design case types, stages, steps, data and personas together, before importing them into Pega Infinity. Since Blueprint added the MCP Agent channel to its live preview, you don’t need the colleague, and you don’t need a running Pega application either. Blueprint itself is the endpoint. Your design becomes a live MCP server that any AI assistant can discover and interrogate — while it is still a design.
Step 1 — Open (or create) the Blueprint (15 min). Take the journey you’re working on — say Report lost or stolen card, with Dispute transaction as a child case. Bring in the case types, stages, steps, data objects and personas as they exist today. Resist the urge to polish first: the point of the test is to find out what’s missing, not to confirm what you’ve just fixed.
Step 2 — Expose the design as an MCP server (5 min). In the workflow live preview, switch the channel to MCP Agent. Blueprint generates a name and a temporary, tokenized MCP URL. No API key, no environment, no import — the design itself is now queryable.
Step 3 — Connect an AI assistant (5 min). In Claude, Microsoft Copilot, Cursor — any MCP-capable client — add a custom connector and paste the name and URL. Watch the tool list appear: your case types and their actions, described word for word as you wrote them in Blueprint. This is the vocabulary row of the table above, suddenly load-bearing. If a description says “LC-01 Card Service Flow”, that is all the agent knows about when to use it.
Step 4 — Play the customer (30 min). Now run the new-colleague test live. Say what customers actually say, not what the design assumes:
- “The machine ate my card” — does the agent map it to the right case type, or hesitate between three that all sound alike? That’s check 1.
- Walk through creating the case — does the agent ask for fields in business words, or echo technical codes back at you? That’s check 2.
- “So when is this all done?” — does the design give one answer, or does “resolved” mean something different per stage? That’s check 3.
- “There’s a €212 payment I didn’t make” — does the design lead to the dispute child case, or dead-end? That’s the relations row.
Every wrong turn is a finding about the design, not about the model. Tune the conversation where it comes from: sharpen a case type description so the intent is unambiguous, reword a field label so the question sounds like your advisors, add the child-case link so the dispute isn’t a dead end — then ask again. You’re finding these gaps at the cheapest possible moment, before implementation. One honest caveat: the MCP Agent channel is a design-phase simulation for creating and validating cases. It exercises the top rows of the table — vocabulary, data, relations, states, actions. Constraints, roles, commitments and provenance are enforced by the running platform, so they’re tested after import, not here.
Step 5 — Make it real. One question is left: what happens when the same journey runs for real? Import the Blueprint into Pega Customer Service™ and you have the answer. The Pega Platform is an MCP server by default, so external agents discover and execute your live workflows exactly the way your assistant just interrogated the design. And Pega’s own agents don’t even need the protocol: through the platform’s agent orchestration, Predictable AI Agents and the email, messaging and voice channels of Customer Service draw on the same journey knowledge directly — same case, same vocabulary, same next valid moves, now enforced by the platform with rules, roles, SLAs and audit trail. That door is open the day the import finishes.
One Customer Service Blueprint, zero setup, a working agent in minutes
The steps above are not hypothetical — before writing them down, I ran them against a real Customer Service for Financial Services Blueprint, straight out of the box. Switched the preview to the MCP Agent channel, pasted the tokenized URL into an AI assistant, and the design introduced itself: 22 case types exposed as tools — Replace a Card, Dispute Transactions, Manage Autopay, Change APR, Make Payment, Close Account… A genuinely solid service vocabulary, with field descriptions written in business words, not technical codes.
Then I played Léa: “My wallet was stolen tonight, and there’s a €212 payment I didn’t make.” No prompt engineering, no training data, no integration work — and the conversation just worked:
- The assistant mapped “wallet stolen” to Replace a Card and captured the reason as Stolen — intent resolution driven purely by the case type vocabulary the Blueprint ships with.
- It collected the replacement in business terms — the card by its last four digits, the cardholder’s name, the terms acknowledgment — every question coming straight from the design’s field descriptions.
- For the €212 payment, it opened a Dispute Transactions case with the disputed transaction, the amount and the customer’s reason, and got a case ID back —
DIS-723985— that it could quote to the customer on the spot.
Total elapsed time from “open the Blueprint” to “an AI assistant serving Léa on my design”: under ten minutes, none of it spent on plumbing. That is the point of the exercise — the operational ontology the article describes isn’t something you build for the test; the Blueprint is the ontology, and the MCP Agent channel simply serves it to whichever agent asks.
And that’s also what makes the test worth running on your own designs: the same half hour that shows a well-built Blueprint answering like a trained colleague will show you, on a rougher one, exactly which of the six checks to tighten — a description to sharpen here, a picklist or a child-case link to add there. Each of those is a single Blueprint edit, and the re-test takes minutes, because there is nothing to deploy. The design is the system under test — and when the design is good, the agent is good on the first try.
Further reading
- Pega white paper: The Evolution of Conversational Self-Service: From Brittle Bots to Dynamic Workflow Agents
- Pega Academy: A2A and MCP in Pega Agentic AI
- Pega Community: The case is the wire: why multi-agent context integrity is an architecture decision
Let’s discuss
- Where does the meaning of “resolved” live in your implementation today: in the journey, in prompts, or in both?
- Which of the nine building blocks is weakest in your journeys? For many teams it is the vocabulary: case type descriptions written for developers, not for agents.
- If you connect an assistant to your Blueprint’s MCP Agent channel and play the customer, share the first question your design couldn’t answer — those findings say more about the state of our journeys than any architecture debate.