Automation systems

Angelo Torrevillas AI Automation Specialist

I design and build automation systems with the guardrails and human checkpoints that keep them reliable.

See the systems Book a call
  • n8n
  • PostgreSQL
  • Supabase
  • GoHighLevel
  • PayMongo
  • OpenRouter
  • JavaScript
How a NEXT-CARE payment becomes consultation access PayMongo sends a signed webhook. If the signature is invalid, the request is rejected with a 401 and logged. A valid event is recorded once; duplicates are acknowledged and skipped. A guarded update marks the payment paid in PostgreSQL, ignoring already-settled payments. Only then is the confirmation email with the consultation links sent and the CRM contact tagged. invalid dup. settled valid PayMongo signed webhook Signature valid? Record event once Guarded payment update PostgreSQL: verified paid Email consultation links Tag CRM contact Reject: 401, logged Acknowledge, don't reprocess Ignore: already settled How a NEXT-CARE payment becomes consultation access A signed PayMongo webhook is verified; invalid signatures are rejected with a 401 and logged. The event is recorded once, and duplicates are acknowledged and skipped. A guarded update marks the payment verified in PostgreSQL, ignoring already-settled payments. Only then are the consultation links emailed and the CRM contact tagged. PayMongo signed webhook Verify signature (HMAC) invalid → 401, logged Record event once duplicate → skipped Guarded payment update settled → ignored PostgreSQL: verified paid Email links + tag CRM contact
NEXT-CARE, payment to access. The real branches of the signed-webhook workflow and what follows it. PayMongo sandbox; fictional clinic.

Selected systems

Systems, not just workflows.

Each opens as a full case study: the problem, how it runs, where people decide, and what has and hasn't been proven.

Top of the Dispatch Approved Chases workflow graph: webhook, claim pending outbox rows, revalidate live invoice state.
Accounts receivableConcept Demo · FINAL

AR Payment Chasing

Chases overdue invoices by email — once per customer, at the right escalation level, and never after they've paid.

  • n8n
  • PostgreSQL
  • Gmail API
  • OpenRouter
Top of the Route Human Review and Approval workflow graph: review decision form and deadline sweep triggers with automation checks.
Bids & proposalsFINAL · structural

RFP & Tender Response

Turns tender documents into reviewed, approved draft answers — with a person signing off at every point that matters.

  • n8n
  • PostgreSQL + pgvector
  • Ollama
  • OpenRouter
NEXT-CARE Talk to a Doctor page with consultation price and Consult Now button.
Healthcare funnel & paymentsIn development · Sandbox

NEXT-CARE Medical Clinic System

A paid consultation funnel where access is released only after a signed payment webhook is verified against the database.

  • GoHighLevel
  • n8n
  • PostgreSQL
  • PayMongo

Client work

Built for a real business.

Delivered in a paid trial. The client is anonymized and confidential details are withheld.

n8n canvas: approval gate, prior-send check, duplicate-send block and client email.Client details withheld
Interior design firm · AnonymizedCore flow delivered & verified

AI Proposal Intake & Pricing System

Turns a sales intake into a priced, AI-reviewed, approved proposal PDF — and makes sure only an approved proposal reaches the client, once. Deterministic pricing runs first; the AI only advises.

  • n8n Forms
  • OpenRouter (Llama 3.3 70B)
  • Google Docs & Sheets
  • Gmail

All builds

Earlier agents and integrations.

Single-workflow builds and experiments — active builds first, then newest first. This is where the patterns above started.

n8n canvas: Slack mention to a RAG knowledge agent with a retrieval tool over the handbook vector store, reply in Slack.
n8n · RAGActive

RAG Employee Handbook Assistant

Answers policy questions in Slack from handbook documents embedded with Ollama into a Supabase vector store.

  • Supabase
  • Ollama
  • Slack
n8n canvas: Facebook webhook with verification branch and a message branch through a knowledge document and chat agent to an HTTP reply.
n8n · AI agentActive

Messenger Inquiry Assistant

Answers Facebook Messenger inquiries from a Google Docs knowledge source, with webhook verification and short memory.

  • Messenger
  • Google Docs
  • OpenRouter
n8n canvas: invoice image analysed by OCR, AI extraction with structured parser, validation and duplicate checks.
n8n · Document AIActive

