Hi — I found Omniagent while looking at agent projects where customer-facing conversations, multimodal inputs, RAG answers, human-confirmed tool actions, or business-system handoffs may need evidence that survives outside the original runtime.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace Omniagent’s n8n workflows, WhatsApp records, MongoDB Atlas memory/RAG store, OpenAI responses, customer-owned tenancy, tool integrations, typed CONFIRM protocol, MCP repo-inspection server, or normal business-system logs. The receipt only proves a narrow claim:
a specific signer signed a specific claim, and the signed claim has not been altered.
Omniagent seemed relevant because it handles WhatsApp-first customer conversations across text, voice notes, images, PDFs, and spreadsheets; answers from a business’s own knowledge base; remembers conversations; and can take real actions in tools like QuickBooks, bookings, CRM, and ticketing systems, with human approval for actions that move money or are irreversible.
A receipt could potentially bind selected boundary events like:
- conversation/session ID;
- WhatsApp message/thread reference;
- input type, such as text, voice, image, PDF, or spreadsheet;
- extracted/transcribed input hash;
- knowledge-base or RAG source references;
- generated answer/report hash;
- agent/persona reference;
- tool name and target system reference;
CONFIRM decision reference for gated writes;- booking / invoice / payment / CRM / ticket operation reference;
- before/after artifact or record digest;
- escalation/handoff reference;
- status, such as answered, escalated, confirmed, denied, booked, invoiced, paid, ticketed, failed, or handed off;
- timestamp/event ID;
- signer/public key ID.
The strongest use case would be when a customer conversation summary, grounded answer, QuickBooks invoice/payment action, booking/reschedule/cancel action, CRM lead handoff, support ticket, escalation record, or deployment/customer handoff is passed to another agent, business owner, customer, support workflow, accountant, auditor, downstream system, or future debugging process, and they should not have to fully trust the original n8n workflow run, WhatsApp thread, RAG store, memory state, or exported summary.
BoundaryAttest would not prove the answer was correct, the RAG source was complete, the customer intended the action, the CONFIRM decision was wise, the tool action was authorized, the payment/booking/CRM state remained unchanged afterward, or the runtime was uncompromised. It would only prove that a specific claim about a selected Omniagent artifact/action/handoff was signed and has not been altered after export.
There are a few small external interop patterns/examples here:
https://github.com/cullenmeyers/BoundaryAttest/blob/main/docs/external-interop-patterns.md
Does this kind of portable signed receipt fit any workflow you imagine for Omniagent, especially around WhatsApp conversation handoffs, RAG answer exports, typed CONFIRM approvals, QuickBooks invoice/payment actions, booking changes, CRM lead handoffs, support tickets, or customer/business-owner reports? Or are the current n8n execution records, WhatsApp/business-system logs, typed confirmation flow, and customer-owned deployment records enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around customer-facing business agents that take real actions.
Hi — I found Omniagent while looking at agent projects where customer-facing conversations, multimodal inputs, RAG answers, human-confirmed tool actions, or business-system handoffs may need evidence that survives outside the original runtime.
I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, actions, artifacts, or handoffs that cross trust boundaries:
https://github.com/cullenmeyers/BoundaryAttest
The idea is not to replace Omniagent’s n8n workflows, WhatsApp records, MongoDB Atlas memory/RAG store, OpenAI responses, customer-owned tenancy, tool integrations, typed
CONFIRMprotocol, MCP repo-inspection server, or normal business-system logs. The receipt only proves a narrow claim:Omniagent seemed relevant because it handles WhatsApp-first customer conversations across text, voice notes, images, PDFs, and spreadsheets; answers from a business’s own knowledge base; remembers conversations; and can take real actions in tools like QuickBooks, bookings, CRM, and ticketing systems, with human approval for actions that move money or are irreversible.
A receipt could potentially bind selected boundary events like:
CONFIRMdecision reference for gated writes;The strongest use case would be when a customer conversation summary, grounded answer, QuickBooks invoice/payment action, booking/reschedule/cancel action, CRM lead handoff, support ticket, escalation record, or deployment/customer handoff is passed to another agent, business owner, customer, support workflow, accountant, auditor, downstream system, or future debugging process, and they should not have to fully trust the original n8n workflow run, WhatsApp thread, RAG store, memory state, or exported summary.
BoundaryAttest would not prove the answer was correct, the RAG source was complete, the customer intended the action, the
CONFIRMdecision was wise, the tool action was authorized, the payment/booking/CRM state remained unchanged afterward, or the runtime was uncompromised. It would only prove that a specific claim about a selected Omniagent artifact/action/handoff was signed and has not been altered after export.There are a few small external interop patterns/examples here:
https://github.com/cullenmeyers/BoundaryAttest/blob/main/docs/external-interop-patterns.md
Does this kind of portable signed receipt fit any workflow you imagine for Omniagent, especially around WhatsApp conversation handoffs, RAG answer exports, typed
CONFIRMapprovals, QuickBooks invoice/payment actions, booking changes, CRM lead handoffs, support tickets, or customer/business-owner reports? Or are the current n8n execution records, WhatsApp/business-system logs, typed confirmation flow, and customer-owned deployment records enough for the current scope?No pressure if it is not relevant — I’m mainly trying to learn where signed receipts are actually useful around customer-facing business agents that take real actions.