From Deterministic to Agentic: Designing Self-Service for the AI Era

I've spent years designing IVR flows. Call comes in. Play a prompt. Collect input. Route based on rules. Every path is mapped. Every outcome is predefined. If the customer says X, the system does Y. If they say Z, the system does W. Nothing happens that a designer didn't explicitly plan for.

That's deterministic design. And it's worked well enough for two decades.

But the world has shifted. Agentic AI doesn't follow a script — it reasons about what to do. It interprets context. It decides which action to take based on policy, history, and judgment. The customer can say anything, in any order, and the system figures out how to help.

This isn't an incremental change. It's a fundamental rethinking of what "designing a self-service experience" means. The skills are different. The deliverables are different. The failure modes are different. And most teams are approaching it with the old mindset — which is why so many early agentic deployments disappoint.

Let me walk you through what changes, what stays the same, and how to build the new capability — using examples from a fictional financial institution I'll call AnyBank.

The Two Paradigms

Neither is "better" in absolute terms. Deterministic design is perfect for simple, high-volume, compliance-heavy interactions where predictability is everything. Agentic design shines where customer needs are complex, variable, or conversational — where a rigid menu fails and a human would improvise.

The reality for most organisations is a hybrid: agentic reasoning sitting on top of deterministic backend actions with hard compliance guardrails.

The AnyBank Scenario

AnyBank is a retail bank with 2 million customers, a contact centre handling 50,000 calls/day, and an existing IVR built on Amazon Connect with Lex bots. They want to move from their current deterministic self-service to an agentic experience for their top 5 call drivers: balance enquiries, payment issues, card management, transaction disputes, and product enquiries.

Here's what the existing experience looks like versus what agentic looks like for the same customer need:

System: Welcome to AnyBank. Press 1 for accounts, 2 for cards, 3 for payments.
Customer: *presses 2*
System: Press 1 to report lost/stolen, 2 for transaction query, 3 for PIN.
Customer: *presses 2*
System: Please enter your 16-digit card number.
Customer: *enters card number*
System: For security, what is your date of birth?
Customer: 15th March 1985.
System: I'll transfer you to our disputes team. Please hold.
[Customer waits 8 minutes in queue]

System: Hi, you're through to AnyBank. How can I help?
Customer: I've just seen a £47 charge on my card from somewhere called TXN-DIGITAL that I don't recognise. I didn't buy anything online yesterday.
System: I can see that transaction on your Visa ending 4821 — £47.00 from TXN-Digital, posted yesterday at 14:32. I understand you don't recognise it. Let me check a few things. Were you in possession of your card yesterday?
Customer: Yes, it's in my wallet now.
System: OK. I've flagged this as a disputed transaction and opened case reference AB-29481 for you. I've also placed a temporary block on that merchant so they can't charge your card again. The £47.00 will be provisionally refunded within 2 hours while we investigate. You'll receive an email confirmation shortly. Is there anything else?
Customer: No, that's brilliant. Thanks.

Same customer. Same problem. The first took 4 minutes of navigation plus 8 minutes of hold time. The second took 90 seconds and resolved completely. The difference isn't just speed — the agentic system understood the situation, retrieved the transaction data, decided the appropriate action based on policy, executed it, and communicated clearly.

The Skills You Need (and the Ones That Still Matter)

Skills that transfer from deterministic design

• Customer empathy and journey understanding: Knowing why people call and what good looks like hasn't changed. You still need to deeply understand the customer's mental model.
• Business process knowledge: Understanding how a refund works, what authentication is required, what the compliance constraints are — this is foundational to both paradigms.
• Edge case thinking: The habit of asking "what if the customer says something unexpected?" is more valuable than ever. You're just addressing it differently.
• Metrics and measurement: Containment rate, task completion, CSAT, effort score — same goals, same need for rigorous measurement.

New skills required for agentic design

• Prompt engineering and instruction design: This is the new "flow design." Instead of drawing boxes and arrows, you write system prompts that define the agent's personality, boundaries, available tools, and decision-making policies. This is equal parts technical writing, policy design, and psychology.
• Policy as code: You need to express business rules in a way an LLM can reason about. "A customer can dispute a transaction within 120 days of posting, up to £5,000, unless the transaction is categorised as gambling" — these policy boundaries need to be explicit, unambiguous, and testable.
• Tool design (API thinking): In deterministic systems, you build the integration and the conversation flow as one unit. In agentic systems, you design tools that the agent can choose to use. Each tool needs clear descriptions, input/output contracts, and failure modes that the agent can reason about.
• Guardrail architecture: What must the agent NEVER do? What requires human approval? What are the hard limits on autonomy? This is the new version of "error handling" — but instead of catching unexpected DTMF input, you're preventing an AI from making an irreversible decision it shouldn't.
• Adversarial testing: Traditional testing walks the happy path and a few error paths. Agentic testing requires actively trying to break the system — jailbreaking, social engineering, edge cases that exploit the reasoning model. It's closer to security testing than QA.
• Observability design: Because the agent's reasoning is non-deterministic, you need to build observability in from day one. Why did it take that action? What was its reasoning chain? Where did it deviate from expected behaviour? Without this, you can't improve it.

