Julian Morel — Full-Stack Builder & AI Product Owner

I build whole platforms — and the agentic systems that run inside them.

For two years I've been building multi-agent workflows, orchestration and gen-AI pipelines, with the guardrails that keep non-deterministic AI contained inside deterministic architecture. And the full product around them — frontend, backend, CRM, payment processing, comms, API integrations, infrastructure — designed and shipped end to end, by one person — from a working MVP in days to a governed system hardened for production. Grounded in twenty years of commercial product experience.

Open to work — remotely · available now
See the systems ↓Get in touch ↗

Where this is going

The roles are merging.

For twenty years, product and engineering were separate seats — one decided what to build, the other built it, and a wall of specs sat between them. AI is dissolving that wall. When you can prototype a working system in days, the gap between understanding a problem and proving the solution closes — no handoff, no telephone game. That's the seat I work from: close enough to the problem to know what's worth building, and able to go build it.

What this is

Built solo.
Built with a spine.

Agents, models and generative tools are powerful, but left alone they drift, hallucinate, break workflows and create risk. The difficult part is not getting a model to produce output. The difficult part is building the spine around it: routing, validation, retries, fallbacks, permissions, audit trails, human checkpoints and clear stop conditions. That is the through-line across every system below — non-deterministic AI contained inside deterministic architecture.

Everything here was designed and built end-to-end, from architecture through to production. Not isolated demos — production-minded systems, built workflow by workflow so they stay understandable, debuggable and owned, never black boxes. The work below is the evidence.

Selected Systems

Built and architected solo over the last few years. Different domains, same instinct: governed, reliable AI applied to real-world workflows. Each system explains the problem, the orchestration behind it, the stack, and includes a short walkthrough of the product in use.

FinalEyes

Certified document translation & reconstruction platform · finaleyes.co ↗
Live with usersDemoable end-to-end

Word documents go in; near-perfectly reconstructed, professionally translated documents come out — tables, boxes, fonts and layout preserved — with a human translator in control of every segment.

The problem
Certified translation isn't just “translate the words” — the output has to be a faithful reconstruction of the original: tables, boxes, fonts, stamps, layout, all preserved, often for legal or official use. Today that means expensive manual desktop-publishing rework after translation. And you can't just trust a model end-to-end: a single dropped or mis-mapped segment in a government form is a real-world failure. The system has to be fast, structure-perfect, and never silently wrong.
How it works — the orchestration
A complexity router sends each document down the right pipeline, then translation runs as a concurrent, self-checking process that preserves the document's XML structure exactly rather than rebuilding it.
  • Smart routing — documents are scored and routed: a fast path for simple files, an XML-preserving “complex” path for anything with tables, forms or merged cells.
  • Structure-perfect extraction — the complex pipeline extracts translatable segments while keeping every original file, with coordinate-based box detection so form fields stay grouped and reconstruct in place.
  • Two-level concurrent translation — segments are grouped by element type (paragraphs never mixed with table cells), and groups run in parallel while batches within each group also run in parallel — fast, without ever letting the model see a mixed soup of content it would mistranslate.
  • Never silently wrong — every batch retries with exponential backoff on rate limits; a permanently failed segment falls back to source text and is flagged for review, never dropped. ID mismatches between request and response are logged, not swallowed.
  • Human-in-the-loop CAT tool — a full translator workbench (XLIFF projects, glossaries, status workflow, a baseline-comparison check that flags translation drift) where a certified translator reviews, edits and approves every unit before the document is certified and exported.
Why it's hard / why it matters
This is the anti-“hype” exhibit: generative AI applied to a domain where being roughly right isn't good enough. The rigor that matters in production AI — structure preservation, concurrency that doesn't corrupt context, retry and explicit fallback, a human approving the final artifact — all sits here, in a compliance-heavy, non-creative workflow. It proves the engineering discipline transfers far beyond generation.

The complex DOCX pipeline is genuinely XML-native: extract → translate → reconstruct, rebuilding the .docx from only the files that were in the original, with binary assets base64-preserved so Word never sees a corrupted file. Box detection reads table coordinates from the XML so semantic fields map 1:1 through translation.

Translation supports both DeepL and GPT-4o behind one interface; the GPT path adds glossary support and the two-level ThreadPoolExecutor concurrency model. There's a separate “baseline” translation generated for quality comparison — it diffs a clean text-only translation against the formatted output to flag drift, synonyms and reconstruction errors back to specific translation units in the CAT tool.

Stack: Python / Flask service on Cloud Run, Firebase (Auth, Firestore, Storage, Cloud Functions in TypeScript), DeepL + OpenAI for translation, Next.js frontend. Certification and secure authenticated download round out the workflow.

