Agentic HITL Flywheel

Executive summary

Trinity's acquisition product is the demo surface. The reusable primitive underneath is an Agentic Human-in-the-Loop Flywheel: Phoenix/BEAM owns authority, Postgres owns truth, Oban makes work durable, LiveView/PubSub makes state visible, Hermes proposes work, Jido blocks unsafe or unreleased context, NVIDIA/Nemotron adds structured model review, ToolRouter executes only approved external effects, and proof packets make the resulting operation inspectable.

This page is written for AI security reviewers evaluating whether an agent can reason, learn, and operate without becoming the authority layer. The answer in Trinity is deliberately asymmetric: agents can propose plans, drafts, skills, and action intents; Phoenix contexts, database constraints, policy modules, approval records, and ToolRouter decide what can persist or execute.

Short version

Why normal HITL is not enough

Basic HITL usually means "show a human a draft before sending." That is insufficient for agentic systems because the danger is not only the final send. Risk enters through retrieved documents, inbound email, attachments, skill memory, tool payloads, model outputs, payment links, account scope, and cross-tenant reuse.

Full flywheel

User intent
-> Phoenix project workspace
-> Scoped context pack
-> Hermes plan or action intent
-> Jido/content-firewall and provenance checks
-> Deterministic policy review
-> NVIDIA/Nemotron risk, safety, scoring, or QA review where useful
-> Human edit or approval
-> ToolRouter execution
-> Postgres audit, ledger, RunEvent, ToolCall, ModelDecision, and proof-packet records
-> Hermes memory or skill update

Control plane and durable truth

The BEAM matters because agent operations are concurrent, interruptible, and failure-prone. LiveViews can keep operators in the loop while workers retry, supervisors restart processes, and Postgres remains the durable authority.

Hermes role

Hermes proposes, plans, drafts, reasons over released context, and learns reusable skills. Trinity wraps that work in project/account scope. Hermes does not receive raw secrets, OAuth tokens, unreleased inbound content, or authority to approve high-risk actions.

See Hermes Integration and Vendor map .

Jido and content firewall role

Jido is intentionally narrow. It is not the business authority layer. Trinity uses it as a typed action seam for content and provenance checks before hosted Hermes receives payloads that may include references to documents, email, or attachments.

This creates a human-governed content release boundary for indirect prompt injection defense: inbound content can exist in the system, but Hermes should see only metadata or explicitly released content refs until a human releases it.

See Jido , Security governance , and Documents and artifacts .

NVIDIA and Nemotron role

NVIDIA/Nemotron is used for structured review, not invisible authority. ModelRouter chooses official NVIDIA routes by default, keeps fallback aggregators disabled unless explicitly enabled, sanitizes payloads, stores hashes, and records ModelDecision evidence.

See NVIDIA , ModelRouter , and AI governance posture .

ToolRouter role

ToolRouter is the audited side-effect membrane. External effects should pass through AutonomousAgency.Tools.ToolRouter or an explicitly equivalent audited boundary. The router resolves account scope, enforces idempotency, runs policy modules, records denials, executes adapters, creates ToolCall rows, links model decisions where applicable, and appends audit/sandbox proof.

See ToolRouter and Live action gates .

Human approval role

Humans are not a decorative checkbox. The approval system is durable, account-scoped, append-only at the event layer, and tied to role permissions. ApprovalRequest records the action type, provider, operation, resource, amount, currency, risk summary, idempotency key, linked run/tool/model records, and decision user. ApprovalEvent records requested, approved, rejected, or expired transitions with unique idempotency.

See Approvals and Security governance .

Gmail, inbound quarantine, and draft gates

Gmail is account-connected and project-selected. The platform owns one Google OAuth app, each account connects its own mailbox, each project selects an approved account alias, and OAuth tokens stay behind vault refs.

See Gmail outreach and Security governance .

Proof and audit chain

Proof packets turn the flywheel into an inspectable graph. Governance.ProofPacket.for_run/1 gathers run events, state snapshots, sandbox checks, tool calls, model decisions, approvals, approval events, audit events, skills, chat messages, action intents, revenue events, orders, order intakes, deliverables, CRM records, email drafts, artifacts, and documents. Missing proof is reported as degraded; it is not fabricated.

See Audit ledger and Data flow .

Example: snapshot request to proof packet

This is not a hardcoded sales funnel. TrinitySales is a read-only capability contract. The live work remains available to Hermes through scoped project context, approvals, ToolRouter, Stripe, Gmail, CRM, and proof primitives.

Implemented vs planned/future posture

What this is not

• Not a generic approval button.
• Not a chatbot with direct tool access.
• Not a replacement for deterministic policy.
• Not a claim that models are authority.
• Not a claim that every runtime is already fully sandbox-enforced.
• Not a system that exposes raw secrets, raw emails, hidden reasoning, or unreleased content to the agent.

Why this generalizes beyond acquisition

The acquisition workflow exercises the hard parts: untrusted inbound content, CRM state, payment, outbound email, model review, human approval, provider tools, generated deliverables, skill reuse, and proof. The same flywheel can govern customer support, security triage, procurement, finance ops, research workflows, compliance review, and enterprise back-office agents because the reusable primitive is not "sales automation." It is scoped intent -> reviewed plan -> typed policy -> human authority -> audited execution -> durable memory.

Open-source extraction path

The full Trinity product is a commercial acquisition system, but the reusable primitive can be extracted as an open-source reference architecture: action intents, approval records, policy decisions, ToolRouter interfaces, content-firewall checks, proof-event schemas, and sample adapters.

Public-safety disclosure

This page is public-safe. It names modules, routes, schemas, and architecture boundaries without exposing credential values, OAuth tokens, private customer data, unreleased inbound content, raw model context, or hidden reasoning. Model and tool records store structured summaries, hashes, routes, risk labels, idempotency keys, and proof links rather than private payload dumps.

Internal reading path

• Architecture
• Technology stack reference
• Hermes Integration
• Jido
• NVIDIA
• Stripe
• ToolRouter
• Approvals
• Security governance
• Live action gates
• Gmail outreach
• Documents and artifacts
• Data flow