Development / AI
AI & Agent Engineering.
Somebody has to build the robot army. That’s the job I do — the fleet of agents, the tools they run on, the skills that teach them judgment, and the brakes that keep them from doing damage. One engineer, data model to deploy.
10
specialized agents in one workforce
205
tool methods across 37 groups
21
skills teaching them when to act
100
neural networks training in parallel
0
fabricated rows in agent-facing data
Where this comes from
These engagements were subcontracted and stay unbranded at the client’s request. The architecture, the decisions, and the numbers are mine to discuss — the logos aren’t.
Enterprise agent platform
A virtual workforce: a fleet of specialized agents with shared memory and real authority to act, running a company’s coordination layer continuously through its own systems. I built the tool and skill layers they operate through, the chat surface people manage them from, and the dashboard they all report into.
Clinical assessment product
An AI-guided ADHD and autism assessment: a conversational avatar conducts a directed interview across roughly twelve domains, drafts a report overview, and surfaces patterns worth a clinician’s attention — suggestions for the reviewing doctor, never diagnoses. Delivered end to end as a configurable multi-clinic product running on a local LLM.
Machine learning simulation
A casino-floor game built on the real operating data of casinos the client ran, where the objective is arranging a floor to earn the most. A person can play it and so can the machine — a hundred reinforcement-learning agents train against the same board and get measurably better at it.
Building an AI Workforce
The product isn’t a chatbot, it’s a set of coworkers — and somebody has to build them. A company ends up with a fleet of agents that each own a function, share what they know, and act through the systems the business already runs on. I build that whole layer: what the agents can do, how they know when to do it, and the surface people manage them from.
Stand up a fleet of agents that each own a job
Not one general-purpose assistant but specialists — revenue and pipeline, operations, marketing, finance, customer success, executive assistant, communications, and a QA agent whose whole job is watching the others’ output. They hold persistent memory, hand work between each other, and run continuously rather than waiting to be asked. People talk to them in a dashboard, watch what they’re doing, and set what each one is allowed to touch.
10 specialized agents operating as one workforce
Build the tool layer the workforce runs on
Tools are the APIs — the concrete things an agent is actually capable of doing. I design and build them in three kinds: the company’s internal operating surface (tasks, tickets, deals, metrics), integrations with what the business already runs on (Google Workspace, Salesforce, Intuit, calendar and mail), and creative tools that let an agent produce something rather than only report on it — video, voice, brand assets.
37 tool groups · 205 methods
Turn raw capability into judgment
The distinction that matters most in this work: tools are what an agent can do, skills are how and when to do it. An agent with a tool can technically call it; an agent with the matching skill knows that it should. Writing skills has more in common with onboarding a new hire than with programming — and I keep a test asserting every tool method has a skill granting it, so nothing an agent can reach is something nobody taught it to use.
21 skills across 10 agents
Let people build their own interface by asking for it
The dashboard people read is assembled from the same tools the agents call, so someone can ask the system for a view — a pipeline board, a KPI tile, a live feed — and get a working widget instead of a request in a backlog. Collapsing the human and agent data paths into one has a second payoff: a capability built for agents shows up for people free, and the reverse.
12 widget types on one shared, org-scoped renderer
Trust & Verification
Autonomous software is only worth deploying if people believe what it tells them. Two versions of that problem, and I’ve shipped answers to both: models invent things, and an agent should never be able to see data that isn’t its own.
Make the numbers dependable
A model that narrates its own tool results in prose will miscount rows and invent entries. Rather than prompt-engineer around that, I moved the data out of the model’s hands: the server captures the structured payload the tool actually returned, the client renders it one-to-one, and the model gets a caption — so a count is a literal array length. A turn-anomaly watcher flags drift on top of that, and the rule underneath both is that the database is ground truth and the transcript never is. An agent will cheerfully tell you it fixed something it didn’t, so “done” means a real row exists.
A class of data error to zero — and 330+ test files holding it there
Scope authority at the data layer, not the interface
On a platform scoped to an organization hierarchy, authority inherits downward: a parent org’s agent can act across its children, a child’s can’t see sideways or upward. I inject that scope where data is fetched rather than enforcing it in the UI, so an agent cannot request another organization’s records even if it tries. When you’re handing autonomous software real access to a business, that boundary is what makes it adoptable.
Model & ML Systems
Beyond calling a hosted API. I’ve built environments that learn from playing, run models on hardware the client controls, and design conversations that actually gather evidence rather than just taking turns.
Build environments where people and machines play the same game
A casino-floor simulator where the objective is arranging a floor to earn the most — which tables, which mix, placed where — built on the real operating data of casinos the client ran. A person can sit down and play it, and so can the machine: the AI rearranges the floor, sees what it earned, and gets measurably better at the game. Because the whole system is API-first, agents play through the exact interfaces a human plays through, which is the only reason the two are comparable at all.
Trained on real operating data from working casinos
Train distributed reinforcement-learning systems
A hundred PyTorch deep Q-network agents training in parallel, each exploring a different strategy, compiling into a master consensus network that then plays live. Trained models sit in object storage with a queue pushing updates, so a running system picks up new learning without a restart — all while the simulation itself holds 100+ concurrent players across 50+ tables at 60 frames a second.
100 DQN networks + a consensus network, in production on AWS
Run models on infrastructure the client controls
Not every product can send its data to a third party. I’ve shipped local LLM deployments — running an entire clinical interview engine and its report generation on self-hosted infrastructure, which keeps sensitive conversation off someone else’s servers, and driving live analysis inside a simulation. Hosted versus local is an architecture decision with real consequences, and I make it deliberately rather than by default.
Design conversations that gather real evidence
The difference between a chatbot and an intake instrument is the follow-up. I built a directed interview engine that steers a conversation until it has what a given domain actually requires and only then moves on, so an incomplete answer gets pursued instead of merely recorded. Downstream it drafts a report overview for the reviewing clinician and surfaces patterns worth a second look. The line the product does not cross: those are suggestions for a doctor, never diagnoses.
~12 domains, branching across two clinical assessment paths
Shipping & Safety
An AI feature that never reaches production is a demo; one that reaches production without brakes is a liability. I handle both ends — getting it live, and making sure a confused agent can’t do real damage once it’s there.
Keep a person in the loop where the stakes are
Agents get authority in proportion to how reversible their actions are. Reads are free, routine writes are logged, and anything destructive or irreversible stops and waits for a human. In practice that means scoped credentials rather than blanket access, an audit trail on every action, and a strong bias toward suggest-and-confirm over silent execution. The design goal is simple: the worst outcome of a confused agent should be a rejected suggestion, not a restored backup.
Suggest, never silently expand
Fail loudly at the boundary
Every agent call gets parsed and validated where it enters the system — identifiers, dates, assignees, malformed arguments — so a bad call fails visibly instead of quietly writing garbage into a live business system. I also made mis-addressed calls visible rather than invisible: a class of bug where the agent believed it had acted and nobody had any way to know it hadn’t.
Take it from data model to deploy
UI, API surface, data model, and the deploy path — Next.js and React with TypeScript, Node and Fastify services, PostgreSQL behind a typed data layer, running on Kubernetes and AWS with real CI/CD. I build the team-facing side too: a per-tier hot-mount development loop that took the edit-to-live cycle from rebuild-and-wait down to nothing, plus the runbook for the failure that kept re-breaking it.
Build with AI, deliberately
I plan the architecture and write the spec first, then drive execution with an AI pair — owning every design decision and reviewing every line that comes back. That’s how one experienced engineer delivers at closer to team scale, and it means I have production experience on both sides of this technology: building with it, and building it.
134 commits in three weeks ramping into an unfamiliar monorepo
Architecture
Illustrations of the ideas, not captures of the software — the products are unbranded, and passing concept art off as a screenshot would be a strange move on a page about being careful with the truth.
The stack
AI & ML
Application
Data
Infrastructure
Quality
Available for work
Every robot army needs a human.
I'm the one who builds it, teaches it the job, and makes sure it can't knock anything over. Agent fleets, tool and skill layers, ML systems, or the whole product end to end — happy to walk through any of it in detail.