Distinguished Architect, owner from discovery through handoff · 2025 In production

Procurement Decision Automation Platform

A deterministic-first procurement automation platform for a precious metals retailer, automating reorder decisions across four metals and five sales channels with AI constrained strictly to an advisory role.

Problem

A leading precious metals retailer's procurement relied on manual replenishment decisions across gold, silver, platinum, and palladium, spanning five sales channels. The process was slow, inconsistent, and produced no audit trail for decisions touching high-value inventory.

Contribution

Architected and delivered the platform end to end as technical lead for the QBrainX Phase 1 engagement. The defining design choice was glass-box, deterministic-first: all procurement quantities are produced by auditable rules-based math. AI (Amazon Bedrock running Qwen3-32B) is constrained to advisory and narrative output and is never permitted to emit a purchase quantity. That guardrail is enforced in code as a non-retryable error. Built a reusable primitives library on n8n Enterprise (Queue Mode) that abstracts connection management, error handling, and S3 I/O away from business workflows. The deterministic engine itself handles large-order exclusion, low-velocity gating, promotional adjustments, and per-metal thresholds. Owned seven deliverables across four payment gates: standards and AI guardrails pack, primitives library, business-rules engine, AI reasoning and validation layer, operations readiness, production setup, and full knowledge-transfer handover.

Outcome

In production since July 2026, run every Monday across about 21,000 products and operated by the customer. Measured in the 14-day shadow run: deterministic results matched the reference logic 100% after fixes in the first three days, and each of five specialists' weekly time on the workflow fell from about 40 hours to about 8. The VP of Procurement called it the first AI implementation in his unit to deliver real value. The engagement grew into a three-phase AI adoption strategy for the retailer and its sister brands.

n8n EnterpriseAmazon BedrockEKSTerraformAurora PostgreSQLElastiCache RedisAmazon S3KEDAAWS Secrets ManagerCloudWatchRedshiftMySQLDocker

It started in a two-day executive workshop in September 2025. Four candidate use cases were scored from 1 to 5 on business value, technical feasibility, time to value, autonomy potential, and risk. Procurement scored 21 of 25 and won because its data and APIs already existed, an SOP defined the inputs and outputs, and the agent needed no personal data. The customer’s earlier RAG chatbot had failed, so the first use case had to earn trust.

The POC hypothesis was that an LLM agent driven by the SOP could turn weekly Excel exports into restocking recommendations the team would accept. It failed for numbers: about 90% of records mismatched the Excel reference and prompt tuning never closed the gap. I turned the model off for calculations and proposed the two-route design, then spent five days walking the embedded procurement specialist through each deterministic module against the macro logic it replaced. The design did not change after that. What changed was that they could see inside it.

The production SOW I wrote carried the acceptance gates: full SKU coverage in the batch window, deterministic accuracy of at least 99.5% against the reference (the clean-data ceiling, since about 100 of 21,000 records carry legacy data errors), AI schema validity of 97% first pass and 99.5% after repair, a failure-and-replay drill, and 14 days of shadow operation. A three-person offshore team built the production workflows on the standards pack and primitives library.

The core architectural bet was that AI has no business owning a purchase quantity in a high-stakes financial workflow. The glass-box design enforces this in code rather than in policy: the LLM layer receives context and produces reasoning and narrative, but if it attempts to return a quantity, the system raises a non-retryable error. That boundary is what makes the platform auditable and trustworthy to a finance team, not just technically impressive.

The primitives library was the quiet enabler. Every workflow node in n8n that touches infrastructure goes through a shared abstraction: connection logic, retry behaviour, error taxonomy, and S3 I/O are encapsulated once and reused everywhere. Business-logic workflows never manage infrastructure directly. This was the decision that made the seven-deliverable scope achievable without the codebase becoming a maintenance problem on handover.

The no-static-credentials principle was non-negotiable from day one. Production runs on EKS with IRSA for pod-level AWS access; dev and staging run on EC2 with instance profiles. AWS Secrets Manager with External Secrets Operator handles secret rotation. The Terraform repo is modular across environments so the same infrastructure definition covers all three tiers with environment-specific overrides.

KEDA autoscaling on the n8n worker tier means the platform handles order-volume spikes without manual intervention. The queue-mode architecture separates workflow execution from the n8n main process, keeping the control plane stable under load.