Invoice Agent for Telegram

Invoice photo in, structured record out: OCR, AI extraction, validation and duplicate checks before anything is stored.

  • Telegram
  • OCR.space
  • Google Sheets
n8n canvas: Slack mention to SQL Sales Agent with GPT-4o mini, sales database query, calculator and reasoning tools, reply in Slack.
n8n · AI agentExperimental

SQL Sales Analytics Assistant

Answers sales questions in Slack by querying a PostgreSQL table through an AI agent's SQL, calculator and reasoning tools.

  • Slack
  • PostgreSQL
  • OpenRouter
n8n Book slots tool: webhook, argument parsing and verification, Google Calendar event creation.
n8n · Voice agentBuilt · inactive

Dental Voice Appointment Setter

A Vapi voice agent calls n8n webhook tools to check, book, update and cancel Google Calendar slots, logging calls in Airtable.

  • Vapi
  • Google Calendar
  • Airtable
n8n canvas: chat trigger to Online Sales Agent with GPT-4o mini, four data table tools and a calculator.
n8n · AI agentSuperseded by SQL version

AI Sales Data Assistant

The earlier sales assistant: an agent answering questions through four n8n Data Table tools and a calculator.

  • n8n Data Tables
  • OpenRouter
Zapier editor: Asana trigger split into paths for ready to start, no response, quoted, approved, paid and closed.
Zapier · CRMEarlier build

Zapier–Asana CRM Automation

An Asana task update routes each lead down one of five paths: folders, sub-tasks, timed follow-ups and emails.

  • Zapier
  • Asana
  • Gmail
Zapier editor: form submission, Apollo organisation lookup and AI lead scoring steps.
Zapier · Lead qualificationEarlier build

Zapier Lead Qualification & Outreach

Enriches form leads through Apollo, scores them with AI, and routes high, medium and low leads to different follow-up.

  • Zapier
  • Apollo
  • Supabase
  • Slack
Zapier editor: new Google Drive file, date formatting, logging and an mp3 filter.
Zapier · ContentEarlier build

Zapier Content Repurposing

Audio dropped in Google Drive is transcribed, drafted into blog and social posts, and routed to publish or review.

  • Zapier
  • Google Drive
  • Sheets
GoHighLevel workflow builder: contact tag or new contact triggers, waits, opportunity creation and tagging.
GoHighLevel · CRMEarlier build

Car Insurance Sales Workflows

New leads get an opportunity, tags, an intake-form email, an assigned agent and an internal alert.

  • GoHighLevel
  • Email
GoHighLevel workflow builder: salon inquiry form, waits, opportunity and tag steps.
GoHighLevel · CRMEarlier build

Salon Client Retention Pipeline

Salon inquiries become opportunities with a welcome email, a front-desk alert, a note and a contact task.

  • GoHighLevel
  • Email
GoHighLevel workflow builder: booked-appointment form, waits and tag changes.
GoHighLevel · CRMEarlier build

Lead Nurturing Pipeline

Tag-driven stages move a lead from new, to nurturing, to booked as forms are submitted.

  • GoHighLevel
  • Forms

15 builds

How I build

Design before workflow.

The selected systems went through the same written gates, each needing sign-off before the next.

  1. Process map

    Actors, decisions, exceptions and hand-offs — and where automation should stop.

  2. Architecture gate

    What is deterministic, where AI is allowed, which database holds the truth.

  3. Premortem

    Assume it failed and find out why. For AR Payment Chasing: seven design holes, fixed before building.

  4. Implementation spec

    States, contracts, tests and scope — sent back when it isn't build-ready.

  5. Build & validate

    Structural and runtime evidence reported separately; blocked and failed paths exercised.

  6. Honest status

    Untested paths, deferrals and known limitations written down.

Failure-injection suites are part of each implementation spec; so far they have only been run in part.

Angelo Torrevillas, AI Automation Specialist

About

Reliability is the point.

I'm Angelo Torrevillas, an AI automation specialist in the Philippines. Connecting apps is the easy part; making it dependable is the work — explicit state in a database, deterministic rules before AI, and people in the loop for decisions that cost money or trust.

My background is computer engineering. I'd rather write down what hasn't been tested than let a demo imply it has.

Based in
Philippines
Education
BS Computer Engineering, Technological Institute of the Philippines (2026)

