Ehi AigiomawuField notes · Applied AI systemsLet’s talk about a problemLet’s talk

Backend engineeringApplied AISystems thinkingCustomer problem-solving

I turn complex business problems into practical AI systems.

I’m Ehi Aigiomawu, a backend engineer working at the intersection of customer needs, system architecture and applied AI. I start by understanding the workflow, the people and the risks. Then I design, build and evaluate solutions teams can rely on.

Explore my work Let’s talk about a problem
Now
Backend engineering, applied AI systems and customer-facing technical problem-solving.
Fig. 01 · From brief to systemExample: CS-01
The brief
“Our employees spend hours searching internal documents, policies and procedures. Build us an AI assistant.”

  1. The real problem isn’t slow search. It’s inconsistent policy interpretation, repeated questions to compliance, and answers that have to be auditable.

  2. Who asks, what they ask, where the documents live, how often they change, and who is allowed to read each one.

  3. Permission-aware hybrid retrieval, answers that cite approved sources, and an “I don’t know” path when the evidence is weak.

  4. Permission leakage, made-up policy, stale documents, prompt injection: each one gets a mitigation and a test.

  5. Time-to-answer against a measured baseline, citation validity, evaluation pass rate, and zero permission violations.

The system

A pilot-ready design, and a working prototype that enforces it.See CS-01

Problems I solve

You may not need AI. You need the right problem solved.

Organised around the problem, not the technology. For each one: how I’d approach it, and the outcome the business is actually after.

  1. Nobody can find the answer, or two people find different ones.

    How I’d approach it

    I start with the question log, not the model: which questions repeat, where the source of truth lives, how often it changes, and who may read what. Then I choose between fixing the documents, better search, a curated FAQ, or a permission-aware assistant that cites its sources.

    What the business wants

    Faster, consistent answers that can be traced back to an approved source.

    CS-01 · Bank policy assistant

  2. Support is buried under the same questions, asked again and again.

    How I’d approach it

    Before automating anything, I segment tickets by volume, complexity and risk. Documented questions are answered first. Account changes stay behind approvals. Everything else goes to a person, with the context already gathered.

    What the business wants

    Shorter queues and faster responses without losing customer trust.

    CS-02 · Support automation

  3. The AI demo worked, but nobody trusts it with real work.

    How I’d approach it

    I add what demos leave out: an evaluation set built from real questions, abstention when the evidence is weak, citation checks, query logging, and tests for each failure mode, so behaviour can be measured before anyone relies on it.

    What the business wants

    A system whose behaviour you can measure, explain and improve.

    CS-01 · Evaluation loop

  4. The AI has to work inside the software, permissions and processes you already run.

    How I’d approach it

    I map the existing APIs, identity and permission model, and the business process. Integration goes through narrow, auditable interfaces, and a model never gets broader access than the person it is acting for.

    What the business wants

    AI that fits existing systems and controls instead of working around them.

    CS-03 · Approvals in Snitch

  5. Should we build this, buy it, or drop it?

    How I’d approach it

    I define the baseline and the decision criteria first, compare building, buying and waiting on cost, risk and time-to-value, then run a small pilot so the decision rests on evidence rather than enthusiasm.

    What the business wants

    A clear, defensible decision, including "don’t build it" when that is the right answer.

    How I think · DR-01
Selected work

Three case studies, where the thinking is the evidence.

Each is labelled with its real status, so you can tell what I built from what I’m proposing. The case studies themselves go deep: architecture, trade-offs, risks and how success would be measured.

Status key

Implemented
Built and working as described.
Prototype
Working code that proves the hard parts. Not production, not deployed for a client.
In progress
Actively being built. Parts work; parts are still planned.
Design exercise
How I would approach a realistic scenario. No system built and no data analysed.
CS-01PrototypeBanking · Internal knowledge · RAG

A permission-aware policy assistant for a bank

An internal assistant that answers only from documents the employee is allowed to read, cites its sources, and says “I don’t know” when the evidence is weak. Working prototype with 36 automated tests.

Read the case study Prototype repository Article on Medium

All work: 2 smaller builds, 5 next experiments and 1 article

Seen something relevant?

How I think

Six steps from a vague request to a system people can trust.

The order matters more than the tools. Most failed AI projects skip the second and fourth steps.
  1. D1

    Discover

    Understand the users, their workflow, the constraints, and the outcome the business actually needs.

  2. D2

    Diagnose

    Measure the baseline, find where things break, and identify the real bottleneck.

  3. D3

    Design

    Compare architectures and build-versus-buy options against the success criteria.

  4. D4

    De-risk

    Work through permissions, security, reliability, evaluation, cost and failure modes before they surprise anyone.

  5. D5

    Deliver

    Define a small, measurable pilot and build it before expanding anything.

  6. D6

    Improve

    Let feedback, evaluation and observability decide what changes next.

DR-02 · An example decision3 decision records

Where should document permissions be enforced?

TemptingRetrieve everything and tell the model what the user may not see

What I’d doRemove unauthorised content before it reaches the model, then check again

The safest boundary is simple to state and to test: the model only ever sees what the user is allowed to see.

The full method, all 3 decision records, and their trade-offs

Capabilities

Six things I’m good at, each backed by real work.

Every capability links to the projects that show it.

See every tool and where I used it

Working with me

What to expect, whether I join your team or take on a defined problem.

  1. A structured discovery conversation
  2. A clear problem statement and success criteria
  3. An architecture proposal with trade-offs
  4. A focused prototype or pilot
  5. An evaluation plan and explicit risks
  6. A clear recommendation on next steps

What each step involves, and 7 deliverables with real examples

About

A backend engineer who starts with the problem.

I’m Ehi Aigiomawu. I build backend systems and I’m moving deeper into Forward Deployed and applied AI engineering, the work between a customer’s problem and a system that solves it.

The part I find most interesting is the translation. That means understanding how people actually work, finding the constraint that matters (often permissions, data quality or trust rather than the model), designing something that fits the systems and rules already in place, and being honest about what it can’t do yet.

I work in public. My GitHub has a series of FDE-style projects, starting with a permission-aware RAG assistant, and I write about AI system design on Medium.

Profile
Focus
Backend engineering · Applied AI · Forward Deployed Engineering
Elsewhere
GitHubMediumLinkedIn

§07 Contact

Have a complex workflow, an AI idea, or a system that needs a rethink?

Let’s work out what is worth building.

A few sentences is enough. There’s no call to book and no long brief: tell me what you’re trying to solve, and I’ll reply with questions or a suggested next step.

Message

Opens your email app with this message ready to send. Nothing is sent until you press send there.

What’s this about?