Static curated answers for architecture reviews, technical interviews, role-fit screens, and senior AI platform conversations.
Architecture
Why should we not just use LangGraph for orchestration?
Best for: AI platform lead
The library is not the architecture. Production systems need explicit state, typed interfaces, retry boundaries, observability, evaluation hooks, and cost controls regardless of the orchestration framework.
- At Knit, the durable unit was a DAG of inspectable tasks, not a vague autonomous loop.
- Explicit workflows made parallel execution, retries, judge verification, and debugging practical.
- Frameworks can help, but production ownership lives in the domain-specific boundaries around them.
Cost and infra
How do you control LLM and ML infrastructure costs?
Best for: VP Engineering or platform lead
I treat cost as an architectural constraint. Cost control comes from task classification, model routing, sandbox reuse, caching, selective judge coverage, retry limits, and visibility into unit economics.
- Knit required model routing, persistent sandbox reuse, and task-level observability.
- Epic required infrastructure ownership that reduced cost by 10x and pod usage by 100x.
- The Cost Anatomy challenge shows normalized cost units only, never actual internal figures.
Cost AnatomyRepresentative normalized model for AI workflow unit economics.
Evals and reliability
How do you keep AI-generated analysis from becoming fluent but wrong?
Best for: Senior AI engineer
I separate generation from verification. For analytics, that means executable artifacts, independent checks, source-linked outputs, and failure modes that can be inspected instead of trusted blindly.
- Generated Python gave analysis an executable audit path.
- Independent judge verification reduced self-confirming errors.
- Chart and narrative quality gates made artifact quality visible before deck assembly.
Full-stack execution
Can you own the whole product path, not only the model layer?
Best for: Hiring manager
My strongest work sits across product, backend, ML, data, frontend, and operations. I can connect model behavior to user-facing artifacts and production constraints.
- Knit combined LLM orchestration, Python execution, charting, Deck IR, APIs, streaming, and observability.
- Epic combined ML infra, Elasticsearch, recommendations, Kubernetes, and product experiments.
- Osmo combined computer vision, learning-product UX, data collection, and real-time constraints.
Case study gridBreadth across LLM systems, infrastructure, search, CV, and product systems.
Risk and weaknesses
What is the risk in hiring you, and how do you manage it?
Best for: Hiring manager
The risk is that I can bias toward building robust systems when a team only needs a quick demo. I manage that by making scope gates explicit and choosing the lightest system that preserves correctness.
- V1 of this portfolio deliberately avoided a live assistant until content and evals were ready.
- I prefer static, typed, reviewable artifacts first, then add dynamic systems when the proof is stable.
- That same discipline applies to product work: prototype quickly, but do not confuse a prototype with the architecture.
Role fit
What roles are the strongest fit?
Best for: Recruiter or hiring lead
The strongest fit is a senior AI engineering role where production LLM systems, evaluation, observability, workflow architecture, and full-stack execution matter.
- Best fit: AI Platform Engineer, Senior AI Engineer, LLM Systems Architect, or Founding AI Engineer.
- Strong environments: serious AI products, workflow automation, analytics, research tooling, infra-heavy AI applications.
- Less ideal: pure research roles, frontend-only roles, or teams optimizing for demos over production systems.
Static curated answers stay available alongside the optional live assistant. Both rely on approved public or sanitized evidence.