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

How I think, in detail.

The stages I work through, the questions I ask at each one, three decisions I see teams get wrong, and what you would get from working with me.

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.

    Questions I ask
    • Who is affected, and what do they do today?
    • What would a good outcome look like to the business, in its own words?
    • What can’t change: systems, regulation, budget, timelines?

    OutputProblem statement and success criteria

  2. D2

    Diagnose

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

    Questions I ask
    • How long does it take today? Measured, not guessed.
    • Is the bottleneck information, access, process or tooling?
    • Which failures are expensive, and which are only annoying?

    OutputBaseline and bottleneck analysis

  3. D3

    Design

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

    Questions I ask
    • What is the simplest design that meets the criteria?
    • What could we buy or reuse instead of building?
    • What does each option cost to run and to own?

    OutputArchitecture proposal with trade-offs

  4. D4

    De-risk

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

    Questions I ask
    • What happens when the system is wrong?
    • Who must never see what?
    • What is the worst a tool call could do, and who approves it?

    OutputRisk register and evaluation plan

  5. D5

    Deliver

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

    Questions I ask
    • What is the smallest scope that proves or disproves the value?
    • What are the exit criteria, agreed in advance?
    • Who uses it first, and how do they give feedback?

    OutputPilot plan and working prototype

  6. D6

    Improve

    Let feedback, evaluation and observability decide what changes next.

    Questions I ask
    • Which failures are we actually seeing?
    • Are the metrics we agreed on moving?
    • What should we stop doing?

    OutputEvidence-driven iteration backlog

Improve feeds back into Diagnose. A pilot is a measurement, not a finish line.

Decision records

Three decisions I see teams get wrong. Compare the tempting option with the one I’d choose.

DR-01 · Decision recordContext: A team asks for “a chatbot over our documents”.

Is a RAG assistant the right answer to this knowledge problem?

Option A: what goes wrong

You may ship a fluent interface over the wrong problem. If people are really asking about live data, conflicting policies or a handful of recurring questions, retrieval will not fix it, and it will repeat contradictions with confidence.

Option B: what you get

A short discovery step sorts questions by where their answers live. Live data (“how many leave days do I have left?”) needs an API call, not a document. Conflicting policies need an owner to fix them. A small set of recurring questions may only need a maintained FAQ. RAG is the right choice when answers live in a large, changing body of approved text and people phrase their questions unpredictably.

Rationale

The model is rarely the hard part. What decides the outcome is choosing the right mechanism for each kind of question.

DR-02 · Decision recordContext: An internal assistant over documents with different access levels.

Where should document permissions be enforced?

Option A: what goes wrong

A prompt instruction is not access control. Anything in the model’s context can leak through the answer, a citation, a summary or a prompt-injection attack. One mistake exposes restricted content, and no log shows exactly what leaked.

Option B: what you get

The model never sees text the user is not allowed to read. Access is checked again after generation, so a permission revoked mid-request fails closed. Citations can only point to documents the user may open.

Rationale

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

Evidence from my work

My prototype does this and tests it: restricted chunks are dropped before the context is built, and a regression test asserts restricted text never reaches the model. Known limit: filtering happens after candidate retrieval, so lower-ranked documents the user may read can be missed. The pilot fix is to filter inside the index query.

See the trace in CS-01
DR-03 · Decision recordContext: An assistant that could look up accounts, issue refunds or post replies.

How much access should an AI agent get to business tools?

Option A: what goes wrong

A model can be wrong, or be steered by text it reads. With broad access, the worst case is a refund, a deleted record or a public post that nobody approved, and it might happen twice.

Option B: what you get

Read-only lookups are scoped to the verified customer. State-changing actions become proposals that pass a policy check and a human approval, run once (idempotently), and leave an audit trail. The worst case becomes a rejected proposal.

Rationale

Limit what a tool can do and you limit what a mistake can cost. Then trust can grow one category at a time, based on evidence.

Evidence from my work

In Snitch, approving a reply and publishing it are separate actions. Publishing requires its own API scope, which the default read-write key leaves out, and a unique constraint stops the same reply being posted twice.

See approvals in CS-03
Working with me

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

I’m early in client-facing work, so instead of a client list, every deliverable below links to a real example from my own projects.

The engagement

  1. A structured discovery conversation

    About the people, the workflow, the constraints and the outcome, before any talk of models or tools.

  2. A clear problem statement and success criteria

    Written down and agreed, including what “good enough” means and how it will be measured.

  3. An architecture proposal with trade-offs

    The options I considered, the one I recommend, why, and what would make me change my mind.

  4. A focused prototype or pilot

    The smallest scope that can prove or disprove the value, with real users and real data where possible.

  5. An evaluation plan and explicit risks

    What could go wrong, how we would detect it, and what the system does when it isn’t sure.

  6. A clear recommendation on next steps

    Expand, adjust or stop, based on what the pilot showed rather than on momentum.

What you’d get

Deliverables index7 items
Let’s talk about a problem