Building AI Agent Skills That Actually Work in Metrc, Dutchie, and LeafLink

Ask a general-purpose AI agent to reconcile a month of transfers and it will confidently produce something wrong. The model is not the weak link. It simply has no way of knowing that a Metrc package, a Dutchie product, and a LeafLink invoice line are three different objects that sometimes describe the same eighth of flower. "Manifest" means a regulated transfer document in one system and a delivery batch in another. And in a state mid-migration from BioTrack, half the historical records use a different identifier scheme entirely.

MIT's 2025 study of 300 public AI deployments found roughly 95% failed to deliver measurable return, and the researchers put the blame on what they called the learning gap: generic tools that are impressive in a demo and brittle inside a real workflow. The deployments that worked were the ones built into specific, high-value workflows instead of handed to people as a chat window.

Agent skills are how that gap gets closed. A skill is a folder of instructions, reference files, and scripts that an agent loads when it recognizes the work in front of it. At best, it converts knowledge that currently lives in three people's heads into something applied consistently every time. At worst, it's a wordy prompt that changes nothing.

The collisions are in the vocabulary

Cannabis platforms overload the same handful of words with incompatible meanings, and every one of those collisions is a place where an agent produces a plausible wrong answer without flagging it.

Metrc is the official track-and-trace system in roughly 20 state markets, with New York currently phasing off BioTrack. In Metrc, a package is a regulated inventory unit with a tag, and a transfer manifest is the legal chain-of-custody document. In a POS, a product is a catalog entry that may map to many Metrc packages, or to none at all if someone created it manually during a busy receiving shift. In LeafLink, a line item is a commercial commitment that may not correspond to anything that has physically moved yet.

So an agent asked "how much of this SKU do we have" will answer from whichever system it happened to query. All three answers are legitimately different. Without a skill telling it which system is authoritative for which question, it picks one and moves on.

Write the gotchas, not the concepts

The model already understands accounting and can read an API response. What it cannot know is your environment, which is why the specific failure points are worth more than any amount of background explanation.

Compare two versions of the same instruction:

``` Weak: When reconciling inventory, compare Metrc data to POS data and identify discrepancies.

Strong: Metrc package adjustments are append-only. The current state of a package is the row with the highest adjustment sequence, NOT the most recent lastModified timestamp - bulk syncs rewrite that field and will silently backdate your answer.

A POS product with no metrcPackageId is not necessarily an error. Non-plant-touching accessories legitimately have none. Filter on productCategory before flagging. ```

The second version isn't more sophisticated. It's just true about your systems, and it heads off a specific wrong answer the agent would otherwise produce every time. Anthropic's engineering guidance makes the same point: a skill that restates what the model would do by default adds context without adding value.

Push the deterministic work into scripts

Skills are folders rather than documents, and that turns out to matter more than it sounds.

Anything with a correct, repeatable answer belongs in a script the agent runs instead of prose the agent interprets. Tag checksum validation, license number format checks by state, unit conversion between grams and eighths, aging bucket math. All of it is deterministic, and every time an agent recalculates that logic from a description, it gets another chance to get it wrong.

The practical split is that scripts handle computation and validation while markdown handles judgment, and the agent composes the pieces. It also cuts token consumption substantially, which matters once a reconciliation run spans thousands of records.

Descriptions are triggers, and they should be pushy

A skill that never loads is worth nothing. The description field is what the agent reads when it decides whether the current task is relevant, so write it for the model rather than for a human browsing a list.

Name the actual artifacts and phrases someone would use: "Metrc", "manifest", "package tag", "transfer reconciliation", "COA mismatch", "aging report". Agents under-trigger skills far more often than they over-trigger them, so err toward including whatever vocabulary your team actually types.

Establish a baseline before you write anything

Run the task without the skill first and record exactly where the agent fails. This is the step that separates a working skill from a document nobody ever validated.

Take twenty real reconciliation cases with known correct answers and run them cold. Catalog the errors: wrong authoritative source, mishandled adjustment ordering, invented package IDs. Write instructions that address those failures and nothing else, then rerun the same twenty. Track accuracy, but track runtime and token count too, because a skill that doubles accuracy while tripling cost may not be worth deploying.

Most teams skip this and write skills from imagination. The result is long, comprehensive, and aimed at problems the agent never had.

Where to start

Pick one workflow your team does weekly, that has a verifiable right answer, and that currently requires someone who has been there two years. Transfer manifest reconciliation and invoice-to-manifest matching both qualify.

Then write down every correction that person makes when reviewing a junior's work. Those corrections are the skill. The process documentation matters less than you'd think, because the agent can mostly infer it. What it can't infer is where this particular stack lies to you.

None of this is glamorous, and none of it depends on having a better model than anyone else. The operators who compound value from AI over the next few years will mostly be the ones who wrote down what their systems actually do, in a form an agent can load at the moment it needs it.