Assist is a platform where teams can build, host, and deploy internal AI software and agents in one place — giving companies a safe, controlled environment to standardize workflows and improve operations.

What are sandcastles?

Sandcastles are purpose-built internal apps created by non-technical teams on the Assist platform. They allow employees to build custom tools and workflows without engineering resources.

How much does Assist cost?

Assist uses pay-as-you-go pricing: provider costs + 5%, $0.17 per 1k tool calls, with no seat fees. Enterprise custom pricing is also available.

Do we need engineers to use Assist?

No. Assist is designed for non-technical teams to build and deploy AI tools. Engineers can use it too, but it doesn't require engineering resources to get started.

Playbook: Build a Reconciliation Drift Tracker Across Two Systems

Your warehouse management system and your ERP are supposed to agree. The WMS says you have 12,400 units of part number A-7321 on hand. The ERP says you have 12,387. The finance team notices the gap during the monthly close, files a ticket, and somebody spends half a day tracing where the mismatch came from. By the time the reconciliation finishes, another mismatch has already appeared — and nobody can tell whether the new mismatch is a different problem or the same problem that was never actually fixed.

This playbook walks you through building a subagent with a filesystem that takes daily snapshots of inventory from both systems, diffs them automatically, and keeps a running log of every discrepancy — whether it is new, recurring, or resolved. The operations team gets a dashboard that shows which mismatches are still open and which ones have been fixed. Finance gets a clean audit trail. Nobody has to remember to run anything.

What you will build

By the end of this playbook, you will have:

A scheduled subagent that runs every morning and takes a snapshot of the inventory in your WMS and your ERP.
Custom tools that connect to both systems and return a canonical view of every SKU.
A filesystem layout that stores each day's snapshots as dated files, with discrepancy logs generated by comparing them.
An "open discrepancies" index file the agent maintains — every new mismatch gets added, every resolved one gets closed with a timestamp.
A sandcastle app where the ops team investigates each discrepancy, assigns it to a person, and marks it resolved.
A weekly summary that tells leadership whether reconciliation drift is getting better or worse.

What you need before you start

An Assist workspace with your AI client connected via MCP.
Editor access to create and schedule agents.
Read credentials for both systems. If your WMS and ERP only support SOAP, REST, or database access, any of those will work — just make sure the credentials you use have a read-only scope so the reconciliation agent cannot accidentally mutate production inventory.
A canonical list of SKUs you care about. You may not want to track every part number — just the ones that matter financially or operationally.
An understanding of the acceptable variance between systems. Some drift is normal (in-flight transactions, batch lag). You will tune a threshold.

This playbook uses a fictional WMS at https://wms.internal.company.com/api and an ERP at https://erp.internal.company.com/api. Substitute your real systems.

Step 1: Create the agent and agree on the file layout

Start in your AI client:

"Create a new subagent called 'Reconciliation Drift Tracker'. Its purpose is to pull daily inventory snapshots from our WMS and ERP, compare them, log discrepancies over time, and help the ops team investigate mismatches. It should never write anything back to either system — it is read-only."

Open the agent in Assist and turn Filesystem Volume on.

Now agree on the filesystem layout in a fresh chat with the agent:

"We are going to use your filesystem to track inventory reconciliation between our WMS and ERP. Here is the layout I want:

/snapshots/wms/<YYYY-MM-DD>.jsonl — one line per SKU, each line a JSON object with sku, on_hand, location, timestamp.

/snapshots/erp/<YYYY-MM-DD>.jsonl — same shape, from the ERP.

/discrepancies/<YYYY-MM-DD>.md — a human-readable diff file generated by comparing that day's two snapshots. Each discrepancy is one section with: SKU, WMS count, ERP count, delta, first-seen date, status.

/open.md — the current list of unresolved discrepancies, ordered by oldest first. This file is updated every run.

/closed.md — an append-only log of every discrepancy that has been marked resolved, with the resolution date and resolver.

Whenever you run, you should read yesterday's /open.md, pull fresh snapshots, generate today's diff, update /open.md to reflect the current state, and append anything newly resolved to /closed.md. Does that layout make sense?"

The agent confirms or suggests changes. Iterate until you are happy.

Step 2: Build the snapshot tools

Write tools that pull from both systems:

"Create a custom tool called wms_inventory_snapshot that takes no parameters, calls our WMS at https://wms.internal.company.com/api/inventory, and returns every SKU's current on-hand count with location. Return the result as an array of {sku, on_hand, location} objects. Include the WMS server timestamp from the response header."

"Create a custom tool called erp_inventory_snapshot that takes no parameters, calls our ERP at https://erp.internal.company.com/api/inventory/current, and returns the same shape: an array of {sku, on_hand, location} objects plus the ERP timestamp. Normalize the SKU format so they match the WMS output — our ERP uses A_7321 and WMS uses A-7321, so convert."

Test both tools against today's data. Confirm you are getting a reasonable number of rows, the SKU formats match, and the counts are within a plausible range. If the ERP tool returns zero or the shape is wrong, iterate on the prompt until the data is clean.

Step 3: Run a manual snapshot and diff

Before scheduling anything, walk through one full run manually:

"Take an inventory snapshot from both systems right now. Save the WMS result to /snapshots/wms/<today>.jsonl and the ERP result to /snapshots/erp/<today>.jsonl, each as JSON-lines format (one object per line). Then compare the two and write /discrepancies/<today>.md with one section per SKU whose WMS and ERP counts differ by more than 5 units — that's our variance threshold. Each section should have the SKU, both counts, the delta, and a status of 'open'. Finally, update /open.md to list every discrepancy from today's diff."

