Current direction
Distributed media systems, event-driven pipelines, agent platforms, and observability — full-stack work where reliability is the product, not a feature.
Portfolio / Enniskerry, Co. Wicklow
I build distributed media systems that stay clear under load.
Full-stack engineer working across Python, Node.js, and TypeScript. I design event-driven backends, contract-validated multi-agent pipelines, and observability-first services — with the operational habits that come from working inside live production environments at AWS and broadcast IT.
The work I enjoy most lives in the joins: orchestrators that don't pretend services talk to each other, contracts that catch silent failures before they propagate, and routing layers that make cost a first-class concern instead of an afterthought.
- Event-driven microservices on AWS & GCP
- Multi-agent pipelines with contract validation
- OpenTelemetry / Dynatrace observability
About
Alan Maizon
Argentine-Italian engineer based in Ireland. I build full-stack systems that survive real inputs — distributed backends, media pipelines, and AI-assisted tools with explicit service boundaries and verifiable behaviour. AWS Cloud Practitioner and Anthropic Claude API certified, currently completing a Distinction Certificate in Computing at the National College of Ireland.
Originally from Córdoba, Argentina, I moved to Ireland in 2021. My route into software ran through live infrastructure — AWS data-centre operations, broadcast IT at Spirit Radio, audio pipeline automation at Sacred Space. Those environments are where I learned the habits I now bring into engineering: move carefully, verify assumptions, leave the system more legible than I found it.
Stack I reach for
Python & Node.js backends, TypeScript & React on the front, FastAPI / Django REST, Docker, GitHub Actions, AWS and GCP (Cloud Run, Pub/Sub, Vertex AI).
Creative thread
Singer-songwriter work outside the keyboard. It shapes how I think about product feel, communication, and the human experience of using a tool.
Selected Projects
Work that says more than a profile paragraph
Five projects, ordered by what they show. The first two are media-pipeline systems built for production-grade hackathons; the last three are full-stack and AI prototypes that informed how I now design services.
Featured build / Hackathon: Built with Opus 4.7
rectoverso — Multi-Agent Media Production Pipeline
A four-tier distributed system that turns a creative brief into an assembled short film. Strict service isolation, contract-validated dispatch, capability-aware provider routing, deterministic ffmpeg compositing.
Problem
Multi-agent AI pipelines are notoriously fragile. Agents talk to each other directly, state drifts, silent failures cascade, and provider costs spiral. I wanted to prove these systems can be built with the same discipline as any other distributed backend.
Approach
Four enforced tiers — orchestrator, stateful specialists, stateless generators, deterministic workers — with one golden rule: no agent talks to another agent directly. All coordination goes through a shared JSON manifest acting as a single source of truth.
Architecture
A Producer orchestrator owns the manifest and event log. Specialists do verified file operations (shot judging, audio, editorial). LLM workers handle generation. A deterministic compositing layer assembles the final MP4. A validation contract sits between every step.
Stack
Python, JSON state machines, GitHub Actions CI, Anthropic Claude API, Google Vertex AI (Veo), Kling 2.x & Alibaba Wan 2.7 via API, ElevenLabs, ffmpeg, HTML-based compositing (Hyperframes), Apache 2.0 licensed.
Technical decisions
- Strict tier separation eliminates the most common multi-agent failure mode — runaway agent-to-agent communication with no audit trail.
- An isolated contract-validation layer gates every tool dispatch, catching silent agent hallucinations and configuration drift before they propagate downstream.
- Dynamic provider routing chooses between Kling 2.x, Wan 2.7, and Vertex AI Veo per shot, based on complexity and per-render budget caps — production-grade cost orchestration.
- A Demo Mode with golden-path fixtures lets the entire pipeline run offline without API spend, so demos and CI never depend on live credit.
Outcome
A working pipeline that takes a brief and produces an assembled MP4 — with every state transition recorded, every contract violation caught, and every provider call accounted for. Built for a hackathon, designed like a production system.
What it shows
I think about agent systems the way I think about any distributed backend: service isolation, deterministic workers where they belong, contracts at the seams, and cost as a first-class concern.
In development / Hackathon: Google Cloud Rapid Agent — Dynatrace track
StudioFlow — AI SRE Agent for Media Pipelines
A simulated event-driven media pipeline on Cloud Run, fully OpenTelemetry-instrumented to Dynatrace, with a Gemini agent that detects, diagnoses, and proposes remediation for production incidents — under human approval gates.
Problem
Production media systems fail in ways that are tedious to diagnose at 3am — OOM kills, codec panics, latency anomalies. Most AI agents are chatbots; few can actually read traces, correlate with deploys, and propose remediation that's safe to apply.
Approach
Build the substrate first: a deliberately fragile media pipeline that fails in scripted, repeatable ways. Wire it head-to-tail with OpenTelemetry. Then layer a Gemini 3.1 Pro agent that uses the Dynatrace MCP server as its primary tool to diagnose and act.
Architecture
Cloud Run microservices (ingest, workflow, transcode, enrichment) connected by Pub/Sub with Firestore state. OpenTelemetry exports to Dynatrace. An ADK agent orchestrates Dynatrace MCP, a pipeline-control API, and a human-approval gate. All write actions block until an operator approves.
Stack
Python, Google Cloud Run, Pub/Sub, Firestore, Cloud Storage, Vertex AI, Gemini 3.1 Pro, Google Agent Development Kit, OpenTelemetry, Dynatrace, Terraform, Next.js / TypeScript frontend, Apache 2.0.
Technical decisions
- The encode service is deliberately fragile — three scripted failure modes (memory leak, codec panic, latency throttle) reproducible on demand for testing and demos.
- The agent's evidence rule: every claim must cite a Dynatrace trace ID or DQL query result. No diagnosis without observed signal.
- The HumanApprovalGate tool is the system's soul — the agent can propose, but only an operator can approve a write. Hackathon brief required it; production systems demand it.
- Two-model cost discipline: Gemini 3.1 Pro for the main reasoning loop, Gemini Flash for status summaries.
Outcome
In active development. Submission target 11 June 2026. The build plan is public on GitHub; weekly milestones cover infrastructure, agent skeleton, approval gates and UI, then polish and demo video.
What it shows
Observability isn't a passive sink for traces — it can be the agent's eyes. I'm building the project I'd want to operate, not the demo I'd want to give.
Voice tech workflow
My Voicebank
A reproducible pipeline for training DiffSinger singing voice synthesis models from your own recordings, built around the OpenVPI ecosystem.
Voice tech workflow
GitHub
Problem
Training a voice model from personal recordings usually means stitching together several specialist tools, repeated setup steps, and brittle handoffs between stages.
Approach
I treated it as a workflow problem first. The project maps the path from raw recordings through labeling, forced alignment, note extraction, and training so the process stays repeatable rather than improvised every time.
Architecture
The build is organized around explicit stages and tooling boundaries: dataset prep, alignment, note extraction, model training, and environment-specific execution across Colab, GCE, and local Mac setups.
Stack
DiffSinger, OpenVPI tooling, forced alignment, note extraction, workflow automation, Colab, Google Cloud, and local Mac training paths.
Technical decisions
- Structured the pipeline around named stages so each step can be checked and rerun without guessing.
- Kept labeling, alignment, and note extraction visible instead of hiding them behind a black-box setup.
- Designed the workflow to work across Colab, GCE, and local Mac environments instead of locking it to one machine.
- Treated documentation and repeatability as part of the product, not as cleanup after the technical work.
Outcome
This is the clearest overlap between my technical and creative work. It turns a niche, easily frustrating process into something more understandable, reusable, and practical.
What it shows
I like making complicated toolchains feel more navigable, especially when the work sits between software, media, automation, and real human use.
Cloud and integration case study
Nebula
A drafting workspace for turning dense source material into traceable, reviewable submissions.
Cloud-oriented full-stack system
GitHub
Problem
Document-heavy drafting workflows are slow, difficult to trace, and easy to derail when requirements are missed or evidence is weak.
Approach
I broke the system into explicit stages: upload and parsing, requirement extraction, cited section generation, coverage analysis, unresolved evidence review, and export.
Architecture
The frontend is a Next.js workspace. The backend is a FastAPI pipeline with isolated services for parsing, validation, coverage, and export. Local development uses SQLite and filesystem storage, while the AWS deployment path is designed around RDS, S3, Bedrock, and Cognito-aware routing.
Stack
Next.js, React 19, FastAPI, SQLite, Postgres-ready data paths, S3, Amazon Bedrock, Cognito, Docker, GitHub Actions, and typed frontend utilities for traceability and quality diagnostics.
Technical decisions
- Kept parsing, generation, coverage, and export as separate modules so failures are easier to diagnose and improve.
- Added quality-signal panels and unresolved-gap views so users can see weak inputs before exporting output.
- Built a cloud-ready deployment path with AWS readiness scripts covering ECS, RDS, S3, CloudFront routing, and config checks.
- Protected delivery quality with backend tests, type checks, build verification, and docker smoke steps in CI.
Outcome
Nebula is the clearest example of how I think about structure. Each stage has a job, the interfaces are explicit, and the deployment path was designed to feel real instead of hand-waved.
What it shows
I like breaking broad product problems into services, checks, and review steps that keep the output explainable for the people using it.
Systems-thinking proof of concept
Entropy
A research-heavy prototype for exploring how a system can absorb information, challenge itself, and update its own model over time.
Proof-of-concept system
GitHub
Problem
I wanted to explore continual learning as a software architecture problem, not just as prompt experimentation.
Approach
I designed a system with separate ingestion, memory, reasoning, orchestration, and API layers so each concern could be tested and evolved independently.
Architecture
FastAPI exposes ingestion and reasoning endpoints. The backend coordinates vector memory, graph memory, and episodic memory, while a React and Vite frontend acts as a lightweight dashboard over the system.
Stack
FastAPI, React, Vite, Qdrant, Neo4j, SQLite, Pydantic settings, Docker Compose, and pytest.
Technical decisions
- Separated vector, graph, and episodic memory so each one has a clear role in retrieval, structure, and history.
- Kept API endpoints narrow around ingestion, hypothesis generation, reasoning cycles, and graph inspection.
- Used Docker Compose to stand up local supporting infrastructure instead of hiding dependencies behind assumptions.
- Documented the architecture heavily so the proof-of-concept remains understandable as the system grows.
Outcome
It is deliberately experimental, but the implementation still follows rules I care about: clear module boundaries, observable behavior, and documentation good enough that future changes stay possible.
What it says about me
I enjoy ambitious ideas, but I only trust them when the system underneath is readable and testable. This project let me prove that instinct.
How I Work
Habits from working inside live systems
Before software became the main thing, I learned the operational habits that now shape how I design and run services — diagnosing under pressure, protecting live environments, and leaving systems more legible than I found them.
Troubleshooting under pressure
At Spirit Radio I handled Windows, network, and configuration faults on live broadcast IT. The job taught me to narrow unknowns quickly, reproduce failures, and explain the fix clearly while people are waiting on signal to come back.
Working safely around live systems
At AWS I supported server infrastructure under formal change-management procedures — exposure to the operational discipline real distributed systems demand. Move carefully, verify assumptions, respect dependencies, escalate cleanly when a boundary matters.
Documentation that actually helps
At Sacred Space I designed a Bash-based audio processing and denoise pipeline, standardized recurring steps, and wrote runbooks non-technical editors could follow. Documentation is part of the deliverable, not cleanup afterwards.
The operational background is the engineering background. Production systems break at 3am; I've been the person who fixes them.
Toolbox
Tools I reach for often
Languages
Python, JavaScript, TypeScript, Java, SQL, Bash
Frontend
React, Next.js, TypeScript, Vite, Tailwind, semantic HTML, responsive CSS, accessibility-minded UI
Backend
Node.js, FastAPI, Django, REST APIs, GraphQL concepts, event-driven microservices, state machines
Cloud & DevOps
AWS (Certified), Google Cloud (Cloud Run, Pub/Sub, Firestore, Vertex AI), Docker, GitHub Actions, Terraform (familiar), Linux
Observability & Data
OpenTelemetry, Dynatrace (in-flight), distributed tracing concepts, SQL, NoSQL (Firestore), JSON state machines
AI / Multimodal
Anthropic Claude API (Certified), Amazon Bedrock, Google Vertex AI / Gemini, Model Context Protocol (MCP), RAG, ElevenLabs, ffmpeg / media pipelines
Contact
If the work feels like a fit, say hello.
Open to full-stack engineering roles working on distributed systems, media pipelines, observability, or agent platforms. Based in Wicklow, comfortable with hybrid or remote within Ireland.
Email is the simplest way to start. GitHub has the code; LinkedIn has the formal version.
- Based in Enniskerry, Co. Wicklow, Ireland
- AWS Certified Cloud Practitioner · Anthropic Claude API Certified
- Comfortable across engineering, product, and operational context
Useful links
Enough context for a quick first pass
Start with email. GitHub and LinkedIn fill in the rest.
Email
maizonalan@gmail.com
Best route for recruiter outreach and role discussions.
GitHub
github.com/alanmaizon
Source code and project implementation detail.
LinkedIn
linkedin.com/in/maizonalan
Professional profile and role context.
Location
Enniskerry, Co. Wicklow
Ireland based, open to hybrid or remote within Ireland.
If you prefer the one-page version, the CV is here.