I build the infrastructure AI agents actually run on: agent runtimes, sandbox isolation, and the developer platform underneath them.
Eight problems I've owned across agent infrastructure, developer platforms, enterprise AI, analytics, and governance. Open any of them for the full story.
An agent that executes code is an untrusted workload holding your credentials. Most teams solve that by not letting agents do anything interesting. We built real isolation instead.
Platform teams write runbooks. Engineers don't read them — they file a ticket or they guess. The knowledge exists; the interface is wrong.
Most AI-for-incidents demos showcase the novel failure. Production is the opposite: the same signatures recur, and at 3am you want deterministic, not creative.
Generic cost optimizers assume steady-state traffic. A business with a hard seasonal peak has the opposite requirement.
A useful enterprise AI product is as much a legal, compliance, and workflow problem as a model problem. The product had to make natural-language analysis trustworthy enough to use.
Sales teams needed answers assembled from enterprise knowledge, not another chatbot that improvised. Retrieval and governance were the product foundations.
Managing infrastructure as SaaS requires a shared, real-time view of system behavior. Without it, every support case begins with reconstructing reality.
At platform scale, moderation cannot be a collection of local judgment calls. Policy, escalation data, and model quality have to operate as one system.
Three domains, with self-assessed depth against an explicit rubric rather than a logo wall. I'd rather be checked on this than flatter myself. Open a domain for how I actually use it.
Defined architecture and requirements, made the build/buy call, can defend the tradeoffs at a whiteboard.
Wrote PRDs against it and worked daily with the engineers building it.
Evaluated it, benchmarked it, or used it as reference.
Agent runtimes, the protocol layer above them, and retrieval that holds up in production.
Kubernetes at multi-tenant scale, and the isolation and autoscaling layers on top.
The measurement layer — pricing, adoption, reliability, and cost.
Part of a platform PM's job is knowing when not to build. These are categories I've evaluated seriously, with the positioning I formed at the time. Reasonable people disagree, and these markets move fast.
| Product | Category | Positioning as I read it |
|---|---|---|
| ScaleOps | K8s cost optimization | Strong automated right-sizing. Optimizes toward observed steady state, which is the right default for most fleets. |
| Cast.ai | K8s cost optimization | Broad automation and good bin-packing. Best fit where infrastructure policy can be delegated wholesale. |
| Zesty | K8s cost optimization | Commitment and capacity management angle. Value concentrates on the purchasing side rather than workload shape. |
| AWS AgentCore | Managed agent runtime | Managed runtime with the depth of the AWS control plane behind it. Strongest where you're already all-in on AWS identity. |
| Anthropic Agents API | Managed agent runtime | Cleanest developer ergonomics of the group. Optimizes for time-to-first-agent over infrastructure control. |
| Fly.io Sprites | Ephemeral sandboxes | Fast, lightweight isolated execution. Attractive when the unit of work is short-lived and stateless. |
| Vercel Sandbox | Ephemeral sandboxes | Tight integration with an existing deploy workflow. Compelling if your app already lives there. |
| Datadog | Observability / AIOps | Deepest signal coverage in the category. The question is usually cost curve and data gravity, not capability. |
This page is generated from a single structured markdown file. So is my resume PDF. So is the context an LLM gets when it's asked about my work — I built a local MCP server over the same source so an agent can query it directly rather than scraping a webpage. The point isn't the novelty. It's that a career, like a product, benefits from having one source of truth and a machine-readable interface.
The structured profile behind this page. Plain markdown with YAML frontmatter — readable by a person, parseable by a model, and the same file the resume PDF builds from.
profile.md →A personal MCP server that turns a directory of markdown into a semantically searchable knowledge base, with drafting tools on top. Built for my own use; running daily.
| Tool | Purpose |
|---|---|
search_knowledge_base | Semantic search across the corpus, optionally scoped to a category. |
read_entry | Read one entry with its frontmatter intact. |
create_entry | Create a new entry. Fails if it already exists unless forced. |
update_entry | Append or overwrite. Appends by default — destructive mode is opt-in. |
retrieve_drafting_context | Pull persona, policy, and relevant entries before writing anything. |
check_task_readiness | Check whether enough is known to start. Returns what's missing. |
ingest_knowledge_base | Re-index the corpus. |
compile_indexes | Generate wiki-style index files per category. |
health_check_kb | Report stale entries, missing metadata, and stub content. |
A person's bio and a strategy doc want different treatment. Short or atomic entries stay whole; long documents split on markdown headings with the YAML frontmatter re-prepended to every chunk, so a retrieved fragment still knows what it belongs to. A sliding window is the fallback, not the default.
A debounced filesystem watcher re-indexes changed files automatically, re-ingest deletes prior chunks so duplicates can't accumulate, and changing the embedding model triggers a full rebuild. You edit a markdown file in any editor and retrieval is correct a second later. No ingest step to forget.
`check_task_readiness` is the tool I'd argue for hardest. Before writing anything, it checks the request against a task template and reports what's missing — so the model asks a question instead of confidently inventing a detail. Most drafting failures are missing-context failures.
ChromaDB for vectors, sentence-transformers (all-mpnet-base-v2) for embeddings — both running locally. No API key, no external calls at query time, telemetry off. A knowledge base that includes work notes shouldn't require shipping them to a third party to search them.
{
"mcpServers": {
"knowledge-base": {
"command": "bash",
"args": ["/absolute/path/to/start_server.sh"],
"env": {}
}
}
}Honest framing: this is a personal project I use daily, not a packaged product. It runs locally against my own corpus and isn't distributed. The config below is illustrative of the shape, not an install path.
I don't treat infrastructure as a plumbing problem. I treat it as a developer experience problem. When an engineer spends a workday editing YAML to change one autoscaling parameter, or diagnoses the same failure signature for the fortieth time in a quarter, that's a product failure wearing an engineering costume. My job is to find the product underneath the infrastructure.
I got here sideways — consulting across Taipei, Shenzhen, Beijing, and the Bay Area, then product at Cisco during the shift to cloud-native infrastructure. Lately I've been the sole PM for an internal developer platform: the agent runtime and sandbox, the Kubernetes compute layer beneath it, and the incident response system that keeps it standing. My users are engineers, and the product is the paved road they ship on.
The industry context happens to be consumer finance, but little of the work is finance-specific. Multi-tenant isolation, a governed path from intent to production, and an operations layer people trust at 3am are every platform team's problems — a seasonal traffic curve just makes them arrive earlier and hurt more.
That inside view is what I'd bring to a vendor. I've been the buyer evaluating this category and the builder who decided to build instead. I know which demos land with an enterprise platform team, which get quietly dismissed, and what the internal alternative actually costs.
Product strategy, roadmap, and go-to-market for a flagship hyperconverged infrastructure platform spanning cloud-native infra, DevOps tooling, and analytics. Shipped some of the business unit's earliest LLM products, and negotiated certified technology partnerships with Google Cloud and Red Hat. Moved from consulting into product here and was promoted to Senior in two years.
Technology and digital transformation consulting delivered across Taipei, Shenzhen, Beijing, Raleigh, and San Francisco. Clients included ByteDance / TikTok, Alibaba, SAP Labs, Huawei, HTC, and Lenovo. Top Performer three consecutive years.
Best reached by email or LinkedIn.
yenkai.ykh@gmail.com
·
linkedin.com/in/YenkaiHuang