Background

Rebar Vista camera screen showing a rebar column with a live distance reading.
Team thesis · Computer vision

Rebar Vista — Rebar Column Measurement System

Mask R-CNN on a Raspberry Pi 5 measures rebar columns and recommends a cement mix. 96.3% system test success rate (77 of 80 trials, ±5% tolerance).

  • Python
  • Mask R-CNN
  • Flask
  • Raspberry Pi 5
Sign-in screen of the Quezon City Public Library employee daily time record system.
Internship · Web app

Employee Daily Time Record System

A web app for the Quezon City Public Library that replaced manual attendance records.

  • PHP
  • MySQL
  • JavaScript

FAQ

Common questions.

What does Angelo Torrevillas build?

Automation systems for business processes: n8n and GoHighLevel workflows backed by a database, integrations with CRMs, payment providers, email and chat tools, and AI steps where they genuinely help — such as reviewing proposal pricing, classifying replies, or retrieving and drafting answers from approved documents.

What tools does he work with?

Mainly n8n, PostgreSQL and Supabase, and GoHighLevel. For AI he uses models accessed through OpenRouter and Ollama for embeddings; for payments, PayMongo (so far in sandbox); for communication, Gmail, Slack, Telegram and Facebook Messenger. He writes JavaScript for custom logic, and has used Zapier, Airtable and Vapi on earlier builds.

How does he approach automation reliability?

He maps the business process, sets architecture boundaries and runs a premortem before building. Deterministic rules come first; AI gets a narrow role and no authority over money or records. Systems use idempotency, allowlists and kill switches, a person approves anything costly or irreversible, and each project's status states what has and hasn't been tested.

How can someone work with him?

Use the Book a call section on torrevillas.tech or email angelo.automates@gmail.com with a short description of the process you want to automate.

Contact

Tell me what's manual, slow or fragile.

I'll tell you honestly whether automation is the right fix — and what it would take to make it dependable.

Book a call

Pick a time for a discovery call. The calendar is provided by GoHighLevel and loads only when you open it.

Open booking calendar

Calendar not loading? Open it in a new tab or email angelo.automates@gmail.com.

Case studies

Selected system · Accounts receivable

AR Payment Chasing

  • Concept Demo · FINAL
  • Portfolio system · synthetic data

Chases overdue invoices by email — once per customer, at the right escalation level, and never after they've paid.

Problem

Chasing overdue invoices is repetitive, but mistakes are expensive: a reminder sent after payment, three emails to one customer, or a message to the wrong address damages the relationship. Simple automations can't rule those out.

Solution

Four n8n workflows over a PostgreSQL state machine. Deterministic rules decide who to chase and how firmly; reminders go through a durable outbox that re-checks each invoice before sending; replies are triaged by a narrowly scoped AI classifier that cannot change financial records.

How it flows

  1. Sync invoicesAccounting adapter → idempotent upsert into PostgreSQL
  2. Plan chasesEligibility rules, one consolidated reminder per customer at its highest tier
  3. Large invoices held Human decisionAbove the approval threshold, reminders wait for a person and are never auto-sent
  4. DispatchAtomic claim → re-check payment → allowlist → kill switch → send
  5. Route repliesKeyword pre-filter, then AI classification with a confidence floor
  6. Audit trailEvery sent, blocked, superseded or failed outcome is recorded

Runs automatically

  • Invoice sync with stable, duplicate-free upserts
  • Eligibility and escalation-tier decisions
  • Per-customer consolidation and outbox de-duplication
  • Template rendering per tier
  • Reply triage: opt-out, bounce, out-of-office, promise-to-pay, dispute

Where humans decide

  • Reminders above the approval threshold stay in awaiting approval; dispatch cannot claim them
  • Low-confidence reply classifications aren't acted on automatically
  • An operator can stop all sending with the kill switch

Guardrails

  • Atomic claim — a single UPDATE … RETURNING
  • Send-time revalidation: paid or closed invoices are superseded, not sent
  • Recipient-domain allowlist
  • Kill switch that safely releases claimed rows
  • AI classifier has no tools and no write access to financial state
