Applied AI engineering · Architecture · Product

I turn business need into software in production.

More than 15 years in technology, from 24×7 mission-critical infrastructure to AI product leadership. This is the technical record of what I built: the engineering problem, the decision that holds it up and what that decision cost to learn.

15+years in technology
MVP → prod.full cycle
Applied AILLMs · agents · RAG
24×7mission-critical
MulticloudAWS · Azure · GCP

Who I am

Marco Gomes

AI Product Leader · Architecture and applied AI engineering

I started in telecom infrastructure and moved through IT and cloud infrastructure. I led infrastructure and information security teams and ran data center migrations in 24×7 operations, the kind of project where mistakes are expensive and nobody notices when it goes right. IT coordination, service management and project and product management came next.

That background puts business, architecture, development, security and cost under a single head, which shortens the distance between the technical decision and the product decision. It is where the method comes from: the real pain first, execution afterwards.

AI Product Management AI Engineering LLMs & agents Applied AI Architecture Conversational AI Cloud · AWS/Azure/GCP DevSecOps Multi-tenant Unit economics Python · TypeScript Applied AI Architecture specialisation CCNA

Working thesis

AI products and products built with AI, taken from MVP to production with financial viability, security and scalability.

The work covers architecture, development, code validation, infrastructure and cost model.

Products from zero to production02
EducationMBA · MIT
Years in technology15+
Based inSão Paulo · remote

Knowledge assets

Problems already solved and the reasoning behind each decision.

Systems I built from the first commit to production. Open each one to see the engineering problem, what was built and the decision that holds it up.

Problem
Operations that need to change conversation rules without waiting for a deploy, while keeping tenant isolation and an audit trail.
What was built
An engine where the flow is versioned data rather than code: a core isolated from channel and interface, persisted session and context, handoff to a human operator decided by the core, declarative RBAC and structured logging per node. Alongside it, a visual canvas flow editor with import of legacy diagrams and export to the target formats.
Decisions behind it
Backend-first: the interface only exists once core, database and audit are stable. The core decides, but never sends a message or calls an external API. And the tenant filter applies to every table and every query, no exceptions.

TypeScript · Node · PostgreSQL · React · WebSocket · REST

Problem
Connecting a modern voice channel (WebRTC with encrypted media) to platforms that speak SIP, within the RFCs, traversing NAT and without depending on a public IP.
What was built
A TypeScript control plane with signed webhook ingest, anti-replay, a per-call state machine, permissions, billing records and multi-tenant isolation through row level security. The media plane is purpose-built in Go and sits behind an interface: swapping the media implementation never touches signalling.
Decisions behind it
No media decision was closed before a real packet capture. The documentation separates what is implemented from what is proven, and that distinction is deliberate. Media invariants each carry an automated test, because violating any one of them drops the call silently.

TypeScript · Go · WebRTC/SRTP · SIP · PostgreSQL RLS

Problem
Identifying customers on voice channels accurately enough to automate the identification step, without turning a deterministic process into a recurring generative AI bill.
What was built
An understanding engine tailored to the domain, solving identification and the deterministic steps that precede it. The design came out of watching the real operation.
Decisions behind it
Where the process is deterministic, determinism is cheaper, faster and auditable. A generative model only belongs where there is genuine linguistic ambiguity.

NLU · Python · Intent recognition

Problem
Companies adopt AI without knowing how much they spend, who spends it and what the return is. The cost usually shows up after it has already been committed.
What was built
A multi-tenant platform that measures token consumption per person, team and cost center, applies rates and closes a monthly invoice. It also supports the skills catalogue, the adoption tracks and the usage governance, with analytics and roles defined per organization.
Decisions behind it
Explicit SQL, no ORM, and reversible migrations. Isolation lives in the database through RLS, on top of the filter in the application. Every mutation goes through audit. Data protection was there from day one, with export and anonymization, and authentication is pluggable.

TypeScript · Fastify · PostgreSQL · React · Cloudflare · Fly.io

Problem
Hundreds of pages of technical specification in PDF were converted by hand into the binary format of a plant CAD tool. That burned weeks of specialist work and produced errors that were hard to find.
What was built
A deterministic pipeline that goes from the PDF to the CAD files through an intermediate model. The vendor format was reverse-engineered from a working file. Validation stops and asks only what is genuinely ambiguous, every run produces a verification report and access is controlled by role.
Decisions behind it
Zero generative AI: the process is deterministic, and determinism can be audited. One single orchestrator, shared by the command line and the web interface. What restricts access is the route, because a button hidden in CSS restricts nothing at all.

Python · SQLite · PDF parsing · pytest

Problem
Recording and tracking clinical progress outside the clinic without creating a central repository of sensitive data in the cloud.
What was built
An application that keeps everything on the device, with pure and tested domain logic that is independent of interface and storage. Export is an explicit user action, and the same codebase is packaged for iOS and Android.
Decisions behind it
Privacy settled in the architecture before it becomes policy: there is no account, no backend and no collection. Derived data is always computed and never becomes the source of truth. The product only promises what the data model can hold up.

React · TypeScript · IndexedDB · Capacitor · Vitest

Areas of work

Five fronts, one engineering practice.

From discovery with the business teams to running in production. These are the fronts I work in and where the experience runs deepest.

01

Applied AI engineering

LLM integration into products, agent orchestration, RAG, prompt engineering, model evaluation and cost-per-token control. That includes saying plainly when generative AI is not worth it.

LLMs · RAG · Agents · Cost per token
02

Agent-assisted development