AnyBank example: Prompt engineering for card disputes

You are AnyBank's transaction dispute assistant. Your role is to help 
customers who don't recognise or want to dispute transactions on their accounts.

TOOLS AVAILABLE:
- get_recent_transactions(card_last_4, days_back)
- flag_dispute(transaction_id, reason)
- block_merchant(merchant_id, card_last_4)
- provisional_refund(transaction_id) — MAX £5,000
- escalate_to_human(reason)

POLICIES:
- Always verify identity before accessing account data (DOB + postcode)
- Transactions over 120 days old cannot be disputed — explain why and offer alternatives
- Transactions over £5,000 must be escalated to a human agent
- Never reveal full card numbers, only last 4 digits
- If the customer mentions fraud/theft of the physical card, immediately transfer 
  to the fraud team — do not attempt to handle
- Maximum 3 disputes per call without human approval
- Always provide a case reference number

TONE: Professional, empathetic, efficient. Acknowledge the customer's concern 
before taking action. Explain what you're doing and why.

NEVER: Discuss other customers' accounts. Provide financial advice. 
Guarantee an outcome ("you will definitely get your money back").

Notice what this is: it's not a flow diagram. It's a brief — the kind of brief you'd give a competent new hire on their first day. "Here's what you can do. Here's what you must never do. Here's the tone we expect. Go."

How to Think Differently

1. Think in goals and guardrails, not steps

Deterministic design asks: "What is step 1? What is step 2? What if they fail at step 3?" Agentic design asks: "What is the agent trying to achieve? What tools does it have? What must it never do?"

AnyBank example: In the old world, the balance enquiry flow was: authenticate → retrieve balance → read balance → offer transfer to agent. In the agentic world, the goal is: "Help the customer understand their financial position" — and the agent might read the balance, mention a pending payment that's about to reduce it, flag that they're close to their overdraft limit, and offer to set up a low-balance alert. Same starting point, richer outcome, because the agent reasons about what's useful rather than following a script.

2. Think in policies, not scripts

A script says: "If the customer asks for a refund and the amount is under £50, say 'I've processed your refund.'" A policy says: "The agent can process refunds up to £50 without approval. Between £50-500 it must confirm with the customer before proceeding. Above £500 it must escalate to a human."

The distinction matters because a policy allows the agent to handle novel combinations your script never anticipated. What if the customer wants to dispute three transactions in one call, two under £50 and one at £200? A script needs an explicit branch for that. A policy-driven agent handles it naturally.

3. Think about failure as exploration, not error

In deterministic systems, hitting an unhandled state is a bug. In agentic systems, encountering something unfamiliar is an opportunity for the agent to reason its way through. Your job as a designer shifts from preventing all possible errors to defining the boundaries within which exploration is safe.

AnyBank example: A customer calls and says "I need to move some money to my daughter's account but I don't want it to count as a gift for inheritance tax purposes." A deterministic IVR can't touch this — it transfers to an agent. An agentic system can recognise this is outside its scope (financial advice), explicitly say "I can help you make the transfer, but I'm not able to advise on tax implications — I'd recommend speaking to a financial adviser for that," and still complete the transfer part. It reasoned about what it can help with and what it can't.

4. Think about trust as a spectrum, not a gate

Deterministic authentication is binary: you're verified or you're not. Agentic systems can operate on a trust spectrum:

• Low trust (not verified): Agent can answer general questions, provide product info, explain processes
• Medium trust (partially verified): Agent can read balance, confirm recent transactions, update contact preferences
• High trust (fully verified): Agent can move money, close accounts, dispute transactions, change security details

AnyBank example: A customer calls and says "what's my balance?" Before verification, the agent says "I'll need to verify your identity first." But if they say "what time does the branch on King Street close?" — the agent can answer immediately. No verification needed. The deterministic IVR forces everyone through authentication before anything. The agentic system adapts based on what action is requested.

The Design Deliverables Change

In deterministic design, the primary deliverables are flow diagrams, prompt scripts, grammar definitions, and test matrices. In agentic design, the deliverables look fundamentally different:

