Projects an employer can open and judge.

A publicly hosted product with its own domain or stable URL, plus a public repo: the orchestrator and worker agents, an MCP-based tool layer, a fast accessible web UI for submitting questions and reading results, CI/CD running lint/tests/build on every commit, persisted and inspectable run traces, a marketing landing page, a 10-slide pitch, a recorded demo video, and a README documenting the coordination design, the failure-recovery and scaling strategy, and three example end-to-end runs with their published reports.

• Submit-a-question interface accepting an open-ended technical or market question with a depth setting (quick scan vs deep dive).
• A lead orchestrator agent that decomposes the question into a research plan and spawns specialized worker agents.
• Specialized workers — web search, source reading, synthesis, and an independent fact-checker that verifies every claim.
• An MCP tool layer exposing search, fetch, and document tools so the same tools are reusable across agents and projects.
• Live run view: a real-time graph of agent activity, sub-questions in flight, and sources being consumed.
• Inline-cited report output where every claim links to the exact retrieved passage that supports it.
• Export to PDF, Markdown, and a shareable public report URL.
• Persisted, replayable run traces with token spend and latency per agent for cost auditing.
• Automatic worker-failure detection and re-dispatch so a crashed worker never aborts a run.
• A workspace history of past research runs with search and one-click re-run.
• Concurrency controls and per-run budget caps so many users can run research in parallel safely.

• The orchestrator decomposes a question and coordinates at least three specialized worker agents through explicit shared state.
• Tools are exposed through a standard protocol (MCP), not bespoke per-agent glue.
• The system is deployed to real public hosting with CI/CD on every commit and production observability (logs, traces, metrics).
• The architecture handles concurrent research runs under load, and a worker failure mid-run still yields a complete, correct deliverable.
• The web UI is fast, WCAG 2.2 AA accessible, and usable by a non-technical analyst without instruction.
• Every claim in the output report is traceable to a retrieved source, and run traces are persisted and inspectable.
• The project ships complete marketing: a landing page, a 10-slide pitch, and a recorded demo, presentable as a real product.
• The product is publicly reachable and fully reproducible from the repo by a stranger.

A publicly hosted product with a stable URL, plus a public repo: the planning-and-execution loop, the sandbox isolation layer, a fast accessible dashboard for queuing issues and inspecting trajectories, CI/CD on every commit, production observability, an eval suite over a set of real issues with pass/fail trajectories, a marketing landing page, a 10-slide pitch, a recorded demo, and a README documenting the isolation threat model, the horizontal-scaling design, and the workflow-versus-agent decision.

• GitHub integration: connect a repo, and the agent picks up issues labeled for automation.
• A planning stage that reads the issue, explores the codebase, and produces a fix plan before writing code.
• Generated code runs only inside a hardened microVM or container sandbox with enforced CPU, memory, filesystem, and network limits.
• An iterative loop: run the test suite, read failures, revise, and retry until tests pass or a budget is hit.
• Automatic pull-request creation with a written summary of the change and the test evidence.
• A live trajectory dashboard showing the agent's plan, edits, command output, and retries in real time.
• An eval mode that runs the agent over a fixed set of real issues and reports pass rate and trajectory quality.
• Prompt-injection defenses: untrusted issue and repo text is treated as hostile, with least-privilege tool scopes.
• Horizontal sandbox-fleet scaling so many issues are worked concurrently without contention.
• Per-job cost and time tracking, with configurable budget caps and a hard kill on runaway jobs.
• An audit log of every command the agent ran inside the sandbox.

• Generated code executes only inside an isolated sandbox with enforced CPU, memory, filesystem, and network limits.
• The agent iterates on test feedback and recovers from its own failed attempts.
• The sandbox fleet scales horizontally to many concurrent jobs and the scaling design is documented.
• The product is deployed to real public hosting with CI/CD on every commit and production observability.
• A fast, WCAG 2.2 AA accessible dashboard lets a developer queue issues and inspect agent trajectories.
• An eval suite reports pass rate and trajectory quality over a fixed set of real issues.
• The isolation threat model is documented, including sandbox-escape containment, and prompt-injection via issue or repo content is mitigated with least-privilege tool access.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo — and is publicly hosted and reproducible from the repo.

