Download Official PDF↓

Benjamin Stone

AI Transformation & Operations Leader | Agentic Systems | Business Automation Architect

Lehi, UT•benstone2038@gmail.com•385-225-1199•linkedin.com/in/benjamin-stone-lehi•benstone.org•View Verified Work ->

AI Transformation Leader and systems architect combining hands-on experience designing and operating production agentic systems, multi-agent escrow marketplaces, and cryptographic verification with a decade of Controller-level financial systems leadership.

AI Systems Architect -> Agent Infrastructure -> Verification -> Automation -> Operations -> Financial Controls

Focus Areas (Finance Transformation)

  1. Finance Systems, Controls & Audit-Ready Verification
  2. SwarmSync.ai — Multi-Agent Marketplace

Selected Work & Verifiable Claims

  • Engineered InvoiceProof, AuditProof, VerifyAPI, and Conduit/Halo controls — a verification stack using hash-chained logs, cryptographic proofs, and approval gates to produce independently auditable action records for automated financial and agent-driven actions.[FOS-001]
  • Served as Controller for a multi-million-dollar business (~50 staff) for 10 years, directing full-cycle accounting (GL, AP/AR, inventory, cash, payroll, sales tax, vendor processes) and re-engineering the close process to consistently deliver a 3-day month-end close.[FOS-002]
  • Architected PilotCPA (formerly PacketOS), a desktop tax-workpaper automation app for SMB owners and bookkeepers, around a safety-first architecture: an LLM proposes, code computes, a human can approve, and an append-only, hash-chained audit log records every action — with a hard, test-enforced invariant that the system never files, signs, submits, transmits, or pays anything.[PKT-001]
← Back to Verified Systems
Run Interactive Demo →Proof Ledger →
Executive Operator Brief • Architecture & Verification

Turning Multi-Entity Finance Operations into an AI-Operated System

Business Problem

  • Manual month-end close and AP/AR/inventory/payroll processes consumed excess time and lacked standardized controls
  • Automated financial and agent-driven actions lacked an independently auditable record
  • No standardized way to prove an automated decision was authorized and unaltered after the fact

Constraints

  • Automated financial and agent-driven actions needed to be independently auditable without slowing the finance team down.
  • Consequential actions (payments, GL postings) could not be allowed to execute without a human approval step — a wrong automated action in finance is expensive and hard to unwind.
  • The system had to operate across already-fragmented business systems, accounting systems, and reporting tools rather than replacing them outright.

Decision

I architected the governed FinanceOS operating layer, including Cato orchestration, specialist-agent routing, approval controls, and the cryptographic verification stack (InvoiceProof, AuditProof, VerifyAPI) — ensuring every automated financial decision is independently auditable with human approval gates.

Alternatives Rejected

  • One large general-purpose AI model handling the entire finance process end to end. — Harder to audit, harder to correct when it is wrong in one narrow area, and does not map to how finance teams already divide responsibility (AP, AR, close, treasury).
  • Traditional single-task automation (e.g. one RPA script per workflow). — Solves individual tasks but does not create a coordinated operating layer across the whole finance function, so the underlying fragmentation problem remains.
  • Fully autonomous execution with no human approval step. — Consequential financial actions carry too much downside risk to run unsupervised; the design keeps a human approval gate for anything beyond preparation and drafting.

System

  1. Business Systems
  2. FinanceOS Data/Knowledge Layer
  3. Cato Orchestration
  4. Genesis Specialist Agents
  5. Controlled Output / Human Approval / Audit

What Ben Personally Did

Designed
  • The five-layer architecture: Business Systems -> FinanceOS Data/Knowledge Layer -> Cato Orchestration -> Genesis Specialist Agents -> Controlled Output/Human Approval/Audit.
  • The hash-chained, cryptographic audit-trail approach (InvoiceProof, AuditProof, VerifyAPI, Conduit-Halo) so any automated action stays independently checkable after the fact.
Decided
  • That consequential actions require an explicit human approval gate rather than full autonomy.
  • That specialist agents (Genesis) should be scoped narrowly per finance function (AP, AR, close, treasury) instead of one general-purpose model.