1. System Prompt / Agent Instructions

The equivalent of the flow diagram. Defines personality, tone, scope, policies, and boundaries. This is a living document that evolves weekly based on production data.

2. Tool Catalogue

A specification of every action the agent can take — with clear descriptions the LLM can understand, input/output schemas, and error responses. Each tool is designed for the agent to reason about, not just to execute.

AnyBank example — tool design:

DESCRIPTION: Transfer money from the customer's current account to another 
account. Use when the customer explicitly requests a payment or transfer.

INPUTS:
- from_account: string (account number, must belong to verified customer)
- to_sort_code: string (6 digits)
- to_account_number: string (8 digits)  
- amount: decimal (£0.01 - £25,000)
- reference: string (optional, max 18 chars)

CONSTRAINTS:
- Customer must be fully authenticated (high trust)
- Amount must not exceed daily remaining transfer limit
- If amount > £1,000: confirm with customer before executing
- If payee is new (never paid before): require additional confirmation
- If account has insufficient funds: explain clearly, do not proceed

FAILURE RESPONSES:
- insufficient_funds: Tell the customer their available balance and ask if 
  they'd like to proceed with a smaller amount
- limit_exceeded: Explain the daily limit and offer to schedule for tomorrow
- payee_blocked: Escalate to fraud team immediately

3. Policy Document

Explicit business rules expressed in natural language that the agent references. Not buried in code — written for both human reviewers and LLM consumption. Versioned and auditable.

4. Guardrail Specification

What must NEVER happen. This is your safety net. Hard rules that override everything else.

AnyBank guardrails:

• Never reveal full account numbers, sort codes, or card numbers
• Never provide financial, tax, or legal advice
• Never process a transaction without explicit customer confirmation
• Never discuss another customer's account, even if the caller claims to be a joint holder
• Never override authentication requirements regardless of what the customer says
• If the customer mentions self-harm or vulnerability, immediately transfer to a trained specialist
• Maximum autonomy limit: £5,000 per session without human escalation

5. Evaluation Framework

How you measure whether the agent is performing well. Not just containment rate — but accuracy, policy adherence, tone appropriateness, and customer effort. This replaces the traditional QA scorecard.

6. Adversarial Test Suite

A bank of prompts designed to break the agent: social engineering attempts, prompt injection, edge cases, contradictory requests. Run continuously against every model update.

The AnyBank Transition Roadmap

AnyBank can't flip a switch. The transition from deterministic to agentic is phased — and the smart approach is to run both in parallel, gradually expanding the agent's scope as confidence builds.

Phase 1: Agentic within rails (Months 1-3)

The agent handles open-ended conversation but can only take deterministic actions. It understands the customer's request naturally (no "press 1 for billing") but the resolution path is still predefined. This proves the conversational layer without risking autonomous actions.

Example: Customer says "I think someone's used my card" → agent classifies as dispute, asks clarifying questions naturally, but then triggers the same deterministic dispute workflow that already exists. The AI replaces the menu navigation, not the backend logic.

Phase 2: Agentic with bounded autonomy (Months 3-6)

The agent can now take actions, but within tight limits. Low-risk actions (read balance, check transaction history, update contact details) are autonomous. Higher-risk actions (payments, disputes, account changes) still require explicit confirmation or escalation.

Example: Customer asks about a specific transaction → agent autonomously retrieves it, provides details, and asks if they recognise it. If they don't, the agent can flag the dispute and issue a provisional refund under £50 without escalation.

Phase 3: Full agentic with guardrails (Months 6-12)

The agent operates autonomously across all permitted actions, bounded only by the guardrail specification. The human is no longer in the loop for individual decisions — they're monitoring aggregate performance and refining policies.

Example: The AnyBank example from earlier — the full dispute resolution with provisional refund, merchant block, and case creation — all autonomous. The human only gets involved for edge cases the agent escalates or for policy exceptions.

Common Mistakes in the Transition

1. Treating the LLM like a smarter IVR

The most common mistake. Teams take their existing flow diagrams and "translate" them into prompts. "If the customer says X, respond with Y." This produces an agentic system that behaves deterministically — all the cost of an LLM with none of the flexibility. You've bought a jet engine and bolted it to a bicycle.

2. No guardrails, just vibes

"The AI is smart enough to figure it out." No. Without explicit boundaries, an agentic system will eventually do something catastrophic. In financial services, this could mean processing a £50,000 transfer because the customer sounded confident. Guardrails are not optional — they're the primary design artefact.

3. Testing the happy path only