A publicly hosted inference service with a stable URL and a clean playground UI, plus a public repo: the batching scheduler and KV-cache manager, an autoscaling deployment, CI/CD on every commit, production observability dashboards, a load-test harness, a benchmark report comparing static versus continuous batching across concurrency levels, a marketing landing page, a 10-slide pitch, a recorded demo, and a README explaining the memory, scheduling, and scaling design.

• An OpenAI-compatible HTTP API (chat/completions, streaming) so the service is a drop-in for existing clients.
• A paged KV-cache manager that eliminates memory fragmentation and supports prefix sharing across requests.
• Iteration-level continuous batching so new requests join the running batch without waiting for it to drain.
• A request scheduler with configurable priority and a tunable time-to-first-token versus throughput policy.
• Token-level response streaming over server-sent events or WebSocket.
• A clean playground UI to send prompts, watch streaming output, and see live latency and throughput.
• A live metrics dashboard: tokens-per-second, time-to-first-token, queue depth, GPU memory, and KV-cache utilization.
• Autoscaling across replicas driven by queue depth, with health and readiness probes.
• A built-in load-test harness that sweeps concurrency and emits a static-vs-continuous-batching benchmark report.
• API-key authentication and per-key rate limiting on the endpoint.
• Graceful degradation and request shedding when the GPU is saturated, instead of timeouts.

• The server implements paged KV-cache management and iteration-level continuous batching.
• A request scheduler is present and its time-to-first-token versus throughput tradeoff is documented.
• The service is deployed publicly with a clean playground UI, CI/CD on every commit, and autoscaling across replicas.
• Production observability tracks tokens-per-second and latency percentiles, and the endpoint is secured.
• A load-test report shows throughput and latency percentiles across concurrency levels, with continuous batching measurably compared against a static-batching baseline.
• GPU memory usage and KV-cache fragmentation are reported with the design that controls them.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo.
• The service is publicly reachable and reproducible, with a clear benchmark methodology.

A publicly hosted deployment with a stable URL and a hyper-usable demo UI, plus a public repo: the quantization and speculative-decoding pipeline, an autoscaling serving setup, CI/CD on every commit, production observability, an accuracy report on a representative benchmark before and after compression, a marketing landing page, a 10-slide pitch, a recorded demo, and a README with the cost-per-token analysis and scaling design.

• A quantization pipeline supporting INT4/INT8 (GPTQ or AWQ) and FP8, with a one-command recompress workflow.
• An automatic accuracy-regression check that benchmarks the model before and after compression on a representative task.
• Speculative decoding with a paired draft model, exposing the acceptance rate as a tunable, observable metric.
• An OpenAI-compatible serving API behind the optimized model so it is a drop-in replacement.
• A hyper-usable demo UI showing side-by-side latency of the baseline versus the optimized deployment.
• A live cost dashboard computing cost-per-million-tokens from real throughput and GPU pricing.
• Autoscaling with fast cold starts and scale-to-zero so idle GPU spend is eliminated.
• A finance-grade report export: before/after cost, latency, and accuracy in one shareable document.
• Configurable quality gates that block a deployment if accuracy loss exceeds a set threshold.
• API-key auth, rate limiting, and request quotas on the public endpoint.
• Production observability for time-to-first-token, tokens-per-second, and GPU utilization.

• The model is quantized with a named method and the accuracy delta on a representative benchmark is reported.
• Speculative decoding is implemented and its acceptance rate and latency gain are measured.
• The deployment is publicly hosted with a hyper-usable demo UI, CI/CD on every commit, autoscaling, and production observability tracking time-to-first-token and tokens-per-second.
• The endpoint is secured and the architecture holds under concurrent load.
• A finance-grade cost-per-million-tokens analysis shows the before-and-after improvement, and accuracy loss is reported honestly with the tradeoff justified.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo.
• The deployment is publicly reachable and fully reproducible from the repo.