PythonFlaskCloud RunFirebaseCloud FunctionsXML / DOCX reconstructionDeepL / GPT-4oNext.jsConcurrent pipelinesHuman-in-the-loop

ThemeTuned · lazy.productions

Automated music-video generation pipeline · lazy.productions ↗
Live

One prompt becomes a finished music video — lyrics, song, synchronised visuals, final render — through a route-based pipeline that orchestrates a shifting roster of image, video and audio models behind a single interface.

Walkthrough (two parts — the flow runs longer than a single recording)

The output it produces

The problem
Stitching generative models into a finished video is where everything breaks. A voice model sings what it reads; a transcription model writes what it hears — and when those diverge (a number, a name, a vowel held across a phrase) the audio-to-text alignment fails silently, at scale. And every model wants different inputs, so the pipeline has to stay provider-agnostic as the fast-moving model landscape churns under it.
How it works — the orchestration
The pipeline is organised around routes — the fundamental generation flow — with suppliers as swappable config choices at each step, not hard-wired into the architecture.
  • The normalisation layer — the bridge between what one model outputs and what the next expects, handling every case where formats diverge so alignment doesn't break silently. This is the piece that makes automated video actually work.
  • Retry & quality gates — generation is non-deterministic, so the pipeline runs multiple attempts with style fallbacks, measures alignment quality after each, and only proceeds past a threshold.
  • Route-based, provider-agnostic — text-to-video, scene-to-video, character-composite routes each define a flow; Runway, Kling, Luma, Flux, Nano Banana etc. are picked per-step by capability and cost. Adding a provider is a config entry, not a rewrite.
  • Forced variety — the determinism dial turned the other way: deliberate mechanisms stop the models collapsing to the same output, so a series evolves rather than repeating.
  • Reusable IP & Worlds — persistent characters and a navigable “Worlds” location system mean scenes and characters stay consistent across episodes — build a world once, reuse it forever with no new generation cost.
Why it's here
This is the generative-media end of the same engineering: multi-provider orchestration, silent-failure prevention, quality gating and cost-aware model selection. The full showcase — with the videos themselves — lives on its own site.
FirebaseCloud Functions / RunFFmpegWhisperSunoRunway / Kling / LumaFlux / Nano BananaReplicate / fal.aiRoute-based architectureNormalisation layer

SynthMedica

Synthetic patient engine for medical training
In developmentDemoable end-to-end

A synthetic-patient simulator that trains doctors against patients who lie, hide things, exaggerate, or push their own agenda — while the clinical ground truth they have to reach stays fixed.

The problem
Training a clinician's diagnostic skill needs more than a textbook case. Real patients are unreliable narrators — anxious, evasive, exaggerating, sometimes seeking something they won't admit to. You can't just prompt an LLM to “act like a difficult patient”: it drifts, it's not reproducible, and you lose track of what the right answer even was. The system has to vary behaviour without ever corrupting the underlying clinical truth the trainee is being marked against.
How it works — the orchestration
A declared patient context (e.g. “hidden agenda: opioid-seeking”) drives an eight-stage pipeline that transforms how a patient presents. The crucial design choice: only two stages touch an LLM. The rest is deterministic.
  • Context Expression Engine — maps the context to weighted behavioural levers (manipulation skill, overtness, consistency, truth-alignment) and rolls them deterministically from the scenario seed — same scenario, same result, every time.
  • Playbook Builder — translates those levers into concrete chatbot instructions: “when challenged, double down”, “escalation limit: 3”, “pressure target: medication”.
  • Context Transform — adjusts the patient's presentation style, ideas/concerns/expectations and symptom history — all deterministic, no AI.
  • Disclosure + phrase enrichment (LLM) — the only two model calls: reorganise what the patient volunteers vs. hides, and generate delivery-tuned phrasing (“barely above a whisper, trailing off”).
  • Two-layer validation — one check confirms the declared context is actually expressed in the output; another blocks nonsensical pairings (no opioid-seeking for a skin rash).
Why it's hard / why it matters
The whole system rests on one principle: context distorts presentation, never reality. The answer key is fixed; only the patient's behaviour changes. That's a clean separation of a simulation's behaviour from its correctness — and it's enforced by a deterministic core with the LLM confined to the linguistic surface. Built for a regulated, high-stakes domain, with doctor sign-off (human-in-the-loop) built into the workflow — augmentation, not replacement.

The pipeline runs off a Firestore trigger, not a frontend call — saving a context fires the whole chain automatically, with guards against infinite loops (only draft variants, context must have actually changed, not already processing).