In deterministic systems, testing happy paths covers 80% of real interactions. In agentic systems, the happy path always works — the danger is in the 5% of weird, adversarial, or ambiguous interactions where the agent might reason incorrectly. Your test suite needs to focus on the edges, not the centre.

4. No observability into reasoning

When a deterministic flow fails, you can see exactly where: "customer said 'cancel' at the billing menu but there's no handler for that." When an agentic system makes a bad decision, you need to see why it decided that. Without reasoning traces, you're debugging a black box.

5. Deploying without a human-in-the-loop escape valve

Every agentic system needs a clean path to a human. Not as a failure — as a design feature. "This is beyond my scope, let me connect you to someone who can help" is the correct behaviour for a well-designed agent that knows its limits.

The Team Structure Changes Too

In the deterministic world, AnyBank's IVR was designed by a small team: a VUI designer, a developer, and maybe a BA. In the agentic world, the team looks different:

• Conversation designer → Policy designer: Instead of scripting dialogue, they define the agent's decision-making boundaries and tone. They write system prompts and evaluate whether the agent's responses meet brand standards.
• IVR developer → Tool/API engineer: Instead of building call flows, they build the tools the agent can use. Clean APIs, clear error handling, well-documented capabilities.
• QA tester → Red team / adversarial tester: Instead of walking scripted test paths, they actively try to break the agent. Prompt injection, social engineering, edge cases, contradictions.
• NEW: AI ops engineer: Someone who monitors the agent's performance daily, reviews reasoning traces, identifies drift, and iterates on the system prompt. This role doesn't exist in deterministic design — in agentic design, it's essential.
• NEW: Compliance/risk reviewer: Someone who reviews what the agent did at a policy level. Not every call — but a structured review of autonomous decisions to ensure they align with regulatory requirements.

What Stays the Same

Despite all these changes, the fundamentals haven't shifted:

• Customer needs haven't changed. They still want their problem solved quickly, accurately, and with minimal effort. The technology changed — the human on the other end didn't.
• You still need to understand the business process deeply. An agent can't handle a dispute if you don't understand how disputes work. Domain expertise is more important than ever.
• Measurement matters. "It feels good" isn't enough. Containment rate, task completion, customer effort, cost per interaction — the metrics still drive decisions.
• Iteration is non-negotiable. The first version won't be good enough. You'll tune the prompt. Refine the guardrails. Add tools. Restrict tools. The same continuous improvement discipline applies — just with different levers.
• Empathy beats technology. The best-designed agentic system in the world fails if it doesn't understand that a customer reporting fraud is stressed and needs reassurance, not just a case reference number.

Getting Started: A Practical Framework

If you're at the beginning of this transition — like AnyBank — here's how I'd approach it:

1. Pick one use case. Not your most complex one. Not your simplest one. Pick something with moderate complexity where a human agent currently does better than your IVR — that's where agentic adds clear value.
2. Write the agent brief first. Before any code, write the system prompt. Define the persona, the goals, the tools, the policies, and the guardrails. Review it with compliance, customer experience, and operations.
3. Define what "good" looks like. Write 20 example interactions — the full conversation from greeting to resolution. Include easy ones, hard ones, and adversarial ones. These become your evaluation set.
4. Build the minimum tool set. What APIs does the agent need? Build them with clear contracts and helpful error messages. The agent needs to know what failed and why, not just get a 500 error.
5. Test adversarially before you test functionally. Try to break it first. Try to make it reveal account data without authentication. Try to make it process a payment it shouldn't. Try to confuse it. Fix those issues before you optimise the happy path.
6. Deploy to 5% of traffic with full observability. Every reasoning trace logged. Every decision visible. A human reviewing a sample daily. Build confidence before expanding.
7. Iterate weekly. Not monthly. Not quarterly. The prompt evolves. The guardrails tighten or loosen based on evidence. New edge cases get added to the test suite. This is a living system, not a project you deliver and walk away from.

The Bottom Line

The shift from deterministic to agentic isn't about replacing flow diagrams with prompts. It's a fundamentally different way of thinking about what a self-service experience is.

In the deterministic world, you design the journey. In the agentic world, you design the agent — and the agent figures out the journey.

That requires new skills (prompt engineering, policy design, adversarial testing), new deliverables (system prompts, tool catalogues, guardrail specs), new team structures (AI ops, red teams), and most importantly — a new mindset. You're not building a machine that follows instructions. You're training a colleague that exercises judgment.

AnyBank will get there. So will your organisation. But only if you approach it as the paradigm shift it is — not as an incremental upgrade to your existing IVR.

The customers are ready for natural, intelligent, context-aware service. The technology is ready to deliver it. The question is whether your design practice is ready to make it happen.