Building products and MVPs with coding agents, defining architecture, writing and validating code and provisioning infrastructure up to go-live. Review and testing stay a human responsibility.

MVP → Production · Review · Tests
03

Discovery and turning business need into product

Mapping real pain with the operations, sales and customer service teams, with use cases prioritized by impact, effort, risk and value. The scope comes out of that conversation.

Discovery · Scope · Roadmap · KPIs
04

Solution architecture and technical review

Domain, data, integrations and isolation designed before the code. Real multi-tenancy, row level security, audit trails and decisions recorded as ADRs.

Multi-tenant · RLS · Scale · Resilience
05

Cloud, DevSecOps and continuity

Cloud architecture, delivery pipelines, observability, security policies and contingency and disaster recovery plans, always with operating cost in the equation.

AWS · Azure · GCP · DRP · Observability

How I work

From the real pain to cost under control.

01 · Discovery

Pain before solution

The problem is mapped alongside the people who live it, in operations, sales and customer service. The scope comes out of that conversation.

02 · Architecture

Decisions on record

Domain, data, integrations, isolation and cost model defined and written down before the first line of code.

03 · Build

From MVP to production

Agent-assisted construction, with human review, tests and incremental delivery. Speed without giving up validation.

04 · Operate

Cost under control

Observability, security, continuity and unit economics stay tracked well after go-live.

Engineering principles

Technical opinions that were expensive to form.

Every rule below came out of a system in production and out of at least one mistake that paid for the lesson.

01
AI where it solves, determinism where it suffices.A deterministic process does not need a generative model. Picking the expensive path without needing to is a poor product decision dressed up as technological progress.
02
Implemented and proven are different things.Code that runs in the lab has not been through real traffic yet. Confusing the two is the most expensive error a roadmap carries.
03
Tenant isolation is settled in the database.Filtering in the query is the bare minimum. Isolation that exists only in code fails on the first forgotten line, and nobody gets warned.
04
A flow is data, not code.Changing a business rule should not require a deploy or a developer. What changes every week has to live outside the binary.
05
The route is what restricts access.Hiding a button in the interface restricts nothing. A permission the server never checks simply does not exist.
06
Cost belongs in the architecture.Cost model, break-even and unit economics are part of the design. By the time they show up in a spreadsheet after launch, it is late.
07
Privacy is settled in the architecture.Data that never leaves the device cannot leak. Choosing where the data lives weighs more than any policy promising to look after it.
08
One head for technical and business calls.When scope, schedule, risk and communication answer to the same person who decides the architecture, the distance between both decisions shrinks.

Stack

The right tool for the problem.

The stack is chosen by need and best cost-benefit, with attention to scalability, security and operating cost.

TypeScriptPythonGoNode.jsFastifyReact VitePostgreSQLSQLiteDockerGitHub ActionsCloudflare Fly.ioSupabaseAWSAzureGoogle CloudOpenAI AnthropicGeminiMeta LlamaLangChainWebRTCCapacitor

Construction assisted by coding agents. Architecture, review and testing stay under human responsibility.

Track record

From mission-critical infrastructure to AI product leadership.

By period, responsibility and industry. Company and product names are left out: what matters here is the kind of problem faced.

since 2026

AI and CX product management

Technology · CX · Forward Deployed Engineer

Full lifecycle of AI products, from ideation with the business teams to production: development with AI agents, applied AI engineering (LLMs, agents, RAG, evaluation and cost per token), architecture and DevSecOps, pricing, roadmap and KPIs. Two products taken from zero to production, both with an active sales pipeline.

2025 to 2026

Project management

Multidisciplinary projects · technology

Scope, schedule, risk and stakeholder communication, with responsibility for financial planning and control, including budget, forecast, variance analysis and cost optimization, plus vendor management and strategic meetings.

2022 to 2025

IT coordination

Insurance sector

Leading the technology team and the digital transformation agenda: process automation, service digitalization and self-service. Infrastructure and information security with governance and regulatory compliance, omnichannel orchestration, cloud migration (AWS, Azure and GCP), IT budget, contracts and business continuity and disaster recovery plans.

2019 to 2020

IT service management

Managed services · global company

Operational excellence with ITIL and governance: SLAs and KPIs, service desk, RPA automation, infrastructure and cloud, cybersecurity, change management, proactive monitoring and APM, plus leadership of multidisciplinary teams.

2014 to 2019

Telecommunications coordination

24×7 mission-critical operations · insurance

Telecom infrastructure for mission-critical operations with high availability and low latency. Network and telephony modernization (VoIP and cloud PBX, SD-WAN), contact center solutions with IVR and messaging, NOC leadership, contingency and link redundancy, carrier negotiation and regulatory compliance.

2009 to 2014

Telecommunications analyst, mid and senior

Corporate networks · contact center

Administration of LAN, WAN, Wi-Fi and MPLS networks; VoIP and PBX, including cloud-based; support for contact center platforms (IVR, call recording, IP telephony); proactive monitoring, SLAs, carrier contracts and contingency plans.

2007 to 2009

Start in IT

Support and infrastructure · corporate telephony

Installation, configuration and maintenance of corporate telephony platforms and wireless networks in large-scale environments.

2019 to 2020

MBA · Master in Information Technology

Information Technology

2012 to 2015

Systems Analysis and Development

Bachelor's degree in Information Technology

2005 to 2007

Industrial Electronics

Technical degree in Electrical and Electronic Engineering

Contact

Where to find me.

This site is a technical record, not a commercial proposal. If you want to talk about any of these experiences, LinkedIn is the shortest path.

Based inSão Paulo, Brazil · remote
LanguagesEnglish · Portuguese