The behavioural core is a Context Expression Engine → BehaviouralEngineProfile chain: lever definitions are pure data, the rolls are seeded, and the output is a structured playbook the chatbot obeys. I've since extended this to deterministically alter the patient's underlying intent, not just their surface presentation — a deeper layer of reproducible control over the same fixed ground truth.

Stack: Firebase (Firestore, Cloud Functions, triggers), Next.js frontend with reactive onSnapshot updates, OpenAI confined to the two transform/enrichment calls. Validation and compatibility logic live entirely in deterministic TypeScript.

FirebaseCloud FunctionsFirestore triggersTypeScriptNext.jsOpenAIDeterministic engineSeeded generationHuman-in-the-loop

FightAnything

Autonomous AI content engine + live arena · fightanything.com ↗
Live with users

Type a prompt, get a complete fighter — backstory, art, theme song, intro video — then watch them compete in a league whose outcomes are decided by logic, not a coin-flip, and whose daily highlight show is produced entirely without a human.

Walkthrough (two parts — the arena, then the autonomous broadcast it feeds)

The output it produces

The problem
A fully automated content platform has two hard demands. First, outcomes have to feel earned — a league where results are pure RNG feels hollow, but you also can't let a model just decide who wins (unreliable, unrepeatable, ungovernable). Second, the daily output — script, voiceover, graphics, talking-head host, fight footage, final cut — has to assemble itself reliably from numerous non-deterministic AI services with no one in the loop — and if any one of them fails, the whole broadcast breaks.
How it works — the orchestration
The same principle as everywhere else: the deciding is done in code; the model does the telling.
  • Narrative-weighted outcomes — a fighter's skills, lore and form weight the odds before any result is generated, so outcomes emerge from logic and matchup, not a raw coin-flip. The engine decides who wins; the LLM writes the story of how — never the other way round.
  • RAG commentary memory — every fight is stored in a vector DB; when the daily show is generated, the engine retrieves relevant history — rivalries, rematches, near-misses — so the commentary knows these two have met before and what happened.
  • Async generation pipeline — the daily video routes numerous AI steps (script via GPT-4o, voice via ElevenLabs/OpenAI, graphics via headless-browser screenshots, talking-head host via SadTalker on on-demand GPU, fight footage via Kling/Veo) through a single unified provider with a robust webhook dispatch pattern, not fragile synchronous polling. Any one step failing is designed for — the orchestrator catches it rather than letting the broadcast collapse.
  • Engineered for safety & correctness — Ed25519 signature verification on every AI callback, timestamp replay protection, and a server-side double-dispatch guard so a job can never fire twice regardless of frontend state. A proprietary profanity filter keeps user-generated fighters safe — containment built in, not bolted on.
  • On-demand GPU economics — talking-head GPU pods spin up, pass a health check, generate, and tear down — compute paid for only when used.
Why it's hard / why it matters
This is autonomous orchestration at scale, live, with real users — fighters, leaderboards, knockout tournaments with real prizes, a daily automated broadcast. It's the proof that the same governed-AI discipline scales to a fully unattended pipeline coordinating many unreliable services into a finished product every single day.

All AI generation routes through fal.ai behind one key (Luma backdrops, Nano Banana composites, Kling and Veo animation), with OpenAI for script and GPT calls and ElevenLabs/OpenAI for TTS. Long-running jobs use an async pattern: submit → write a job-routing doc → return immediately → a signed webhook receives the callback, verifies it, and routes the result to the right place. The job-routing collection is Admin-SDK-only and unreadable from the client.

A stateless Python service on Cloud Run handles the things that are painful in Node — Playwright screenshots, RunPod GPU orchestration for SadTalker talking heads, and FFmpeg compositing for the final render. Functions call it with a GoogleAuth-signed ID token. Serve routes proxy Storage assets with referrer-lock and rate-limiting so URLs aren't exposed.

Honest status: live and running daily. As with any active build there's roadmap — closing the fight-scene footage into the final render is in progress — but the autonomous pipeline, the narrative engine and the live arena are real and in front of users today.

Next.jsFirebaseCloud FunctionsCloud RunPythonfal.aiRunPod / SadTalkerKling / Veo / LumaElevenLabsVector DB (RAG)FFmpeg / PlaywrightAsync webhook orchestration

Agent Peanut

Governed multi-tenant AI agent platform for SMBs · agentpeanut.com ↗
In developmentOnboarding demoable

A platform that lets a small business run its operations through a single conversation — built on a hard architectural rule that keeps autonomous agents contained even when they're attacked.

