The one thing most "AI for ERP" pitches skip: how the agent actually writes
AI-for-ERP demos routinely stop at a read. The hard part — a write that a security review would actually pass, with policy enforcement, approval gates, and a rollback path rather than a direct database write with a prayer — is what most pitches skip.
Read the same explainer as text
How a governed write reaches the ERP
- 01 ProposeThe agent proposes a change. It does not write.
- 02 Policy checkA policy gate checks the proposal before anything is sent.
- 03 Approve or blockAbove a threshold, an approval step decides. A block is recorded.
- 04 Write and read backThrough the application's own API and rules, never a direct database write. The result is read back.
Dated run · 2026-07-31
- 3 writes persisted, each re-read to confirm
- 2 rejected: vendor on hold; closed purchase order
Real Snowflake sandbox tenant, synthetic data; the write ran through a stored procedure, not an ERP application. Not a client system. Run record below.
Who this is for
IT and security leaders who've been pitched AI-for-ERP demos that mostly stop at read-only — and want to know how a write actually gets approved, logged, and rolled back.
What you get
A working, governed write path from your AI agent into your ERP — executing through the application's own logic layer, with a policy-enforcement gate, a full evidence trail, and a defined rejection/rollback flow.
Why this is real, not a pitch deck
A named engagement, not a hand-wave
The Agent-Ready ERP Diagnostic & Governed Write-Path is scoped specifically around one stalled write path in your environment — chosen because it's the constraint actually blocking you.
Try the write-path pattern in your browser
The Governed AP Exception Workflow demo runs the full loop — propose, policy decision, approval or block, simulated write, audit, and rollback — the same pattern this engagement builds around your write path.
A real write into a real Snowflake sandbox, not a mock
On 2026-07-31 this pattern executed against a real, paid Snowflake sandbox tenant — not a free trial, not a mock: 3 real writes to an open PO's committed amount persisted and were confirmed by re-reading state afterward, plus 2 correctly rejected writes (a vendor on hold, a closed PO), with the full gateway-to-Snowflake round trip logged with real policy-check and audit-trail data. Ask and I'll walk you through it directly. Read the dated run record below →
Operator experience on both sides
Before founding Tioga AI, the founder managed ERP systems across four sister companies — including the approval and control workflows a governed write has to respect.
Audit-grade evidence, not a screenshot
Every write produces a reviewable record — what was proposed, what policy check ran, who or what approved it, and what happened if it was rejected.
Dated run record: a governed write against a real Snowflake account (2026-07-31)
What this is
On 2026-07-31 Tioga's governed-write pattern was run end to end against a real, paid Snowflake account (a sandbox tenant Tioga created that day, not a client's system and not a free trial). The record below is what was checked and what came back. Account, user, role, host and key identifiers are removed.
Label: real system, synthetic data. The purchase-order rows are seed data created for this test. This shows the pattern working against a real database's stored procedure; it is not a client deployment and not evidence about throughput or scale.
What was set up
- A scoped service role, user and warehouse, provisioned with one setup script that ran without error: schema, tables, seed rows and a CHANGE_PO stored procedure.
- The agent gateway called the ERP only through the one sanctioned change endpoint; the Snowflake-backed service exposed the same HTTP contract as the mock it replaced, so the gateway needed no code change.
What was run and what came back
| Check | Result |
|---|---|
| List purchase orders (GET /pos) | Returned the 4 seeded rows correctly |
| Change a purchase order's committed amount (POST /pos/:id/change), three separate times | 3 real writes succeeded and persisted; state was re-read after each one to confirm |
| A change against a vendor on hold | Rejected, with the accurate error message |
| A change against a closed purchase order | Rejected, with the accurate error message |
| Gateway policy check → ERP round trip, recorded in the ledger | Confirmed; measured latency about 2.2 seconds for the ERP call, likely dominated by the warehouse resuming from auto-suspend |
| Optimistic-concurrency write logic across sequential real calls | Worked |
On the same day, a scripted rerun of the six canned scenarios the demo had then (it has since gained a seventh and its amounts have changed) reproduced five exactly. The auto-approve scenario came back blocked because earlier test writes had already pushed that order's committed amount up, so a further $2,000 genuinely exceeded its ceiling. That is expected behavior for stateful test data, not a defect; the setup script includes a reset to restore the seed values.
Re-verified 2026-08-17: the connection and key-pair authentication still worked against the same account.
What this record does not have
- No preserved raw transcript or ledger export of the 2026-07-31 writes. The details above come from the dated verification notes written that day. If a primary artifact is wanted (a ledger export or a recording), it has to come from a new run, dated when it is run, against the same account.
- No rehearsal on a live prospect call has happened.
- Nothing here says how the pattern behaves on a client's production system.
Doesn't ServiceNow's Action Fabric (or SAP's Agent Hub, or Salesforce's MCP servers) already do this?
Partly, and it's worth being precise about which part. ServiceNow's Action Fabric — a GA MCP server bundled into every Now Assist / AI Native SKU — already lets an agent write through ServiceNow's own flows, playbooks, and approvals. SAP ships an equivalent through Agent Hub and Joule Agent Studio's MCP gateway. Salesforce ships hosted MCP servers, GA and free on Enterprise Edition and above, with full user attribution. Inside each vendor's own estate, a governed write already exists.
The write path most buyers actually need crosses that boundary. An agent that qualifies a lead in Salesforce, resolves an AP exception flagged in ServiceNow, or reconciles a PO in SAP frequently needs to write into a different system of record than the one that triggered it — an ERP the triggering platform doesn't own. Action Fabric's approval trail stops at ServiceNow's edge; it doesn't extend into SAP's application logic, and none of these platforms' write paths were built to police a competitor's ledger. That's not a defect — it's the natural limit of a platform vendor governing its own product.
It's also not something a platform vendor has an incentive to build well: verifying that a write into a competing ERP was authorized and consistent with that ERP's own controls isn't governing its own transaction anymore, so a platform vendor has its own interest in how it is done. Tioga discloses its own vendor relationships. This engagement builds the specific write path through the target ERP's own application logic layer — not a database write — with a policy-enforcement gate and an audit-grade evidence trail, regardless of what triggered the write. It's designed to work alongside Action Fabric, Agent Hub, or Salesforce's MCP servers as the trigger or orchestration layer, not to replace them — the gap it closes is the write itself, into the system that actually owns the record.
The same applies to an AI gateway or agent-security control plane you may already run for discovery, identity, policy enforcement, or a kill switch. Keep it. This engagement scopes the write path to sit behind it: the control plane decides whether the agent may act, and the governed write path makes sure the action that reaches the ERP goes through the ERP's own application logic and leaves an evidence record the target system can vouch for. Tioga does not build a gateway or policy engine and does not compete with one; scoping starts with which one you run today.
Engagements
Every engagement starts with a 5-day Discovery Sprint ($5,000 flat, prototype included) that scopes the work before any larger commitment — credited toward the price below if you move forward.
Not ready to scope an engagement? Free ERP Agent-Readiness Checklist →Agent-Ready ERP Diagnostic & Governed Write-Path
Assess one stalled agent-to-ERP write path, then build a governed version of it — executing through your application's own logic layer, with policy enforcement and an audit-grade evidence trail your control owners can actually clear.
$60–120K
~6 weeks
Questions
What does "governed write" mean technically?+
The agent never writes directly to the database. It executes through your application's own API/logic layer — the same path a human user's action would take — with a policy-enforcement check and logging before and after.
What if the agent gets it wrong?+
The write path is designed with an explicit rejection and rollback flow from day one, not added after an incident.
How is this different from just giving an agent API credentials?+
API credentials alone don't give you policy enforcement, an approval gate, or an audit trail scoped to what a control owner needs to see. This engagement builds all three around the write, not just the API call.
Can we see the audit trail this produces?+
Yes — see the live Governed AP Exception Workflow demo for the interactive version. This pattern has also run against a real Snowflake sandbox tenant, not just the mock (3 real writes persisted, 2 correctly rejected, full policy-check and audit-trail data on 2026-07-31) — ask and I'll walk you through the real run directly.
What happens when an agent retries a write, or a workflow replays one?+
Retries and replays are where a governed write most often goes wrong without anyone noticing: the same proposed change can reach the system of record twice, and two copies of one approval can look like two decisions. The diagnostic asks, for the one write path in scope, whether a retried or replayed step can post a second time, and whether the evidence record shows one write or two. The build acceptance tests include a replay that posts once and a retry that creates no duplicate. Evidence label: engagement design, framework-neutral. These tests are part of the scoped work; the browser demo and the 2026-07-31 Snowflake run record above did not exercise them, and nothing here is a client result.
What if a write fails halfway?+
A partial failure is treated as its own case, not as a failed retry. The scoped work defines in advance what is undone, what is left in place, and who is told, and the build acceptance tests include a partial-failure rollback. Evidence label: engagement design, not demonstrated on this page. The dated run record above shows two writes rejected cleanly and three persisted; it does not show a mid-write failure.
Does the diagnostic cover payroll/HRIS or FP&A write paths too, or only the ERP?+
Yes, where a candidate write path originates in or lands in payroll/workforce management or FP&A planning rather than the ERP alone — grounded in hands-on configuration, implementation, and operating experience with UKG Pro and Workday Adaptive Planning (formerly Adaptive Insights, spanning both its pre- and post-Workday-acquisition generations), not a general "AI in HR" or "AI in FP&A" framework applied from the outside. Two examples: a timecard exception agent proposing punch corrections carries the same attribution-loss risk this diagnostic already looks for on the ERP side — now against real wage-and-hour exposure (FLSA/state overtime rules) rather than only a posting-period control; a headcount-forecast drafting agent has to write into a draft, never a locked/approved, version, with each number tagged to its source data and stated assumption. Any demo shown ahead of a live engagement runs on synthetic data — UKG doesn't issue developer sandboxes outside its formal partner program, and Adaptive Planning sandboxes come bundled with a customer license — stated plainly, not implied away.