Documented evidence
Re-running sync kept row counts stable. A customer with three overdue invoices got exactly one reminder at the highest tier, and re-planning created zero duplicates.
Real Gmail sends plus the blocked, superseded and send-failed paths were run live — including one multi-item run hitting all of them. Kill switch tested in both directions.
Not yet proven / deferred
Mutual exclusion under truly simultaneous runs (lock proven within a single run only).
Deferred to a pilot: real Xero connection, the approvals interface, watchdog alerting and opt-out suppression.
Design objective
Remove manual reminder work while making double-sends, post-payment reminders and wrong-recipient emails prevented by construction. No business outcome has been measured; it runs on synthetic data.
Graph of the Dispatch Approved Chases workflow: webhook, claim pending outbox rows, revalidate live invoice state, still valid to send, retrieve send details, render chase template, check recipient allowlist, check kill switch, send chase email, and record sent, blocked, superseded or failed events.
Workflow 03 · Dispatch Approved Chases. Every email passes a claim, a payment re-check, the allowlist and the kill switch first. Drawn from the workflow's exported JSON (node names and connections only).

Stack: n8n · PostgreSQL · Gmail API · OpenRouter LLM (classification only) · JavaScript

Selected system · Bids & proposals

RFP & Tender Response

  • FINAL · structural completeness
  • Portfolio system · synthetic tenders

Turns tender documents into reviewed, approved draft answers — with a person signing off at every point that matters.

Problem

Answering a tender means pulling every requirement out of long, inconsistent documents, finding the best previously approved answer, drafting the rest and getting sign-off before a hard deadline. A missed requirement or an unapproved claim can cost the bid.

Solution

A multi-workflow n8n system on PostgreSQL with vector search. It parses tender documents, extracts and reconciles requirements, retrieves and scores answers from an approved library, drafts with a structured AI call, and routes every answer through review, approval and owner-only final sign-off.

How it flows

  1. Ingest tenderPDF, DOCX, XLSX or CSV → parsed text
  2. Go / no-go Human decisionRecorded with a rationale before any work starts
  3. Extract requirementsExtraction and reconciliation, including addenda
  4. Confirm requirements Human decisionThe locked list is what gets drafted
  5. Retrieve & draftVector retrieval and scoring; low confidence becomes a review task, not a draft
  6. Review, approve, sign off Human decisionPer-answer approval, escalation on deadlines, owner-only final sign-off

Runs automatically

  • Document parsing and requirement extraction
  • Candidate retrieval and confidence scoring
  • Structured, validated AI drafting
  • Review-package compilation
  • Deadline sweeps with tiered Slack escalation
  • Answer-library freshness checks

Where humans decide

  • Whether to bid at all
  • Which requirements are confirmed
  • Every answer: approve, reject, or hand to manual drafting after two rejections
  • Final sign-off by the bid owner only, through a verified login rather than a typed name

Guardrails

  • AI drafts but never approves
  • Owner-only enforcement on sign-off; unauthorized attempts are rejected
  • Append-only audit events
  • Fail-closed kill switch at twelve entry points
  • Duplicate decisions return “already processed”
Documented evidence
Parsing, extraction, retrieval and drafting (workflows 01–05) were built and tested against synthetic tenders. Review/approval and sign-off/submission (07, 08) were live-tested, including a rejected unauthorized sign-off.
The kill-switch toggle, demo-data reset, library re-embedding and freshness sweep were live-tested; eight review-task lifecycle scenarios passed.
Structural only / deferred
Validated but not runtime-tested: the kill switch wired into the twelve entry points, the confirm-requirements → drafting trigger, and review-package compilation (7 of 8 planned steps).
Deferred: addendum → drafting trigger, OCR for scanned documents, and live DOCX/XLSX tests.
Design objective
Shorten the path from tender to reviewed draft while keeping every claim traceable to an approved source and every decision to a named person. Not yet measured on real tenders.
Graph of the Route Human Review and Approval workflow: a review decision form checks the automation switch and answer status, then writes an approval event or increments rejections and either triggers a redraft or routes to manual drafting; a scheduled deadline sweep computes escalation tiers and sends notifications.
Workflow 07 · Route Human Review & Approval. The human decision form (highlighted) and the scheduled deadline sweep. Drawn from the workflow's exported JSON.

Stack: n8n · PostgreSQL + pgvector · Ollama embeddings · OpenRouter (GPT-4o mini) · Google Drive & Docs · n8n Forms with user auth · Slack