Work in progress — what you're seeing vs. where it's going
This one is early and built in the open — the walkthrough shows the first part of the onboarding flow, not the finished product. The full intended experience: you sign up and talk to Barry, who onboards you conversationally — confirm your email, then connect WhatsApp or Telegram (enter a code in Telegram and that becomes your channel). Once both email and channel are verified and matched, Barry asks for your website. Keith, the technical agent, crawls it (Python) and feeds back a useful read on your business — and in the background the platform spins up a microsite for you. The aim is the best agent onboarding experience going, fronting a bespoke suite of agents — deterministic wherever possible, with conversational agents on Mastra and the intended heavier backend agents on LangGraph. The video stops partway through that flow for now; the rest is actively being built.
The problem
Giving an autonomous agent real power — sending messages, booking jobs, spending money — is exactly where agentic AI gets dangerous. A single prompt injection shouldn't be able to drain an account or email a customer list. Most “AI agent” demos hand the model the keys. The hard problem isn't making an agent act — it's making sure it can only ever act within boundaries you control.
How it works — the orchestration
The entire platform rests on one rule: agents never call external APIs. They express intent; a privileged governance layer decides whether to execute it.
  • Intent / execution barrier — an agent writes an intent document to Firestore and the tool returns immediately. A Cloud Function triggers on that write, validates it (rate limit, permissions, kill-switch, org check), and only then calls the real API with credentials the agent never sees. Prompt-inject the agent and the worst it can do is write a request that gets rejected.
  • Argus — deterministic compliance — a zero-token pipeline runs on every message (injection, PII leakage, runaway-cost, unauthorised-commitment checks) and only escalates to an LLM when a checker actually fires.
  • Tier discipline — rules-based work runs on deterministic Cloud Functions because that's the reliable choice, not just the cheap one; conversational agents handle genuine judgment; heavy batch reasoning runs separately. A model is used only where code couldn't give a dependable answer.
  • Token isolation — single-use, purpose-scoped platform tokens are minted server-side and written straight into agent memory. The LLM never parses or handles a credential.
  • Multi-channel onboarding — a guided agent (“Barry”) runs a deterministic phase-gated flow with Telegram/email-OTP verification (no phone number needed) and a live website-analysis crawl, committing the result in one atomic write at the end.
Why it's hard / why it matters
This is the question every company deploying agents is quietly terrified of: how do we let this thing act without letting it hurt us? The answer here is an explicit, auditable containment architecture — language-agnostic governance in Firebase, credentials isolated to privileged functions, server-side verification of every system trigger so none can be spoofed, SSRF protection and two independent auth layers on the scraping service. It's agentic AI treated as an attack surface to be engineered, not a demo to be shipped.

Frontend conversational agents run on Mastra (TypeScript) as a standalone server; heavy backend agents run in Python on Cloud Run; Firebase is the language-agnostic governance layer holding audit, kill-switches, budget and state. Next.js 16 frontend on Vercel, Cloudflare DNS, Resend for transactional email.

The intent pattern is concrete: tools write to verificationRequests/, webCrawlRequests/ etc.; Cloud Functions trigger, validate and execute, then write results back. Verification routes (Telegram Bot API, Twilio for WhatsApp) all validate signatures — constant-time secret comparison, HMAC-SHA256 — and credentials live only in the functions environment.

Honest status: architecturally complete with the governance core, multi-phase onboarding and website-analysis pipeline live and demoable end-to-end. Microsite generation, the full agent roster and VPS migration are roadmap. The interesting part — the containment model — is built and working.

MastraTypeScriptPythonFirebaseCloud RunCloud FunctionsNext.js 16VercelTelegram / TwilioAgent governancePrompt-injection containment

How I build

Three rules,
in concrete.

Not principles in the abstract — the actual decisions that run through every system above. Each one anchored in something real I had to get right.

01
Cost is an engineering constraint
With AI, “best” is often not commercially viable. FightAnything's daily broadcast needs a talking-head host — a hosted service like HeyGen would do it in one call, but it'd be expensive and overkill for fast, daily, not-for-the-big-screen output. So the pipeline spins up a self-hosted SadTalker config on a RunPod GPU, generates, and tears it down — paying only for the seconds of compute it actually uses. The same logic picks the right model per job — Kling over pricier options most of the time — quality where it matters, cheap where it doesn't. The right call is the one that ships sustainably, not the one with the glossiest output.
02
Deterministic by default, contained always
Code where code will do; a model only where judgment genuinely lives. In my agent platform, agents never touch an API directly — they write intent to a database and a privileged layer decides whether to execute it, so a prompt-injected agent can do nothing but write a request that gets rejected. Pipelines carry loop guards so nothing runs away. The engine decides outcomes; the LLM only narrates them. Nothing non-deterministic ever runs unbounded.
03
Never silently wrong — a human where it counts
In production, failure isn't an edge case — it's Tuesday. Every pipeline fails loudly and recovers: retries with backoff, explicit fallbacks, a translation segment that drops back to source and gets flagged rather than vanishing. And where the stakes or the law demand it, the system escalates to a person — the translator approves every segment, the doctor signs off the consultation, the compliance layer hands to a human when a checker fires. Augmentation, not blind automation.

