About the author
Edy Figueroa builds AI systems that move from demo to production.
I am an AI architect and engineer focused on the practical side of production AI: agent workflows, retrieval architecture, MCP integrations, governed automation, and the software boundaries that make intelligent systems usable in real organizations.
What I build
My work sits at the intersection of application engineering and AI platform design. I build systems where a signal from tools like Jira, support queues, documents, or internal workflows can become structured analysis, generated reports, routed actions, and auditable evidence. The goal is not another chatbot. The goal is useful AI software that can be tested, governed, observed, and improved after launch.
AI platforms
Architecture for model routing, prompt templates, structured outputs, evaluation, telemetry, cost controls, and release gates.
Agent workflows
Agentic systems that gather context, call tools, request approvals, generate artifacts, and leave clear traces for operators.
RAG and knowledge systems
Chunking, retrieval, source grounding, content boundaries, citations, and practical checks for knowledge quality.
MCP and integrations
Tool contracts, connector boundaries, enterprise APIs, workflow automation, and safer ways to connect agents to real systems.
How I think about architecture
Good AI architecture is mostly about boundaries. WordPress can be the publishing layer. Django can own authenticated workflows, packages, policies, and operational APIs. MCP servers can expose narrow tool contracts. The assistant experience can sit on top of those layers without turning every layer into a runtime.
That separation matters because production systems need permissions, logs, rollback paths, source freshness, and ownership. A prototype can hide those decisions. A real platform cannot.
Why this publication exists
AI The Architect is where I turn that building work into field notes. The articles are written for engineers, founders, product owners, and teams trying to ship AI features that survive real users, real data, real governance, and real delivery pressure.
The systems I care about are not impressive because they answer once. They are useful because they keep working when the workflow, data, model, and organization change.