Build Your Way into AI Engineering
A portfolio project is credible when it proves how the system fails, not only that the happy path works. This eight-part series is a learning pathway for developers, architects and technical graduates in South Africa: build one support system and evolve it, adding structured contracts, memory, retrieval, tools and multiple agents only when a specific failure demands each one, then present the result to an architect and a business leader with evidence, economics and a runbook. One fictional Durban fibre provider's support desk carries the examples, and the practical labs are written walkthroughs with short, original code sketches.
8 articles
- Part 1Stop collecting AI tutorials. Build one system that evolves.Plenty of developers can show ten finished AI tutorials and still cannot explain why any component exists. Part 1 sets out a different route into AI engineering: one small system, grown a capability at a time, with every stage justified by a failure the previous stage could not handle.7 min read
- Part 2Your first AI project should include failure and costA ticket classifier that works in a demo takes an afternoon. One that protects personal data, resists manipulated input, falls back safely and knows its own cost per ticket takes a week, and teaches far more. Part 2 builds Umgeni Fibre's first stage with the failure paths drawn in from the start.7 min read
- Part 3From prompt to structured contractAsking a model to 'reply in JSON' is a formatting preference. Defining what the output must contain, what values are allowed and what your code does when they are not is a contract. Part 3 turns Umgeni Fibre's classifier output into one, and shows the four layers between a model's answer and an action.7 min read
- Part 4Add memory only when the stateless design failsThe first thing a conversational assistant gets wrong is forgetting what the customer said one message ago. The tempting fix is to send the whole conversation every turn. Part 4 adds the smallest state that solves Umgeni Fibre's problem, then a preference memory with provenance, correction and expiry, and the tests that prove both.7 min read
- Part 5Add retrieval only when knowledge must change independentlyRetrieval is often the first thing added to an AI project and the last thing evaluated. Part 5 adds it to Umgeni Fibre's assistant for one specific reason, knowledge that changes faster than anyone can edit a prompt, and shows why the first test is what the system finds, not what it writes.7 min read
- Part 6Add tools only when the system must actTools are what turn an assistant that explains into one that does. They are also where a wrong answer becomes a wrong action. Part 6 gives Umgeni Fibre's assistant three tools that read and one that acts, keeps authority out of the model's hands, and gives the agent loop the stop conditions most demos forget.7 min read
- Part 7Add multiple agents only when work really has separate responsibilitiesMulti-agent diagrams look impressive, and every new agent adds hand-offs that can fail, lose context or hide blame. Part 7 shows why Umgeni Fibre rejected an agent per ticket category, the three tests that justified its one real split, and the hand-off contract that keeps two components honest with each other.7 min read
- Part 8How to present an AI portfolio to an architect and a business leaderA working demo answers one question: does the happy path run? An architect and a business leader both want to know what happens when it does not, what it costs and who runs it on Monday. Part 8 turns Umgeni Fibre's five stages into a portfolio built on evidence, economics and a runbook.7 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala