DEV Community: Luis Cruz

Building Production LLM Agents That Actually Ship: Lessons from 10+ Years in the Trenches

Luis Cruz — Fri, 07 Aug 2026 03:10:35 +0000

Tool-calling agents, RAG pipelines, and the automation stack that turns "AI demo" into "AI in production" — and why I'm opening up for new projects.

The gap nobody talks about

Most AI content online is about getting a model to respond well in a chat window. The harder, less glamorous problem is getting that same model to reliably book an appointment, update a CRM record, or hand off to a human at exactly the right moment — in production, at 2am, when an API times out or a timezone field silently defaults to the wrong value.

That gap — between "cool demo" and "system a business can depend on" — is where I've spent most of my career, and it's the thread that connects everything I build now.

What "shipped" looks like

A few examples from recent and past work:

RAG systems that refuse to guess. I built a health-data RAG pipeline with embeddings, cosine retrieval, inline citations, and — critically — honest refusal when the retrieved context doesn't support an answer, plus a full audit log. In healthcare-adjacent domains, a system that says "I don't know" is more valuable than one that sounds confident and is wrong. → health-data-rag.vercel.app · source

Voice + SMS agents wired into real CRM systems. Built and debugged a full lead follow-up and appointment-booking system combining GoHighLevel, Retell AI (voice/chat), and n8n for a multi-location client. The interesting engineering wasn't the AI — it was the plumbing: explicit timezone configuration per calendar (never inherit it), Luxon expressions in n8n's startTime field, correctly distinguishing a status === "booked" response from a missing statusCode field, and drawing a hard architectural line so voice-generation and SMS-sending never leak into each other. Small details like these are the actual difference between a bot that works and one that quietly fails a week after launch.

Automation across the LLM app surface. From FastAPI backends and Next.js frontends to n8n/Make.com workflows and multi-agent orchestration, I own the full chain: agent logic, retrieval, inference APIs, and the interface around them — not just the prompt.

Open source, not just employer work. Contributing to Inglorious Forge — SSX compatibility testing, a merged ElementSize entity, an error boundary with passing unit tests, a before/after slider component. Reading someone else's production codebase closely enough to contribute cleanly is its own skill, and I think it shows in how I approach client handoffs.

The stack I reach for

Python FastAPI TypeScript Next.js Supabase/PostgreSQL (pgvector, RLS) n8n Make.com GoHighLevel OpenAI API Anthropic API Retell AI Vercel

What I'm looking for

I'm currently taking on new freelance projects — particularly:

AI agent / chatbot systems wired into real business tools (CRMs, calendars, ticketing)
RAG pipelines that need to be trustworthy, not just impressive in a demo
n8n / Make.com automation connecting AI to existing workflows
Integration debugging — if your AI feature "mostly works" and you can't figure out the 10% that doesn't, that's often exactly my kind of problem

If any of that matches something you're building, I'd genuinely like to hear about it.

Luis Cruz Senior AI Developer — LLM Agents, RAG, Automation 📧 stackbuilder1228@gmail.com 🔗 topstar-ai-github-io.vercel.app · GitHub · Contra

Building a Production AI Booking Agent: Architecture Notes from a Retell + n8n + GoHighLevel Build

Luis Cruz — Tue, 04 Aug 2026 14:49:03 +0000

I built an AI agent that answers inbound leads by voice and
SMS, qualifies them, checks live calendar availability
across two locations, and books the appointment. No human
step anywhere in the flow.

Here is how it is architected, and the decisions that made
it reliable.

The architecture

Three layers, with a hard boundary between them:

Retell AI handles conversation - voice and SMS, prompt design, qualification logic
n8n orchestrates - slot lookup, availability filtering, booking calls, error routing
GoHighLevel owns state - CRM records, calendar, and all message delivery

Decision 1: the LLM writes, the CRM sends

The most important boundary in the system. Retell generates
reply text and nothing else. It never holds a phone number
and never touches the send path.

Everything that delivers a message goes through GHL. This
means exactly one system is responsible for delivery, so
threading stays intact and every message is traceable to a
single source. Letting the model act directly on the send
path is where these systems get non-deterministic and
undebuggable.

Decision 2: timezone is configured, not inferred

The clinic runs two locations in Eastern time; the account
was provisioned in Central. Calendar timezone in GHL is set
per calendar and does not inherit from the account, so it
gets set explicitly - America/New_York - as a
configuration step, not an assumption.

Downstream, n8n datetime fields are built in Expression
mode with Luxon and setZone: true, so the local time you
constructed is the local time that arrives. Anything less
explicit coerces to UTC silently.

Decision 3: validation that fails loudly

Booking success is confirmed by testing the actual status
value the API returns - status === "booked" - not an
assumed status code. A booking system that reports success
on failure is worse than one that crashes, because nobody
finds out until a patient shows up to an appointment that
does not exist.

Same principle on the request side: GHL's booking endpoint
requires a title field, and its absence surfaces as a
validation error that appears to be about something else
entirely. Every required field is asserted before the call
rather than discovered from an error message.

What shipped

Full architecture diagrams, agent prompts for both voice
and SMS paths, the complete n8n workflow, a per-platform
testing checklist so the client could verify it themselves,
and a walkthrough video for handover.

Walkthrough: https://www.loom.com/share/dd792a043d6b4d4483adba463bbe02f3

I build AI agents, RAG pipelines, and automation systems
end to end. Available for contract work.

github.com/topstar-ai
jeanlimaav@gmail.com

ai #automation #n8n #showdev

Building Visit Lübeck: Designing a Better Digital Experience for Travel Discovery

Luis Cruz — Thu, 16 Jul 2026 01:29:14 +0000

I recently worked on Visit Lübeck (https://www.visit-luebeck.com/) — a travel-focused digital platform designed to help users discover destinations, experiences, and essential city information through a clear and intuitive interface.

The biggest lesson from this project was that building a travel platform is not only about presenting information — it is about creating a smooth journey from curiosity to action.

My focus was on improving:

Information architecture and content organization
User-friendly navigation flows
Clear presentation of destination experiences
Responsive and accessible web experiences
Performance-focused frontend implementation

Travel websites often contain large amounts of content, so the real engineering challenge is making that information feel simple and natural for users.

A strong digital experience requires more than visual design. It requires understanding user intent:

What does the visitor need to know?
How quickly can they find it?
What helps them make a decision?

From a technical perspective, this project strengthened my approach to building content-heavy platforms where usability, performance, and maintainability must work together.

One important takeaway:

Great digital products do not overwhelm users with information — they guide them through it.

Whether building AI systems, SaaS platforms, or customer-facing applications, the same principles apply:

Clear structure
Reliable performance
Simple interactions
User-centered architecture

Visit Lübeck was a valuable experience in combining engineering discipline with product thinking — creating a platform that connects people with places in a more meaningful way.

Project: https://www.visit-luebeck.com/

Building Visit Lübeck: Designing a Structured Travel Experience Platform

Luis Cruz — Fri, 03 Jul 2026 20:27:58 +0000

I recently worked on Visit Lübeck (https://www.visit-luebeck.com/), a project focused on creating a structured and user-friendly digital experience for exploring travel and location-based information.

The main objective was to design a clear, intuitive platform that helps users quickly access relevant city insights, navigation paths, and curated information without friction. I focused on improving information hierarchy, usability, and performance across the interface.

From an engineering perspective, this project emphasized clean system design, content structuring, and user-first navigation flow.

It reinforced a key principle: in travel platforms, clarity and accessibility matter more than complexity or feature density.

Building hewdoes.xyz: Lessons From Shipping a Lightweight Digital System

Luis Cruz — Thu, 02 Jul 2026 17:27:57 +0000

I recently worked on hewdoes.xyz (https://hewdoes.xyz), a lightweight digital project focused on building a clean, fast, and structured web experience.

The main goal was to prioritize simplicity and performance over complexity. I focused on designing a minimal system with clear user flow, fast interaction, and maintainable structure rather than adding unnecessary features.

From an engineering perspective, the work emphasized frontend clarity, system organization, and reducing friction in user interaction.

This project reinforced an important principle in my experience: effective digital products are not defined by how much they do, but by how clearly and reliably they deliver value.

Building Quantinium: A Focus on Production-Ready AI Systems

Luis Cruz — Wed, 01 Jul 2026 15:51:34 +0000

I recently worked on Quantinium (https://quantinium.uk), a project focused on building structured, production-ready AI systems with a strong emphasis on reliability and system design.

The core experience reinforced a key principle: real-world AI engineering is less about model experimentation and more about system architecture. I focused on designing stable pipelines, structured data flow, and predictable outputs instead of relying on prompt-driven behavior.

Key work included building modular AI workflows, enforcing output consistency, and optimizing backend integration for scalable performance.

This project strengthened my approach to building AI systems that prioritize clarity, stability, and real-world usability over complexity.

Building WhatIsGC.com: Lessons From Designing a Production-Ready AI Information System

Luis Cruz — Mon, 29 Jun 2026 16:09:16 +0000

Recently, I worked on WhatIsGC (https://whatisgc.com) — a lightweight AI-driven information system designed to simplify how users understand and interact with structured knowledge.

The goal wasn’t to build another “AI demo.” It was to design a usable, reliable system that behaves consistently in production.

As a senior AI engineer focused on production systems, I approached this project with one principle in mind:

If it cannot scale reliably, it is not a real system.

🧠 System-first, model-second approach

Instead of starting with prompts or model tuning, I focused on system architecture first:

Clear input/output contracts
Structured response formats (to avoid free-form instability)
Separation between reasoning, retrieval, and formatting layers
Deterministic validation before output delivery

This helped reduce variability — which is one of the biggest issues in LLM-based applications.

⚙️ Multi-layer AI pipeline design

WhatIsGC is not a single LLM call system. It follows a structured pipeline:

Input normalization
Context understanding layer
Knowledge/response generation
Output validation layer
Final formatting layer

This separation ensures that failures are isolated instead of cascading across the system.

📦 Key engineering focus: stability over intelligence

One of the biggest lessons from this project was:

The hardest part is not making the system smart — it is making it consistent.

To achieve this, I implemented:

Strict schema-based outputs
Guardrails for hallucination-prone responses
Fallback logic for incomplete or uncertain outputs
Controlled context window handling for predictable behavior

This made the system significantly more reliable under real usage.

🔌 Real-world integration challenges

Beyond the AI layer, a large part of the work involved traditional engineering:

API orchestration and response handling
Latency optimization for faster inference cycles
Backend structuring for scalability
Error handling across distributed components

In production AI systems, the model is often the smallest part of the architecture.

🧪 Testing approach

Instead of standard unit tests, I relied on:

Scenario-based evaluation sets
Edge-case injection testing
Output consistency checks across prompts
Regression tracking for behavioral drift

This helped ensure predictable system behavior even under noisy inputs.

🚧 Final takeaway

Building WhatIsGC reinforced a consistent pattern across all my AI systems:

Real-world AI engineering is about control, not creativity.

The focus is always on:

structure over prompts
stability over complexity
systems over models

That is what makes an AI product production-ready.

Building Production Multi-Agent Systems: Lessons from automator.ai

Luis Cruz — Mon, 29 Jun 2026 02:19:12 +0000

When I started building automator.ai, I wanted to solve a specific problem: how do you orchestrate multiple specialized AI agents to handle complex automation workflows without everything falling apart?

The answer wasn't more complexity. It was the opposite.

The Problem We Solved

Most automation platforms treat AI as a black box — you feed it a prompt and hope it figures things out. That works fine for single-task problems. But when you're automating entire business workflows (lead qualification, appointment booking, follow-up sequences), single agents start to fail:

They make conflicting decisions
They don't hand off context properly
They struggle with multi-step reasoning
One mistake cascades through the entire workflow

automator.ai was built specifically to handle this: a multi-agent orchestration layer for GoHighLevel that lets specialized agents coordinate without breaking the workflow.

The Architecture That Actually Works

We built automator.ai on LangGraph + GoHighLevel white-label, and here's what we learned works in production:

Separation of Concerns (Agents Have Jobs)

Each agent does ONE thing well:

Qualification Agent: Reads lead data, asks clarifying questions, scores fit
Booking Agent: Manages calendar, handles scheduling logic
Follow-up Agent: Tracks engagement, triggers re-engagement sequences
Pipeline Agent: Quality gates, flags anomalies, escalates edge cases

This sounds obvious, but most teams ignore it. They build one "smart" agent and wonder why it fails on variations.

Lesson: Narrow purpose = predictable behavior = easier to debug and improve.

Shipping Cadernos e Planner Digital Brasil: Systems Thinking Behind a Digital Product

Luis Cruz — Fri, 26 Jun 2026 02:22:24 +0000

I recently built Cadernos e Planner Digital Brasil
👉 https://cadernoseplannerdigitalbrasil.com

It’s a digital planner system for iPad and Android — focused on helping people organize goals, habits, and daily life in a structured way.

But honestly, this project taught me something bigger than “building a planner.”

It reminded me what actually makes a product usable.

It’s not a file. It’s a system.

Most digital planners fail because they’re just… PDFs with pages.

But people don’t need pages.

They need flow.

So I stopped thinking in terms of “designing pages” and started thinking in systems:

Year → Month → Week → Day structure
Clear separation between life areas (goals, habits, finance, health)
Predictable layout everywhere
No guessing, no learning curve

The goal was simple:

Open it and instantly know what to do.

Simplicity is the hardest part

The more I worked on it, the more I removed.

Not added.

Because complexity kills usage.

I focused on:

reducing visual noise
keeping everything consistent
making each section self-explanatory
avoiding “creative but confusing” layouts

If something needed explanation, it was wrong.

The real work is structure

Even though it looks like a “digital product,” most of the effort was actually structural:

organizing reusable planner modules
keeping consistency across all versions
designing content blocks that scale
making sure everything connects logically

It felt more like system design than design work.

Shipping a Niche Digital Product: Systems, Challenges, and Lessons Learned

Luis Cruz — Thu, 25 Jun 2026 13:47:15 +0000

Recently, I worked on Cadernos e Planner Digital Brasil (https://cadernoseplannerdigitalbrasil.com) — a digital product focused on structured planning tools and digital organization workflows for users in the Brazilian market.

This project wasn’t just about building a website — it was about designing a complete product system that supports real user needs, content structure, and long-term usability.

As a senior AI and systems developer, I approached it the same way I approach production AI systems: structure first, execution second.

🧠 1. A digital product is a system, not a page

One of the biggest misconceptions in digital product development is treating it like “just a website.”

In reality, this project required thinking in systems:

Content structure and hierarchy
User navigation flow
Product packaging and clarity
Conversion paths and intent mapping

A successful digital product is closer to a system design problem than a frontend problem.

⚙️ 2. Simplicity is harder than complexity

A key challenge in building this project was reducing unnecessary complexity.

What helped:

Removing over-engineered sections early
Focusing on clarity of value proposition
Designing for fast comprehension, not feature density
Prioritizing user intent over technical flexibility

The simpler the system becomes for the user, the more intentional the backend structure must be.

📦 3. Structuring content is the real engineering work

Even without heavy backend logic, a lot of engineering effort went into:

Organizing digital planner content logically
Structuring reusable templates
Ensuring consistency across sections
Designing modular content blocks

This is often underestimated — but content architecture is product architecture.

🔌 4. Real-world products depend on clarity, not features

Unlike technical systems where complexity can be hidden behind abstractions, user-facing digital products must be extremely clear.

Key decisions:

Clear value proposition above the fold
Minimal cognitive load per page
Strong visual hierarchy
Predictable navigation patterns

Users don’t explore unclear products — they leave them.

🧪 5. Validation happens through user behavior, not assumptions

In production, the real feedback loop is usage.

Instead of relying on assumptions, I focused on:

How quickly users understand the product
Where users drop off in the flow
Which sections actually get interaction
What needs refinement based on behavior

This is fundamentally different from building in isolation.

🚧 6. The hardest part is positioning, not building

Technically, building the system was straightforward.

The real challenge was:

Positioning the product clearly
Defining who it is for
Making the value instantly understandable
Differentiating from generic digital planners

Most product failures happen at the positioning layer, not the code layer.

🧭 Closing Thoughts

Building Cadernos e Planner Digital Brasil reinforced a core principle I’ve seen across both AI systems and digital products:

Execution is easy. Clarity is hard.

Whether you’re building AI systems, SaaS tools, or digital products, the real engineering work is:

Structuring information
Reducing ambiguity
Designing predictable flows
Aligning system design with user intent

That’s what makes a product usable — not just functional.

👉 Project: https://cadernoseplannerdigitalbrasil.com

Building JetsCreative: My Experience as a Senior AI Developer Working on Production Systems

Luis Cruz — Wed, 24 Jun 2026 14:31:01 +0000

https://jetscreative.com

🔷 Post Content
Introduction

Recently, I’ve been working on JetsCreative (https://jetscreative.com) — a production-focused AI and automation system built to streamline workflows and improve how digital systems handle tasks, content, and structured operations.

As a senior AI developer focused on real production systems (not prototypes or demos), this project was another opportunity to stress-test how far LLM-based systems can go when properly engineered.

🧠 1. Real AI systems are architecture-first, not model-first

One of the earliest realizations while building JetsCreative was that the model itself is rarely the bottleneck.

What matters more:

System design and flow control
Separation of responsibilities across components
Data contracts between stages
Deterministic behavior around non-deterministic models

Without this structure, even the best models become unreliable in production.

Senior AI Engineer Perspective: What Actually Matters When You Build AI Systems in Production

Luis Cruz — Wed, 24 Jun 2026 00:43:25 +0000

In recent years, AI has moved from research labs into production systems at scale. Publications like The Economist and others have repeatedly highlighted how AI is reshaping industries — but what’s less discussed is what it actually looks like to build and maintain these systems as an engineer.

As a senior AI developer working on production systems (not prototypes or demos), the gap between perception and reality is still significant.

Production AI is mostly engineering, not prompting

Outside of demos, the real work is:

Data pipelines that don’t break under edge cases

API orchestration across multiple services

Structured outputs that can be validated and trusted

Retry logic, fallbacks, and failure recovery

Cost control and latency optimization

Most “AI features” fail not because the model is weak — but because the surrounding system is not robust.

Reliability matters more than model choice

In practice, switching from one model (GPT, Claude, etc.) to another is rarely the hardest part.

The real complexity is:

Ensuring deterministic behavior where needed

Designing schemas for model outputs

Handling partial failures gracefully

Preventing cascading errors in multi-step workflows

A strong AI system behaves like distributed systems engineering, not just ML usage.

Multi-agent systems introduce real complexity

Multi-agent architectures (or even simple chained LLM workflows) quickly become non-trivial:

Debugging becomes harder due to hidden intermediate states

Small prompt changes can create systemic failures

Observability becomes mandatory, not optional

Without proper logging and tracing, these systems become unmaintainable very quickly.

“AI product” ≠ “AI wrapper”

There is still a misconception that AI products are just wrappers around APIs.

In reality, the value is usually in:

Domain-specific orchestration logic

Data normalization and enrichment

Integration into real business workflows

Guardrails and validation layers

The model is a component — not the system.

The real bottleneck is integration, not intelligence

Most production AI systems struggle with:

Connecting to legacy systems

Handling inconsistent data sources

Managing authentication and permissions

Meeting enterprise reliability expectations

The “AI” part is often the easiest piece. The system design around it is what determines success.

Final thought

AI engineering is increasingly becoming a hybrid discipline: part distributed systems, part data engineering, part applied ML, and part product engineering.

The companies that succeed are not necessarily the ones with the best model — but the ones that build the most reliable system around it.