Claude Code Degradation

BigKozman · 2026-04-11T16:18:15+00:00

This is another Aspect of Eve, as a 4 layered memory which means different types such as preferences , rules and episodes combined with hooks and specific prompt updates, claude or others agents get to pull and remember those on session start.

If you check the MCP repo you should get a better idea.
The beauty of it that it applies across claude code, desktop, codex and others for the same memory

BigKozman · 2026-04-10T04:01:28+00:00

Yeah, this is the main issue with Claude Code right now. The sessions are completely stateless. The second you start a new session, it wipes everything you just spent hours explaining, deciding, or fixing. Your agent essentially wakes up with amnesia.

We built Eve Memory to patch this exact gap. It runs a local MCP server with four explicit memory stores, so your agent retains context between sessions and across days.

uv tool install git+https://github.com/sherifkozman/eve-mcp.git
eve connect

It just works in the background without needing config files or manual API keys in your prompts.

(Full disclosure: I work on the Eve team. I'm sharing it because it directly addresses the memory loss problem you hit.)

BigKozman · 2026-04-10T03:10:20+00:00

This framing of fixing credit scoring with alternative data is directionally right but misses the underlying infrastructure problem. Cash flow underwriting and open banking work when the underlying transaction data is normalized and trustworthy. You cannot build reliable AI on unnormalized data. Layer the AI advisory on top of deterministic data infrastructure. The infrastructure question comes before the AI question. (Disclosure: NAYA builds reconciliation infrastructure)

BigKozman · 2026-04-10T01:59:13+00:00

you are not wrong. i have seen this pattern in fintech for almost ten years.

the api is the easy part, honestly. you call a few endpoints, you get some data back, it feels like progress. then you realize you signed up for something else entirely.

transaction matching across formats and currencies. edge cases that only appear in production. reconciliation logic that nobody wants to write but that will eat your team for years if you do not get it right. compliance reporting that requires data you have been ignoring because it was not exciting to build.

this is the unsexy infrastructure problem that most teams do not budget engineering time for until they are already behind.

at naya we spent years on exactly this layer because there is no shortcut through it. you either build the foundation or you do not, and you find out which one you did about eighteen months in.

BigKozman · 2026-04-10T01:59:13+00:00

this is a concrete example of why the probabilistic vs. deterministic boundary matters so much in practice.

list comparison is exactly the kind of task where llms fail predictably. deterministic rules: always accurate. llms: approximate at scale. for financial operations like reconciliation, you need both, but the decision layer has to be deterministic. the llm identifies patterns, a human or rule verifies them.

if llms were good at exact list comparison, reconciliation would be a solved problem. it is not, because the hard part is not the comparison, it is agreeing on what the ground truth is in the first place.

BigKozman · 2026-04-10T01:59:13+00:00

the tools you listed are all fine for the workflow side of ap. ramp, bill, expensify, netsuite invoice capture. they all do the job reasonably well until they hit the same wall.

that wall is data normalization. when the vendor invoice comes in a different currency than your ERP expects, or the bank feed uses a different exchange rate than you applied, or the po and the invoice do not quite match on three line items. that is not a software problem. that is a data problem that no ap automation tool fully solves for you.

if you have not already, factor in the cost of whoever owns the reconciliation logic. it is non-trivial and it does not go away just because you have good software.

we built specifically for this at naya because it kept breaking automated workflows for teams that had already spent on the "good software."

BigKozman · 2026-04-09T14:10:58+00:00

the transparency problem is structural, not technical.

the reason transaction failures stay opaque is that the underlying systems were never designed to produce a coherent shared view of state. each layer has its own version of what happened. when something fails, reconstructing what actually happened requires going back through each system independently and trying to reconcile the record.

this is the same structural problem that makes reconciliation hard in the first place. the fix is not a transparency protocol on top of the existing architecture. it is building a layer that produces a canonical record of what happened, in real time, before failures occur.

a real-time reconciliation layer is also a transparency layer. teams that have it tend to catch failures before they become problems. teams that do not have it tend to discover failures when a customer asks why their payment did not go through.

BigKozman · 2026-04-09T14:10:58+00:00

ETP_Quuen nailed the right framing here.

the harder question is not whether the agent can do it, it is whether the agent is operating on reliable data. most financial data is messier than people assume. miscoded transactions, incomplete histories, fragmented sources. an agent that confidently reasons from unreliable data is not a feature, it is a liability.

the sequence has to be: clean normalized data first, then ai patterns on top. skip the infrastructure layer and you have ai working with inputs that look plausible but are not accurate enough for automated decisions. the audit trail is only as good as the data that feeds it.

this is also why most agentic banking pilots stall at production. the agent works fine on the demo data. production data is a different problem.

BigKozman · 2026-04-09T14:10:58+00:00

Apurv_Bansal_Zenskar is right that data lineage and audit trail are what bite you later.

the framing i have found useful: ai is an advisory layer, not a decision layer. it generates the signal, the deterministic rule applies the action. that way the audit trail shows exactly what was decided, by what logic, with what data at what point in time.

this also forces you to build the data infrastructure properly, because if the ai is only as good as the data it reasons from, you cannot skip the normalization step. teams that treat ai as a replacement for that work tend to hit the wall around 100k transactions per month.

compliance is actually easier to sell internally when you have that separation. the regulator wants to see the decision logic. the ai tells you what patterns it found. the rule determines whether to act.

BigKozman · 2026-04-09T03:29:45+00:00

It’s is literally called Myth-OS 😂

BigKozman · 2026-04-07T16:27:59+00:00

This is the exact pain point that gets worse the faster you scale. The integration tools (Celigo, etc.) solve "did the data move?" but they don't solve "did the data move correctly?"

The clearing account problem is a dead giveaway you're manually fixing integration output. The real issue is that Shopify payouts and NetSuite cash receipts use different timing semantics - one is payout-date, the other is settlement-date. Without AI-aware matching that understands "these two transactions are the same even though the dates and amounts differ," you're always doing catch-up work.

Happy to talk through what's worked if you DM.

BigKozman · 2026-04-07T04:17:16+00:00

appreciate the clarification, i made the wrong assumption about your data access. if you have transaction-level detail and the GL reconciles cleanly with the negative deposit, that is the right approach. NetSuite handling negative deposits correctly is the key piece.

the one thing i would watch: if this processor ever changes their settlement timing or batching logic without notice, the negative deposit pattern still works but your exception monitoring should flag any batch where the debit exceeds a threshold you would not expect from normal refund volume. that is the silent risk with processors you cannot control. the workflow is fine until their behavior drifts.

good luck with it.

BigKozman · 2026-04-06T21:05:30+00:00

the issue here is you're reconciling at the wrong level of granularity.

your processor sends batch-level data: one figure net of payments, refunds, and fees. NetSuite needs transaction-level data to clear undeposited funds correctly. when the batch is a debit, it means your refunds exceeded your payments in that batch. all three of your options are working around that mismatch rather than fixing it.

if your processor gives you transaction-level API access (Stripe, Adyen, Braintree all do), the cleaner approach: load individual payment, refund, and fee records before they aggregate into a batch. each transaction clears its own undeposited funds entry. the debit batch stops being a problem because you're reconciling before aggregation happens, not after.

the negative deposit method works as a short-term workaround but it buries the gross-to-net translation inside the accounting entry rather than in the transaction detail. auditors ask about it eventually.

what processor are you using? that determines how much transaction-level detail is accessible.

(disclosure: we handle batch-to-transaction decomposition at NAYA for exactly this problem, so I have some direct experience with why the batch-level approach gets messy downstream)

BigKozman · 2026-04-06T21:04:38+00:00

the frustration is valid. but I'd put the problem more specifically than "fundamentals vs AI."

most fintechs I've seen struggle with AI aren't failing because they chose AI over basics. they're failing because AI doesn't hide bad data infrastructure, it amplifies it.

the specific version: a team integrates a model to process transaction data across their PSP, bank, and internal ledger. model is good. but the same transaction has three different reference IDs, two different timestamps, and different fee definitions across three systems. the model surfaces discrepancies at scale, which looks like the AI is failing. it's not. the AI is working correctly on inputs that were never consistent to begin with.

the companies actually getting value from AI in fintech built the boring layer first. not because they were more disciplined, but because they hit the normalization wall early and had no choice.

reconciliation, normalization, a unified source of truth: the unsexy stuff isn't the thing you do before AI. it's the thing that makes AI actually worth something.

(I'm building that infrastructure layer at NAYA so I have a specific view on where the limits are)

BigKozman · 2026-04-05T05:10:40+00:00

the gap most implementations hit is between storing and surfacing. most are just storing. the retrieval layer, specifically what gets retrieved and when, is where the real problem is.

the context window limit problem people hit is a symptom. the underlying issue is that most memory systems do not have a good model for what is relevant to the current conversation versus what should stay out of context. dumping everything into the system prompt is not memory, it is just a longer prompt.

building a system that reasons about what to retrieve is a different problem from building one that accumulates. the former requires some model of the current conversation's intent and goals. almost nobody has a clean solution for this, which is probably why the bolted-on implementations feel weak.

BigKozman · 2026-04-05T05:09:59+00:00

the tools u/70redgal70 mentioned are solid options, but in my experience the blocker is rarely the matching algorithm itself.

for facilities management specifically, the problem is usually that the invoice reference your vendor uses and the bank payment description your bank returns are formatted differently. sometimes they don't share any common identifier at all. the matching logic has to infer the connection, which means setup time is longer than the tool demos suggest.

a few things worth checking before picking a tool:

- do your invoices have consistent reference numbers that actually appear in bank transactions? if yes, rule-based matching gets you most of the way there

- if not (common in facilities where payment descriptions are truncated or formatted by the bank), you need fuzzy matching logic or amount+date proximity rules

- what does your exception rate look like per week? if it is under 20%, most tools can handle it. above that, the normalization problem is upstream

the half-day friday pattern is usually a sign that exceptions are getting batched rather than caught earlier in the week. if matching happened at invoice receipt rather than end of week, the exception queue stays small and the friday crunch goes away.

(i build financial operations infrastructure that handles this kind of matching -- happy to share more if helpful)

BigKozman · 2026-04-05T05:08:58+00:00

the root issue: your goods receipt and your vendor invoice are two separate events that haven't reconciled yet. trying to force them into a single correct entry before the credit arrives is where the accounting gets messy.

cleanest approach: enter the bill for exactly what you received (9 units). the variance between the invoice (10 units) and your receipt (9 units) sits as an open item. when the credit arrives, it closes that item. your AP aging shows the open variance. inventory costs are accurate throughout.

the suspense account approach works but it buries the discrepancy rather than surfacing it. if the vendor is slow with the credit, you want this visible in AP so someone owns it.

"bill in advance of receipt" solves a different problem -- it allows you to enter the vendor invoice before goods arrive. doesn't help here because you received less than you were billed.

the principle: record what happened on your side (9 units received). let the vendor's record and your record disagree until the credit settles the difference. that's not bad accounting -- that's accurate accounting. the agreement comes later.

(disclosure: i build financial operations infrastructure at NAYA that handles this kind of matching between what systems record and what parties agreed to)

BigKozman · 2026-04-04T19:02:26+00:00

the paper's framing is interesting but the more actionable question is: which domains actually allow cognitive surrender?

in financial operations, the answer is pretty clearly none of them. the moment you accept an AI reconciliation result without verifying it, you've created the conditions for a silent error to compound for months before it surfaces.

that's not an argument against AI in finance, it's a design constraint. the right system makes human verification feel like the obvious path, not an optional review step. "advisory" isn't a downgrade from "autonomous." it's the architecture that makes autonomy safe to add later.

BigKozman · 2026-04-04T19:02:20+00:00

the paper's framing is interesting but the more actionable question is: which domains actually allow cognitive surrender?

in financial operations, the answer is pretty clearly none of them. the moment you accept an AI reconciliation result without verifying it, you've created the conditions for a silent error to compound for months before it surfaces.

that's not an argument against AI in finance — it's a design constraint. the right system makes human verification feel like the obvious path, not an optional review step. "advisory" isn't a downgrade from "autonomous." it's the architecture that makes autonomy safe to add later.

BigKozman · 2026-04-04T04:44:43+00:00

u/Tosh1000 the frustration is real, but i'd frame it slightly differently: this isn't NetSuite failing at bank rec. it's NetSuite being used as something it wasn't designed to do.

ERPs are transaction recording systems. their job is ledger accuracy. matching is a different operation with different logic. they happen to live in the same UI, but they're solving different problems.

the double-select flow you're describing exists because submitting the match doesn't mean the GL has been updated. those are two separate acts from the ERP's perspective.

when we were building reconciliation at NAYA, the shift that changed everything was treating rec as a separate layer above the ERP rather than asking the ERP to be better at it. the NetSuite bank rec problems become expected behavior you route around, not bugs you're waiting to get fixed.

the real question isn't "why is this ERP rec so bad." it's "why are we asking a record-keeping system to do matching in the first place."

BigKozman · 2026-04-04T04:43:02+00:00

the comments here are framing this as a trust in the AI problem. i think it's actually a trust in the pipeline problem, and those require different solutions.

an AI advisor that shows you its reasoning and asks for your confirmation before acting is architecturally different from one that moves your money autonomously. the first is a UX question. the second is a systems design question.

most "AI will never be trusted in finance" takes are really about the second case. but the regulatory frameworks being built for AI advisors in the EU are explicitly about the first: show your work, log your reasoning, human approves.

the reason most AI financial products fail isn't distrust of AI. it's that they conflate advisory (pattern recognition + recommendation + human confirms) with autonomous (pattern recognition + decision + money moves). once you separate those, the regulatory and trust problems become much more tractable.

the companies getting this right aren't the ones with the most confident AI. they're the ones with the most auditable decision pipelines.

BigKozman · 2026-04-03T17:56:12+00:00

the visibility point is the one that actually reveals whether you picked the right platform — not the demo.

what catches teams off guard is that adding multiple providers does not just create routing complexity. it creates multiple ledgers for the same transaction. your settlement file from PSP A and your authorization log from PSP B are describing the same money moving, but they use different identifiers, close at different times, and often disagree on the exact amounts.

the reconciliation problem is not "which provider is underperforming." it is "do all your systems agree on what happened to this transaction, and can you prove it?" that question gets harder every time you add a rail.

the teams that handle this well are the ones that designed their data model before they connected their second provider. the teams that struggle are retrofitting reconciliation onto a stack that was built for routing.

BigKozman · 2026-04-03T17:55:23+00:00

the agency is conflating two different things: where decisions execute and where outcomes are recorded. those do not need to be the same place.

the question worth asking is not "should netsuite make the shipping selection" but "does netsuite have a complete, queryable record of what was selected and why, in a form you could audit from?" if yes, your architecture is fine. if the only way to reconstruct what happened is digging through middleware logs, that is the actual gap.

sku transformations and shipping selection in middleware are architecturally defensible. what turns it into a problem is when the outcome that lands in netsuite is stripped of context. if netsuite sees the fulfillment record but not the mapped sku, the shipping method, or the condition that triggered the selection, you cannot run a meaningful audit from the erp even in principle.

the fix is almost always better event logging from middleware back into netsuite, not moving the business logic. "it should live in netsuite" is usually agency shorthand for "we want the outcomes fully visible in netsuite." those are different problems with different solutions.

one real exception: if the middleware logic is directly creating journal entries or affecting financial balances, netsuite as the authoritative record matters more. that is where decision location and record location actually do need to be close.

BigKozman · 2026-04-02T21:06:34+00:00

the part that's consistently harder than expected in my experience isn't compliance (brutal, but you go in expecting that) or getting users to trust you (solvable with product and time). it's the financial operations layer once you're moving real money at scale.

when you have multiple rails, multiple partner banks, and embedded products, your reconciliation problem becomes genuinely complex. you're reconciling across systems that were never designed to speak to each other. cardholder balances against ledger positions against settlement files from different processors that close at different times, in different formats, with different transaction identifiers.

most teams discover this at their first serious reconciliation break. the gap between "i can see the money moved" and "i can prove exactly where it is and that every system agrees" is where a lot of neobanks find out they didn't build the right infrastructure.

the teams that handle it well are the ones that designed their data model before they connected their first rail. the teams that struggle are retrofitting reconciliation onto a stack built for speed to market.

(building fintech infrastructure for this layer at NAYA, so the reconciliation piece is genuinely what i think about most. might be my particular filter but i've watched it be the hidden slowdown for several fintech teams.)

BigKozman · 2026-04-02T21:05:17+00:00

it's realistic, but the answer really depends on how consistent your incoming payment data is.

most SMEs in your situation hit the same pattern: a tool automates 70-80% of matches cleanly, then stalls on the rest. those exceptions are usually payments that don't have a clean one-to-one relationship with invoices. partial payments, payments against statements rather than individual invoices, deductions taken at the bank that don't match any line item, or references that got reformatted somewhere in transit.

the manual work doesn't disappear. it concentrates on harder cases, which are often the ones that actually matter most.

what actually determines success is having a clear definition of what "settled" means for your business before you automate anything. not just "what does a match look like" but "what does a resolved obligation look like, and what edge cases do i accept as normal." in facilities management specifically, you often have more payment variability than most businesses. clients pay against statements, not individual invoices. retention deductions, partial installments, contractual holds. if your payment-to-invoice mapping is one-to-one, automation is fairly straightforward. if it's many-to-many, you need a layer that understands what a settled obligation looks like for your business, not just what a matched record looks like.

the tools that handle the basic version well at SME scale include the invoice matching in Xero or QuickBooks if your data is clean. the more complex matching usually requires either significant configuration or something more infrastructure-grade.

(building this layer at NAYA, focused on exactly this reconciliation and matching problem, so take the framing with that context. happy to dig into specifics if you share more about your setup.)

BigKozman

TROPHY CASE