Maxwell
Okumu

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?

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. 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

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.
• Tool design — the tools an agent can use define the boundary of its capability. Tool design is the new API design.
• Failure modes — agents fail in ways that synchronous systems do not. Designing for graceful degradation requires thinking about agent failure.
• Evaluation — you cannot unit test an agent the way you test a function.

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. 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%.
• Rubric opacity — most marking rubrics describe qualities without specifying the observable features that distinguish them.
• Scale failure — as student numbers grow, evaluation quality degrades.

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 augmentation with a built-in quality gate.

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 current access rights.
• Unencrypted data at rest — in categories that are plainly sensitive under the Act.
• Vendor agreements that transfer risk without transferring accountability.

"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. For Kenyan institutions navigating the Data Protection Act, Zero Trust is not aspirational. It is the direction of travel.