Daniel MonzonForward Deployed Engineer

Forward Deployed Engineer

I ship AI systems into live customer production — and own them after launch.

I work where AI systems, customer-facing engineering, and production reality meet. I scope the real problem, build the system, deploy it onto live customer infrastructure, and stay on through the failures a demo never shows you — carrier verification, number porting, voice quality, off-script callers. I move between the terminal and the stakeholder call: explaining a carrier-verification delay to a non-technical owner in the morning, shipping the fix that afternoon. The interesting work starts after “it works on my machine.”

RésuméGitHubEmail

CS @ University of Florida — B.S. 2026 · M.S. in progress Orlando, FL Bilingual EN / ES Available full-time now

  • 2 paying clients in the first 3 months, sold and delivered solo
  • 196 tests gating every change to the deployment kit
  • ~1,000 students projected for the curriculum I own delivery of
  • 2× promoted in 20 months — engineer → lead → project manager
Production Case Study

Designing, deploying, and owning a production AI voice system.

Daniel Monzon Automation (DMA) — a bilingual (English / Caribbean-Spanish) AI voice receptionist deployed onto live small-business phone lines, with structured lead capture wired into the owner’s alerts. It happened in two stages: one system built by hand for the first client, then a kit that made the next deployment repeatable.

The first deployment was configured by hand, for Firefly Pilates, whose inbound line is answered daily in English and Spanish. It is still the system in production. A post-call webhook drives the lead path: extract, store, push to the CRM, alert the owner within seconds of hangup. Every piece was assembled client-specifically, before any of it was factored into a kit.

Architecture — as deployed

  1. Conversation Retell
  2. Voice ElevenLabs a dedicated Caribbean-Spanish voice
  3. Telephony Carrier · Google Voice · Twilio forwarding bridges, porting, SMS
  4. Post-call Zapier → Postgres → HubSpot 8 extracted fields, Postgres as source of truth
  5. Web concierge Chatbase its own lead path
  6. Infra Hetzner VPS · Postgres

Then I productized it. After building that first deployment by hand, the differences between clients turned out to be narrow and describable — a greeting, business hours, routing, a voice, what happens after the call — while the hard parts were shared. So the shared parts got factored into dma-deploy-kit, public and MIT-licensed, and the differences pushed into config. It is a parallel, productized system — not a rewrite of what answers Firefly’s line today — and its layers are the ones worth reading.

Architecture — the kit

  1. Client config YAML → pydantic

    One file per client, validated by a strict schema that forbids unknown keys and reports every error at once with YAML-path locations.

  2. Prompt compilation Fixed 13-section taxonomy

    A pure function compiles config into the agent prompt — no templating engine, no network. English and Spanish diverge only in the language section.

  3. Deploy engine plan / apply · lockfile

    Dry-run plan by default; apply creates or updates the agents and writes a per-client lockfile, so re-runs compute a field-level diff and converge to NOOP.

  4. Post-call service FastAPI · HMAC-SHA256

    Verifies the webhook signature, parses the analyzed call into a lead, resolves which client owns the agent from the lockfiles, and dispatches the owner alert.

  5. Booking SMS Twilio REST · send-once ledger

    Sent only when consent, a booking URL, a captured consent flag, and a normalizable US phone all hold — and recorded so a webhook retry can’t double-text.

  6. Evals & CI GitHub Actions · Anthropic API

    A four-layer harness — static prompt policy, transcript assertions, latency budgets, citation-enforced LLM judge — with golden fixtures gating CI.

How a call moves

Caller dials a deployed line Retell answers in the caller’s language Webhook fires on hangup HMAC-SHA256 verified Call parsed into a structured lead Lockfile resolves the owning client Owner alert + consent-gated SMS, sent once

Key decisions

  • First deploymentPostgres is the source of truth rather than trusting CRM state, so lead data survives integration hiccups.
  • First deploymentCall forwarding runs as a live bridge during number porting to guarantee zero dropped calls.
  • First deploymentDelivery channels are separated — voice/email ship independently of SMS — so a single carrier gate can’t block the whole system.
  • The kitThe model is confined to the live conversation. Deploy, diffing, lead routing, SMS gating, and evals are all plain deterministic Python — the parts that must be auditable never depend on a generation.
  • The kitDeploys are idempotent by construction: dry-run plan by default, a per-client lockfile, and re-runs that compute a field-level diff and converge to NOOP — so shipping a change can’t silently mutate a live agent.
  • The kitPost-call SMS is consent-gated and written to a send-once ledger, so a webhook retry can never double-text a real customer.
  • The kitClient differences live in config; the hard parts live in shared code. Improvements ship to every deployment at once, and onboarding is editing a file rather than rebuilding an agent.

Production problems I diagnosed and fixed

01 First deployment

Zero-downtime number porting

What broke
A client’s existing business number had to move onto the new system. Google Voice porting takes days, and the business cannot miss a single call while it runs — so the cutover was the risk, not the configuration.
What I did
Stood up call forwarding as a live bridge, so the AI agent answered immediately while the port completed in the background. Clean cutover — no missed calls, no customer-visible downtime.