Configured
  • Approval-gate thresholds and routing rules connecting Cato's orchestration layer to the underlying accounting structure.
Coded
  • The verification stack itself — InvoiceProof, AuditProof, VerifyAPI, and Conduit-Halo — including the hash-chaining and cryptographic proof logic.
Tested
  • Verified that tampering with a logged action after the fact is independently detectable via the hash chain.
Operated
  • Ran the underlying finance operation this architecture generalizes from directly, as Controller of a ~50-person, multi-million-dollar business for 10 years (Bella Lash Extensions, 11/2011-11/2021), including full-cycle accounting and a 3-day month-end close.

Result

  • Gave automated finance and agent-driven actions an independently auditable, tamper-evident record instead of an unverifiable log line.[FOS-001]
  • Consistently delivered financial statements, reconciliations, accruals, and supporting schedules within a 3-day close window for a ~50-person, multi-million-dollar organization.[FOS-002]

Evidence

  • [FOS-001-EV1] DOCUMENT: Internal repository/documentation for the InvoiceProof/AuditProof/VerifyAPI/Conduit-Halo verification stack (access restricted; architecture described in the operator brief) — no independent public artifact yet
  • [FOS-002-EV1] DOCUMENT: Professional employment history — Controller, Bella Lash Extensions, Vineyard, UT (11/2011-11/2021), as stated on Benjamin Stone's resume; no independent third-party artifact available

What Failed or Remains Incomplete

  • The InvoiceProof/AuditProof/VerifyAPI/Conduit-Halo verification stack has no independent, third-party-hosted evidence artifact yet — it is SELF_REPORTED with only an internal, access-restricted document as evidence, not a public URL or repo a reader can check directly. A public reference implementation or third-party audit is the remaining gap.
← Back to Verified Systems
Visit SwarmSync.ai ↗Proof Ledger →
Executive Operator Brief • Architecture & Verification

Building Trust Infrastructure for Autonomous AI Systems

Business Problem

  • No standard way for AI agents to autonomously discover each other, negotiate, and settle payment with trust and accountability
  • Agent-driven marketplaces lacked the reputation and governance controls needed for production use

Constraints

  • Autonomous agents needed a way to prove identity and authorization before a transaction, not just after the fact.
  • The marketplace had to run under production governance controls, not exist only as a research prototype.
  • Verification and audit records needed to be portable and checkable by parties outside SwarmSync itself, not just an internal log line.

Decision

I architected SwarmSync.ai end to end as the trust and transaction infrastructure for autonomous AI agents, designing the multi-agent negotiation engine, escrow settlement rail, and SwarmScore reputation verification protocol under production governance.

Alternatives Rejected

  • A plain agent marketplace with no built-in identity/authorization or verification layer. — Leaves businesses with no way to know whether an agent's output can be trusted or whether money/data should actually be released — the core problem the marketplace exists to solve.
  • Centralized manual review of every agent transaction. — Does not scale to an autonomous, agent-to-agent marketplace and reintroduces the human bottleneck the system is meant to remove.
  • Relying on proprietary, single-vendor protocols instead of open standards. — Would fragment the agent ecosystem instead of letting different vendors' agents interoperate — the reason this work also produced open IETF drafts and W3C AIVS participation.

System

  1. Agent performs action
  2. Identity/authorization checked
  3. Evidence generated
  4. Verification performed
  5. Approval/transaction decision
  6. Proof receipt/audit record

What Ben Personally Did

Designed
  • The end-to-end trust/transaction flow: agent action -> identity/authorization check -> evidence generation -> verification -> approval/transaction decision -> proof receipt.
  • ProofRail as the governed transaction rail underneath the marketplace, recording what happened, why it was permitted, what provider responded, and what proof exists afterward.
Decided
  • To require identity/authorization checks and evidence generation before any transaction is allowed to settle.
  • To pursue open standards (IETF, W3C) alongside the product so the trust model is not locked to one vendor.
Coded
  • The discovery, negotiation, escrow-settlement, and reputation-scoring logic underlying the live marketplace at swarmsync.ai.
