Open to remote and on-site AI engineering roles — UTC+1
AI systems that
do real work.
RAG · Agentic AI · AI Applications · Evaluation · Cloud Deployment
I build production-oriented AI systems for knowledge-heavy and operational workflows—from retrieval and agent orchestration to evaluation, APIs, and cloud deployment.
My systems are built around a simple principle: define what correct means, measure it, engineer for failure, and deploy only what you can evaluate.
4 end-to-end systems · AWS deployment · CI/CD · Evaluation suites
Victor Isuo
AI Systems Engineer
30-case eval suite
Cross-domain
The domain changes. The engineering doesn't.
Industrial diagnostics. Legal intelligence. Autonomous pipelines. AI evaluation. Different problems, different constraints, different definitions of success. The approach stays consistent: understand the workflow, define what good looks like, test it against reality, and design around the ways it can fail. The goal isn't a convincing demo. It's a system you understand well enough to trust within its limits.
What I can own
More than the model.
I can take a system from an idea to a working service — and own the engineering around it.
AI application architecture
Designing RAG systems, agentic workflows, tool-using systems, and multi-step pipelines around the job they need to do.
Retrieval
Building the retrieval layer end to end: chunking, embeddings, hybrid search, reranking, and citations that let users trace an answer back to its source.
Backend services
Python and FastAPI services, REST APIs, validation, error handling, and clean boundaries between the AI system and the rest of the application.
Evaluation
Building test sets, defining scoring criteria, measuring changes, and adding regression checks so a new version doesn't quietly make the system worse.
Cloud deployment
Containerizing services and deploying them on AWS, with CI/CD, secrets management, storage, and load balancing.
Debugging & reliability
Following failures through retrieval, orchestration, model APIs, and infrastructure, then fixing the underlying problem rather than patching the symptom.
Technical depth
The tools behind the systems.
Not a list of everything I've touched — the technologies I use where they solve a specific engineering problem.
LangGraph
CrewAI
Tool calling
Structured outputs
MCP
Agentic workflows
BM25
Hybrid retrieval
Cohere reranking
ChromaDB
Citation grounding
REST APIs
Docker
Async / scheduled workflows
Third-party integrations
ECR
ALB
S3
Secrets Manager
GitHub Actions
OIDC
Benchmark datasets
Weighted scoring
Regression testing
CI gates
Execution patterns
Four systems, four execution patterns.
Each one exists because a workflow was slow or error-prone to do by hand. The underlying pattern is consistent: grounded retrieval or reasoning, checked by an evaluation layer.
Multi-Agent Orchestration
Supervisor-led delegation to specialist agents with isolated context, used when a query genuinely spans multiple domains at once.
Industrial AI Copilot — supervisor + 4 specialists
Sequential Reasoning Pipelines
Role-based handoff where each agent's output gates the next, for domains where the reasoning order matters as much as the answer.
LexAI — 4-agent legal risk pipeline
Autonomous, Schedule-Driven Systems
No human trigger required — ingestion, synthesis, and delivery run on a schedule, with a priority path for time-sensitive signals.
Busiv — 6-hour ingestion, daily briefing
Evaluation & Regression Infrastructure
LLM-as-judge scoring with CI/CD gates, so a prompt or model change that degrades quality is caught before it reaches users.
AgentEval — regression detection at 5% drop
Deployed systems
Deployed systems.
Industrial AI Copilot is the deepest case study, broken down in full below. The other three apply the same discipline to different domains.
Industrial AI Copilot
Multi-agent fault diagnosis, deployed on AWS
Industrial operations — but the capability demonstrated is multi-agent AI system engineering, not an industrial specialization.
Industrial troubleshooting means searching manuals, reading live telemetry, and interpreting visual evidence — usually across three separate tools.
A supervisor agent delegates to four specialists (retrieval, telemetry, analysis, safety) over hybrid dense + BM25 retrieval, live MQTT telemetry, and Gemini vision analysis.
30-case eval suite · 90% answer accuracy · all 10 retrieval cases passed · 3.09s average latency
LexAI
Sequential AI workflow for contract intelligence
Legal — the transferable capability is sequential multi-agent architecture where each stage's output gates the next.
Four CrewAI agents in strict sequence — Analyst → Legal Researcher → Risk Assessor → Plain Language Specialist — over a curated Common Law and UNIDROIT knowledge base, with 14 regex-based risk signals detected before any LLM call.
Research prototype — not legal advice.
Other systems — evidence of range
Busiv
Autonomous, schedule-driven intelligence pipeline
Monitoring an industry for regulatory, product, and market signals consumes hours of manual research every week — and most of what's monitored is noise.
Collect → filter → classify → deduplicate → synthesize → deliver, with no human trigger after deployment. Relevance scoring and a four-category signal layer decide what reaches synthesis; a priority path exists for time-sensitive regulatory signals.
AgentEval
The evaluation discipline behind my AI systems
AI systems degrade silently as prompts, models, or retrieval strategies change — a static benchmark run once at launch doesn't catch that.
RAG, single-agent, and multi-agent evaluation with LLM-as-judge scoring on weighted axes. A regression check compares every run to the last and blocks deployment on a >5% score drop.
Flagship case study
Building it under real constraints.
The industrial setting is incidental. What matters here is how the system was architected, tested, broken, fixed, and shipped.
Problem
Three tools, no shared context.
An engineer troubleshooting a fault has to search technical manuals for the right procedure, pull live telemetry to check whether a reading is actually out of spec, and interpret a photo of a gauge or nameplate — usually switching between three separate systems to do it. None of those tools reason about the other two. The workflow needed one system that could hold all three sources of evidence at once and reason across them.
System architecture
Supervisor-led orchestration.
A query reaches a supervisor agent, which fans out to whichever specialists it actually needs — retrieval, telemetry, vision, or all three — then a report agent synthesizes their findings into one cited response.
Separately, deployment runs through a standard CI/CD path to AWS:
Engineering decision log
Why each piece is what it is.
Every non-obvious choice in this system traces back to a constraint.
| Decision | Chosen | Alternative | Reason |
|---|---|---|---|
| Retrieval | Hybrid dense + BM25 | Dense-only | Domain terminology (part numbers, standard codes) needs exact-match, not just semantic similarity. |
| Reranking | Cohere rerank-english-v3.0 | No reranker | Improves top-k relevance without upgrading the base embedding model. |
| Orchestration | Supervisor + specialists | One flat agent with all tools | Isolated context per specialist avoids token overflow on multi-domain queries; routing stays explicit. |
| Single vs. multi-agent | Both, routed by complexity | Multi-agent for everything | Most queries resolve in 1–4s with a single agent. Multi-agent adds latency that's only worth it for genuinely cross-domain queries. |
| Deployment | AWS ECS Fargate | Hugging Face Spaces | Infrastructure control, no cold-start sleep on inactivity, real production topology. |
| Persistence | S3-backed hydration | Container filesystem | Durable vector store artifacts that survive redeploys. |
| CI authentication | OIDC | Long-lived IAM keys | No stored credentials in GitHub — short-lived, scoped tokens per run. |
Evaluation
A baseline, before any optimization.
30 hand-crafted test cases across spec checks, unit conversion, retrieval, and edge cases — scored on tool-selection accuracy (40%), keyword match (40%), and severity classification (20%), with a 0.70 pass threshold. This is not RAGAS: RAGAS evaluates retrieval quality alone, and this framework also scores tool selection and severity reasoning across the full agentic behavior.
Continuous evaluation beyond this one-time benchmark is what AgentEval exists to provide — it's the evaluation discipline behind this system, not a separate portfolio piece.
Failure analysis
What broke, and why.
Four of the 30 eval cases failed. Understanding why matters more than the score — each one is a specific, implementable fix.
Ambiguous unit in spec check
Agent received a pressure value with no explicit unit and defaulted to psi when bar was implied by context.
A unit-disambiguation step that prompts for confirmation before comparison.
Out-of-scope query, partial match
A query about electrical grounding returned a partially fabricated citation from adjacent-but-irrelevant KB content.
Explicit citation validation requiring the agent to say "not found in the knowledge base" rather than extrapolate.
Multi-parameter spec check
A query with two simultaneous out-of-spec readings — the agent caught one and missed the second.
A loop in the spec-checker that runs once per detected parameter instead of terminating after the first match.
Contradictory inputs
A query stated a reading was both within spec and dangerous — a known LLM failure mode under logical contradiction.
A consistency-validation step that flags and rejects contradictory inputs before tool execution.
Production readiness race condition (during AWS migration).
The ALB marked the service healthy before application initialization — retrieval and agents — had actually finished loading.
Process liveness and application readiness were being treated as equivalent.
An explicit is_ready flag returning 503 until the pipeline finishes initializing, plus grace-period tuning on the health check.
Infrastructure health is not the same thing as application readiness.
Deployment
Off Spaces, onto AWS.
Originally deployed on Hugging Face Spaces, which sleeps on inactivity — not viable for anything meant to look production-oriented. Migrated to ECS Fargate behind an ALB, with ECR for images, S3 for ChromaDB persistence, Secrets Manager for API keys, and a GitHub Actions pipeline authenticated via OIDC. The migration surfaced real problems beyond the readiness race above: an empty knowledge base caused by .gitignore excluding data files (fixed via S3 hydration at startup), and a missing iam:PassRole permission that blocked the first deploy. HTTPS is deliberately deferred pending a purchased domain.
Results
What the numbers mean.
A full plant-wide audit — pulling readings, cross-referencing manuals, checking standards, writing a report — normally takes a qualified engineer an estimated 30 to 90 minutes. The multi-agent path completes the same audit in about 30 seconds for that specific workflow: roughly a 180× reduction against that estimate, not a claim about general system-wide speedup. For a single-equipment query, the single agent returns in 1–4 seconds; multi-agent orchestration is reserved for queries that genuinely span retrieval, telemetry, and safety at once.
On evaluation: 90% overall pass rate (29 of 30 cases), all 10 retrieval test cases passed, and 3.09s average latency across the suite. Full methodology and the raw eval log are in the repository.
Repository / live system
Inspect it yourself.
The live AWS deployment and the full source — including the evaluation runner, the failure cases above, and the CI/CD pipeline definitions — are both public.
Second case study — architecture transfer
Sequential handoff, where order matters.
You can't score a clause's risk before grounding it in a legal standard, and you can't recommend action before the risk is scored. LexAI enforces that order agent by agent. Legal is just where I happened to build it.
Each agent's output is the next agent's required input — the Risk Assessor cannot score without the Researcher's citations, and the Plain Language Specialist cannot recommend before risk is justified. Parallelizing this would mean merging incomplete, ungrounded outputs. Sequential isn't a limitation here; it's the correct model for how a law firm actually reviews a contract.
Fourteen risk patterns — unlimited liability, broad indemnity, one-sided termination, automatic renewal — are flagged by regex on every clause before any LLM call. These signals are handed to the agents as structured input, not discovered mid-reasoning, which is what lets the highest-risk clauses get prioritized when the input budget is constrained.
The live demo runs on free-tier inference with a capped token budget, which limits full-contract coverage on longer documents — documented in the repo rather than hidden. Two config changes (removing the clause cap, upgrading the model tier) move this to full production coverage with no architectural change. That gap between demo-tier and production-tier is itself the kind of constraint I design for explicitly, not the kind I paper over.
Research prototype — not legal advice.
Process
How I approach a new problem.
The domain changes. But the processes to follow stays the same.
Understand the workflow
What task, decision or bottleneck are we trying to improve?
Identify constraints
Data, latency, cost, security, reliability, and how much human oversight the system needs.
Start with the simplest solution
Use conventional software where it is enough. Add retrieval, tools, workflows, agents, or multiple agents only when the problem calls for them.
Define correctness
What does success actually mean, in measurable terms?
Test it
Build the evaluation set early. Measure the system before relying on it.
Design failure behavior
What happens when evidence is missing, conflicting, or wrong?
Put it into operation
Deploy it, watch what happens, and learn from the latency, errors, cost, and real usage.
Engineering principles
Working principles.
Each one tied to a specific decision.
Architecture follows constraints.
Cost, latency, data quality, and reliability determine architecture — I start there and work backward.
Evidence: hybrid retrieval was chosen because domain terminology made dense-only retrieval insufficient.Evaluation precedes trust.
A system that hasn't been measured hasn't been proven to work — measurable pass/fail criteria come before assuming success.
Evidence: the 30-case eval suite was built before any optimization, to get an honest baseline.Failure modes are part of the architecture.
A wrong answer and a wrong action are not the same risk. The NORMAL / CAUTION / WARNING / CRITICAL severity gate exists because a shutdown recommendation needs a different confidence bar than a document lookup.
Deployment is part of engineering.
Containerization, observability, and reproducible deployment are considered from the start, not cleanup work at the end.
Evidence: migration from Hugging Face Spaces to AWS ECS Fargate behind an OIDC-authenticated CI/CD pipeline.Background
A mechanical engineering foundation.
My background is mechanical engineering — constraints, failure modes, tolerances, tradeoffs. It shaped how I think more than what I build. A model that's usually right isn't the same thing as a system that's safe to deploy, and closing that gap is most of what I actually do.
Every system here started as a workflow problem, not a technology I wanted to try out. For any of them I can explain why I chose that architecture, where it still breaks, and what I'd change under a different budget, latency target, or consequence of being wrong.
I'm looking for a full-time AI engineering role, remote or on-site, where I can own systems end-to-end.
University of Uyo
Engineering notes
Notes from the build.
Implementation notes from the systems above.
Industrial AI Copilot: from RAG to a production-oriented agentic system
The full path from a hybrid retrieval engine to a multi-agent system running on AWS.
Read on Hashnode ↗Why I built a separate evaluation system before trusting my own AI
The case for LLM-as-judge scoring and regression gates over a one-time benchmark.
Read on Hashnode ↗I built an AI system that runs while I sleep
The architecture behind a schedule-driven pipeline with no human trigger.
Read on Hashnode ↗What mechanical engineering taught me about building AI systems
Constraints, failure modes, and tradeoffs — and why sequential agent handoff was the correct call for LexAI.
Read on Hashnode ↗Get in touch
Get in touch.
I'm looking for a full-time AI engineering role — remote or on-site — where I can own systems end-to-end. If you'd like to talk through a specific system, a take-home, or a role, send a note and I'll respond within 24 hours.