Autonomous Agent · Procurement & Freight Operations

A procurement team member that runs itself.

Not a chatbot. Not a macro. A fully autonomous agent that owns the purchase-order lifecycle end to end — drafting POs, booking freight, filing documents, chasing ETAs — across Zoho, CH Robinson, and a stack of live business systems, on a schedule, from anywhere, while healing and improving itself.

Zoho Inventory Baserow Google Sheets Google Drive Gmail CH Robinson
Harness Claude Code / Codex · cron · runs anywhere Tools chr-cli · Zoho · Baserow · Sheets · scripts Skills 12 procedures the agent runs by intent Database Baserow + Sheets · production · errors · logs one coherent autonomous operator
12
specialized skills across the full PO & freight surface
14
Baserow tables — every PO, line, quote & run logged
daily autonomous runs — inbox, drift audit, freight sync
All
failures trapped & escalated — logged, fingerprinted, healed
The premise

It does the job of a procurement coordinator.

Everything a human in this seat does daily — creating POs, booking freight, filing docs, reconciling systems — turned into deterministic, auditable, around-the-clock automation.

A HUMAN COORDINATOR DOES… …THE AGENT DOES IT AUTONOMOUSLY Re-key supplier orders into the PO system Parses the PDF, builds & writes the PO in seconds Email carriers, compare freight quotes by hand Quotes every carrier, ranks by cost · speed · coverage Dig through the inbox for invoices & tracking Reads every email, files docs, extracts ETAs by LLM Manually reconcile three systems for drift Audits Baserow ↔ Sheets ↔ Zoho nightly, flags drift

The human stays in the loop where it matters. The agent drafts, never sends blind. POs are created as DRAFT, freight is never booked, and emails are never sent without explicit approval. It does 95% of the work and asks for a signature on the 5% that carries money or risk.

System architecture · how I build every agent

Four layers: harness, tools, skills, database.

Every autonomous agent I ship is the same four-part stack. The harness gives it a body and a clock; tools give it hands; skills give it know-how; the database gives it memory — and a permanent record of every action, error, and run.

① HARNESS — the body + the clock Claude Code / Codex repo = working dir cron / launchd inbound email operator chat supplier PDF ② TOOLS — the hands chr-cliCH Robinson LTL portal Zoho Inventory APIPO of record + PDF BaserowREST API Sheets / Drivetracker + docs Gmail APIpurchasing@ scripts/lib — po_builder · po_writer · quality_gate · eta_calculator ③ SKILLS — the know-how PO lifecycle · revision blanket PO · release intake · freight booking quoting · monitoring each skill = a self-contained, tested SKILL.md playbook ④ DATABASE — the memory + the black box PRODUCTION · POs · lines · vendors · items RUNTIME · Activity Log · write-outcomes ERRORS · error-registry · drift audit
Every skill the harness invokes drives tools and writes its result — and any failure — to the database

The procurement signature: dual-write. Baserow is the source of truth, but every status change fans out to Google Sheets — and where relevant Zoho, Drive, and Gmail — in one atomic pass, then verifies it landed. No system is ever left half-updated, so the three records can't silently drift apart.

Core flow · purchase order lifecycle

From draft to delivered — tracked at every step.

The agent shepherds a PO through a strict, verifiable status flow. Status only advances on high-confidence signals — a tracking number is verified on the carrier's own site, never inferred from an email subject line.

DRAFT created · awaiting approval ON PROCESS issued · supplier producing IN TRANSIT tracking # verified on carrier site DELIVERED confirmed on tracking · STOP CHECKED IN warehouse app only — agent never touches operator approves ↓ shipping email ↓ carrier confirm ↓ zoho-po-lifecycle inbox · update-eta chr-shipping / sync Every transition dual-writes to Baserow + Sheets, both header & line-item level when ALL lines on a PO reach DELIVERED → the PO header flips to DELIVERED automatically

🔒 Confidence-gated

Status never advances on a guess. DELIVERED requires verification on the carrier's tracking site — a "carrier arrived" email may mean pickup, not delivery.

↕ Two levels, one truth

Line-item and PO-header status stay in lock-step. Change a line, the header recomputes. No half-updated POs.

📅 Self-correcting ETAs

An open PO can never have an arrival date in the past — the agent pushes it forward until the order actually lands.

Spotlight · the chr-cli tool

A purpose-built robot for the freight portal.

CH Robinson has no usable API for what we need — so the agent drives the real Navisphere web portal through a browser. chr-cli is a first-class command-line tool (Python + Playwright) that logs in once through Okta, quotes every carrier, books the load, and pulls the paperwork.

Supplier says "ready for pickup" → freight booked & documented PARSEpickup addr · dimsweight · lot # chr quoteall carriers, livevia headless browser RECOMMENDrank: coverage ≥80%cost ≤$3/kg · speed APPROVALoperator confirms— only cost gate chr create-orderbooks the loadreturns tracking # chr order-docsBOL + pallet labels→ Drive folder UPDATE + NOTIFYBaserow · Sheets → IN TRANSITdraft supplier email A daily chr sync job refreshes every in-transit ETA from the portal and flags missed pickups — unattended.

The command surface

chr ordersdashboard of every open / in-transit load
chr quotelive multi-carrier quote + recommendation
chr create-orderbook a load — gated behind explicit approval
chr trackquick PRO# / tracking lookup
chr syncrefresh in-transit ETAs into Baserow + Sheets
chr order-docsdownload BOL + pallet labels
chr health-checkvalidates portal selectors before they break

Why this is hard — and impressive

Most "integrations" need a clean API. This one doesn't have one. The agent operates the same web UI a human uses — surviving Okta SSO, session expiry, and silent portal redesigns.

A dedicated health-check probes the portal's form selectors on a schedule, so when CHR ships a UI change, the agent reports the breakage before a booking ever fails — not after.

PlaywrightOkta SSOsession cache
Layer ③ · the skill library

Twelve specialized skills. One coherent operator.

Each skill is a self-contained, tested SKILL.md the agent invokes by intent. They auto-load from the repo, so the same skills run identically whether a human asks in chat or a cron job fires at 7 a.m.

PO creation & lifecycle

zoho-po-lifecycle

Creates a regular PO across Sheets, Baserow & Zoho. Add → draft → issue on approval → status → Drive folder.

PO creation

zoho-blanket-po

Stands up a volume-commitment blanket PO with a locally-generated PDF, tracked in Baserow + Sheets + Drive.

commitments

zoho-blanket-po-release

Draws down quantity against an existing blanket commitment as a release order.

commitments

po-revision

Safely revises an open Zoho PO: edit → re-issue → archive the prior version.

PO edits
Intake & freight

supplier-order-intake

Auto-converts Container & Packaging Sales Orders and Yason Pack Proformas into full draft POs.

intake

chr-shipping

End-to-end LTL freight: parse pickup email → quote carriers → recommend → book → file BOL/labels → notify.

freight

material-research

Pre-PO briefing: full PO history, sample-tracker status, every quote on file, and a recommended action.

research
Quoting & communication

email-quote-extraction

LLM-extracts raw-material quotes from any email format and logs them to SA Material Quotes (745).

quoting

email-packaging-quote-extraction

Same for packaging — pouches, scoops, containers, poly bags — into SA Packaging Quotes (746).

quoting

email-response

Drafts on-brand HTML replies to live supplier threads and logs every interaction.

comms
Monitoring & unattended runs

procurement-inbox

The scheduled 2×/day sweep — files docs, extracts ETAs, drafts follow-ups, runs COA checks, auto-processes supplier orders.

cron

sourcing-inbox-monitor

Watches the sourcing inbox for inbound supplier inquiries and routes them to the right skill.

monitoring
Unattended operation · the inbox monitor

It works the inbox while you sleep.

Twice a day, a single scheduled run executes five independent tasks under a strict time budget. Each task is isolated — if one fails, the others still finish — and each checkpoints its progress so an interrupted run resumes exactly where it left off.

SCHEDULED 7:00 AM & 2:00 PM · total budget ~540s · per-task slice + yield 1 file-docs invoices · COAs · BOLs → per-PO Drive folder → update Sheets docs cols runs COA compliance inline 2 update-eta 3-layer pre-filter LLM extracts ETA + conf. writes only if ≥0.85 else → flag for review 3 followup finds POs idle ≥7 days drafts supplier nudge DRAFT only — never sends labeled for approval 4 coa-check flags COAs for spec review organic compliance gate updates Baserow status needs-review on fail 5 supplier-intake C&P SOs · Yason PIs parse → build → validate → full draft PO + folder Zoho DRAFT · no email ⛨ Each task wrapped in escalation handler — a crash is recorded & isolated, the run continues · checkpoints survive timeouts Result of every run → JSONL log · per-task timing · Telegram summary to the operator
Layer ④ · the database — production, runtime & error logging

Nothing happens that isn't written down.

Baserow is the system of record. Every PO, line item, quote, and autonomous run lands in a table — and every failure lands in a structured error log. That's what makes the agent auditable, debuggable, and trustworthy enough to run unattended.

