AI Engineering · led by Lam Hoang
AI systems & automation engineering
Most AI projects die between the demo and the daily run. We build the second kind: agent systems, retrieval pipelines, and workflow automation that operate unattended, with human approval gates exactly where they belong — and then we stay on them, watching the runs and tuning what drifts. The build is where the work starts, not where it ends.
This is Lam Hoang's side of the studio: ten-plus products in production, the oldest running since 2020. The pattern is the same in every one — a system does the repetitive work unattended, a human approves anything with consequences, and someone watches the runs. The projects are listed with their numbers on the work page; the search strategy they often serve is agentic SEO.
What this work looks like
Agent orchestration
Multi-agent systems that research, draft, review, and execute — with budgets, circuit breakers, and adversarial review built in. Not a chatbot bolted onto your site. An orchestrated system splits the work across roles: one agent gathers, another drafts, a third critiques against explicit rules before anything reaches a person. Cost ceilings and step limits mean a bad run stops itself instead of burning the API budget overnight. We build on the Claude Agent SDK and MCP — the same stack our own newsroom pipeline uses, exposing eleven internal tools to the agents that run it.
RAG & semantic search
Retrieval over your own knowledge: vector databases, hybrid search, reranking, and grounding. The difference between an assistant that guesses and one that knows. The unglamorous parts decide whether it works — how documents get chunked, how queries get rewritten, when the system says "that's not in the knowledge base" instead of improvising. TroponinIQ runs this stack over a professional coach's methodology on pgvector, and reached 100+ paying subscribers within 3.5 months. The same chunking mechanics also govern how answer engines read your site — which is why this service and our search strategy work share a vocabulary.
Workflow automation
The connective tissue between your tools — n8n-class workflows, custom APIs, and pipelines that replace the copy-paste steps quietly costing you hours every week. We start by writing the workflow down as it actually happens, exceptions included, then automate the boring middle and leave the judgment calls to a person through an approval queue. The measure of success is dull on purpose: a Tuesday task that stopped existing, and a log proving the system did it instead.
Custom SaaS & internal tools
Multi-tenant products and internal platforms, end to end: auth, billing, portals, and the AI layer — shipped by one engineer who owns the whole stack, so there's no integration seam where projects usually die. Oase, the operating system for design agencies, is the reference build: client portals, design review, quoting, invoicing, and a context-aware assistant, built by a two-person team. The build history is on the work page and the people behind it on the about page.
Running it, month after month
We watch the system operate: reviewing output, catching failure modes, adjusting rules, swapping models when better ones land. You get a report on what it did and what that produced — not a repo and good luck. This is the managed-automation part, and it's most of the value: the tools are available to anyone, the tuning discipline is not. Editorial pipelines get the same treatment under content systems.
How an engagement runs
Scope against the real workflow
We map the process as it actually runs — inputs, exceptions, who approves what — and pick the narrowest slice worth automating first. The first deliverable is a working vertical slice on real data, not an architecture diagram. Narrow on purpose: the fastest way to find where an automation breaks is to run it small and watched.
Build and calibrate
The slice goes live with approval gates at every consequential step: nothing sends, publishes, or spends without a sign-off. We calibrate against your judgment — wherever the system's output diverges from what your team would have done, the rules change until it doesn't.
Run, watch, widen
The system runs on schedule while we review its output, catch failure modes early, and gradually widen what it's trusted to do. Approval gates loosen only where the track record earns it — autonomy is granted per step, not assumed per project.
Report in plain numbers
What ran, what it produced, what it cost, what failed, and what we changed. When a better model lands, we test it against your actual workload before swapping it in — you hear about it in the report, not by noticing your system got worse.
Proof, with numbers
100+
paying subscribers within 3.5 months of kickoff
TroponinIQ
An AI coaching platform built solo on a professional coach's methodology — RAG over proprietary knowledge with pgvector, subscriptions, and a client portal. Kickoff to paying users inside a quarter.
313
consecutive days · 160+ entities
Descout
An automated newsroom: source monitoring, newsworthiness scoring, drafting under editorial rules, and syndication — with an MCP server exposing eleven tools to the agents that run it.
Runs on our own properties first · human-approved, reversible
A private internal-linking engine
Managed automation in miniature: it proposes, a human approves, changes apply byte-safe with an undo path, and it measures its own Search Console lift — before and after, per link.
Why us
- Ten-plus products still running in production, the oldest since 2020 — systems that run daily without hand-holding, listed with their numbers on the work page.
- One engineer owns the whole stack, from data model to deploy to the AI layer — no integration seam, no three-vendor finger-pointing when a run fails.
- Human-in-the-loop is an architecture choice here, not a disclaimer: approval gates, snapshots, and undo paths are designed in from the first vertical slice.
- We manage what we build. The tools are available to anyone; the process for tuning a system week after week is the part that doesn't copy, and it's what you're actually buying.
- The engineering sits next to a 30-year search strategist — useful when the system you're automating has to be legible to machines as well as correct. You can hear the two disciplines argue it out weekly on the podcast.
Claude Agent SDK · MCP · RAG/pgvector · Next.js · n8n · Production since 2020
Common questions
07 Questions
What does managed automation mean?
Managed automation means we build the system and then operate it — the engagement doesn't end at handover. We review output, catch failure modes, adjust rules, swap models when better ones land, and report monthly on what ran and what it produced. The alternative — a delivered repo and good luck — is where most automation projects quietly die.
What's the difference between an AI agent and a workflow automation?
A workflow automation follows a fixed path; an agent decides its next step based on what it finds. Most business problems want both: deterministic rails for the parts that must never vary, agent judgment for the parts you can't enumerate in advance. We default to the simplest mechanism that works — agents where they earn their complexity, plain pipelines everywhere else.
What is RAG, and why does it matter?
Retrieval-augmented generation grounds an AI's answers in your own documents instead of its training data. The system retrieves relevant passages from a knowledge base — vector search plus reranking — and answers from those, with sources. It's the difference between an assistant that guesses plausibly and one that cites your actual policy, price list, or methodology.
Where do humans stay in the loop?
At every step with consequences: anything that publishes, sends, spends, or changes production data goes through an approval gate. The system drafts unattended; a person signs off. Gates loosen over months, only where the track record supports it — our own newsroom has run 313 consecutive days this way, with editorial rules enforced in the pipeline and a human able to step in at any point.
What happens when models change?
Model churn is an operations problem, and we treat it as ours. Because we run the systems we build, we test new models against your actual workload, compare output quality and cost, and swap only when the numbers favor it. You hear about the change in the monthly report — not by noticing your system got worse.
Who owns the system once it's built?
You do — code, prompts, data, and infrastructure run under your accounts. What we retain is the operating role, for as long as it's worth paying for: the watching, tuning, and reporting. If you take it in-house later, you inherit a documented system your team already holds the keys to, not a dependency on us.
How fast is something actually running?
A working slice of the automation runs on real data inside the first month — that's how we scope. Broad platforms take longer to finish, but nothing we build stays theoretical for a month: the fastest way to find where an automation breaks is to run it small, watched, with an approval gate in front of anything irreversible.
Working together