07
Automation and applied AI
Automating is easy while everything works. The real work is deciding what happens at step three of seven when step four fails: roll back, retry, or call someone?
- n8n
- saga and retry
- LLM APIs
- OCR and PDF
- ETL
- cron and queues
- notifications
Sagas, not scripts
A provisioning run or a publishing cycle is a distributed transaction: every step has a compensation, a retry ceiling and persistent state. If it falls over halfway, the system knows where it was and what to undo — it doesn't start again hoping nobody notices.
Every step is idempotent by construction: re-running it must produce the same result, because sooner or later it will be re-run.
A real queue, not a hopeful cron
Jobs live in a queue with exclusive claims (in PostgreSQL, skipping rows already taken) so two workers never do the same thing twice. The queue is drained on a schedule and also right after an insert, so nothing waits for the next tick without reason.
AI where it adds value, humans deciding
LLMs are useful for understanding and proposing: draft replies, classification, extraction from documents. But while an action is public or irreversible, the proposal goes through an approval — in the app or as a message with two buttons — and stays on the record.
The value is not "AI does everything": it is removing the mechanical preparation and leaving the decision to a person, with the context already laid out.
Portfolio
What I did on this, project by project.
Orbitas
Provisioning orchestration and self-healing
- Provisioning saga in n8n split into dispatcher, step processor, retry and final smoke test: a new customer is born by crossing traced steps, not one monolithic script.
- Proactive and reactive reconciliation: the system periodically compares real state with desired state and reacts to events when something drifts.
- Service self-healing with multi-level escalation and a full trail, plus an automated smoke test after every provisioning run.
- Written, versioned architecture decisions on step idempotency and the semantics of destructive operations: the part that makes automation dependable rather than reckless.
- n8n
- saga pattern
- PostgreSQL
- Consul
- bash
- ADR
BigFishIta
Content orchestrator and agents
- A PostgreSQL job queue with exclusive claims and retries, drained by a cron every two minutes and opportunistically after each insert.
- Agents that prepare the work (analysis, drafts, proposals) and put it up for approval: nothing public goes out without an explicit yes.
- Operational notifications on Telegram with LLM-assisted quick actions, plus periodic comment polling as a safety net over the social integration.
- Nightly metric snapshots to keep the history the social APIs don't retain.
- Next.js
- PostgreSQL
- cron
- n8n
- LLM APIs
- Telegram
Need this?
Tell me the problem and I'll tell you how I would tackle it — and if it isn't worth doing, I'll tell you that too.
Let's talk