Lesson 10 of 10 · 9 min read
Patterns in the wild
In one paragraph
Real AI systems mix deterministic logic and bounded model use. The recurring pattern is the same: let models handle volume and messy inputs, keep anything that commits the business in reviewed code, and put people where judgement is genuinely needed. This lesson shows that pattern in three kinds of systems and ends with a five-step plan.
In this lesson
- Recognise the deterministic-plus-bounded-AI pattern in real systems
- Map each part of a workflow to code, model or person
- Leave with a five-step plan to start in your own organisation
The video version of this lesson is in production. The full lesson is below.
Nine lessons of principles. This one shows how they look in real systems IOanyT has built, using public case studies, and describing the design pattern rather than confidential detail.
Pattern 1: call quality review at full coverage
The workflow. Contact centres, including collections teams, need to know whether calls follow policy and regulation. Traditionally a small sample of calls is reviewed by hand.
The pattern. In The Heartbeat, IOanyT’s own call QA-as-a-service product, AI reviews every call and human analysts verify. The model does what models are good at, covering volume no team could listen to. People keep what people should own: verifying findings and making judgements about agents and customers.
The principle. Bounded AI at scale (Levels 1–2 on the ladder), with human verification designed in, not bolted on.
Pattern 2: insurance operations with many parties
The workflow. An offline motor-insurance market in Zambia, with customers, agents, administrators and a regulator, moved onto a single digital platform (case study).
The pattern. When several parties, including a regulator, rely on the same records and decisions, the rules have to behave identically for everyone. That is deterministic logic’s home ground: policy rules and workflow states as reviewed, versioned code. If AI is added to a system like this, its natural place is the messy edges, such as reading uploaded documents into fixed fields (Level 2) with code checking the result. The rules themselves stay in code.
The principle. Shared records and regulated workflows need one source of truth, and that source is code.
Pattern 3: numbers people act on
The workflow. A real-time portfolio risk dashboard for an Indian fintech platform, updating every minute from live market data (case study).
The pattern. Risk figures drive trading decisions, so they must be exact and reproducible. Same inputs, same figures, every time. That makes the calculation deterministic by necessity. Where a model could add value is around the numbers, for example explaining a movement in plain language, never in producing the number itself.
The principle. Numbers that drive decisions belong in code. Models can explain them; they don’t compute them.
The pattern behind the patterns
| Best owned by | Because | Examples |
|---|---|---|
| Models (bounded) | Volume and messy inputs | Covering every call, reading documents, drafting |
| Code | Commitments and numbers | Prices, eligibility, risk figures, policy rules |
| People | Judgement and accountability | Verifying findings, edge cases, consequential calls |
Every workflow in this course can be split this way, step by step.
Where to start: five steps
- List every place AI touches a decision in your organisation, including informal use like staff pasting data into chat tools.
- Rank them by what a wrong answer costs: money, fairness, customers, regulators.
- Test consistency on the top three with the ten-minute test from lesson 1, and a 20-case golden set from lesson 5.
- Choose one workflow to make reliable. Map each step to code, model or person using the table above and the ladder from lesson 4.
- Prove it: measure accuracy, consistency and cost per case on real data, then decide whether to scale.
One workflow proven end to end is worth more than ten pilots in progress.
You’ve finished the course
You now have the vocabulary (lesson 2), the architecture (lessons 3–4), the measurement practice (lesson 5), the cost model (lesson 6), the accountability landscape (lessons 7–9) and a plan (this lesson). The glossary keeps the terms in one place, and the compiled AI and deterministic AI explainers are good pages to share with colleagues.
Key takeaways
- Models are best at volume and messy inputs; code is best at commitments and numbers; people are best at judgement.
- Numbers that drive decisions (risk, price, eligibility) belong in deterministic code.
- Human review is part of the design, not a sign the system failed.
- Start with one workflow, measured end to end, rather than many pilots.
Check yourself
Pick an answer, then open the card to compare.
-
1. In a call-quality review system, which part suits a model best?
- A.Deciding a disciplinary outcome for an agent
- B.Covering every call at volume and flagging what needs attention
- C.Setting the scoring policy
Show the answer
B. Covering every call at volume and flagging what needs attention Volume is where models help. Policy is set by people, and consequential judgements stay with people.
-
2. A dashboard shows portfolio risk figures that traders act on. Where should the risk calculation live?
- A.In deterministic code, so the same inputs always give the same figures
- B.In a model that estimates the figure each time
- C.In a spreadsheet emailed daily
Show the answer
A. In deterministic code, so the same inputs always give the same figures Numbers that drive decisions must be exact and reproducible.
-
3. What's the recommended first step for a team starting out?
- A.Launch AI pilots in every department at once
- B.List every place AI touches a decision, then rank by what a wrong answer costs
- C.Buy the largest model available
Show the answer
B. List every place AI touches a decision, then rank by what a wrong answer costs An inventory ranked by stakes shows where reliability matters most, so effort goes there first.
Common questions
Are these real IOanyT projects?
Yes. Each pattern comes from a published IOanyT case study, linked in the lesson. The lesson describes the design pattern, not confidential details.
What if our workflow doesn't fit any of these patterns?
Use the mapping exercise at the end: split the workflow into steps and decide, step by step, whether code, a bounded model or a person should own it. The Graduated Exposure Ladder from lesson 4 gives the levels.
Where can we get help applying this?
IOanyT runs a free AI Reliability Review, and a fixed-scope Proof Sprint that compiles one workflow and measures it on your data. Both are linked at the end of the lesson.