A publicly hosted product with a stable URL and a hyper-usable demo UI, plus a public repo and a published model card: the data pipeline, the QLoRA training configuration and run logs, an autoscaling serving deployment, CI/CD on every commit, production observability, an evaluation comparing base versus fine-tuned on a held-out set, a marketing landing page, a 10-slide pitch, a recorded demo, and a README documenting data sourcing, the contamination check, the scaling design, and the cost of the run.

• A dataset builder that ingests raw domain documents and turns them into cleaned, deduplicated instruction data.
• An automatic train/eval contamination check that flags and removes overlap before training.
• A LoRA/QLoRA training workflow with a reproducible config file and full run logging.
• An experiment view comparing runs across hyperparameters, with loss curves and eval scores.
• A held-out evaluation harness reporting target-task accuracy for the base model versus the fine-tuned model.
• A catastrophic-forgetting check that scores the fine-tuned model on general tasks, not just the target task.
• Adapter management: deploy one base model and hot-swap LoRA adapters per request.
• An OpenAI-compatible serving API for the fine-tuned model, with autoscaling.
• A hyper-usable demo UI where a domain user can try the specialist model on real prompts.
• An auto-generated model card documenting data sourcing, intended use, limitations, and run cost.
• Production observability and a secured, rate-limited endpoint.

• A training dataset is built, cleaned, and deduplicated, with sourcing documented.
• Parameter-efficient fine-tuning (LoRA or QLoRA) is run with a reproducible configuration.
• A held-out evaluation shows a measured improvement of the fine-tuned model over the base, with train/eval contamination explicitly checked and catastrophic forgetting measured.
• The fine-tuned model is served behind a real public API with a hyper-usable demo UI, autoscaling, CI/CD on every commit, observability, and a secured endpoint.
• The serving architecture holds under concurrent load and the scaling design is documented.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo.
• The repo is reproducible, a model card documents intended use and limitations, and the product is publicly reachable.

A publicly hosted product with a stable URL and a hyper-usable demo UI, plus a public repo and a published student model: the distillation data pipeline, the student training and preference-optimization configuration, an autoscaling serving deployment, CI/CD on every commit, production observability, a benchmark comparing teacher, student, and base on the target task, a cost-and-latency comparison, a marketing landing page, a 10-slide pitch, a recorded demo, and a README on the distillation method and scaling design.

• A teacher-labeling pipeline that uses a frontier model to generate or label distillation data for a chosen task.
• Synthetic-data generation with quality filtering so the student trains on clean, diverse examples.
• A student-training workflow producing a small (0.6B-8B) model, with reproducible configs and run logs.
• Optional preference optimization (DPO) to align the student where the task needs it.
• A three-way benchmark — teacher, student, and base — reporting capability retained on the target task.
• A cost-and-latency comparison computing the serving-cost reduction versus the teacher.
• An accuracy-floor gate that blocks shipping a student that drops below a configured retention threshold.
• An OpenAI-compatible serving API for the student model with autoscaling and scale-to-zero.
• A hyper-usable demo UI letting a buyer try teacher and student side by side on real prompts.
• An auto-generated model card with the distillation method, retention numbers, and intended use.
• Production observability and a secured, rate-limited endpoint.

• A teacher model is used to generate or label distillation data with a documented method.
• A smaller student is trained and the capability retained on the target task is measured against the teacher.
• Preference optimization (DPO or RLHF) or alignment of the student is applied where appropriate and justified.
• The student is served behind a real public API with a hyper-usable demo UI, autoscaling, CI/CD on every commit, observability, and a secured endpoint that holds under concurrent load.
• A cost and latency comparison shows the student is materially cheaper to serve, with the accuracy-versus-cost tradeoff reported honestly.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo.
• The repo is reproducible, the student model is published with a model card, and the product is publicly reachable.

