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. The interesting work starts after “it works on my machine.”

RésuméGitHubEmailBook 15 min

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. Two parts: the hand-configured system that actually answers the phone today, and the kit I built afterward to make the next deployment repeatable.

Part 1

The first deployment

Built and configured by hand for Firefly Pilates, whose inbound line is answered daily in English and Spanish. This is the system in production — everything below was assembled client-specifically, before any of it was factored into a kit.

Architecture — as deployed

  1. Conversation Retell

    Orchestrates the voice agent — call routing, turn-taking, and tool/webhook calls.

  2. Voice synthesis ElevenLabs TTS

    A dedicated Caribbean-Spanish voice for native-sounding bilingual handling.

  3. Telephony Carrier · Google Voice · Twilio

    Carrier numbers, call-forwarding bridges, number porting, and Twilio for SMS.

  4. Orchestration + data Zapier → Postgres → HubSpot

    Post-call webhooks feed a Zapier extraction pipeline (8 structured fields) into Postgres as source of truth, then push to HubSpot CRM and fire email/SMS lead alerts.

  5. Web concierge Chatbase — "Mona"

    A site assistant with its own lead-alert path.

  6. Infra Hetzner VPS · Postgres

    Self-hosted VPS with Postgres as the durable store.

How a call moves — first deployment

  1. 01 Caller dials in
  2. 02 Retell answers in the selected language
  3. 03 Conversation completes
  4. 04 Webhook fires
  5. 05 Zapier extracts 8 structured fields
  6. 06 Writes to Postgres + pushes to CRM
  7. 07 Lead email / SMS fires
  8. 08 Owner gets an actionable lead within seconds of hangup

Key decisions — first deployment

  • Postgres is the source of truth rather than trusting CRM state, so lead data survives integration hiccups.
  • Call forwarding runs as a live bridge during number porting to guarantee zero dropped calls.
  • Delivery channels are separated — voice/email ship independently of SMS — so a single carrier gate can’t block the whole system.

Production problems I diagnosed and fixed

01

Zero-downtime number porting

Symptom
A client’s existing business number had to move onto the new system, but Google Voice porting takes days and the business cannot miss a single call.
Diagnosis
Treat the cutover as a live-traffic migration, not a config change.
Fix
Stood up call forwarding as a bridge so the AI agent answered immediately while the port completed in the background.
Outcome
Clean cutover — no missed calls, no customer-visible downtime.

LessonA 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

Toll-free / SMS carrier verification

Symptom
SMS lead notifications weren’t delivering.
Diagnosis
Not a code bug — messaging was gated behind toll-free verification with the carrier (Twilio). A compliance/carrier state, not application logic.
Fix
Decoupled the pipeline so voice + email lead delivery shipped immediately, with SMS wired in the moment verification cleared.
Outcome
Lead capture went live without waiting on the carrier; SMS layered in cleanly after.

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

03

Bilingual voice quality (dialect-level QA)

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

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

04

Reliable structured extraction on off-script calls

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

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

Part 2

Productizing 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 a kit and the differences pushed into config. That kit is dma-deploy-kit, public and MIT-licensed. It is a parallel, productized system — not a rewrite of what answers Firefly’s line today.

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 data moves — through the kit

  1. 01 Caller dials a deployed client’s line
  2. 02 Retell answers in the caller’s language
  3. 03 Conversation completes and the webhook fires
  4. 04 FastAPI verifies the HMAC-SHA256 signature
  5. 05 Call is parsed into a structured lead
  6. 06 Lockfile resolves which client owns the agent
  7. 07 Owner alert dispatched; consent-gated SMS sent once
  8. 08 Owner has an actionable lead within seconds of hangup

Key decisions — productization

  • The 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.
  • Deploys 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.
  • Post-call SMS is consent-gated and written to a send-once ledger, so a webhook retry can never double-text a real customer.
  • Client 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.

The problem productizing created

05

Proving a prompt change didn’t break a deployment

Symptom
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.
Diagnosis
Behavior needed a test suite, and the suite itself needed to be proven still capable of failing.
Fix
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.
Outcome
196 tests standing between a prompt edit and a deploy.

LessonA 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 running the entire loop solo — outreach, discovery, scoped proposals, build, deployment, support.
    • Firefly Pilates’ inbound line is answered daily in English and Spanish by a voice agent I built by hand and operate (Retell, ElevenLabs, Twilio).
    • Productized deployments into dma-deploy-kit (public, MIT), so the next customer is configuration, not code.
    • Own production reliability down to the carrier — routing, porting, and carrier restrictions that never surface in a demo.
    • Delivered a second engagement end-to-end for CleanAvenue (Orlando): a custom TypeScript website 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 + reinforcement-learning curriculum shipping into UF’s AI Fundamentals course (projected ~1,000 students) — scope, milestones, risk, and release readiness against university stakeholder acceptance criteria.
    • Built the simulation stack on NVIDIA Isaac Sim + Webots: network-communication backend, Python video streaming for live-lab observability, and reproducible VM environments with runbooks that let new engineers ramp independently.
    • 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 data warehouses) ranking hundreds of thousands of recovery accounts by propensity-to-pay × balance.
    • Validated in-time and out-of-time across placement vintages, then translated the output into interpretable, 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 →
How I Work

I like working where software meets customers.

I’m at my best translating a messy customer problem into a technical solution, owning the deployment, and debugging the unclear failures that live between systems and the real world. I move comfortably between the terminal and the stakeholder call — explaining a carrier-verification delay to a non-technical owner in the morning and shipping the fix that afternoon.

University of Florida CS — B.S. 2026, M.S. in progress — plus a credit-risk rotation at Synchrony and delivery lead for an AI robotics curriculum in an NVIDIA-partnered lab. Bilingual English / Caribbean Spanish.

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éGitHubEmailBook 15 min