governed execution

Automations

Duvo's published function coverage names finance (freight audit and reconciliation, trade deductions and claims, invoice checking), supply chain (chasing suppliers, out-of-stocks, inventory balancing), planning/merch, and ecom/DTC. The tools below were built directly against that list, with policy gates and human-approval checkpoints the agent cannot bypass built in at the tool layer — not bolted on after.

From the record. The ingest → process → report loop on this page was a working practice first: operational data flowed into an Airtable working layer automatically for processing, and once processed, automated column summaries emailed out the report draft — weekly visibility that ran itself. Automation carried the data and the reporting; the decisions in the middle stayed human — the same division of labor the staged-write gate below encodes.

retail_ops — ten tools, mapped to Duvo's function list

A buyer-side retail/CPG supply-chain-ops agent: reconciling three-way matches, disposing exceptions, chasing suppliers, validating deductions, and computing delivery KPIs.

Tool	Duvo function coverage	What it does
`lookup_policy`	the read layer	retrieves the governing policy clause for a case — decisions cite policy, not vibes
`get_records`	the read layer	pulls POs, receipts, invoices, ASNs from the corpus — the evidence every scored call draws on
`three_way_match`	Finance — invoice checking	PO ↔ goods-receipt ↔ invoice; qty/price/UOM/duplicate detection
`reconcile_deduction`	Finance — trade deductions and claims	validates a retailer chargeback against the record; posts or disputes
`chase_ladder_step`	Supply chain — chasing suppliers	the correct next dunning step (soft/firm/escalation) or stop-signal
`otif_fill_rate`	Supply chain — inventory balancing / out-of-stocks	on-time-in-full and fill rate, per-PO and per-supplier
`classify_exception`	cross-function exception handling	auto_close / hold_approval / escalate / dispute
`normalize_uom`	cross-function data integrity	pack-hierarchy conversion; explicit Ambiguous over a silent wrong number
`audit_completeness`	governance	mandatory audit-trail fields present
`approval_gate_check`	governance (hard gate)	fails the case if a must-approve action is auto-executed

approval_gate_check is a hard gate, not a scored dimension: it fails outright the moment the agent proposes to auto-execute an action policy requires a human to approve — auto-pay a mismatched invoice, auto-close a must-review exception, issue a credit or debit note, post a deduction, write off above threshold, cancel a PO, accept-and-bill an over-ship. 34 cases across 8 metrics, reproduces keyless: uv run agentic-eval eval --domain retail_ops --backend replay → 34/34, every metric 1.00.

The connector layer — retail-ops-mcp-kit

Four FastMCP servers, one per enterprise-system class a retail/CPG ops agent integrates — ERP, supplier network, email, spreadsheet — each modeling a real named SaaS dialect on the wire (SAP S/4HANA, NetSuite, and Dynamics 365 for ERP; SPS Commerce, Coupa, and Ariba for the supplier network; Microsoft Graph and Gmail for email; Google Sheets and Graph Excel for the worksheet), selectable by environment variable, over one shared synthetic corpus. The tool signature is identical across every dialect a server models — only the wire envelope changes.

Every mutation is a staged write

A write tool validates its payload against the corpus, stages it, and returns a pending_approval record with an approval_id. Nothing executes at stage time.

Approval needs a token the agent cannot hold

approve(approval_id, token) checks against a human-approval token that lives only in the server environment, compared with hmac.compare_digest — never a tool return, never in the corpus, never a default. Absent a configured token, approval fails closed.

Auto-execution is impossible by construction

Not a policy the agent is asked to respect — a structural gap it has no channel to cross. A fingerprint invariant (sha256 over the corpus) makes this testable: byte-identical before staging, after staging, and after a full approve+execute.

Shared across all four servers

approve, list_pending_approvals, get_approval_status, and an active_system() tell — one governance surface regardless of which SaaS dialect is wired. 25 tests.

browser_ops — the portal path

Not every enterprise system exposes an API; a supplier portal often means a browser. browser_ops is a reliability domain gated on the three properties a portal-automation agent has to hold: it must not re-submit a completed action (idempotency), it must recognize when a workflow is actually done (stop-condition), and a retry after a transient failure must not double-execute (retry-safety). 24 cases across 4 metrics, 8 hard gates, reproduces keyless: uv run agentic-eval eval --domain browser_ops --backend replay → 24/24.