Blog & Insights

Walk into almost any government ministry, parastatal, or large private institution in Kenya and ask the ICT team about their core systems. You will find one of three things: a system that was built years ago and no one fully understands anymore; a system that was recently procured at great expense and is barely used; or a gap where a system should exist, filled by spreadsheets and WhatsApp groups.

The failure, in almost every case, is not technical. It is architectural.

The Illusion of the System

Most institutional "systems" are not systems at all. They are collections of features — screens, buttons, fields — assembled by a vendor who understood the brief but not the institution. The institution accepted the deliverable, paid the invoice, and is now the custodian of something they cannot maintain, cannot extend, and cannot explain to their successor when they leave.

"You cannot maintain what you did not design. You cannot extend what you did not architect."

The Root Cause

Institutional system failure has a predictable anatomy:

• Requirements were written by administrators, not systems thinkers. The brief described the current process — not the underlying need the process exists to serve.
• Procurement selected for price, not architecture. The lowest bidder won. The winning proposal had the best slides, not the best schema.
• No one owned the architecture. The vendor left. The IT team inherited a black box. The documentation was a manual, not a design spec.
• The system was built for today's organisation, not tomorrow's. Six months after launch, the institution reorganised, the workflow changed, and the system could not adapt.

What Architectural Thinking Actually Means

A systems architect does not ask "what should this screen do?" They ask: what data does this institution generate, transform, and depend on? What are the trust boundaries? Where are the failure modes? What does this system need to look like in three years, given what we know about how institutions evolve?

Architectural thinking is not about technology choices. It is about structuring a solution so that it can survive contact with reality — with changing leadership, changing requirements, and the inevitable moment when someone leaves and takes their tribal knowledge with them.

The Path Forward

Institutions that want systems that last must invest in architecture before implementation. Not in the form of lengthy waterfall documentation — but in the form of a structural diagnosis conducted by someone who understands both the institution's operational DNA and the technical landscape it needs to navigate.

This is the gap Maxwell Okumu fills. Not as a vendor, but as a structural advisor — someone who sits on the institution's side of the table and designs systems that the institution can actually own, operate, and evolve.

For the last thirty years, software engineering has been fundamentally reactive. We build systems that wait for input, process it, and return output. The engineer's job has been to make that loop fast, reliable, and correct. That paradigm is ending.

Agentic AI systems do not wait. They plan, act, observe, and adapt — autonomously, across sequences of steps that no single prompt or API call could accomplish. This is not a productivity upgrade. It is a new layer of the engineering stack.

What "Agentic" Actually Means

The word is overused. Every chatbot with a tool call is being marketed as "agentic." Let me be precise: an agentic system is one that can decompose a goal into sub-tasks, execute those sub-tasks using available tools, observe the results, and revise its plan accordingly — without human intervention at each step.

"We are not building smarter chatbots. We are building autonomous systems that can act in the world. The engineering implications are profound."

The Architecture of Agency

• State management — agents must maintain context across long action sequences. This is not a database problem; it is an architectural problem about what gets remembered, what gets compressed, and what gets discarded.
• Tool design — the tools an agent can use define the boundary of its capability. Poorly designed tools produce poorly behaved agents. Tool design is the new API design.
• Failure modes — agents fail in ways that synchronous systems do not. They can spiral, hallucinate action sequences, and take irreversible actions. Designing for graceful degradation requires thinking about agent failure, not just software failure.
• Evaluation — you cannot unit test an agent the way you test a function. Evaluation requires new frameworks, new metrics, and a tolerance for probabilistic outcomes.

The East African Context

In the Kenyan institutional context, agentic AI presents extraordinary opportunities — particularly in domains where skilled human labour is scarce and repetitive high-stakes processes are common. Academic evaluation, IT audit, compliance monitoring, and data governance are all candidates for agentic augmentation.

The question is not whether these systems will arrive. They are already here. The question is whether East African institutions will be architects of these systems or merely consumers of them. Maxwell Okumu is working to ensure the former.

The examination system is a black box. A student submits work. Some days later, a mark appears. Between those two events is a process so opaque, so variable, and so dependent on the particular state of a particular evaluator on a particular day, that calling it a "system" in any meaningful engineering sense is generous.

I say this not to criticise lecturers. I am one. I say it because I have built an alternative — and the data is striking.

The Problem Is Structural

• Evaluator variance — the same submission, evaluated by two different markers, routinely produces marks that diverge by 15–25%. This is not opinion; it is documented in education research literature.
• Rubric opacity — most marking rubrics are not operationalised. They describe qualities without specifying the observable features that distinguish them. The rubric is a label, not a measurement instrument.
• Scale failure — as student numbers grow, evaluation quality degrades. The 200th submission is evaluated by a different human — cognitively depleted — than the first.

The Algorithmic Alternative

The AI-Assisted Academic Evaluation System I designed does not replace human judgement. It operationalises it. By extracting the implicit criteria inside a rubric and instantiating them as structured evaluation dimensions, the system creates a repeatable, auditable process where the evaluator's wisdom is encoded once and applied consistently at any scale.

"The goal is not to remove the human from evaluation. It is to make evaluation worthy of a human's signature."

Multi-Pass Bias Mitigation

The system runs each submission through multiple evaluation passes with different framing — a technique that surfaces variance in the model's own assessment. Where passes diverge significantly, the submission is flagged for human review. This is not automation — it is augmentation with a built-in quality gate.

The result: faster evaluation, lower variance, and a transparent audit trail that any student can request to understand precisely why they received the mark they did. That is not a feature. That is a right.

Kenya's Data Protection Act 2019 changed the legal landscape. But changing the law does not change behaviour. Three years after its passage, most organisations subject to the Act are still treating data privacy as a compliance exercise — a form to fill, a policy to publish, a box to tick before the regulator calls.

This is a category error. Data privacy is not a compliance problem. It is an architectural one.

What an IT Audit Actually Reveals

• Data inventories that don't match reality — organisations think they know what data they hold. Their systems tell a different story.
• Access controls that have drifted — the permissions matrix approved at system launch bears no resemblance to the access rights that currently exist.
• Unencrypted data at rest — in categories that are plainly sensitive under the Act.
• Vendor agreements that transfer risk without transferring accountability — third-party processors with no data processing agreements.

"The question is never whether your organisation has a data privacy policy. The question is whether your systems enforce it."

The Remediation Architecture

An IT audit that ends with a risk register is half an audit. The value is in the remediation architecture — the specific, sequenced set of technical and governance changes that move the institution from its current state to a defensible compliance posture.

Zero Trust as the New Baseline

The Zero Trust security model — never trust, always verify — is not a product. It is an architectural philosophy. In the context of data privacy, it provides the design principle that should underpin every system that processes personal data: assume breach, design for least privilege, audit everything.

For Kenyan institutions navigating the Data Protection Act, Zero Trust is not aspirational. It is the direction of travel. Maxwell Okumu's Zscaler ZTCA certification grounds this not in theory but in practical implementation — the kind that survives contact with real institutional systems.