Applied AI Engineer · Boston

systems forreal-worldworkflows.

I build and evaluate AI systems for real organizational workflows. My current work focuses on agent systems, tool use, evaluation, workflow automation, guardrails, observability, structured data, and human oversight.

Explore my work
GitHub Resume

Selected technical work

Evidence before claims.

Four projects: independent agent-system work followed by collaborative full-stack engineering. Each claim links back to public implementation and stated limits.

01

Flagship · Applied AI engineering

When is more agent complexity actually worth it?

Agentic Analytics Lab

Problem
Analytics agents can sound correct while violating the data or metric boundary.
What I built
A guarded ClickHouse analytics agent, deterministic evaluation layer, and separate single-agent, routed-execution, and natural-language routing lanes.
Measured evidence
146 tests on Python 3.11/3.12 · green CI and CodeQL · reviewed 12/18 baseline vs. 17/18 oracle-routed comparison, explicitly bounded to execution-layer evidence.
Read case study →View repository ↗

02

Evidence-controlled research agent

Let the model choose the path without waiving the evidence rules.

Agent Systems Evidence Scout

Problem
Research agents can produce fluent answers while citing papers they never verified.
What I built
A bounded arXiv research workflow with model-directed tools, a per-run verification registry, and a deterministic citation gate outside the LLM.
Measured evidence
39 deterministic tests · Python 3.11/3.12 CI · successful Hugging Face + arXiv integration run in 4 of 6 available steps.
Read case study →View repository ↗

03

Prototype · Human-in-the-loop agents

Automation that knows when to ask permission.

HomeOps Agent

Problem
Household automation needs a clear boundary between safe routine work and actions that require a person.
What I built
A deterministic Good Night Check with explicit tool contracts, approval gates, failure handling, audit history, and a Strands adapter.
Measured evidence
12 tests on Python 3.11/3.12 · Chromium scenario-parity coverage · simulated device layer for reproducible safety and failure tests.
Read case study →View repository ↗

04

Collaborative Full-Stack / Applied AI Engineering

Did the shopper succeed, or just finish running?

Glasswing Gateway

Problem
A storefront can work for people while browser agents miss product evidence or shopping constraints.
Team implementation
A collaborative storefront-testing prototype that turns merchant-reviewed shopping scenarios into bounded browser sessions, replayable evidence, and separate deterministic and AI-based evaluations.
Engineering highlights
Merchant approval before execution; constrained Playwright actions; schema-validated model responses; independent evaluation; owner-scoped records.
My contribution & team
My hackathon work covered investigation/replay UX, authentication/security work, regression testing, and demo coordination. Later release hardening was AI-assisted. The application was built with Nathan, Andrew, and LeulTe.
Technology stack
Next.js, React, TypeScript, Tailwind CSS, Playwright, Zod, Supabase Auth, and the OpenAI Responses API.
Verification limits
Local fixture tests exercise the application and browser runner with synthetic identity and model outputs. Hosted Supabase behavior and live-model outcomes remain unverified. A hackathon-origin prototype, not a production service.
View Glasswing Gateway on GitHub ↗Read contribution records ↗

Supporting product and measurement work: Closing the Loop →

How I work

I care about what happens after the demo.

Useful AI needs a baseline, a boundary, and a way to learn from failure.

Baseline first

Start with the simplest credible system, define success, and make added complexity earn its place.

Bound the tools

Permissions, data scope, semantic rules, and approval gates are part of the architecture.

Separate the measures

Execution, correctness, grounding, routing, latency, and cost should not collapse into one score.

Learn from failure

Stable failure patterns are evidence. They should shape the next experiment, not disappear from the story.

Current context

Applied AI Engineering ·
AI for Knowledge Work

Alongside my engineering work, I serve as Applied AI Programs & Operations Coordinator at the Paul English Applied Artificial Intelligence Institute at UMass Boston. The role gives me a close view of how people learn, adopt, and operationalize AI, and why technical systems must make sense inside the organizations around them.

About

Engineering with a wider systems view.

My path into applied AI is interdisciplinary: psychology, analytics, information systems, operations, and hands-on system building.

That mix shapes the questions I ask: Can the system stay inside its boundary? Is its output grounded? What happens when a tool fails? When should a person remain in control? And what evidence would justify the next layer of complexity?

I am completing an MBA at UMass Boston. It supports my focus on applied AI engineering rather than replacing it.

Let’s talk

Useful AI.
Clear evidence.

Email Ajanee LinkedIn GitHub