What it taught meA cutover is a live-traffic migration, not a config change. Bridge the traffic first, move the plumbing second, and you never drop a call.

02 First deployment

Toll-free / SMS carrier verification

What broke
SMS lead notifications weren’t delivering. Not a code bug — messaging was gated behind toll-free verification with the carrier (Twilio), a compliance state rather than application logic.
What I did
Decoupled the pipeline so voice and email lead delivery shipped immediately, with SMS wired in the moment verification cleared. Lead capture went live without waiting on the carrier; SMS layered in cleanly after.

What it taught meIn telephony, a large share of “bugs” are carrier / compliance states — the fix is diagnosis and sequencing, not more code.

03 First deployment

Bilingual voice quality (dialect-level QA)

What broke
Generic Spanish TTS sounded flat and non-native for a Caribbean-Spanish-speaking customer base. “Speaks Spanish” is not the bar; dialect and pronunciation are.
What I did
Built and tuned a dedicated Caribbean-Spanish voice so Spanish calls sound native rather than translated — measuring output quality, not just capability. Bilingual calls that hold up with real customers.

What it taught meCapability isn’t quality. “It speaks Spanish” clears a demo; dialect and pronunciation are what hold up on a real call.

04 First deployment

Reliable structured extraction on off-script calls

What broke
Real callers go off-script — partial info, wrong language selected, early hangups — which threatened the structured lead output. The post-call extraction needed to degrade gracefully instead of failing.
What I did
Built fallback handling so every call still yields an actionable lead across all 8 fields where possible. The owner always receives something usable, regardless of how the call went.

What it taught meReal callers never match the happy path. Design the pipeline to degrade gracefully so every call still yields something the owner can act on.

05 The kit

Proving a prompt change didn’t break a deployment

What broke
Prompts are edited constantly, and the kit ships one change to every deployment at once. “It still sounds fine” is not evidence, and a regression only surfaces on a real call. Behavior needed a test suite — and the suite itself needed to be proven still capable of failing.
What I did
Built a four-layer harness — static prompt policy, deterministic transcript assertions, latency budgets, and an LLM judge structurally barred from unverifiable claims (a “fail” is downgraded unless it quotes a verbatim span from a cited turn). Golden synthetic fixtures gate CI so every push proves the checks still discriminate. Each run pins the sha256 of every compiled prompt, and a regression is flagged only when a check newly fires. 196 tests standing between a prompt edit and a deploy.

What it taught meA passing suite only means something if it can still fail. Gate CI on fixtures that prove the checks discriminate — otherwise you’ve automated a green checkmark, not a guarantee.

Experience

Where I’ve shipped.

Full detail — including education and honors — is on the résumé.

  1. Founder & Forward Deployed Engineer

    Daniel Monzon Automation (DMA)

    May 2026 – Present Orlando, FL

    Solo AI deployment practice — bilingual EN/ES voice agents & workflow automation for service businesses

    • Landed 2 paying clients in the first 3 months, solo across the whole loop — outreach, discovery, scoped proposals, build, deployment, support.
    • Built by hand and operate Firefly Pilates’ inbound line, answered daily in English and Spanish (Retell, ElevenLabs, Twilio).
    • Productized deployments into dma-deploy-kit (public, MIT): the next customer is configuration, not code.
    • Own reliability down to the carrier — routing, porting, and restrictions that never surface in a demo.
    • Second engagement delivered end-to-end for CleanAvenue (Orlando): a custom TypeScript site with embedded price-estimator tooling.
    • Retell
    • ElevenLabs
    • Twilio
    • FastAPI
    • Python
    • TypeScript

  2. Project Manager & Lead Engineer

    CogAbility — Mars Rover AI Lab

    May 2024 – Present Gainesville, FL

    NVIDIA-partnered robotics / RL lab · promoted twice in 20 months: Software Engineer → Lead Software Engineer (01/25) → Project Manager & Lead Engineer (01/26)

    • Own end-to-end delivery of an AI robotics + RL curriculum shipping into UF’s AI Fundamentals course (~1,000 students projected) — scope, milestones, risk, and release readiness against university acceptance criteria.
    • Built the simulation stack on NVIDIA Isaac Sim + Webots: networking backend, Python video streaming for live-lab observability, and reproducible VMs with runbooks new engineers ramp on unaided.
    • Engineered a real-time computer-vision pose-recognition system over WebSockets driving interactive behavior in a production web app — the work behind the first promotion.
    • NVIDIA Isaac Sim
    • Webots
    • RL
    • WebSockets
    • Python

  3. Credit Risk Analyst

    Synchrony — Business Leadership Program (Credit)

    06/25 – 07/25 Stamford, CT

    Recovery Strategy — selected nationally into Synchrony’s competitive BLP

    • Built a value-based segmentation model (SAS decision trees over Oracle warehouses) ranking hundreds of thousands of recovery accounts by propensity-to-pay × balance.
    • Validated in-time and out-of-time across placement vintages, then turned the output into executive-ready recommendations the team acted on.
    • SAS
    • Oracle
    • SQL
    • modeling