Selected system · Healthcare funnel & payments

NEXT-CARE Medical Clinic System

  • In development · Sandbox
  • Portfolio system · fictional clinic

A paid online-consultation funnel where the patient only receives consultation access after a signed payment webhook has been verified against the database.

Problem

For paid online consultations, the consultation link is the product. A clinic needs patients to move smoothly from interest to booking, but access should only be released once payment is genuinely confirmed — not because a redirect page said so.

Solution

Built in two stages. First the GoHighLevel layer: a patient funnel and CRM workflows that move contacts through a pipeline, send reminders and alert staff. Then a payment layer in n8n and PostgreSQL: server-side pricing, PayMongo hosted checkout, signature-verified webhooks and a database-backed payment state that decides what the patient receives — synced back to the CRM.

System layers and their status

  1. Patient funnelGoHighLevel pages: landing → talk to a doctor → doctor profile → patient details → payment → confirmationBuilt · public preview
  2. CRM & bookingFour GHL workflows: readiness routing, pipeline stages, booking reminder loop, medical-history stage, visit follow-upImplemented
  3. PricingServer-side quote with USD → PHP conversion; the browser never sets the priceRuntime-tested
  4. CheckoutPayMongo hosted checkout with a guard that refuses anything but test modeSandbox-tested
  5. Payment verificationSigned webhook → HMAC check → idempotent event → guarded state change in PostgreSQLBuilt · sandbox
  6. Access & confirmationConsultation and medical-history links are emailed only after verified paymentBuilt · sandbox
  7. CRM syncVerified payment → one controlled tag write to the GHL contactVerified once · controlled
  8. Staff notificationGHL alert to staff when the verified-payment tag landsImplemented

Runs automatically

  • Lead routing, pipeline moves and booking reminders in GHL
  • Price quote, checkout creation and webhook verification
  • Payment-state transitions and confirmation email
  • Verified-payment status synced to the CRM contact

Where humans decide

  • Staff are notified on verified payment and continue the clinic process
  • Staff move a patient to the on-site visit stage, which triggers follow-up
  • CRM writes run only as deliberate, controlled runs — the sync is kept locked otherwise

Guardrails

  • Missing or invalid doctor is rejected — never defaulted to another doctor
  • Invalid webhook signatures get a 401 and are logged
  • Duplicate webhooks are acknowledged but not re-processed
  • Already-settled payments can't transition twice
  • Database outage returns 503 so the provider retries
Documented evidence
Sandbox payments were completed end-to-end in PayMongo test mode. Pricing was runtime-tested against PostgreSQL. After the latest checkout-guard change, checkout creation was re-tested in sandbox.
One controlled live CRM tag write was verified on a synthetic test contact.
Open items
A full paid run hasn't been repeated since the latest guard change. There's no sweeper for abandoned checkouts yet.
Known limitation: consultations currently share one meeting link; per-patient links are planned. Live merchant activation is out of scope for this phase.
Design objective
Make “paid” mean “verified by the payment provider and recorded in the database” before any access is sent. The clinic is fictional; no production payments have been processed.
NEXT-CARE Talk to a Doctor page: headline, consultation price and a Consult Now button.
Talk to a Doctor. Entry point of the patient funnel (GoHighLevel page, public preview).
Doctor profile page with specialty, experience, affiliations, certifications and a Consult Now button showing the fee.
Doctor profile. Fictional doctor; demo content for a fictional clinic.
Payment page showing 'Please select a doctor' because no valid doctor was provided.
Guardrail in action. Opening the payment page without a valid doctor is refused instead of falling back to a default.
GoHighLevel workflow builder showing NCMC 01: form submitted, branch on check-up readiness, create opportunity, wait, add tag, and send welcome email, with an internal notification on unexpected values.
CRM layer · NCMC 01. New-lead routing by readiness, with a staff alert when the value is missing.
Graph of the Receive Payment Webhook workflow: parse signature header, build signed string, compute HMAC, check validity, idempotent insert of the payment event, decide whether to process, guarded payment and consultation transition, and specific responses for invalid signature, duplicates, already settled, success and database unavailable.
Workflow 03 · Receive Payment Webhook. Signed PayMongo webhook → PostgreSQL payment state, with a distinct response for every outcome. Drawn from the workflow's exported JSON.

