I'm Zeeshan Yaqoob.
I turn complex workflows into
AI agents that do useful work.
From plant-floor control systems
to tool-using agents. Built with intent.
Tested with evidence.
01 / FEATURED CASE STUDY
Real integrations. Explicit boundaries.
Inspect the architecture below.
Six workflows. A queue-based runtime. One connected assistant.
Verified from project files. Current runtime operation has not been tested.
JARVIS / VOICE CHAT
SuccessRespond to Webhook
ErrorRespond Error
Reorganized for readability from the supplied n8n screenshot. Not a live run.
One agent. A useful set of tools.
Boundaries enforced in code.
Jarvis combines saved n8n workflows with Python services for speech, browser and desktop control, memory, notes, reminders and screen reading. Docker Compose separates the main process, worker and task runner, with PostgreSQL, Redis and a WhatsApp bridge.
The supplied workflow shows a webhook connected to the AI Agent, with separate success and error response nodes. Tool connections sit beneath the agent rather than hiding the orchestration in a single prompt.
Postgres chat memory, remember facts and recall facts.
Read Gmail, create drafts, read events and manage calendar entries.
Web search, browser opening, a PC controller and calculation.
Set, list and cancel reminders, with a daily briefing workflow.
These tool categories are visible in the supplied n8n workflow, available through “Inspect original workflow” above. The screenshot documents the connections, not a benchmark of every tool's reliability.
The PC controller is designed to enforce action boundaries in code. Tool access does not mean unrestricted execution. These boundaries are documented in the project brief. The source review established the surrounding controller implementation; a current live run has not been verified.
THE WORKFLOW COLLECTION
Reviewed in the local project. These are implemented workflow artifacts, not claims that every integration is currently running.
Queue mode is configured in the repository. This diagram explains the declared components; it does not represent live service health.
openWakeWord, faster-whisper and Piper TTS around the n8n agent.
A workflow graph makes the agent's dependencies and response paths inspectable.
Tool-call reliability, prompt efficiency and controller safety matter together.
02 / SALES WORKFLOW CASE STUDY
A working sandbox demonstration.
From research to CRM, with a human in the loop.
G / 02 · PERSONAL PROJECT
Research the lead.
Explain the fit.
Ask before the handoff.
A sales automation system built across five n8n workflows. It brings together web research, ideal customer profile (ICP) scoring, Slack approval and HubSpot record updates, with Supabase/Postgres holding the workflow data.
The engineering focus is the handoff: turn scattered lead signals into an evidence-backed recommendation a person can review before the CRM changes.
Form input or demo email text
Tavily search + LLM research
Deterministic JavaScript ICP score
A person approves the handoff
HubSpot contact, company and deal
SUPABASE / POSTGRES Workflow data across the pipeline
FROM THE ACTUAL DEMO
The workflow, then the human handoff.
Real demo evidence, with private details removed.
ICP SCORE
Test lead · Low priority
The lead is flagged for review. Only authorized reviewers can approve the handoff.
The recorded sandbox shows contact and deal associations inside HubSpot.
DEMO NOTES Summaries of the supplied frames. Open each screenshot to inspect the original evidence.
GTM / PROJECT GALLERY
Original project screenshots.
Explore each frame, then open it to inspect.
The original n8n canvas: contact, company and deal upserts, record associations, and a shared failure path. Open the image and zoom in to inspect the node labels.
Original workflow canvases and sandbox evidence. Private details are removed; these frames do not show current production activity.
Tavily and LLMs support lead research. Evidence-weighted JavaScript scoring keeps the ICP calculation explicit and inspectable.
Slack provides the human approval step before the CRM handoff. Only authorized reviewers’ reactions count toward the decision.
Contact, company and deal upserts carry the approved lead into the CRM, with Supabase/Postgres supporting the workflow's data layer.
A working sandbox flow, supported by the saved workflows and a recorded demo. Email intake uses manually supplied demo text. Production deployment, reliability at scale and business impact have not been established.
03 / FURTHER EXPLORATIONS
A closer look at the systems,
the decisions and the results.
Actual Dexter application screenshot · From the public repository · Click to enlarge
The architecture behind
the assistant.
I designed Dexter’s complete LangGraph architecture: the supervisor, specialist agents and the paths that connect reasoning to tools. AI assisted the tool implementation and built the UI.
System architecture and agent orchestration. Existing tools and AI-assisted code support the implementation.
Personal-assistant scope. Multi-user data isolation has not been established.
Explore the repositoryDEXTER / SYSTEM DESIGN
A supervisor coordinates the work. Specialists use tools, return their findings, and hand control back.
Plan → dispatch → review the result
Specialists request tools; results return to the originating agent.
Specialist replies return to the supervisor.
The next step runs, or the turn moves to synthesis.
Combines multi-step findings into one response.
DEXTER / PROJECT GALLERY
Original project screenshots.
Explore each frame, then open it to inspect.
The real Chainlit application interface from the project repository. Zeeshan designed the agent architecture; AI built the UI and assisted the tool implementation.
Real application screenshots using sample inputs. These examples show behavior, not a production reliability benchmark. Open a frame to zoom in.
Actual MLflow experiment dashboard · From the public repository · Click to enlarge
A refund-support agent evaluated on seven synthetic scenarios across seven metrics, with runs tracked in MLflow. Four improvement cycles took the suite from 34 to 49 passing checks.
49/49 is a controlled test-suite result. Refund issuance is simulated; this is not a production payment system.
View evaluation workDEEPEVAL / PROJECT GALLERY
Architecture and original screenshots.
Explore each frame, then open it to inspect.
Agent setup, scenario execution, trace capture and seven evaluation metrics feed an iterative improvement loop. Enhanced reproduction of the original project architecture supplied by Zeeshan.
Historical screenshots from the project repository. Seven synthetic scenarios; the agent and judge share a model family, and improvements were tuned against this suite. These results do not establish held-out or production performance. Refunds are simulated.
Actual training and validation curves · From the public repository · Click to enlarge
A real-time textile inspection system using YOLOv8 and OpenCV, with a Flask dashboard for live inference and reporting. Built as my electronics thesis, with NGIRI funding.
Explore the projectFABRIC INSPECTION / PROJECT GALLERY
Original project images from the README.
Explore each frame, then open it to inspect.
Original Flask application home screen offering video and live-webcam inspection.
Authentic images from the project README, presented without fabricated outputs. Recorded demonstrations and training results do not establish production or unseen-fabric performance.
04 / APPLIED INDUSTRIAL AI
Design-basis extraction with verbatim source evidence, catalogue-grounded BOM drafting and document automation for engineering teams.
Structured extraction with source citations and page-level verification.
Professional work is described generically. No client documents or confidential screenshots are shown.
Illustrative signal motif. The reported score comes from the project review, not this graphic.
05 / CONDITION MONITORING
A bearing-monitoring prototype evaluated on a record-split laboratory benchmark, with a macro F1 of 0.9169.
Not certified or field-validated. A record-split laboratory score should not be treated as evidence of performance on unseen machines or operating environments.
04 / ENGINEERING PRINCIPLES
Good engineering is more than
a convincing demonstration.
Start with the actual problem, the people using the system and the tools they already depend on.
Combine agents, retrieval, APIs and workflow automation. Use LangGraph, n8n and Python where they fit.
Test behavior, trace decisions and improve from failures. Use repeatable evaluations rather than intuition alone.
05 / THE ENGINEERING FOUNDATION
I bring a controls engineer's attention to reliability into applied AI.
I'm Zeeshan, an AI automation engineer based in Lahore. Before building AI systems, I commissioned Honeywell Experion DCS and multi-vendor PLC systems in sugar, fertilizer and paper plants.
That background shapes the questions I ask: What happens when a component fails? Can the output be traced? How will we know the system works?
The Automators Pvt Ltd
Sukkur IBA University
HS Engineering · LX & C300
06 / LET'S BUILD SOMETHING USEFUL
Open to remote AI engineering roles
and freelance automation projects.