A publicly hosted RAG product with a stable URL and a fast, accessible chat UI, plus a public repo: the ingestion and retrieval pipeline, the citation-grounded answer layer, an automated eval harness with a golden dataset wired into CI, CI/CD on every commit, observability of cost and latency, a marketing landing page, a 10-slide pitch, a recorded demo, and a README documenting the retrieval, evaluation, security, and scaling design.

• Document ingestion for PDFs, web pages, and office files, with incremental re-indexing as the corpus changes.
• Configurable chunking plus contextual retrieval that prepends document context to each chunk before embedding.
• Hybrid retrieval combining dense vector search and keyword search, followed by a reranking model.
• A grounded answer layer where every response cites the exact passages it relied on, with click-through to source.
• A fast, accessible chat UI with streaming answers, source citations, and conversation history.
• An automated eval harness scoring faithfulness, context precision, context recall, and answer relevancy against a golden dataset.
• CI integration where an eval-score regression fails the build before a change ships.
• A cost-and-latency dashboard with per-request token usage and retrieval timing.
• Out-of-scope detection so the assistant declines questions the corpus cannot answer instead of hallucinating.
• Input/output guardrails mapped to the OWASP LLM Top 10, including prompt-injection filtering on ingested content.
• Multi-tenant workspaces with access controls so different teams query different corpora.

• Ingestion, chunking, and a hybrid or contextual retrieval pipeline are implemented and justified.
• Answers are grounded in and cite the retrieved passages they rely on.
• An automated eval harness scores retrieval and answer quality against a golden dataset and runs in CI, where a quality regression fails the build.
• The platform is deployed to real public hosting with CI/CD on every commit, observability of cost and latency, and security hardening mapped to the OWASP LLM Top 10.
• The retrieval and serving layers are hyperscalable and hold as corpus and traffic grow; the scaling design is documented.
• The chat UI is fast, WCAG 2.2 AA accessible, and usable by a non-technical stranger without instruction.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo.
• The product is publicly reachable and fully reproducible from the repo.

A publicly hosted product with a stable URL and a hyper-usable security dashboard, plus a public repo: the tracing and observability pipeline, the automated red-team attack suite with a results report, the guardrails it validates, CI/CD on every commit, a marketing landing page, a 10-slide pitch, a recorded demo, and a README documenting the threat model, the drift-detection method, and the scaling design.

• An SDK/proxy that traces every LLM call with token counts, cost, latency, model, and a correlation ID.
• A real-time dashboard of spend, latency percentiles, error rate, and call volume, sliceable by feature and model.
• Silent-quality-drift detection that scores live traffic and alerts when output quality degrades.
• An automated red-team suite running prompt-injection, jailbreak, indirect-injection, and data-exfiltration attack batteries.
• A continuously updated attack library so new jailbreak techniques are tested as they emerge.
• Input and output guardrails (PII redaction, injection filtering, policy checks) with a report of which held under attack.
• A red-team scorecard mapping every finding to the OWASP LLM Top 10, exportable for audit.
• Alerting integrations (email, webhook, Slack) for cost spikes, drift, and failed guardrails.
• A high-throughput ingestion path that absorbs production call volume without sampling loss.
• Scheduled red-team runs in CI so a regression in defenses fails the build.
• Multi-project workspaces with role-based access so security leads and engineers see scoped views.

• Every LLM call is traced with token, cost, and latency telemetry and correlation IDs.
• Silent quality drift is detected and surfaced, not just raw metrics displayed.
• An automated red-team suite runs prompt-injection, jailbreak, and exfiltration attacks, and the report shows which input/output guardrails held and which failed.
• The platform is deployed to real public hosting with CI/CD on every commit and is itself secured.
• The ingestion path is hyperscalable and absorbs high call volume; the scaling design is documented.
• The dashboard is fast, WCAG 2.2 AA accessible, and readable at a glance by a security lead.
• The threat model is documented and mapped to the OWASP LLM Top 10.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo — and is publicly reachable and reproducible.