Stack: GoHighLevel · n8n · PostgreSQL (Supabase) · PayMongo · Webhooks + HMAC · Gmail API · HTML/CSS/JS

Client work · Paid trial

AI Proposal Intake & Pricing System

  • Interior design firm · anonymized
  • Core flow delivered & verified

Turns a sales intake into a priced, AI-reviewed, approved proposal PDF — and makes sure only an approved proposal reaches the client, once.

Problem

The firm wanted design-fee proposals produced from sales intake under firm rules: the same inputs must always give the same fee, AI may advise but never set prices, Sales must approve before anything is sent, and retries or edits must never duplicate a proposal or a client email.

Solution

A 65-node n8n workflow. Deterministic JavaScript pricing runs first; an AI review then checks risk and missing information and returns structured output; Sales decides; the proposal is generated as a PDF, previewed, approved and emailed to the client with Sales copied — with every step recorded.

How it flows

  1. Sales intakeForm, normalization, validation
  2. Version checkNew proposal, material revision, or delivery-only correction
  3. Deterministic pricingRules-based fee with a visible breakdown
  4. AI risk reviewStructured JSON; flags items for manager review
  5. Sales decision Human decisionContinue, adjust pricing, or request changes
  6. Proposal PDFDocument built, exported and stored
  7. Preview & approve Human decisionApprove or send back for revision
  8. Deliver onceDuplicate-send check, then email client and CC Sales

Runs automatically

  • Input validation and proposal numbering
  • Revision detection against existing proposals
  • Fee calculation and AI risk review
  • Document, PDF and record creation
  • Client delivery and status logging

Where humans decide

  • Manager review when the AI flags it
  • Sales accepts, adjusts or rejects the recommendation
  • Sales previews and explicitly approves the PDF before sending

Guardrails

  • The AI never calculates the base fee
  • Structured-output parsing on the AI review
  • Duplicate-send and duplicate-resend blocks
  • AI, PDF and email failures logged on their own paths
  • Separate error-alert workflow
Documented evidence
Trial documentation records the core flow as completed and verified: pricing, AI review, Sales decision routing, PDF generation and preview, the approval gate, client delivery with Sales copied, persistent records, and the revision and AI/PDF/email failure paths.
Not shown
The client's name, pricing rules, proposal content and delivery evidence are confidential and omitted.
Expected impact
Consistent, traceable pricing and no unapproved or duplicate proposals reaching clients. Time saved hasn't been measured.
n8n canvas section 'Approval & Delivery': store proposal PDF, create proposal record and AI review log, preview and approve proposal, approval gate, check prior send status, block duplicate send, attach PDF, send client email, and record sent or log delivery failure.
Approval & delivery. Approval gate → prior-send check → duplicate block → client email, with success and failure recorded.
Overview of the full 65-node n8n workflow grouped into phases: intake and validation, revision detection, pricing, AI review, proposal generation, approval and delivery, delivery correction and failure handling.
The whole workflow. Workflow structure only — client data withheld.

Stack: n8n Forms & Code · OpenRouter (Llama 3.3 70B) · Google Docs & Drive · Google Sheets records · Gmail · Slack error alerts

Build · n8n · AI agent

SQL Sales Analytics Assistant

  • Experimental

Answers sales questions in Slack. An AI agent queries a PostgreSQL sales table through a SQL tool, then uses calculator and reasoning tools before replying. It evolved from the earlier AI Sales Data Assistant, which used n8n Data Tables.

Slack thread where the assistant answers revenue questions and declines a request to delete all sales records.
Test thread in Slack on an example sales dataset, including a refused request to delete records.

Answer accuracy is still being evaluated: some test answers contained wrong dates or totals.

Stack: Slack · n8n · OpenRouter (GPT-4o mini) · PostgreSQL

Build · n8n · Voice agent

Dental Voice Appointment Setter

  • Built · not currently active

A Vapi voice agent calls five n8n webhook tools to check, book, update and cancel Google Calendar slots and to record call results, logging bookings in Airtable.

n8n 'Book slots' tool flow: webhook, argument parsing and verification, create a Google Calendar event with success and error responses, confirm booking and record it in Airtable.
Book-slots tool. Invalid arguments get an error response instead of a booking.

Stack: Vapi · n8n webhooks · Google Calendar · Airtable