Education University of Florida, Herbert Wertheim College of Engineering — B.S. Computer Science (May 2026), minors in Mathematics & Physics, GPA 3.8 / 4.00. M.S. Computer Science expected Summer 2027. NVIDIA Deep Learning Institute certificate. Hispanic Scholarship Fund Scholar, selected from 124,000 applicants.

Selected Work

Selected projects.

Prioritized for engineering depth. Repos are public unless noted.

dma-deploy-kit

Flagship

Python · MIT · public

A config-driven deployment kit that turns one YAML file per client into a fully deployed bilingual AI voice receptionist — strict pydantic validation, a deterministic 13-section prompt compiler, and an idempotent plan/apply engine with per-client lockfiles.

Why it’s interestingThis is the productized form of real client deployments: a FastAPI post-call service with HMAC-verified webhooks, consent-gated Twilio SMS behind a send-once ledger, and a four-layer eval harness (196 tests) gating CI. Everything outside the live conversation is deterministic Python — the model never touches deploy, routing, or gating.

  • Python
  • FastAPI
  • Retell
  • Twilio
  • pydantic
  • evals
  • CI
github.com/danielfmonzon/dma-deploy-kit ↗

quantlab

Python · research / paper-trading only

A research and paper-trading system over a fixed universe of 12 liquid ETFs: end-of-day ingest and validation, a custom daily backtest engine, a report-only statistical validation battery, and a risk-gated paper loop against Alpaca.

Why it’s interestingDiscipline is the point. Strategy parameters are fixed from the source literature and never tuned on the backtest; each approved strategy runs in its own isolated paper account with daily HALT and drawdown KILL gates; and every report header embeds the version plus git short hash, so any artifact traces to the commit that produced it. Live trading is architecturally disabled by a config gate that refuses to start against a non-paper endpoint.

  • Python
  • DuckDB
  • backtesting
  • risk
  • Alpaca
github.com/danielfmonzon/quantlab ↗

pipelinepulse

Python · MIT · public

An agentic pipeline that pulls open Salesforce opportunities via REST, scores deal health with deterministic rules, and posts an LLM-written daily pipeline digest — with recommended next actions — into Notion.

Why it’s interestingRules do the math, the LLM does the language — a deliberate split for reliability. Dockerized and scheduled on GitHub Actions, so it runs unattended.

  • Python
  • Claude API
  • Salesforce
  • Notion
  • Docker
  • GitHub Actions
github.com/danielfmonzon/pipelinepulse ↗

hellog8r

Go · Next.js · Docker · 5-person team

The Docker-hardened pipeline executing untrusted student code for a live UF intro-CS course: network isolation, a read-only filesystem, dropped Linux capabilities, no-new-privileges, and enforced CPU/memory limits.

Why it’s interestingOS-level isolation done properly, behind a REST execution API I designed to align a Go backend, a problem generator, and a Next.js/TypeScript frontend across a five-person team.

  • Go
  • Next.js
  • Docker
  • security
  • infra
github.com/TheShmill/hellog8r ↗
Technical Skills

What I work in.

AI / LLM
  • LLM agents & orchestration
  • Voice AI (Retell, ElevenLabs)
  • LLM eval design
  • LLM-as-judge
  • CI regression gates
  • Prompt engineering
  • Claude API
Languages
  • Python
  • TypeScript / JavaScript
  • Go
  • SQL
  • C++
Integration & Deployment
  • REST API design
  • Webhooks
  • Twilio telephony & SMS
  • Docker
  • Linux / Bash
  • Git
  • GitHub Actions CI/CD
  • WebSockets
Data & Platforms
  • pandas
  • NumPy
  • DuckDB
  • Oracle / SQL warehouses
  • Salesforce
  • CRM & scheduling integrations
Customer-facing
  • Technical discovery
  • Scoping & proposals
  • Executive communication
  • Bilingual EN / ES delivery
Writing

Engineering writeups.

Writeups on systems I’ve built and problems I’ve debugged.

Sandbox Isolation Design

Architecture and security tradeoffs for safely running untrusted / experimental code, and how isolation choices interact with scaling.

  • systems
  • security
  • infra
Read →

Inside a Production AI Voice Architecture

Full teardown of the DMA stack: Retell + ElevenLabs orchestration, the deterministic deploy and post-call path, and the telephony/carrier lessons that only show up in production.

  • AI voice
  • systems
  • production
Read →

Deciding When a System Is Allowed to Ship

A pre-registration discipline for gating systems into production: pre-commit the bar, earn each rollout stage from backtest to paper to live, and fail safe by default. Drawn from quant research, applied to anything that ships.

  • reliability
  • methodology
  • risk
Read →

Let’s talk

Building something where AI systems meet real customers?

Available full-time now, and open to forward-deployed / solutions engineering roles.

RésuméGitHubEmail