A public repo, a benchmark report, and a publicly hosted product with a stable URL and a hyper-usable demo UI serving the trained model: the distributed training configuration, the parallelism strategy, the checkpoint-and-resume logic, a live training-metrics dashboard, an autoscaling serving deployment, CI/CD on every commit, production observability, a scaling report across GPU counts, a marketing landing page, a 10-slide pitch, a recorded demo, and a README documenting the communication pattern, the failure-recovery design, and the serving-scale design.

• A job launcher that takes a model and dataset and spreads training across multiple GPUs from a simple config.
• Data parallelism plus at least one model-parallel strategy (tensor, pipeline, or fully-sharded).
• Gang scheduling so every worker in a job starts together, preventing partial scheduling that idles GPUs.
• Periodic distributed checkpointing with clean resume after a simulated node failure, losing no completed steps.
• A live training dashboard: loss curves, throughput, GPU utilization, and inter-node communication overhead.
• A scaling report that sweeps GPU counts and reports throughput and parallel efficiency.
• Automatic detection and recovery from a stalled or crashed worker mid-run.
• Spot/preemptible-instance support with checkpoint-driven recovery to cut training cost.
• Serving of the trained model behind an OpenAI-compatible API with autoscaling.
• A hyper-usable demo UI where a user can try the trained model on real prompts.
• Production observability and a secured, rate-limited serving endpoint.

• Training runs across multiple GPUs using data plus at least one model-parallel strategy, with correct collective communication and the parallelism decomposition documented.
• Checkpointing is implemented and the run resumes correctly after a simulated node failure.
• A scaling report shows throughput and efficiency across GPU counts, and communication-versus-computation overhead is measured and discussed.
• The trained model is served as a directly deployable product behind a real public API with a hyper-usable demo UI, autoscaling, CI/CD on every commit, observability, and a secured endpoint.
• A live training-metrics dashboard is provided, and the serving layer holds under concurrent load.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo.
• The repo is reproducible with a clear benchmark methodology and the product is publicly reachable.

A publicly hosted platform with a stable URL and a hyper-usable real-time dashboard plus query UI, plus a public repo: the streaming ingestion and inference pipeline, the at-scale vector index, the autoscaling and backpressure design, CI/CD on every commit, fleet observability, a load-and-failure test report, a marketing landing page, a 10-slide pitch, a recorded demo, and a README documenting delivery semantics, fault tolerance, security, and capacity planning.

• Ingestion of a high-rate live event stream (transactions, clicks, logs) from a streaming log such as Kafka.
• Per-event low-latency inference with a documented end-to-end latency budget (target sub-100ms).
• Stated delivery semantics — exactly-once, or at-least-once with idempotent processing — enforced in the pipeline.
• A feature layer that assembles per-event features within the latency window for the model.
• Inference results indexed into a vector store serving real-time similarity and nearest-neighbor queries.
• Backpressure and autoscaling that keep the platform healthy through a sudden traffic burst.
• Node-failure recovery with graceful degradation, demonstrated via injected failure.
• A real-time dashboard of event throughput, inference latency percentiles, and fleet health.
• A query UI for similarity search and recent-event lookup, usable without instruction.
• Alerting on latency-SLO breaches, lag buildup, and anomalous event rates.
• Multi-tenant isolation and a secured, rate-limited query API.

• A live event stream is consumed and inference runs per event with measured low latency.
• Delivery semantics (exactly-once or at-least-once with idempotency) are stated and justified.
• Inference results are indexed into a vector store that serves real-time similarity queries.
• Backpressure and autoscaling keep the platform healthy under a simulated traffic burst, and an injected node failure is recovered with graceful degradation.
• The platform is deployed to real public hosting with CI/CD on every commit, fleet observability, and security hardening.
• A fast, WCAG 2.2 AA accessible real-time dashboard and query UI lets a stranger use the platform without instruction.
• The project ships complete marketing — a landing page, a 10-slide pitch, and a recorded demo.
• The platform is publicly reachable and fully reproducible from the repo.