Build · n8n · RAG

RAG Employee Handbook Assistant

  • Active

Answers policy questions in Slack from company documents. New files in a Google Drive folder are embedded with Ollama into a Supabase vector store; an agent retrieves the relevant passages before answering.

Slack thread in which the assistant lists the leave types from the employee handbook in answer to a question about leave policy.
Slack answer to “What is the company's leave policy?”, grounded in a sample handbook.

Stack: Google Drive · Ollama embeddings · Supabase vector store · OpenRouter · Slack

Build · Knowledge-grounding experiment 1 of 3

Full-Context Assistant: document in the prompt

  • Experiment

One of three small chat agents comparing ways to ground answers in documents. This one answers from reference material written directly into the agent's prompt, with no retrieval step. The RAG assistant is the later approach.

n8n canvas: chat trigger to a Full Context agent with a GPT-4o mini model.
Workflow. Chat trigger → agent → model.

Stack: n8n chat trigger · OpenRouter (GPT-4o mini)

Build · Knowledge-grounding experiment 2 of 3

Full-Context Assistant: documents fetched per message

  • Experiment

Fetches two Google Docs on every message and passes their full text to the agent, trading tokens for complete context.

n8n canvas: chat trigger, two Google Docs fetched in sequence, then the Full Context agent.
Workflow. Two document fetches run before the agent on every message.

Stack: n8n · Google Docs · OpenRouter (GPT-4o mini)

Build · Knowledge-grounding experiment 3 of 3

Full-Context Assistant: documents as tools

  • Experiment

The same two Google Docs exposed as tools, so the agent decides when to read them instead of receiving them on every message.

n8n canvas: Full Context agent with two Google Docs connected as tools.
Workflow. Documents attached to the agent as tools.

Stack: n8n · Google Docs tools · OpenRouter (GPT-4o mini)

Build · n8n · AI agent

Messenger Inquiry Assistant

  • Active

Answers Facebook Messenger inquiries about services from a Google Docs knowledge source. Handles Meta's webhook verification handshake, filters non-text events, keeps short conversation memory and replies through the Graph API.

n8n workflow: Facebook webhook with a GET branch for verification and a POST branch that filters messages, loads the knowledge document, runs the chat agent with memory and replies via HTTP request.
Workflow. Verification branch on GET; message handling on POST.

Stack: Messenger webhook · Google Docs · OpenRouter (GPT-4o mini) · Graph API

Build · n8n · AI agent

AI Sales Data Assistant

  • Superseded by the SQL version

The first sales assistant: a chat agent that answers questions through four n8n Data Table tools — all rows, by product, by date, by transaction — plus a calculator. The SQL Sales Analytics Assistant replaced the Data Table tools with a PostgreSQL query tool.

n8n canvas: chat trigger to Online Sales Agent with GPT-4o mini, four data table tools and a calculator.
Workflow. Agent with four Data Table tools and a calculator.

Stack: n8n Data Tables · OpenRouter (GPT-4o mini)

Build · n8n · Document AI

Invoice Agent for Telegram

  • Active

Send an invoice photo to a Telegram bot: OCR extracts the text, an AI step turns it into structured fields, missing fields and duplicates are caught, the file goes to Google Drive, the record to Google Sheets, and a confirmation comes back. A separate error-handler workflow reports failures.

n8n workflow: receive invoice image in Telegram, download, OCR, AI extraction with a structured parser, validate, notify on missing information, check and route duplicates, merge, upload to Drive, store in Sheets and send a confirmation.
Workflow. Validation and duplicate checks sit before anything is stored.

Stack: Telegram · OCR.space · OpenRouter (GPT-4o mini) · Google Drive · Google Sheets

Earlier build · Zapier

Zapier–Asana CRM Automation

  • Earlier build

An updated Asana task splits into five paths — ready to start, no response, quoted, approved, paid and closed — that create lead folders and sub-tasks, send timed Gmail follow-ups, and draft welcome and recommendation emails with AI.

Zapier editor showing the Asana trigger and five paths with Google Drive, Asana, Gmail, delay, filter and AI steps.
Zap structure. One trigger, five stage-specific paths.

Stack: Zapier · Asana · Google Drive · Gmail · AI by Zapier

Earlier build · Zapier