Tested
  • Verified the marketplace's discovery, negotiation, escrow, and reputation-scoring flows in production at swarmsync.ai.
Operated
  • Runs and maintains the live marketplace at swarmsync.ai.

Result

  • Delivered a live, publicly reachable multi-agent marketplace at swarmsync.ai covering discovery, negotiation, escrow, and reputation scoring.[SS-001]

Evidence

  • [SS-001-EV1] PUBLIC_URL: https://swarmsync.ai (production deployment demonstrating the multi-agent marketplace: discovery, negotiation, escrow, and reputation scoring)

What Failed or Remains Incomplete

  • No independent, formal third-party security audit or penetration test of the marketplace has been published yet — production usage and the public deployment at swarmsync.ai are the evidence available today, not an external audit report.
← Back to Verified Systems
ConduitScore.com ↗Proof Ledger →
Executive Operator Brief • Architecture & Verification

Taking an AI Verification Product from Architecture to a Running Commercial System

Business Problem

  • No single desktop environment let a user orchestrate multiple AI models and tools together
  • Organizations had no standardized way to assess their AI readiness before investing in automation

Constraints

  • Needed to prove instructions, meaning, and behavior survive across different models, agents, and transformations — not just work once on one model.
  • Had to turn a technical verification concept into something a non-technical buyer could actually act on (a score and a plan), not just a research finding.
  • Two different delivery shapes were needed at once: a desktop AI operating environment (Cato) and a public, self-serve SaaS diagnostic (ConduitScore.com).

Decision

I architected and shipped two connected production AI platforms: Cato, a desktop operating environment coordinating multi-model LLM orchestration and MCP tool calling, and ConduitScore.com, an automated public SaaS diagnostic scanning enterprise AI readiness with signed scores and prioritized remediation.

Alternatives Rejected

  • Keep the verification/scoring logic as an internal tool only. — Would prove the technical concept but not that it ships as a commercial product a customer can actually buy and use — the goal was to prove product delivery, not just internal automation.
  • Build Cato as a single-model tool instead of multi-model orchestration. — Users needed to coordinate multiple AI models and tools from one place instead of juggling a separate app per model, which a single-model tool cannot do.
  • A one-time manual AI-readiness assessment delivered as a consulting report. — Does not scale, is not repeatable, and cannot produce a consistent signed/verifiable score the way an automated scan-analyze-score pipeline can.

System

  1. Scan
  2. Analyze
  3. Score
  4. Signed/Verifiable Result
  5. Recommended Fix
  6. Commercial Action

What Ben Personally Did

Designed
  • The Scan -> Analyze -> Score -> Signed/Verifiable Result -> Recommended Fix -> Commercial Action loop that ConduitScore.com runs.
  • Cato's multi-model orchestration and tool-calling architecture.
Decided
  • To ship ConduitScore.com as a public, self-serve SaaS product rather than a bespoke internal assessment.
Coded
  • Cato's orchestration and tool-calling engine and the ConduitScore.com diagnostic scoring pipeline.
Tested
  • Verified ConduitScore.com's scan/analyze/score pipeline against real organizational inputs before public launch.
Operated
  • Runs ConduitScore.com as a live, publicly reachable SaaS product today.

Result

  • Delivered Cato as a working desktop AI operating system with multi-model orchestration and tool calling.[CS-001]
  • Delivered a publicly accessible AI-readiness diagnostic and remediation SaaS product at conduitscore.com.[CS-002]

Evidence

  • [CS-001-EV1] DOCUMENT: Internal product documentation/repository for Cato (desktop AI OS) — access restricted; no independent public artifact yet
  • [CS-002-EV1] PUBLIC_URL: https://conduitscore.com (live AI-readiness diagnostic and remediation SaaS platform)

What Failed or Remains Incomplete

  • Cato remains SELF_REPORTED with only an internal, access-restricted document as evidence — no public artifact exists yet. ConduitScore.com is live and publicly reachable, but no usage or conversion metric for it has been added to career-proof.json yet, so no quantified commercial result can be shown here until that data exists and clears the safe_to_publish gate.