The agent runs the tools, writes the files, and reports what it did. Read each file (read /snapshots/wms/<today>.jsonl, read /discrepancies/<today>.md, read /open.md) and verify:

The snapshots contain every SKU you expected, not just a sampling.
The diff file only contains discrepancies above the threshold.
/open.md reflects the actual current state.

Tune the threshold if too many or too few discrepancies are surfacing. The threshold is just a number in the prompt — change "more than 5 units" to "more than 10 units" or "more than 2% of the WMS count" as needed.

Step 4: Add the "new vs recurring" logic

The core value of the filesystem here is that yesterday's state is available on disk. On the second run, the agent can tell whether a discrepancy is brand new or a returning problem.

"When you take tomorrow's snapshot, compare the list of discrepancies in tomorrow's /discrepancies/<tomorrow>.md against the current contents of /open.md. For each SKU:

If it is in both files, mark it as 'recurring' and copy its 'first-seen date' forward from /open.md.

If it is in the new diff but not in /open.md, mark it as 'new' with today's date as the first-seen date.

If it is in /open.md but not in the new diff, the WMS and ERP now agree on that SKU — move it to /closed.md with today as the resolution date and 'resolved automatically' as the note.

After reconciling, rewrite /open.md so it reflects the current open set."

Test this by running the snapshot again a few hours later. Verify that discrepancies that are still present get marked 'recurring' and their first-seen date is preserved.

Step 5: Schedule the agent

"Schedule the Reconciliation Drift Tracker to run every weekday at 6 AM UTC. When it runs, it should perform the full snapshot + diff + reconcile flow we just built. On completion, it should write a short summary to /runs/<date>.md with: how many SKUs were compared, how many new discrepancies appeared, how many were resolved, and how many remain open."

The agent now runs every morning before the ops team starts work. Their first Slack message of the day is "overnight reconciliation finished — 3 new discrepancies, 2 resolved, 17 still open."

Step 6: Build the investigation app

The ops team needs a place to actually work on the open discrepancies. Build a sandcastle app:

"Build a sandcastle app called 'Reconciliation Workbench' that lets the ops team investigate open discrepancies. The app should:

Show the contents of /open.md as a filterable, sortable table with columns: SKU, WMS count, ERP count, delta, first-seen date, assignee, status.

Let a user assign a discrepancy to a teammate (store the assignment in persistent state so it survives across sessions).

Let a user click a discrepancy to open a detail view that shows: the full discrepancy section from today's diff, a timeline of when this SKU has been in and out of the open list (read every /discrepancies/*.md file and find matches), and any notes collected so far.

Let a user add a note to a discrepancy. Notes are stored in persistent state, keyed by SKU.

Let a user mark a discrepancy resolved with a note explaining the fix. When resolved, the app tells the agent to move the entry to /closed.md with the note and the resolver's name.

Make it clear that the agent handles the file writes — the app stores the user actions as persistent state and the agent processes them on its next run."

Iterate: "group open discrepancies by assignee." "Highlight rows older than 7 days in yellow, older than 30 in red." "Add a chart showing open count over time, sourced from the daily run summaries under /runs/."

Share the app with the ops team. They now have a workbench for reconciliation work, and finance has an audit trail that goes back to day one.

Step 7: Add a weekly trend summary

Leadership wants to know whether reconciliation drift is getting better or worse. Add a second scheduled agent or extend the existing one:

"Every Monday at 8 AM UTC, read every file under /runs/ from the past 7 days plus /open.md. Write a summary to /weekly/<date>-summary.md with:

Total discrepancies opened this week.

Total resolved this week.

Net change in open count.

Top 5 SKUs with the largest deltas, and whether they are new or recurring.

A short commentary section comparing this week to the previous week.

Post a summary message to the #ops-leadership Slack channel with a link to the file."

Now leadership gets a weekly state of reconciliation without anyone remembering to send it. The pattern from the rest of the playbook applies: the filesystem is the durable record, the scheduled agent is the automation layer, the sandcastle is the human interface.

What you built

A daily reconciliation run that captures the state of two systems in per-day snapshot files.
A diff archive that preserves every discrepancy ever found, with timestamps that let you answer "when did this start?"
A live open list that accurately reflects the current state, updated automatically as mismatches resolve themselves or get fixed by the team.
An investigation workbench the ops team uses to assign, note, and resolve discrepancies.
A weekly leadership summary that trends the state of reconciliation without manual work.

The filesystem is what makes the "new vs recurring" distinction possible. Without persistent storage, each day's comparison would start from zero — you would find the same mismatch three times in a week and have no way to know whether it was the same problem or three different problems. With the filesystem, yesterday's state is on disk, and today's comparison is a diff against that known state.

Natural extensions

Per-location reconciliation: instead of one global snapshot, take one snapshot per warehouse and generate separate discrepancy files.
Root cause classification: when a discrepancy resolves, the resolver types a note explaining why. A secondary agent reads every resolution note from the past 90 days and classifies them into categories — timing, data entry error, system bug, in-flight shipment. Trend the categories over time.
Alerts on critical SKUs: a tag system where certain SKUs are marked critical. Any new discrepancy on a critical SKU triggers an immediate Slack notification rather than waiting for the morning summary.
Cross-system inventory audit: extend the tracker to a third system (third-party logistics provider, 3PL) and run three-way reconciliation.

Each extension reuses the same pattern: a tool, a scheduled agent, files on disk, a sandcastle surface. The agent filesystem is the thing holding it all together.