Zapier Lead Qualification & Outreach

  • Earlier build

A form submission is enriched with company data from Apollo, scored by AI and stored through Supabase's REST API, then routed by priority: high and medium leads get a drafted outreach or nurturing email and a Slack alert; low leads get a summary in Slack.

Zapier editor: form trigger, Apollo lookup, AI lead score, Supabase webhook, then high, medium and low priority paths with AI emails, Gmail and Slack.
Zap structure. Enrichment and scoring, then three priority paths.

Stack: Zapier · Apollo API · AI by Zapier · Supabase REST · Gmail · Slack

Earlier build · Zapier

Zapier Content Repurposing

  • Earlier build

An mp3 dropped into Google Drive is transcribed, turned into two blog drafts and Facebook and LinkedIn posts, then routed by an AI approval step to publish or to a “needs review” path saved in Google Docs — with every stage logged in Google Sheets.

Zapier editor: Drive trigger, mp3 filter, transcription and drafting steps, then publish-to-Facebook, publish-to-LinkedIn and need-review paths.
Zap structure. Transcribe, draft, then publish or hold for review.

Stack: Zapier · Google Drive · AI by Zapier · Google Sheets · Google Docs · Facebook Pages · LinkedIn

Earlier build · GoHighLevel

Car Insurance Sales Workflows

  • Earlier build

A set of GoHighLevel workflows for a car-insurance sales process. The first takes a new or tagged contact, creates an opportunity, tags it, sends the insurance intake form, assigns an available agent and notifies the team.

GoHighLevel workflow: contact tag or new contact, waits, create opportunity, add tag, send intake form email, assign to user, internal notification.
CI 01. New contact to assigned agent.

Stack: GoHighLevel workflows · email

Earlier build · GoHighLevel

Salon Client Retention Pipeline

  • Earlier build

GoHighLevel workflows for a salon. New-lead intake turns an inquiry form into an opportunity with a tag, a welcome email, a front-desk notification, a note and a “contact within 1 hour” task.

GoHighLevel workflow: salon inquiry form, waits, create opportunity, add tag, welcome email, internal notification, add note, add task.
SLA 01. New lead intake.

Stack: GoHighLevel workflows · email

Earlier build · GoHighLevel

Lead Nurturing Pipeline

  • Earlier build

GoHighLevel workflows that move a lead through tagged stages. When the appointment form is submitted, the “new lead” and “nurturing” tags are removed and “booked” is added.

GoHighLevel workflow: booked-appointment form submitted, waits, remove new lead tag, remove nurturing tag, add booked tag.
GBA 02. Appointment form to booked stage.

Stack: GoHighLevel workflows · forms

Background · Team thesis

Rebar Vista — Deep Learning-Based Rebar Column Measurement System

A Raspberry Pi 5 with a camera and distance sensor photographs a rebar column; a Mask R-CNN model — chosen after evaluating YOLOv8 and RetinaNet — detects it, the system computes its dimensions and concrete volume, and a web app recommends the cement mixture.

My role

  1. Deep-learning model
  2. Web application
  3. Raspberry Pi deployment

I started as the deep-learning model developer, was reassigned to web-application development in the final phase, and integrated the move from a laptop-hosted web app to a Raspberry Pi deployment.

96.3%System test success rate: 77 of 80 trials within a ±5% tolerance
4.54 / 5Average evaluator rating (two evaluators, five-point scale)

Trials covered rebar-column detection (19/20), non-rebar detection (20/20), dimension and volume computation (19/20) and cement-mixture estimation (19/20).

Rebar Vista camera screen showing a rebar column with a distance reading of 202 cm marked optimal.
Capture with live distance check
Analysis result: rebar dimensions and volume, 1:2:4 cement ratio, wet volume, cement, sand and gravel quantities and water requirement.
Volume and mixture result
'No Rebar Detected' message listing detection requirements: visible rebar, good lighting and a 196–204 cm distance.
Non-rebar input rejected

Stack: Python · Mask R-CNN · OpenCV · Flask · Raspberry Pi 5

Background · Internship · Quezon City Public Library

Employee Daily Time Record System

A web application that replaced manual attendance records: employee time-in and time-out, attendance history, an admin dashboard with search and filters, and attendance reports.

Stack: PHP · MySQL · JavaScript · HTML/CSS