Three classes of data, each with a home — query any of them after the fact PRODUCTION DATA what the business runs on Purchase Orders · 687 PO Line Items · 688 Blanket POs · 689 · Payments · 725 Vendors · 686 · Items · 676 Sheets PO Tracker · Drive folders RUNTIME DATA what the agent did, and when Procurement Activity Log · 764 Supplier Interactions · 765 inbox-monitor-log.jsonl write-outcomes.jsonl — per-system checkpoints · per-task timing ERROR DATA what broke, and what was done error-registry.json — signatures ISSUES.md — novel-failure memory po-audit reports — drift detection schema-snapshot.json — field IDs escalation thresholds (3 / 5)
AGENTS.md mandates it: every supplier touch is logged, and every write outcome recorded — before the agent moves on

🗂 Source of truth

Baserow holds POs, line items, vendors, items & quotes behind one REST API — with field and option IDs loaded from a versioned schema-snapshot.json, never hardcoded.

🧾 Every write is reconstructable

Each multi-system write appends its outcome per (po, system) to write-outcomes.jsonl, so the nightly audit can spot any write that failed to land in one system.

🚨 Errors are first-class

Failures don't vanish into stdout — they're fingerprinted into error-registry.json with volatile IDs stripped, then matched and escalated on a strike count.

The differentiator · self-healing & self-improving

Every failure makes the agent permanently smarter.

This is the design principle I build into every agent I ship. A one-time failure is never just retried into the void — it is trapped, escalated to a human at the right moment, and converted into a durable fix the agent applies forever after. The system compounds.

The compounding loop — a failure becomes architecture 1 · DETECT error_registry traps it, normalizes the signature (row IDs → placeholders) 2 · ABSORB retry w/ exponential backoff on transient 5xx / 429 — fail fast on real bugs 3 · ESCALATE 3 fails → alert a human 5 fails → auto-skip the write, stop the bleeding 4 · CAPTURE root cause → durable docs: AGENTS.md gotchas, ISSUES, schema-snapshot, brain vault 5 · APPLY fix becomes a rule the agent reads on every run. never re-learned twice the next run starts smarter — the failure class can no longer recur Real example: a Baserow write bug failed for 25 consecutive runs, escalated, was root-caused, and fixed by switching to self-hosted field IDs — it has not recurred since.

🛡 Error registry

Failures are fingerprinted with volatile bits stripped out, so the same bug across different rows counts as one. Alerts a human at 3 strikes; auto-disables the failing write at 5 — no infinite silent retries.

DER-575

♻️ Smart retry

A shared retry layer wraps every API client. Transient 5xx / 429 / connection drops back off exponentially with jitter and honor Retry-After. Real 4xx bugs fail fast so they surface immediately.

DER-577

🎯 Confidence gates

LLM extractions carry a confidence score. Below threshold, the agent writes nothing and flags the email for a human. "When in doubt, don't change state" is enforced in code.

update-eta

🧭 Nightly drift audit

A read-only audit compares Baserow ↔ Sheets ↔ Zoho every morning and reports seven classes of drift — missing rows, status mismatches, past-due ETAs — straight to the operator.

po_audit · DER-576

💾 Checkpoint & resume

Long tasks persist a checkpoint after each item. A timeout or crash mid-run loses nothing — the next run picks up from the last processed message, not the start.

DER-580

📚 Compounding knowledge

Hard-won gotchas live in a single source-of-truth doc, a versioned schema snapshot, and a searchable brain vault. The agent reads them on every run — institutional memory that never leaves.

AGENTS.md · brain

Self-defending against the outside world, too. When CH Robinson silently redesigns its portal, a scheduled health-check catches the broken form selectors and reports it — before a real booking fails. The agent notices the ground shifting under it and raises its hand.

Portability · runs from anywhere

One command to stand it up. Then it runs itself.

The entire agent is portable. A single bootstrap script provisions a fresh machine and self-diagnoses every connection; OS-native schedulers keep it running unattended. No servers to babysit, no dashboard to watch.

bootstrap.sh --setup installs deps · builds CHR browser · syncs skills one command, fresh box bootstrap.sh --check 11 self-diagnostics: refresh tokens · ping every API · verify skills synced cron / launchd templated jobs install on Mac or Linux — pick the native scheduler unattended inbox 7am + 2pm audit 7:15am · CHR 7:30am Telegram keeps you posted Source-of-truth docs & skills are CI-enforced to never drift — what's deployed is always what's reviewed.
The takeaway

This is what an autonomous team member looks like.

It owns a real operational seat — a harness that runs anywhere, tools that drive Zoho, CH Robinson and the inbox, twelve skills, and a database that logs every PO, run, and error — with a human only signing off where it commits money or risk. It catches its own mistakes, escalates at the right moment, and gets permanently better every time something breaks.

I build agents this way on purpose: harness, tools, skills, and a logged database — resilient by design, self-healing by default, and compounding over time. Point me at any repetitive, multi-system role and I'll give you one that runs from anywhere.

Autonomous Self-healing Self-improving Fully logged Runs from anywhere
← Back to the full portfolio