I’m Hussain — an AI Software Engineer working on agents, retrieval-augmented generation and LLM applications, and on the full-stack software that has to hold them up.
Architecture, implementation, evaluation and deployment — treated as one job, because a model that works in a notebook and a system people can depend on are not the same deliverable.
AI Agents
Graph-structured workflows, tool calling, state
RAG Systems
Ingestion, chunking, retrieval, grounded answers
LLM Applications
Structured output, streaming, context budgets
Intelligent Automation
Queues, schedules, realtime and push delivery
Full-Stack Systems
Typed APIs, access control, tested domains
Cloud Deployment
Stateless compute, CI, environment-scoped config
Selected work
Four projects, each written up as an engineering case study: the problem, the architecture, the decisions that shaped it, and what proved difficult.
A retrieval-augmented chatbot that answers from a private, continuously ingested corpus instead of the model's training data — with every answer traceable to its source.
View case study
A multi-role institute management platform covering attendance, finance, academics and operations — built as a tested, queue-backed system with realtime delivery and CI, not a CRUD app.
View case study
A working reference set for the primitives agent systems are actually made of — graph-structured workflows, retrieval strategies, vector stores and schema-constrained model output.
View case study
A role-based internal ticketing system — reporters, agents and administrators working the same queue through different permissions — deployed as serverless functions.
View case study
AI Engineering
Capability described through implementation. Every practice below exists in code, not just in a list of technologies.
Agents are control flow before they are prompts. I build them as explicit graphs — ordered steps, concurrent branches, and routing that depends on state — so a failing step can be identified instead of a whole prompt being suspect.
Most RAG systems fail at retrieval, not at generation. I treat ingestion, chunking and retrieval as the parts with the quality problem, and provenance as a requirement rather than a feature.
The boundary between a model and application code is where LLM products break. Anything crossing it gets a schema, so a malformed response fails at the boundary instead of propagating.
Engineering philosophy
A demo has to work once, for someone who wants it to. A system has to keep working while inputs change, providers change and nobody is watching. Almost everything that separates the two is ordinary engineering.
A model is a probabilistic component inside a deterministic system. The system's job is to make the unpredictable part safe: validate what comes back, constrain what it can do, and define behaviour for the case where it is wrong.
If you cannot see what an agent did, you cannot fix it. Explicit state transitions, logged tool calls and retrieval traces turn 'the answer was bad' into a specific step that misbehaved.
AI systems handle credentials and private data by default. Secrets stay in the environment, inputs are validated and sanitised at the boundary, and access is enforced centrally rather than per handler.
Slow work belongs on a queue, not in a request. Compute stays stateless so it can be replicated, and state lives where it can be shared — which is what makes growth a configuration change rather than a rewrite.
The most important thing an agent can know is when to stop. Irreversible actions, low-confidence answers and unfamiliar situations should route to a person by design, not by accident.
Prompt changes are code changes without tests unless you measure them. A fixed question set, a retrieval quality baseline and a regression check make an improvement provable instead of anecdotal.
How I build AI systems
The order matters more than the steps. Most AI projects that fail were built correctly and aimed at the wrong problem, or shipped without any way to tell whether a change made them better.
What decision or task is this actually replacing, who depends on it, and what does being wrong cost? Most AI projects that fail were correctly built and aimed at the wrong problem.
Decide what the model is responsible for and what it is not. Draw the data path, name the failure modes, and pick where a human belongs — before any code exists.
Typed boundaries, schema-constrained model output, thin handlers, secrets in the environment. The AI is one component in a system built to normal engineering standards.
Measure retrieval quality and answer behaviour against a fixed question set. Establish a baseline first, so later changes can be shown to be improvements rather than assumed to be.
Stateless compute, external storage, environment-scoped configuration, CI that builds and tests before merge. Deployment is a property of the design, not a step at the end.
Watch what users actually ask, where retrieval misses and where the system escalates. Real usage is the only source of the next set of improvements worth making.
Technical stack
Restricted to technologies that appear in real work. A longer list would be easy to write and worth less to read.
Agent orchestration, retrieval and output contracts.
APIs, access control and asynchronous work.
Relational, document and vector storage.
Typed, server-rendered interfaces.
Deployment, CI and platform services.
Proving the system still works after a change.
Currently exploring
Open questions I'm spending time on, rather than a list of things I already know.
Multi-step agents that plan, call tools and know when to hand back to a person.
Making prompt and retrieval changes measurable against a fixed question set instead of judged by feel.
Ingestion freshness, retrieval quality and citation integrity at the point where a corpus stops being small.
What an agent should keep between sessions, and what it should be made to forget.
When splitting work across specialised agents beats one capable agent, and when it only adds coordination cost.
Queues, workers, streaming and observability — the layer that decides whether an AI feature survives contact with users.
About
I came to AI engineering through software engineering, and most of what makes an AI feature trustworthy turns out to be ordinary engineering — validation, queues, provenance, evaluation.
I’m based in Faisalabad, Pakistan and work remotely. If something below doesn’t hold up under inspection, I’d rather hear it than not.
More about how I workThe case studies describe code you can open and check. Nothing here rests on a claim you have to take on faith.
Where a result has not been measured, the case study says so. An invented number is worth less than an empty space.
Each case study records what was chosen and what was given up. Architecture without its trade-offs is marketing.
Contact
Send me the problem — not the spec. If it’s a fit I’ll tell you how I’d approach it; if it isn’t, I’ll say so.
Faisalabad, Pakistan · PKT (UTC+5) · Working remotely