Stack & capabilities

The toolkit.

What's actually in the systems above — grouped by what these roles care about most. AI-native from the development environment up: I build with AI, not just on top of it.

How I build (AI-native)
ClaudeCursorVS CodeGitHub CopilotChatGPT / OpenAI
Languages
TypeScriptPythonJavaScriptNode.js
Agents & orchestration
MastraMulti-agent systemsIntent / execution patternsRoute-based pipelinesWebhook orchestrationRAGVector memory
Cloud & infrastructure
FirebaseGCPCloud RunCloud FunctionsFirestoreDockerRunPod (self-hosted GPU)VPSVercelCloudflare
Reliability & security
Guardrails & governanceDeterministic pipelinesPrompt-injection containmentHMAC / Ed25519 verificationSSRF protectionRetry / backoff / fallbackToken isolationHuman-in-the-loop
Backend & frontend
Next.jsReactFlaskFirestore triggersReactive UI (onSnapshot)
Document & data processing
Google Document AI (OCR)PyMuPDFXML / DOCX reconstructionDeepLFFmpegPlaywrightBeautifulSoup
Models & LLM providers
OpenAI / GPT-4oClaudeGroq (Llama)Qwen+ essentially any LLM provider
Generative media
ElevenLabsWhisperDemucsRunwayKlingVeoLumaFluxSunoSadTalker+ most gen-AI media models
APIs, aggregators, comms & payments
fal.aiReplicateTelegram Bot APIWhatsApp BusinessTwilioResendStripe / payment processorsdirect · via aggregators · self-hosted on GPU
∞
The list is a snapshot, not a ceiling. The real skill isn't any one tool — it's that I integrate with whatever the job needs and learn it as I go. New API, unfamiliar SDK, a service I've never touched? I read the docs, wire it in, and ship. The tools change constantly and keeping up is the job. Assume I can work with anything on this page, and anything that isn't.

Where I fit

One capability.
Many names for it.

Every role below is a different company's name for the same thing: take a messy real-world problem and ship the AI system that solves it — whether that's a fast prototype that proves the idea or a governed platform that survives production. That's what the work on this page demonstrates across multiple domains.

AI Solutions / Implementation Engineer
Take a business problem and ship a working AI system end to end — prototype or production.
Agentic Systems / Workflow Engineer
Orchestrate agents, models, tools and APIs into reliable automated workflows.
AI Automation Engineer
Replace manual, repetitive work with governed, self-correcting pipelines.
Forward-Deployed Engineer
Embed with a client, understand the problem, build the bespoke solution fast.
AI Product Engineer
Build AI-native products end to end — from fast prototype to shipped feature.
AI-Native Product Manager / Owner
Own a product end to end: find the real problem, prototype it, build it, ship it.
Head of AI
Own AI across a company — strategy, build, and the commercial reality of both.

Why the breadth is credible: most candidates can build or understand the business. I've spent two years building AI systems full-time and twenty years before that launching commercial products in regulated, fast-moving markets — so I can sit with a stakeholder, find the real problem, and go build the thing that solves it.

Background

Two years building AI.
Twenty building products.

I'm a self-taught, full-stack, AI-native builder: I learned to build with AI as the development environment from day one, and I work fast because of it — from a working agentic prototype in days to a governed system hardened for production. I build the whole stack, front to back, and the through-line is applied AI: agentic workflows, gen-AI pipelines, orchestration.

Before AI, twenty years at the commercial coalface of deliberately disruptive industries. I led B2B business development at a Frankfurt-listed lottery group, building novel insured-lottery products for operators, sports clubs and media companies. I co-developed an insurtech platform with predictive pricing and real-time risk management for the lottery and gaming markets. Earlier, I founded the UK's first online + TV bingo platform — video and audio generated and simulcast to live television in real time. A production pipeline before production pipelines were a thing.

That combination is the point: I can sit with a business problem, understand the commercial reality around it, and go build the AI system that solves it — end to end.

Get in touch

Let's talk about
what you're building.

If you need someone to turn AI from a demo into a governed, working system, that's the work I do.

jumospain@gmail.com ↗LinkedIn ↗

Remote from Spain · UK citizen · available now