AI · Core Technology · Learning

Pattern memory: why Kopi
gets smarter every week.

Published Apr 23, 2026 · 7 min read

Most AI approval tools look identical on day 100 as they did on day 1. You paste in a policy, the AI checks against it, done. If your policies don't change, neither does the product. You're paying for a static rulebook wearing an AI costume.

Kopi is different in a specific, measurable way: the third time your team approves a pattern, nobody even sees it. It just passes. The fourth time, same thing. After a month, the majority of routine approvals are invisible to your managers — the product got out of their way.

This is pattern memory. It's not fancy. It's boringly correct, and it's the reason the value of Kopi compounds over time instead of staying flat.

The loop, in three steps

AI reviews

First time a vendor appears or an amount is new: Claude Vision parses the invoice, 5-dimension scoring, card to approver.

You approve

Approver taps Looks good. The (vendor, amount) tuple lands in pattern_memory with approval_count = 1.

Auto-pass

Third matching submission. Pattern is trusted. Green card, no AI call, no approver click, no time spent.

Why 2 approvals, not 1?

The default is 2 for a specific reason: single-approval data is dangerous. If someone mistakenly approves a fraudulent submission, with a 1-approval threshold Kopi would start auto-passing future fraud from the same vendor. With 2 approvals required, the chance of the same mistake happening twice is vanishingly small — and any rejection on the pattern invalidates it permanently.

Conservative by design. False-pass is the worst failure mode. Every other choice in pattern memory (±30% amount tolerance, rejection_count > 0 = never trust, rejection-invalidates-forever) is designed around never trusting something that shouldn't be trusted.

The data moat that actually matters

The technique isn't hard to build. A competitor with two engineers could ship a version of pattern memory in a couple of weeks. But the value doesn't live in the code — it lives in your tenant's accumulated history.

Every week Kopi runs in your workspace is another week of "this is normal for us" intelligence. A CFO switching tools at month 6 starts from zero on day one of the new tool. For the first 60 days they're clicking through the same approvals Kopi was auto-passing on day 1. That switching cost is real, and it compounds.

This is the defensibility Kopi actually has. Not fancy ML, not proprietary algorithms, not network effects — just accumulated per-tenant history that grows week by week and does not transfer.

What we don't store in pattern memory

We deliberately keep pattern memory narrow. It records:

• Vendor / description signature (normalized)
• Amount range observed (min, max, average)
• Approval count and rejection count
• Last-seen timestamp

It does not record:

• Invoice contents (those are processed ephemerally)
• Approver identity (decisions are tenant-level, not person-level)
• Cross-tenant comparisons (each tenant is fully isolated)
• GL categorization (that's the accountant's job, not ours)

This narrowness is why it works: the data structure is simple enough to inspect, export, and delete. You can see exactly what Kopi "thinks" is normal for your team, and edit it.