DEV Community: Mygom.tech

Chat Records Are Running Your Process

Mygom.tech — Wed, 05 Aug 2026 05:31:24 +0000

A customer asks why their order shipped nine days late. The answer exists. It's in a thread from three weeks ago, between two people, one of whom is now on holiday, and finding it depends on remembering roughly what words they used.

That's the whole problem. The decision was made. The reasoning was sound. It just ended up in chat records rather than anywhere you could look it up six months later.

At Mygom.tech we spend a lot of time mapping how work actually moves through a business, and this is one of the most consistent patterns we find: the official process lives in the ERP or CRM, and the real process - the exceptions, the approvals, the judgment calls - lives in chat records nobody planned to rely on. That isn't a discipline problem, and you cannot fix it with a reminder.

So: why work migrates into chat, what chat cannot hold and what that costs you, how to test whether it's costing you anything yet, how to move the record out without asking your team to stop talking to each other, and where AI actually helps.

Chat wins in the moment because it has no schema
Your ERP or CRM has a form. The form has required fields, allowed values, and a fixed set of statuses. That's what makes it useful, and it's also why the exception doesn't fit. And if you don't have an ERP at all - the form is a spreadsheet, and the fixed set of statuses is in someone's head - nothing changes except that you hit this sooner.

A customer wants a partial shipment. A supplier slipped two days and the job needs resequencing. A regular client asks for a discount slightly outside the standard band. The form has no field for any of them. So somebody types the situation into a channel, someone else replies, a decision gets made, and work continues.

Chat accepts anything. That's precisely why it wins at 4 p.m. on a Thursday, and precisely why it fails months later when someone needs to reconstruct what happened.

Four patterns show up almost everywhere we look:

Approval by reaction. A thumbs-up emoji is the sign-off on something with money attached.
Exception handling with no trace. "This one's urgent, skip the second check." Reasonable call. Nothing in the system says the check was skipped, or why.
Status that never travels. The team knows the order is on hold. The system still says in production.
No final version. Three revisions went back and forth in the thread. Nobody can say which one the customer actually received.

All four are people keeping work moving with the fastest tool available. But the fastest tool available is not the same thing as the place the information should live.

What chat records can hold, and what they can't
Chat records are genuinely good at discussion, context, and speed. What they cannot do is hold state. There's no status you can filter on, no owner field you can assign, no due date that can expire and escalate, and no value you can count.

Here's the test we use: can you count last month's exceptions without reading anything?

If answering "how many orders needed a manual override last month, and what were the three most common reasons" means scrolling and reading, you don't have anything you can count. You have an archive. Archives are useful for disputes. They're useless for improving a process, because you can't run the numbers on prose.

That's also why better search isn't the answer. Search retrieves what you already know to look for. A structured record lets you ask questions you hadn't thought of yet.

What it costs when decisions live in chat
The answer nobody can verify. Someone asks what was agreed. Now a person has to go and find out. The problem is not how long that takes - it is what they come back with.

Microsoft's 2025 workplace data shows the average worker receives 153 chat messages and 117 emails every working day. The thread you need from three weeks ago is one of several thousand. So the search usually ends one of two ways. You find something that looks right but turns out not to be the last word. Or you give up and go ask the person who was there, and that person is on holiday.

Both endings lead to the same place. Somebody answers the customer while still unsure. Often the guess holds. Sometimes it doesn't, and you correct it a week later in front of that customer.

That is the real cost. Not the time spent looking. The answer you gave before you were certain.

Worth being honest about the source: that is Microsoft's own product data, it measures office-based knowledge workers, it leaves out EU customers, and Microsoft sells the tool it recommends as the fix. If your team works on a shop floor or in a field rather than at a desk, the volume is lower. The record is worse. A decision made over the phone or across a workbench never becomes a message at all, so there is nothing to search in the first place.

The numbers that leave things out. This is the one that costs real money. It is also the one nobody notices.

If an exception gets handled in chat, it never reaches your data. Your override rate, your late-delivery reasons, your discount frequency - every one of them reads lower than the truth, because the system only counted the cases that fit the form.

Say your dispatch report shows four late shipments last month. Three more slipped too, but someone spotted them early, agreed a new date with the customer in a group chat, and delivered on that. The system only ever saw the new date, so those three never counted as late.

Seven orders missed the date you first promised. Your report shows four.

Four looks tolerable. So you spend the quarter tightening the packing step, while the actual cause - a supplier who confirms late - never shows up in anything you read.

The record that disappears. Chat records run on a clock. Database records do not.

If the approval sits in someone's personal WhatsApp or Messenger, it walks out with them when they leave. It is on their phone. You have no right to ask for it back.

Even a tidy setup has a deadline. Slack lets an admin delete messages on a schedule, and on free workspaces your team can only see the last 90 days. If a supplier dispute comes up in month five, the approval you were counting on may simply be gone.

Nobody deleted it on purpose. It aged out.

There's a fourth cost we've covered elsewhere, so we won't repeat it here: when the only copy of a decision rule lives in one person's head and their sent messages, that person is a single point of failure. We wrote about it in When the Whole Business Runs on One Person.

Try this on your last three exceptions

Before changing anything, find out whether this is costing you. Think of the last three things that didn't go the standard way - an override, a late shipment, a price outside the usual band, a rush job. For each one, answer four questions using only your systems. No asking colleagues. No opening chat.

1. Who decided? Not who typed it in. Who had the authority and used it.
2. When? A timestamp you could show a customer or an auditor.
3. On what basis? The reason, in a form you could count across all three.
4. What changed downstream? Did the price, date, or route actually update where it needed to?

Answer honestly. If all four come out clean on all three cases, your process is in better shape than we usually find, and this article is not your priority.

If your honest answer to any of them is "I'd have to ask someone," you already have your result. The record is in chat, and those exceptions are missing from every report you make decisions from.

You can't fix this by telling people to stop messaging
Attempts to solve this by policy usually fail, and the reason is simple. The exception still doesn't fit the form. Telling people to stop using chat just means the exception stops getting handled. Speed wins, and it should.

So do the opposite. The system holds the record. Chat carries the conversation.

In practice that means a small number of unglamorous decisions:

- One owner field, one status field. Both required, both from a fixed list.
- Exception reason as a picked value, not free text. Five to eight options and an "other." This single change is what turns exceptions from anecdotes into numbers.
- A timestamp created by the system, not typed by a person.
- A link back to the thread. Keep the conversation. It's genuinely useful context. The chat record just stops being the only copy.

One rule decides where things go: anything that changes what happens next belongs in the system. Anything that only explains it can stay in chat.

Not every exception deserves this. If a category comes up a handful of times a year, has no money attached, feeds no report, and nobody downstream needs to know it happened, structuring it is overhead for its own sake. Leave it in chat and spend the effort elsewhere. We would rather say that than sell you a project.

And keep the form small. The instinct is to design a thorough exception record with a field for everything, which nobody completes, which sends everyone back to chat within two weeks. The list above is three fields a person fills - owner, status, reason - and two the system fills by itself. Start there. Add a fourth once the first three are habit.

Once your reason list exists, read it once a quarter. If "other" is the most common reason, the list is missing an option. If one reason accounts for a third of everything, that isn't an exception any more, and it belongs in your standard flow.

Where AI genuinely helps, and where it shouldn't touch this
This is one of the cleaner cases for AI in an operations workflow, because the problem matches what models are actually good at.

The input is unstructured human language. It arrives in no agreed format, and the meaning is obvious to a person and invisible to a database. That is real ambiguity, not disorganisation, and turning it into structure is exactly the job. A model can read a resolved thread and propose the record: exception type, affected order, who decided, what was agreed, what changes downstream. A person confirms it or corrects it in one click.

That matters more than it sounds. It removes the actual reason people skip the form. Nobody avoids structured records on principle. They avoid retyping something they just explained in three messages. If the record drafts itself from the conversation, the friction that pushed the work into chat is gone.

We've built on this pattern before. MYGOM Invoices does the same thing with invoices that arrive as PDFs, photos, spreadsheets and email text, from hundreds of suppliers, in no consistent format.

What AI should not do here is decide. Approval limits, discount bands and routing rules are deterministic, so they stay deterministic. You don't want a probabilistic answer deciding whether a €40,000 order clears. You want a rule, a validation and a log. Use the model where language is messy. Use plain logic where authority is involved. The longer argument for that split is in Process Automation Starts After Process Repair.

What it looks like when it works
Once the record exists, the day goes differently. The customer asks why the order shipped nine days late. Someone opens the order and sees the exception, the reason, who approved it and when. The answer takes thirty seconds, and nobody has to remember anything.

The same record helps in two other places. Your exception numbers start telling the truth, so the reports you plan from are actually about your business. And the next person to meet a case like this can see how the last one was decided, without asking anyone.

Not sure whether your process lives in your system or in your chat records?
The test earlier tells you whether the problem is there. It doesn't tell you what to do about it, and that is the harder question. Some of this is worth fixing and some of it isn't, and the difference is rarely obvious from the inside.
That's what our free 3-minute diagnostic is for. It sorts out whether you need AI, a cleaner process, or a connection between two systems you already pay for.
If you'd rather talk it through, get in touch, or see how we approach this kind of work in AI Integration & Automation.

When One Person Becomes the System

Mygom.tech — Wed, 22 Jul 2026 09:59:08 +0000

There's someone on your team who "does the invoices."

Maybe it's the office manager. Maybe it's someone in accounting. Maybe it's the founder's assistant who picked it up three years ago and never put it down.

Every day - or every week, or every time a delivery comes in - they open an email, pull out a PDF, and start typing. Vendor name. Invoice number. Line items. Amounts. Into the accounting system. Into the ERP. Sometimes into a spreadsheet first, then into the system. Sometimes twice, because two systems don't talk to each other.

Nobody assigned this job formally. It just... settled. Like sediment.

And nobody's fixing it, because nothing's on fire.

This is what's called manual invoice processing - though nobody in your office calls it that. And it costs more than you'd guess.

The Cost of Manual Invoice Processing Isn't What You Think

Ask most business owners what this costs and they'll say: "Maybe an hour a day. Not a big deal."

Run the actual numbers and it looks different.

Industry benchmarks from Ardent Partners and APQC put the fully-loaded cost of manual invoice processing at $13-$20 per invoice - once you account for the person's time, the error correction, the back-and-forth with vendors, and the occasional late payment because something got missed in the pile.

If you process 200 invoices a month, that's $2,600-$4,000. Every month. For a task that feels like background noise.

But the money is almost the smaller problem.

Three Things That Are Actually Happening

Time that compounds quietly. An hour a day is 20 hours a month. That's two and a half working days. For one person. On one task. That produces zero insight, zero relationship, zero strategy - just data moving from one place to another. That person is probably good at their job. This isn't it.
Errors that hide until they hurt. Manual data entry has an error rate of around 1-4%, measured per field entered. On invoices, that means wrong amounts posted, wrong vendors matched, wrong VAT codes applied. Most errors don't surface immediately. They surface during reconciliation, during audit, or when a vendor calls asking why they haven't been paid. By then, the original entry is weeks old and the person who made it doesn't remember the context.
The process lives in one person's head. This is the fragility nobody talks about. Your invoice person knows which vendors send PDFs in weird formats. They know that Supplier X always puts the total on page 2. They know to ignore the "draft" watermark on a certain client's documents because that's just how they send things. They know the workarounds.

None of that is written down anywhere.

They go on holiday for two weeks. What happens? Either someone else muddles through and makes mistakes, or invoices pile up until they're back. Either way, you've just discovered that a critical business process is a single point of failure - and you only found out because someone took a vacation.

Why This Specific Task Is One Software Actually Does Well
Most automation hype is exactly that - hype. "AI will transform your business." Sure. Maybe. Eventually.

But reading a document and moving structured data into a system - the heart of manual invoice processing - is genuinely one of the narrow categories where software outperforms humans - not because humans are bad at it, but because humans are too good at other things to be wasted on it.

The task has clear inputs (a document), clear outputs (fields in a system), and clear rules (this field goes here, that number goes there). It repeats hundreds of times. It doesn't require judgment, relationship, or creativity.

It requires patience and accuracy. Software has infinite patience and doesn't make typos.

The Honest Part: "AI Can Do This" ≠ "You Need AI"
Here's where we'll say something you probably don't expect from a software company:

Sometimes you don't need AI. Sometimes you don't need automation at all.

A few scenarios we see regularly:

The systems already talk - nobody set it up. Your accounting software and your ERP have a native integration that's been sitting there unused for two years. The fix is a half-day configuration, not a custom build.

The process is broken first. Automating a broken process doesn't fix it - it just breaks it faster, at scale. If invoices are being entered in three different formats because nobody standardized the intake, automation will faithfully replicate that chaos. The cleanup has to come first.

The volume doesn't justify it. If you're only processing ten invoices a month, the math probably doesn't work. Manual entry takes maybe half an hour. Automation costs money to build and maintain. Do the arithmetic before you commit.

It genuinely pays for itself. If you're processing 500+ invoices monthly, have two people doing it, and errors are causing payment delays - the ROI is real and fast. We've seen setups where the automation pays for itself within a couple of months.

The only way to know which scenario you're in is to look at the actual process. Not the idea of the process. The actual one.

How to Tell If Your Process Is Worth Automating
You can get most of the way there on your own, before anyone else gets involved. A few honest signals tell you most of what you need to know.

Start with volume. If this happens more than fifty times a month, it's worth a closer look. If it's ten, it probably isn't.

Then look at how digital the data already is. Invoices arriving as clean PDFs or emails are far cheaper to work with than handwritten forms or scanned paper. The more digital the input, the lower the cost to fix.

Ask what a mistake actually costs. An error caught and fixed in two minutes is low stakes. One that turns into a payment dispute, a VAT filing error, or a strained supplier relationship is not.

Weigh how stable the process is. Formats and systems that change constantly are expensive to automate and keep running. Predictable ones stay cheap.

And finally, the signal that never shows up in a spreadsheet: if one person being out sick for a week would break this, that fragility is a real cost - whatever the numbers say.

If you're nodding at three or more of these, it's worth spending twenty minutes actually mapping what's happening.

How to Actually Find Out
We built a free 3-minute diagnostic for exactly this.

Not a sales funnel. Not a lead capture form dressed up as a tool. An actual diagnostic - you describe one process, we give you an engineer's read on it.

Three possible outcomes:

Quick win. The fix is simpler than you think. Maybe it's a native integration you didn't know existed. Maybe it's a small script. You'll know in the first conversation.

Clean up first. The process needs standardizing before automation makes sense. We'll tell you what needs to change and why - whether you work with us or not.

Not worth it. Sometimes the honest answer is: the volume doesn't justify the cost, or the process is too unstable, or there's a cheaper fix. We'll say that. We'd rather tell you now than build something that doesn't pay off.

No pitch at the end. No "but if you sign up today..." Just an engineer's read on your specific situation.

If you have someone on your team who "does the invoices" - and you've never actually looked at what that costs - it takes three minutes to find out whether it's worth changing.

Start the free diagnostic.

For the wider picture of where this kind of work hides across a business, we mapped it here.

Where Your Team Loses Time to Manual Work

Mygom.tech — Wed, 08 Jul 2026 14:03:05 +0000

The problem nobody talks about
There's a type of work that doesn't show up in any job description.

It's the person who rebuilds the same report from three different Excels every month. The one who manually uploads invoices into the accounting software because nobody connected the two. The one who copies an order from an email into the CRM, then into the ERP, then sends a confirmation back.

Nobody decided this was their job. It just became their job.

And the strange thing is - it rarely feels like a crisis. The work gets done. Deadlines are met. So the question never gets asked: why is a person doing this at all?

Six places where company time disappears
We've worked with enough teams to know where this usually hides. It's almost always one of these six:

1. Documents, invoices, and accounting software. Someone is manually uploading invoices(opens in new tab), contracts, or delivery notes into a system that could receive them automatically. The document arrives. A human opens it, reads it, types it in. Every time.

2. Reports and KPIs. The monthly report gets assembled by hand - pulling numbers from one spreadsheet, copying them into another, formatting, double-checking. It takes hours. It happens every month. The data exists; the process to combine it doesn't.

3. Client communication. Enquiries land in a shared inbox and wait. Someone reads them, decides what they are, forwards them, or responds. There's no triage, no routing, no acknowledgment. Just a queue that depends on whoever checks the inbox first.

4. Internal / business operations. An order enters the company and travels through it by copy-paste. From email to CRM. From CRM to ERP. From ERP to the team chat. Each step is manual. Each step is a chance for something to go wrong - and those errors add up: Gartner estimates poor data quality costs organizations an average of $12.9 million a year.

5. Sales and proposals. Proposals take longer to prepare than clients are willing to wait. The information exists - past projects, pricing, scope - but assembling it into something sendable takes days. By then, the conversation has cooled.

6. Production and pricing. There's a spreadsheet that calculates costs and timelines. One person built it. One person understands it. It's a bottleneck nobody notices - until they're unavailable, and the process stops.

And here's the part most won't tell you: sometimes the fix isn't AI at all.

Why most companies don't fix this
It's not that people don't notice. It's that the fix feels uncertain.

Do we need AI? A new system? An integration? A consultant who'll spend three months mapping things out and hand us a PDF?

The honest answer is: it depends. And the risk of guessing wrong is real - Gartner found that at least half of generative AI projects get abandoned after proof of concept, often because the data or process underneath wasn't ready. Most of the time, nobody gives you an honest answer before you've already spent something.

That's the part we wanted to change.

What we actually do

We built a 3-minute diagnostic to figure out which category your process falls into - before anyone spends time or money.

Not a score. Not a benchmark against industry averages. An engineer's read on your specific situation - where the process bottlenecks actually are, and whether they're worth fixing.

Sometimes the answer is: you don't need AI. An integration between two systems you already have would solve 80% of the problem.

Sometimes it's: the process needs cleaning before anything can be automated. Automating a broken process just makes it break faster.

Sometimes it's: yes, this is exactly the kind of thing that pays back quickly - and here's what the first step looks like.

The diagnostic is free. The "it's not worth it" answer is also free.

What happens after the diagnostic
If there's potential, we offer three ways to go deeper:

Quick Look - a short, focused review of one specific process with an engineer who actually implements things. You leave with a clear "do it / don't do it" and a scope for the first step.

Structured Audit - a full review of a workflow from end to end: what's actually happening, where time disappears, and what the simplest fix is. Not a theory. A plan.

Deep Dive - for processes where mistakes are expensive and the stakes are high. We go to the data level. We map exceptions, edge cases, and failure modes before recommending anything.

Audit cost gets credited toward implementation. You don't pay for clarity twice.

One thing worth saying clearly

We implement what we recommend.

That matters more than it sounds. It means we don't suggest AI where an integration is enough, because we'd have to build and maintain whatever we recommend. It keeps the advice honest.

We work with the systems you already use: ERP, accounting software, CRM, email, documents, Excel, custom internal tools. We don't ask you to replace anything before we understand what's actually broken.

The goal is simple: less time on manual work, and more on the kind of productivity improvement that actually moves the business.

If you're not sure where to start
That's exactly what the diagnostic is for.

Three minutes. A few questions about your process. An honest answer about whether it's worth going further - and if so, what the next step actually looks like.

No scores. No pitch. Just an engineer's read.

Start the diagnostic.

AI Audit: Find Growth & Cut Costs

Mygom.tech — Thu, 02 Jul 2026 06:09:26 +0000

AI Audit for Businesses: How to Identify Growth Opportunities and Prevent Financial Losses
Most companies can feel something is slowing them down. They just can't point to it precisely enough to fix it.

So they buy another tool, run another training, and wait for something to change.

An AI audit begins with a map of how work actually moves through your business. Once you can see where it stops, you can see exactly where AI helps - and where it doesn't.

What an AI Audit Actually Is
An AI audit is a structured review of your workflows, systems, and team processes to identify where automation can reduce time, cost, or risk - and where it can't.

It's not a technology assessment. It's not a vendor comparison. It's not a roadmap for replacing your team.

It's a diagnostic. You walk in with a list of problems. You walk out with a ranked list of opportunities - each one with a time estimate, a cost estimate, and a clear answer to the question: is this worth building?

The output isn't a slide deck. It's a decision.

The Two Things an Audit Finds
Every audit we run surfaces the same two categories.

Growth opportunities - processes that are working, but slowly. The team is doing the job. It's just taking 3x longer than it should. These are the workflows where automation compounds: faster output, more capacity, same headcount.

Financial leaks - processes that are quietly costing money. Errors that get caught late. Decisions made on stale data. Work that gets duplicated because two systems don't talk to each other. These don't show up on a profit and loss statement. They show up in overtime, rework, and deals that close slower than they should.

Most companies have both. The audit tells you which ones to fix first.

What We Look For
When we map a business's workflows, we're looking for five signals:

1. Manual data movement. Someone is copying information from one system to another. Every time that happens, there's a delay, a potential error, and a person whose time is being spent on something a script could do in seconds.

2. Decisions made on delayed information. Managers making calls based on reports that are 24-48 hours old. Production floors running on yesterday's numbers. Sales teams working from CRM data that's a week behind. The decision isn't wrong - the data is.

3. Inconsistent output quality. The result depends on who does the work. A senior person produces one outcome. A junior person produces another. The process leaves too much room for interpretation. Fix the process, and the gap closes.

4. Bottlenecks tied to one person. One person who knows how the process works. One person who has to review, approve, or touch every output before it moves forward. This is a risk most companies don't price correctly - until that person is unavailable.

Tools that don't talk to each other. Three systems, three logins, three exports. The data exists. It just lives in the wrong place. Integration isn't glamorous, but it's often where the fastest wins are.

Processes We've Already Mapped
The audit ends with a clear list of what's worth building - and what to build first. Some clients take that and build it themselves. Others bring us in. Here's what that's looked like in practice.

Invoice Processing
A finance team was processing invoices manually - reviewing, matching, approving, filing. The work wasn't complex. It was just constant.

After mapping the workflow, we identified the specific steps that could be automated without removing human judgment from the decisions that actually needed it.

Result: 40% less time per invoice. 10x output per person. 30% reduction in software spend from consolidating tools that were doing overlapping jobs.

Proposal Generation
A sales team was spending 3-4 hours on every proposal. Senior people. High-value time. Spent on a document that followed the same structure every time, pulled from the same data sources, and required the same calculations.

We built an internal tool that generates Commercial Proposals, Technical Specifications, and Public Procurement documents in 30-60 minutes. Same quality. Every time. Without the senior person having to start from scratch.

What Makes a Process Worth Automating
Not every workflow should be automated. The audit is as much about ruling things out as it is about finding opportunities.

A process is worth automating when:

It happens frequently (daily or weekly, not once a quarter)
The steps are consistent enough to define (even if they're complex)
The cost of errors is high - in time, money, or quality
The current approach doesn't scale with headcount

A process is not worth automating when:

It changes constantly and has too many exceptions to map
The judgment required is genuinely contextual and hard to define
The volume is low enough that the build cost outweighs the savings

This is the conversation we have before we write a single line of code. No-code platforms skip this step - they assume your process fits their template. Most of the time, it doesn't. That's why they tend to fail on exactly the workflows that matter most.

The Cost of Not Auditing
Here's what we see when companies skip this step.

They automate the wrong thing first. They pick the process that feels most painful, not the one with the highest ROI. They spend 3 months building something that saves 20 minutes a week.

Or they buy a platform. They configure it for their current workflow. Six months later, the workflow changes, and the platform can't follow. Now they're locked in, paying for a tool that owns their process instead of serving it.

Or they do nothing. The manual work continues. The errors accumulate. The senior people keep doing junior work. The business grows, and the operational drag grows with it.

An audit doesn't cost much. The processes it prevents you from building wrong cost significantly more.

How We Run an AI Audit
Our audit is fast, focused, and covers three things:

Workflow mapping - we document how work actually moves through your business. Not how it's supposed to work. How it actually works, including the workarounds, the exceptions, and the manual steps that nobody has written down.

Opportunity scoring - each identified process gets scored on frequency, complexity, error cost, and build effort. This gives you a ranked list, not a flat one.

Build recommendation - for the top opportunities, we outline what a solution looks like, how long it takes to build, and what it's likely worth.

You get a decision-ready document, and we walk through it with you - so you're not left interpreting a report on your own. You know what to build, in what order, and why.

What Comes After the Audit
The audit is the map. What you do with it depends on what you find.

Some clients take the output and build internally. Some bring us in to build the first automation and hand it off. Most ask us to build the top two or three - the ones with the clearest ROI - and then reassess.

The builds are specific. Scoped to a single workflow. Delivered in 2-4 weeks. Deployed in production, not in a sandbox.

If There's a Process Eating Your Team's Time Right Now
You probably already know which one it is.

The one that takes longer than it should. The one that depends on one person. The one that works fine until it doesn't.

Send us the process. We'll map it out. No pitch, no obligation - just an honest look at what's happening and whether it's worth fixing.

Let's talk.

Why AI Projects Fail, and How to Succeed

Mygom.tech — Mon, 29 Jun 2026 14:16:17 +0000

You've seen the number. "95% of AI projects fail." It's in the keynotes, the LinkedIn threads, the "AI is just a bubble" takes - repeated far more often than it's actually read. And if you run a business and you've been cautiously circling AI - maybe your team has ChatGPT, maybe you tried a tool and nothing really changed - that number is the perfect excuse to wait. If nineteen out of twenty projects flop, why risk yours?

Here's the problem with that conclusion. We went back to where the stat actually comes from. The number is real, but it doesn't say what the headline says. Read properly, it's not a reason to wait. It's a map of exactly how to not waste your money.

Where the number actually comes from
It traces to a single source: MIT Media Lab's Project NANDA report, The GenAI Divide: State of AI in Business 2025. Almost everyone repeating "95%" is quoting a headline about it, not the report itself.

And what it measured matters. The study judged AI pilot outcomes by a single yardstick - measurable impact on profit and loss. It didn't find that 95% of AI models broke or didn't work. It found that about 5% of pilots drove rapid revenue acceleration, while the vast majority delivered little to no measurable impact on profit and loss. That's a measure of AI value realization, not technology failure. The AI usually ran fine. It just didn't move the business - which is a very different, and far more fixable, problem.

The number is messier than the headline
Once you look closely, the clean "95%" gets blurry.

It's drawn from a subset. The failure figure comes specifically from custom, task-specific GenAI tools - meanwhile around 40% of companies that piloted general-purpose LLMs successfully got them into production. Even the study's own methodology gets reported inconsistently across outlets - some cite 150 executive interviews, 350 employee surveys, and 300 deployments, others cite far smaller numbers. And critics have pushed on the rigor: one widely-shared critique argued that if MIT stands behind the claims it should release the full supporting data, and if not, retract the report.

None of this means the study is worthless. It means the honest version of the stat is "most enterprise GenAI pilots haven't yet produced measurable financial returns" - which is true, sobering, and a lot less clickable than "95% fail."

Consider who's selling the cure
There's one more thing worth knowing. The report concludes that the fix is more agentic AI - built on protocols that NANDA itself develops. Even Fortune, which covered the study seriously, added the caveat: NANDA has an incentive to suggest current methods aren't working, so it's worth considering the source.

That doesn't make the findings wrong. It's just a reminder that the loudest AI statistics often come from someone with something to sell - including, fairly, vendors like us. Which is exactly why the next part matters more than the number.

The real reason AI projects fail
Skip the headline and read what the study says about why pilots stalled. It's the most valuable thing in the report, and it gets repeated far less than the number itself.

When AI projects fail, it's rarely the model that broke. MIT described a "learning gap" - organizations didn't know how to design workflows that capture AI's value. In other words, the tool worked; the process around it didn't exist. That lines up with what every serious analysis of these failures keeps finding: the failure is rooted not in flawed models but in poor integration and misaligned priorities.

Then there's the misallocation, and this one is worth reading twice: more than half of AI budgets go to sales and marketing tools, yet MIT found the biggest ROI in back-office automation - eliminating outsourcing, cutting agency costs, and streamlining operations. Companies chase the flashy customer-facing use case and underfund the boring internal one that actually pays.

And finally, on how the winners got there: buying from specialized vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded only one-third as often.

What this actually means if you're on the fence
Put those three findings together and the picture flips. Most AI projects fail not because the technology is weak, but because of how they're chosen and run. AI project success didn't come down to better models - everyone has access to the same ones. The 5% who got there did three unglamorous things: they picked a process worth automating, they defined what a win looked like before building, and they integrated the tool into how the team already works instead of bolting it on the side.

The 95% bought a tool and hoped.

We know this pattern because we hit it on ourselves. Our own back-office was the mess - invoicing split across five tools that didn't talk to each other. We didn't start with "what AI can we add." We mapped where the time actually went, then built one system around it: 40% faster processing, 30% lower spend on the tools it replaced, and 10x the volume with no extra headcount. Boring, internal, back-office - and exactly the category MIT says delivers the highest return. We only took it to clients once it worked for us.

How to land in the 5%
If there's one practical takeaway from a much-abused statistic, it's this: don't start with AI. Start with the work.

Map where your team's hours actually go. Find the one process that quietly eats time every week and runs mostly on manual judgment you could codify - usually it's invoicing, reporting, or data being copied between systems. Define what success looks like in plain numbers before anyone builds anything. Then automate that one thing, integrated into your existing stack, and prove the number before you scale. AI projects fail when teams skip that and start with the tool instead.

That's the whole difference between the 5% and the 95%. Not the model. The process underneath it.

That mapping step is exactly what an AI audit is for - an honest look at where automation would actually pay off, and where it wouldn't. Sometimes the answer is a system. Sometimes it's a simpler fix, and sometimes it's "you don't need AI here yet." We'd rather tell you that than sell you into the 95%.

The AI Tax: What Your SaaS Renewal Actually Costs in 2026

Mygom.tech — Tue, 23 Jun 2026 12:19:32 +0000

The email arrived on a Tuesday.

Subject line: Your renewal is coming up - here's what's new.

Buried in paragraph three, after two paragraphs about "exciting AI-powered capabilities," was the number: +31%.

No opt-out. No line-item breakdown. Just a new price, a new SKU, and a deadline.

Your team didn't ask for AI features. Half of them don't use the ones already bundled in. But the vendor has decided that 2026 is the year everyone pays for the future - whether they're living in it or not.

This is the AI Tax. And if you haven't run the real math on it yet, this article is that math.

What Just Happened to Enterprise Software Pricing
In early February 2026, software stocks went through one of their worst stretches on record. Over roughly a week of selling that began in late January, the S&P 500 software and services index fell for six straight sessions and shed close to a trillion dollars in market value - Reuters put the figure at about $830 billion. The trigger wasn't an earnings miss. It was a product launch: Anthropic shipped industry-specific plug-ins for its Claude agent across legal, finance, sales, and data analysis.

Investors did the math in public. If an AI agent can review a contract, reconcile a ledger, or pull together market research, why keep paying per seat for the software built to do that work?

The damage was concentrated where the threat was clearest. Thomson Reuters, which owns the Westlaw legal database, dropped about 16% in a single day - its biggest one-day fall on record. Financial-data and legal-research providers led the slide. The selloff was a verdict on the per-seat model itself: even vendors with growing revenue got repriced, because the question wasn't "are they growing now," it was "what happens to seats when agents do the work."

The vendors know this. Which is why they're doing something counterintuitive: raising prices before the floor gives way. Lock customers into higher-value contracts now, bundle AI features in before customers realize they could build their own, and make switching feel expensive. The renewal letter in your inbox isn't a coincidence. It's a strategy.

The Five-Bucket Cost of Staying
When a software subscription is up for renewal, everyone focuses on one number: the new price. But that's not what staying really costs you. The full cost is spread across five areas, and they rarely get added up together.

Bucket 1: Seat growth. Your team grew last year. Your software bill grew faster. Paying per seat made sense when every seat was a person doing the work. But you're now paying per seat for software that increasingly does the work for your people, so you're paying for access, not for results. On average, companies now spend over $8,000 per employee per year on software, and that number climbs with every new hire and every new tool you add.

Bucket 2: The AI uplift. This is the new charge - the one that wasn't on your bill two years ago. Microsoft is raising Microsoft 365 prices on July 1, 2026, with most business plans going up 5-9% and some plans jumping as much as 43% - all because of bundled Copilot and security features. Salesforce now charges about $0.10 every time its AI takes an action, on top of what you already pay per seat. The pattern is the same everywhere: AI gets bundled in, the price goes up, and you can't say no. You're not buying AI. You're being charged for it.

Bucket 3: Middleware and integration. No tool works on its own. Every one comes with a hidden layer behind it - the Zapier workflows, the Make automations, the custom connectors that hold everything together. None of this shows up on the invoice, but all of it shows up in your engineering team's workload. Every time a vendor changes its software (which happens more often now, because AI features need it), something breaks and someone has to fix it. For a mid-size company running 15-20 tools, that quietly adds up to dozens of engineering hours a year - hours that never appear on any renewal quote.

Bucket 4: Admin and governance. Roughly a third of all software licenses sit unused. That's not a small leak - it's a third of your budget paying for seats nobody touches. And managing the waste takes time too: checking who has what, removing access when people leave, reviewing licenses, handling the vendors. In most companies this falls on someone who already has another job. It's easy to ignore - until it isn't.

Bucket 5: Reconciliation and compliance. Pay-as-you-go pricing - the direction Salesforce and others are heading - sounds fair until the bill arrives. When you're charged per action, per call, per conversation, your finance team has to check usage against budget every single month. That's extra work that didn't exist with a flat fee. And if you're an EU company, add the legal review every time a vendor updates its data terms - which AI features set off constantly.

None of this shows up on the headline price. All of it shows up as a drag on your operations.

The Build Math Nobody Runs
Here's the question CFOs should be asking but rarely do: what would it cost to own this instead?

Not "what would it cost to rebuild the entire platform" - that's the wrong question. The right one is narrower: which specific workflows are we paying this vendor to run, and what would it cost to build those once and own them?

We've run this math on ourselves.

What we learned building Mygom AI Invoice Automation Platform
At Mygom, invoicing was eating our time. The work was scattered across a mix of tools that didn't talk to each other, and it only got heavier as we grew. So we built our own system to handle it - Mygom AI Invoice Automation Platform - first for ourselves, then for clients.

The results:

- 40% faster invoice processing
- 30% lower spend on the tools it replaced
- 10x the volume handled, without adding headcount

And one more result that doesn't fit in a number: no renewal letters, no AI Tax, no forced plan changes. We run it on our own infrastructure. When we want to change something, we change it - we don't wait for a vendor's roadmap or pay a fee for every document.

The savings grow over time. In year one you roughly break even. By year two you're ahead. By year three you're well ahead, and the gap gets wider every time a vendor raises its price. We've since done the same for our sales team, building a tool that writes our proposals(opens in new tab). Same idea, different job.

How to run the math on your own renewal
You don't need our tools to use our approach - just four steps. (Treat the numbers below as rough ranges, not a quote. Your real figures depend on the job, and this isn't financial advice. The point is to run the comparison.)

Pin down the tasks you actually use. Most teams use only 20-30% of what a tool can do. Find the three to five tasks that give you most of the value. Those and only those - are what you'd build.
Get a build estimate. Building one focused tool is a far smaller job than replacing a whole platform - smaller than most people expect. Get a real number from someone who builds for production before you decide it's too expensive.
Add up three years of staying, not one. Start with this year's cost. Add the AI increases (assume they keep climbing - recent ones have run from a few percent to well over 30% in a single year). Then add the middleware, admin, and compliance costs from the five buckets above. That's what staying really costs.
Compare the two. For most higher-priced tools, building your own pays for itself within a couple of years. After that, every year is money saved. The math isn't hard. It just needs someone to actually do it.

This Isn't the Lock-In Conversation
You may have read the big-picture case for owning your software instead of renting it. This isn't that article.

This is a money question with a money answer. Not "should we be against SaaS on principle?" but "is this particular renewal worth signing, or is there a better use of the money?"

What changed is the AI Tax. Renewals used to be predictable - a small increase, a high cost to switch, so staying made sense. That's no longer reliable. Now you get sudden price jumps, AI features you pay for whether you use them or not, plan changes that scrap the tier you were on, and usage fees that are hard to predict. The cost of switching hasn't changed. The cost of staying has gone up. And that changes the decision.

What To Do Before You Sign
Not every tool is worth replacing. Email, calendar, and other everyday tools are usually cheaper to rent. Build the things where owning clearly wins - and walk into the renewal knowing which is which.

Before your next renewal, do four things:

- Add up all five buckets. Don't just read the invoice. Include seat costs, AI increases, middleware, admin time, and compliance. The real number is usually well above the price on the page.
- Write down your most-used features. The two or three features that give you most of the value are your plan if you decide to build.
- Get a build estimate before you sign - even if you don't build. Having a real alternative number changes the conversation. Vendors treat you differently when you can honestly say "we've already priced the alternative."
- Use the leverage you have. Vendors are raising prices because they're under pressure, which is exactly when a renewal, plus a real build option, gives you room to push back. Build when a tool is core to your business, used for just a few key tasks, and keeps getting more expensive. Stay when it's basic, tied deeply into everything else, or the AI features genuinely earn their cost. Negotiate everywhere in between.

Why Owning Pays Off More Each Year
The biggest benefit of owning your tools isn't the money you save in year one. It's what builds up after that.

Every year you own a tool, you understand it better and keep improving it. You add the features your business actually needs, not the ones on a vendor's roadmap. And what you learn stays with you, in your own system, instead of in someone else's.

Mygom AI Invoice Automation Platform didn't just save us money. It became proof. When we tell a client we can build automation that's ready for real use, we're not selling an idea - we're showing them something we rely on every day that clearly works. The vendor's AI Tax pays for their roadmap. Your build pays for yours.

The Bottom Line
The renewal letter in your inbox isn't just routine paperwork. It's part of a bigger shift: software vendors are raising their prices for the AI era, and customers are paying the difference - whether they use the AI or not.

The math has changed. The question is whether the way you make the decision has changed with it.

Add up the five buckets. Look at three years, not one. Get a build estimate. Then decide.

At Mygom, we help growing companies run exactly this analysis - and where the numbers make sense, we build the custom tools that replace the rented ones. We did it for ourselves (40% faster, 30% lower spend), and we've done it for clients across the EU, UK, and US. If you're looking at a renewal that doesn't feel right, let's talk(opens in new tab).

When the Whole Business Runs on One Person

Mygom.tech — Tue, 16 Jun 2026 07:07:13 +0000

Key Person Dependency - When a Business Runs on One Person
It's 7:30 a.m. on Tuesday. Your production planner is out sick. The schedule still exists in the ERP. But nobody else trusts the dates on screen. Only that one person knows which supplier always slips three days, which job can be split mid-run, and which customer will accept a partial shipment. Without them, purchasing stalls. Quotes wait. Invoices pile up.

In a lot of companies this feels normal - especially during growth, when speed beats documentation. Right up until the delays turn into real cost.

It's called key person dependency, and it's a recognised business risk, not a minor inconvenience - the same kind of "single point of failure" you'd find in engineering. The only difference is that here the failure point is a person, with their own holidays, health, and life plans.

Why the problem looks small until production stops
A bottleneck is easy to spot - work pauses the moment one employee is unavailable. Updates need a phone call, not a process. Decisions change depending on who you ask. And the customer feels the slowness, because order status depends on chasing one person instead of checking a stable workflow.

The first cost is obvious - output drops. What hurts longer is what nobody budgets for. Supervisors get pulled into routine clarifications. Approval cycles stretch. A new hire needs weeks to learn the exceptions nobody wrote down. Without clear process, small delays multiply across quoting, planning, purchasing, and accounts payable.

Why holidays become a threat to the business
Leave should be routine. In many growing companies, it isn't. Annual leave turns into stalled approvals and schedules nobody updates. Sick leave is worse - there's no time to hand anything over.

And here's the point that's easy to miss: if daily work runs on memory, there is no real cover. A plan doesn't need a thick binder. It needs clear steps, a named backup, and rules a person can follow even under pressure.

"We don't need a system - we have someone who knows everything"

We hear this constantly. It sounds practical. But it isn't a solution - it just means the risk hasn't gone anywhere. It's quietly sitting on one person's shoulders.

Key person dependency rarely starts with bad management. It starts as a sensible response to pressure: orders grow, customers want answers today, and the fastest path is to let your most capable person handle it. For a while, it works. The planner keeps the rules in their head, the estimator remembers which job needs more margin, the finance lead knows which supplier invoice always breaks the usual flow.

Map almost any quoting process and you'll find the same thing: the real logic isn't in the ERP. It lives in one person's inbox, memory, and judgment. Everyone assumes there's a system. There is. It's a person.

A related version of the same friction - a sheet metal manufacturer whose quoting ran on manual back-and-forth - emails, files, and one slow estimate at a time. The fix wasn't more people, it was turning quoting into a self-service flow that prices a part the moment the customer configures it.

The same goes for the "master Excel file" - when the entire business logic is packed into one spreadsheet only its author understands. While they're working, everything runs. When they leave, the logic walks out with them.

Process first, technology second
This is the most common mistake: software gets bought before anyone defines the actual rules. But the truth is simple, a bad process scaled by software is still a bad process. Just faster, and more expensive.

So the order matters: process first, technology second. In practice that comes down to four steps - whether you do it yourselves or bring someone in.

First, map the real process - not the one drawn on the whiteboard. With the actual triggers, stops, approvals, and the spots where people decide "from memory" because the rules are vague.

Second, capture the rules, exceptions, and handoffs - turning what used to be one person's knowledge into a shared, repeatable method. Exceptions matter most here, because they usually create the heaviest workload.

Third, decide what should stay manual. Not everything should be automated. An experienced buyer will catch a risky substitution faster than any form. Automation helps when rules are clear and outcomes repeat, and helps less when the decision depends on experience or a client relationship.

Fourth, automate only what's stable and repeatable. Sometimes that's simple approval routing. Sometimes invoice capture. Sometimes - no new system at all.

What it actually delivers
The strongest proof isn't that software exists. It's that daily work changes.

In our invoice automation project, we mapped the real flow first - the handoffs and the awkward exceptions people handled from memory. Once the process was clear, automation made sense: invoice processing became roughly 40% faster, software spending dropped about 30%, and each person could process ten times more invoices.

We saw the same pattern building our proposal tool. The real blocker wasn't a slow interface - it was key person dependency. One experienced person carried the rules and judgment in their head. We moved that logic into a system anyone could follow. Proposal creation(opens in new tab) dropped from 3-4 hours to 30-60 minutes. Just as important, the work became easier to repeat, easier to delegate, and far less fragile when that person was away.

A practical first step
The response doesn't have to be dramatic. Start with the five processes that matter most to your output, cash flow, or customer service. For each, ask simple questions: Who actually knows how it works? Where do exceptions pile up? What happens if that person is off for a week? Is the process written down, or is it just habit and memory?

That review alone will show you where your business quietly depends on one person, and where automation might help later.

If the process is still unclear, fix that first. Then decide whether a lightweight tool, automation, or no new technology at all is the right move. If you'd like a second pair of eyes on those five processes, get in touch(opens in new tab) and we'll talk through the practical next step.

Why Most AI Projects Fail - And How to Avoid It

Mygom.tech — Fri, 12 Jun 2026 12:37:30 +0000

Why Most AI Projects Fail Before They Start
Chatbot for support. Dashboard for sales. Maybe an AI tool that summarizes meeting notes. These are the first moves most businesses make — and most of them quietly get abandoned six months later.

Not because AI doesn't work. Because nobody stopped to ask whether those were actually the right problems to solve.

An IBM CEO study found that only around 25% of AI initiatives deliver expected ROI, and just 16% have scaled enterprise-wide. MIT's Project NANDA tracked over 300 AI initiatives and found that 95% of organizations deploying generative AI saw zero measurable return. The failure is almost never the model. It's what happened before the build started.

The Real Problem - Skipping Discovery
The pattern behind most failed AI projects is the same. Someone decides AI is the answer before they've defined the question. A tool gets selected, a vendor gets hired, and only then does anyone sit down with the people doing the actual work.

The most common reason AI projects fail is that they are launched without a clear business problem definition. When the mindset of "let's use AI" comes before answering "what problem are we solving and what value will we create," projects quickly lose direction.

According to a Gartner survey of 782 infrastructure and operations leaders, among those who deliver at least one successful AI use case, success is attributed primarily to integrating AI into existing workflows and securing full support from business executives - not to the technology itself.

The companies that get results don't start with tools. They start with workflows - real ones, not the idealised version on a process diagram.

What Good AI Project Discovery Actually Looks Like
The difference between AI that works and AI that doesn't usually comes down to what questions were asked upfront.

Not "what AI tools are available?" but: where does work actually slow down? Where do people have workarounds they've stopped noticing? What tasks get done inconsistently depending on who's doing them?

These questions don't live in a spreadsheet. They surface when you sit with the people doing the work - watching, listening, mapping the friction that's become invisible through familiarity.

PwC's 2026 AI predictions note that companies seeing real returns link business goals to AI capabilities through structured frameworks for assessing use cases, not by copying what competitors are doing, but by mapping unique pain points to targeted solutions.

That last part matters. Generic AI transformation doesn't exist. What exists is your specific process, your specific data, and your specific bottlenecks. Everything else is just someone else's solution to someone else's problem.

Our Example - From Manual Chaos to One Clean Workflow
We know what this looks like in practice because we've been through it ourselves.

Our own invoice process was barely holding together. PDFs were being downloaded, renamed, forwarded for approval, and then retyped into another system. On a quiet week it looked manageable. When volume picked up, the whole thing started cracking.

The instinct in that situation is usually to add another tool - something for OCR, something for approvals, something to fill the gap. We pushed against that. Instead, we mapped the entire journey from when an invoice arrived through to final approval, identified exactly where the friction was, and built one workflow that handled all of it. No second tab. No new login.

The hardest part wasn't the build. It was staying disciplined about what not to add. There were plenty of nearby problems we could have solved and features that would have looked good in a demo. But the point was to fix the high-friction part - not to build a finance suite.

We built it for ourselves first, proved it worked, and now deploy the same tool for other teams facing the same problems we had.

That discipline - starting with real friction, building only what solves it, nothing more - is the same approach we bring to every automation assessment.

Where This Is Heading in 2026
Gartner projects that by the end of 2026, 40% of enterprise applications will include task-specific AI agents, and year-over-year spending on AI is expected to grow 31.9% between 2025 and 2029. The investment is accelerating regardless of whether the discovery work is done.

According to BCG, companies plan to spend 1.7% of revenue on AI in 2026 - more than double the 0.8% spent in 2025. Yet less than 1% of executives report significant ROI.

That gap between spend and return is where most of the risk lives. And it's almost entirely avoidable if the right questions get asked before anything gets built.

What We Do Differently

At Mygom, we don't start with a tool recommendation. We start by understanding how your team actually works, where the time goes, where errors repeat, where people have built unofficial workarounds to get through the day.

From that, we identify which processes are genuine automation candidates: high volume, rule-based, currently manual, and painful enough that fixing them actually changes how people work. Then we build exactly that, and nothing more.

That's how AI gets adopted. Not because it was announced, but because it makes someone's day genuinely easier.

If you want to know where automation could make a real difference in your business - let's talk.

Claude Fable 5: What It Means for Teams Using Claude

Mygom.tech — Wed, 10 Jun 2026 10:18:40 +0000

Claude Fable 5 Just Launched. Here's What It Means for Teams Building With Claude
On June 9, 2026, Anthropic released its most powerful public model yet - Claude Fable 5. The same day, the company released Claude Mythos 5 - the same underlying model with some safeguards lifted, available only to vetted cybersecurity partners through Project Glasswing.

Tech publications have already covered the technical specs. This is about what they don't - what this release actually means for teams building real products with Claude.

What Actually Changed
Just two weeks ago, Anthropic shipped Opus 4.8 - a modest but solid step up. Fable 5 is a bigger jump: Anthropic introduced a whole new tier of models - Mythos-class - sitting above the Opus class in capability. Until this week, Mythos models were only available to a small group of organizations through Project Glasswing.

Fable 5 is the first Mythos-class model available to the general public. Mythos 5 is the same underlying model with some safeguards lifted, restricted to vetted cybersecurity partners through Project Glasswing.

According to Anthropic, Fable 5 scored 80.3% on SWE-Bench Pro - a meaningful jump over Opus 4.8's 69.2% on coding tasks.

Pricing - $10 per million input tokens and $50 per million output tokens. About half the cost of Mythos Preview.

In high-risk areas - cybersecurity, biology, chemistry - Fable 5 refuses to answer and routes the query to Opus 4.8 instead. The safeguards trigger in less than 5% of sessions on average.

What This Means for Teams Building With Claude
What This Means for Teams Building With Claude
At Mygom, we've been building with Claude for a while now - it powers our proposal generator(opens in new tab), our invoice automation platform(opens in new tab), and the Business Analyst AI(opens in new tab) we use for natural language queries.

So when a new model drops, we're not just reading about it. We can put it straight into something real and see how it actually performs within a few days.

Here's what we'd tell teams building with Claude today:

1. Migrate when the task is long, complex, or runs on its own - not just because it's new. Fable 5 isn't a faster Opus. It's built for long-horizon work: holding more context, making a plan, and carrying a task further before a human has to step in. The clearest signal you should migrate is a specific task your current model can't finish - a multi-file refactor, a codebase-wide migration, a long document where context keeps slipping. Stripe reported that Fable 5 migrated a 50-million-line Ruby codebase in a single day - work that would have taken a team over two months by hand. That's the kind of task where the price jump pays for itself. A simple email draft isn't. If your agent runs fine on Sonnet 4.6 or Opus 4.8 today and isn't hitting those walls, there's no reason to move.
2. Start with one real test, not a full switch. Pick the single task that currently costs you the most time or fails the most often. Run it through Fable 5 and your current model, and compare the outputs side by side. GitHub's own benchmarks found Fable 5 completing the same work with fewer tool calls and lower token use than previous Opus-tier models, which can offset some of the higher per-token price. You won't know if that holds for your workload until you test it on your workload.
3. Plan for depth, not always a clean finish. Early reviewers noted a real tradeoff: when Fable 5 finishes, it produces serious, structured work, but when it struggles, it keeps exploring longer than a normal model would, burning time and tokens. Give it hard limits on time, steps, and token budget. Use it where depth is worth the wait, and keep your existing model for anything that needs predictable speed.
4. Check the safety classifiers against your domain. If the model gets a query in a high-risk area - cybersecurity, biology, chemistry - it refuses and routes the question to Opus 4.8 instead. Anthropic says this triggers in under 5% of sessions on average, so most teams won't notice. But if your product works in legal, medical, security, or biotech, test those exact flows first - Anthropic has acknowledged the biology classifier is currently too broad and may catch legitimate biomedical work until they narrow it. A silent handoff mid-workflow is not something you want to discover in production.
5. Factor in price and latency honestly. Fable 5 costs roughly double Opus 4.8 per token, and it's slower because it thinks longer. But on genuinely hard tasks, it can actually come out cheaper per solved task - around $6.83 versus $7.46 - because it gets there in fewer tries. For routine work, Opus 4.8 is still the better call on both price and speed. The rule we keep coming back to: use Fable 5 where the extra depth changes the outcome, and keep the cheaper, faster model everywhere else.

When It's Worth Switching
A new model is worth using when you have a specific problem that the old one can't solve. That's the simple rule.

Specific scenarios where Fable 5 is probably worth the price bump:

Complex software engineering. If your agent works with large codebases or hard refactoring tasks, that 80.3%(opens in new tab) on SWE-Bench Pro is meaningful.
Long documents with hard context. Fable 5 holds context better across extended interactions.
Tasks that used to need two passes. Work your agent currently does with Opus plus a correction step - Fable 5 may get it right in one.

And here's where Fable 5 is probably the wrong choice:

Simple tasks Sonnet 4.6 already handles well. Paying double for the same output isn't justified.
Low-latency products. If your product needs fast responses, stay with Sonnet or Haiku.
Areas where the safety classifiers trigger. If your product has to operate in cybersecurity or medicine, the automatic Opus 4.8 fallback may be a problem.

What You Need to Know Today
If you're not a technical team building your own AI products, here's the short version:

- Anthropic shipped a stronger model. Today it's available through the Claude API and paid subscription plans.
- For subscription plan users, Fable 5 is free through June 22, 2026. After that, it'll require usage credits.
- If you use Claude through another product (GitHub Copilot, an AI agent, anything that wraps Claude underneath), that product's builders will decide when and how to roll out the new model.

The good news - you don't have to do anything today. The best move is to let real users try the model, wait for the first real results, and then decide whether migration makes sense for your specific use case.

Need AI That Makes It to Production?
If your team is exploring AI but tired of demos that never make it to real use, this is a solvable problem. We build AI tools that actually work day to day - proposal generators, invoice automation, business intelligence. Scoped fast, delivered in weeks, and built around how your team really works.

Talk to us if you want to see what that could look like for your team.

Claude Opus 4.8: What Actually Changed

Mygom.tech — Thu, 04 Jun 2026 13:57:33 +0000

Claude Opus 4.8 Is Live - Here's What Actually Changed for Dev Teams
Anthropic shipped Opus 4.8 on May 28, 2026. No waitlist, no beta — available immediately across the API, Claude Code, and claude.ai. Here's what actually changed and what it means if you're building on Claude today.

What Anthropic Actually Said
Anthropic called this one "a modest but tangible improvement on its predecessor." That's unusually honest language for a product launch, and it's worth reading literally. This isn't a generational leap. It's a meaningful step forward in specific areas that matter for teams running agentic workloads.

Same price as Opus 4.7. API model ID: claude-opus-4-8

What's New
Honesty - and That's Not a Small Thing
The headline improvement isn't speed or benchmarks. It's that Opus 4.8 is far less likely to confidently tell you something is working when it isn't.

Anthropic reports it's around four times less likely than Opus 4.7 to let flaws in its own code pass without flagging them. In practice: fewer false positives in agentic loops, fewer "looks good" responses when the logic is quietly broken, less time debugging output you thought was clean.

For anyone running long autonomous workflows, that compounds fast.

Fast Mode - Same Speed, Much Cheaper
Fast mode runs 2.5× faster than standard mode. On previous Opus models, fast mode cost $30 per million input tokens and $150 per million output. On 4.8, that drops to $10 input / $50 output - three times cheaper. Regular pricing stays at $5/$25 per million tokens, unchanged from 4.7.

If you've been holding off on fast mode because of cost, that calculation just changed.

Effort Control
Users on claude.ai and Cowork can now set how much thinking Claude applies - from Low (faster responses, slower rate limit burn) up to Max (deeper reasoning, more tokens). Defaults to High.

In Claude Code, the top setting is xhigh - useful for long-running async jobs where quality matters more than speed.

Dynamic Workflows in Claude Code (Research Preview)
Claude Code can now plan a task, spawn hundreds of parallel subagents in a single session, verify outputs, and report back - without you managing the orchestration. Anthropic's example: codebase-scale migrations across hundreds of thousands of lines of code, from kickoff to merge, using your existing test suite as the quality bar.

Currently, research preview. Available for Enterprise, Team, and Max plans. Treat it as a powerful test surface for now, not a stable production contract.

Mid-Conversation System Messages (API)
Developers can now send a role: "system" message mid-conversation without breaking the prompt cache. That means updating permissions, token budgets, or environment context as an agent runs, without restarting from scratch or inflating input costs.

Niche for most use cases, genuinely useful for complex agentic harnesses.

How It Compares
On coding, Opus 4.8 leads clearly: 69.2% on SWE-bench Pro versus GPT-5.5's 58.6% - a 10-point gap on real-world repository tasks. Math reasoning jumped sharply too, with a 27-point gain on USAMO 2026 proofs in a single model cycle.

One honest caveat: Opus 4.8 still trails GPT-5.5 on terminal coding - 74.6% versus 78.2% on Terminal-Bench 2.1. If your workload is shell-driven CI and infrastructure automation, that gap is worth noting.

What's Coming Next
Alongside the Opus 4.8 release, Anthropic gave the clearest public signal yet on Mythos - a more capable model class currently in restricted preview for cybersecurity research under Project Glasswing. No firm date has been announced, but Anthropic stated general availability is on the roadmap. Opus 4.8 is the current ceiling for general access.

Bottom Line
Opus 4.8 is worth the switch if you're running agentic workflows or anything where model honesty and code reliability compound over time. It's not a dramatic upgrade - Anthropic is honest about that. But the honesty improvements alone change the calculus for autonomous work, and fast mode becoming three times cheaper is a real operational change.

If you're on Opus 4.7 and things are working, no urgency. If you're hitting false confidence issues in long-running jobs, this is the version to move to.

Read Anthropic's official announcement · System Card

Working With the Latest Models in Production
Knowing what changed in a release is one thing. Actually integrating it into your stack - without breaking what's already working - is another.

At Mygom, we build custom software and AI-powered tools for businesses that want more than off-the-shelf solutions. That includes helping teams implement and automate workflows using the latest models - whether that's adding Claude to an existing product, building internal tools that actually know your context, or replacing manual processes with something that runs reliably on its own.

If Opus 4.8's agentic improvements or fast mode pricing opens up something you've been waiting on, let's talk about what that looks like in practice.

How to Build an AI Agent: A Production Guide

Mygom.tech — Thu, 28 May 2026 05:51:53 +0000

How to Build an AI Agent That Ships to Production Fast
Most teams ask how to build an AI agent too early. The better first question is which workflow your agent must fully own.

Shipping fast depends less on model choice and more on system design, evaluation, and hard operational boundaries. The flashy demo loses to the boring production system every time. This guide shows you how to define the job, shape the architecture, choose the right build path, and deploy with confidence.

Part 1: Frame the Job Before You Touch Code
The teams that ship fast are the ones that pick a narrow target. Not "help sales." Not "automate operations." One job, one workflow, one measurable outcome.

A chatbot talks. An agent does work inside a process. While chatbots answer open-ended questions, an AI agent takes structured input, follows rules, triggers actions, and returns an output your team can review. MIT Sloan(opens in new tab) frames agents as systems that can pursue goals with some autonomy - the operative word being some. Production agents are not autonomous decision-makers. They are bounded specialists.

Good first targets share three traits: expensive, repetitive, and easy to measure. Proposal drafting. Invoice processing. Support triage. Document follow-up. Reporting. Each one has a clear before-and-after - the number of hours spent, the number of errors, the speed from request to answer.

A sensible first version is small and controlled. It accepts structured input - form fields, CRM data, and invoice metadata. It calls a model with strict constraints. It uses minimal memory. It triggers one or two actions. It produces a reviewable output. Think of it like a junior operator with a checklist, not a free-roaming assistant.

What must exist before you ship: API access, a logging layer, a prompt-and-eval workflow, versioned schemas, and a single business owner who defines success. Without those pieces, you are guessing. With them, you can test changes, trace failures, and improve fast.

Part 2: The Five Layers of AI Agent Architecture
The best architecture for an AI agent is rarely the smartest one. It is the clearest one. Think in layers - each one with a single job, each one inspectable on its own.

1. Input layer. This is where you protect quality. The input layer shapes raw requests before the model sees them. Fixed fields. Validation rules. Only the context that fits the task. A support triage agent needs the ticket type, customer tier, product area, and the last five messages. It does not need the whole CRM dump. If a date is missing, a file is too large, or a field is malformed, fail here. Do not ask the model to guess.

2. LLM layer. The model reasons, summarizes, extracts, ranks, and drafts. It does not own business rules, user permissions, or final approval. Think of the model as a strong analyst, not your compliance officer. Let it propose refund language. Do not let it decide who gets paid.

3. Memory layer. Start with less memory than you think you need. Session context, approved examples, and retrieval from source documents are enough for most first versions. Add clear storage boundaries - what is temporary, what is persistent, what should never be stored. Many teams overbuild this layer. Your first version does not need a lifelong memory graph. It needs the right facts at the right time.

4. Action layer. This is where the system starts earning its keep. APIs, record writes, draft creation, task routing, and human handoffs. This is also where you set guardrails: idempotency keys, retries, permission checks, and audit logs. The value of an agent is not the chat. It is the workflow it executes, and the workflow is only trustworthy if every action is logged and reversible.

5. Output layer. Make outputs typed, inspectable, and easy to review. Return JSON with confidence flags, citations, and status codes. Free text alone is hard to test and harder to trust. For example: { approved: false, reason: "missing VAT ID", next_step: "human_review" }. That format plugs into dashboards, queues, and alerts. It also makes the system honest - when the agent isn't sure, it says so, instead of generating a polished-sounding answer that turns out to be wrong.

Start with the simplest working version. One API route. One prompt. One retrieval step. One action. One typed response. You can build an AI agent without a framework. Many teams should. Start small, prove the loop works, then harden it with logs, evals, and human review.

Part 3: How We Did It at Mygom
We did not start with a customer-facing launch. We started with our own team. That choice gave us fast feedback and low political risk - if a draft missed the mark, we caught it internally before it reached a client.

Our internal proposal generator was the first real production agent we shipped. The architecture followed the five layers exactly. Structured input - deal size, scope, client tier. A context assembly step that pulled pricing rules and past examples. The model drafted using those constraints, not loose guesses. A review UI showed the output with confidence flags. A human approved every final version. Proposal work dropped from 3-4 hours to 30-60 minutes, but the gain did not come from the model. It came from tighter inputs, stronger guardrails, and the review step that maintained quality.

The same thinking went into our AI Invoices system. The target was specific: invoice capture, reconciliation, and duplicate prevention. Not a finance suite. Not a general assistant. One narrow job. Result: 40% faster processing, 30% lower spend, 10x volume - and we now deploy the same system to finance teams running into the same problems we had.

The contrarian lesson: your best first move is rarely a customer-facing chatbot. It is usually one high-friction internal workflow with clear ownership. Start where the pain is obvious, and the feedback loop is short. The teams that ship working agents are the ones that resist the urge to launch broadly before they have proved the loop works on something they already control.

Part 4: Three Paths to Building, Each With Tradeoffs
Once the job is defined and the architecture is clear, the next decision is delivery. There are three real paths, and the wrong one slows you down regardless of how good your design is.

Path 1: DIY with direct APIs. Best for speed, control, and a tight pilot. Works well when the workflow is narrow, the failure mode is cheap, and you have engineers who can own the orchestration. You connect a form, a model call, and one action in a week. The tradeoff: you own everything - retries, prompts, evals, logging, rate limits, and every new integration. Fine for a first version. Painful at scale unless you keep the scope tight.

Path 2: Framework-based build. Tools like n8n, LangChain, or similar speed up tool wiring, state handling, and workflow design. Useful when your team wants scaffolding without rebuilding common patterns. The tradeoff: frameworks hide sharp edges. Abstractions can blur token cost, execution paths, and failure states. Debugging often feels like tracing pipes behind a wall. That matters once your agent moves past demos and starts handling real load.

Path 3: Custom team with production delivery. The right path when the workflow touches revenue, compliance, or multiple core systems. If your agent has to read contracts, write to ERP, and trigger approvals across departments, shortcuts get expensive fast. Production delivery beats fast scaffolding when the cost of a wrong decision is real. This path costs more upfront. It also gives you better architecture, testing, security review, and release discipline - the things that determine whether your agent still works in six months.

How to choose between the three paths. Four questions decide it.

How critical is the workflow? If the agent breaks, what's the cost - a missed task or a missed customer? How fast do you need to launch? Days, weeks, or months. How much engineering capacity do you actually have? One person working nights and weekends is different from a team of four. And how much operational risk can you absorb if something goes wrong in production?

Match the answers to a path. DIY works when the workflow is narrow and failure is cheap - a single internal tool, a contained pilot, something you can shut off without anyone noticing. A framework makes sense when you need speed, and your team can live with some debugging friction - fine for medium-stakes workflows that don't touch revenue directly. A custom team is the right call when the workflow is business-critical, crosses multiple systems, or would be hard to unwind once live - contracts, ERP writes, financial controls, anything where the wrong output costs real money.

What Production Actually Looks Like
Testing is not optional once an agent touches a real workflow. You measure prompt quality, schema compliance, retrieval accuracy, tool success rates, latency, cost per task, and the frequency of human intervention. Those signals tell you whether the system is improving or quietly getting worse. They also help you catch the failures that hurt teams most - loose scope, weak data, excessive tool freedom, hidden prompt changes, poor monitoring, and no safe fallback when the agent gets uncertain.

A production-ready release ships with versioned prompts, typed responses, audit logs, feature flags, rate limits, spending controls, and a clear path to human review. That may sound less exciting than a model demo. It is also the difference between an experiment your team tolerates and a system your business can rely on.

The model is one part of the system. Task definition, clean inputs, controlled actions, typed outputs, and a review loop you can trust are the rest.

If you are still asking how to build an AI agent, start smaller than you think. Pick one workflow. Define success in plain business terms. Launch a narrow version with strong visibility and clear limits. Expand only when the evidence supports it.

The teams that win here will not be the ones with the flashiest prototypes. They will be the ones that ship with discipline, measure honestly, and improve in production week by week.

If you want a scoped production plan for your next agent, let's talk.

Why Your Team Trusts the Spreadsheet, Not the CRM

Mygom.tech — Wed, 20 May 2026 11:02:21 +0000

The Shadow Spreadsheet Is Telling You Something. Listen to It.
There’s a moment every operations leader recognizes. You walk past a desk and see a spreadsheet open beside the CRM. The CRM has the deals. The spreadsheet has the truth.

That’s not a workflow bug. It’s a signal.

Shadow spreadsheets don’t appear because people love Excel. They appear because the official system can’t keep up with how work actually moves. The CRM stores records. The spreadsheet runs the business. Once that split happens, your reports show one version of the business, and your team operates from another.

Most teams treat this as an adoption problem. They roll out training. They add fields. They buy plugins. None of it works for long because adoption isn’t the issue. The system doesn’t fit the business.

This is the moment when build vs buy stops being a software debate. It becomes an operating model decision.

What the Shadow Spreadsheet Actually Costs
Most teams budget for CRM the way they budget for any SaaS: seats × users. That math misses everything that matters.

The real cost shows up in five places:

- Seat growth across teams. It starts with sales. Then support needs access. Then finance wants pipeline visibility. Then operations. Per-seat pricing scales with every handoff, not just sales volume.
- Admin and consultant time. Every new workflow needs custom fields, hidden objects, or a configuration session. That work rarely lands in the software line item.
- Middleware subscriptions. Zapier, ETL jobs, sync scripts — each one keeps the CRM connected to the rest of the stack. None of them is free, and all of them break.
- Failed automation cleanup. When an automation misfires, someone manually fixes the records. That work is invisible until you add it up.
- Manager hours on data reconciliation. Every Monday, someone exports data, compares it against another system, and produces a report that leadership trusts. That’s the most expensive hour in the company, and it’s spent fighting the tool.

None of this shows up on the invoice. All of it shows up in operating drag — and at real scale. Recent research estimates that disconnected data systems cost 20–30% of operational efficiency each year. For most mid-market businesses, that’s hundreds of thousands of dollars paid annually in reconciliation, duplicate entry, and reports nobody fully trusts.

Five Signs the Architecture, Not the Tool, Is the Problem
The shadow spreadsheet is the loudest signal. Four others usually appear with it.

1. A critical workflow lives outside the system. Quotes, dispatch, onboarding, claims, renewals — whatever defines your business — happens somewhere other than the CRM. The CRM holds records. The actual work is elsewhere.

2. Daily exports are part of the routine. If teams pull CSVs every morning to do their actual job, the system has become a locked cabinet. Useful for storage. Useless for execution.

3. Reports get disputed instead of being acted on. Sales says one number. Finance has another. Operations trusts neither. When weekly reporting turns into reconciliation, the system has stopped being a source of truth.

4. Every change needs an admin. New process? New plugin. New custom object. New workaround. Change becomes expensive before engineering even starts.

5. Vendor settings own your customer journey. The logic that defines how your business treats customers lives in someone else’s UI. That’s the deepest version of the lock-in we covered in Agentic AI Lock-In Isn’t About Contracts — same problem, different system.

If three of these are true, the issue isn’t the CRM. It’s the architectural fit.

Why “More Stages” and “Another Plugin” Don’t Fix It
Most teams try the same fixes first. Add more pipeline stages. Force every workflow into one record type. Buy another plugin and hope consistency follows.

It rarely does. Those moves treat symptoms, not structure. More stages don’t create a booking object. One record type can’t model an approval chain or a dispatch window. A plugin patches one team’s pain and creates two new sync problems for someone else.

Data quality degrades fast when people work around a bad structure. They skip fields that don’t fit. They overload text boxes with status notes. They keep the real answer in a spreadsheet — which is where this all started.

This is the same dynamic we wrote about in Custom Software vs SaaS: When Replacing Tools Wins. Generic CRM software handles standard sales motion well. It breaks when your business runs on bookings, dispatch, supplier matching, invoice extraction, approvals, or custom states. Those aren’t sales notes. They’re operating objects, and they need a system built around them.

What Actually Works: Build Around the Real Objects
The fix isn’t another plugin or another admin layer. It’s a system built around the objects, states, and rules your team already uses.

We’ve shipped this pattern across several industries. The result is consistent — the workflow drives the software, not the other way around.

Steel Manufacturing ERP. The client was running production from Excel files. Procurement, warehouse, factory floor — three teams, three spreadsheets, zero real-time visibility. We replaced it with a connected platform that combines material requests, supplier bidding, warehouse tracking, and on-site usage in a single system. Result: 15% increase in production throughput, 35% faster material picking and dispatch, three hours saved per production manager per day.

Beauty and Wellness Booking Platform. The client managed bookings across hundreds of salons with tools that weren’t designed for the business — exception handling, staff schedules, and customer retention all lived in workarounds. We built a system where booking was the core object, not an afterthought. Appointments increased 20%. Customer retention reached 75%.

B2B Food Marketplace. Buyer-supplier matching used to depend on side files and email threads. We modeled buyer intent, supplier fit, and timing as native objects in the platform. Buyers completed purchases 60% faster. Supplier matches tripled.

MYGOM Invoices. Built for ourselves first. Invoices arrived as emails, PDFs, images, and spreadsheets. People retyped data by hand, matched payments line by line, and occasionally paid the same invoice twice. We built AI capture, bank payment reconciliation at 95% match accuracy, and duplicate prevention that saves $2,000+ per blocked duplicate. Invoice processing time dropped 40%. The system now runs for finance teams beyond ours.

None of these started with “we need a better CRM.” They started with “the spreadsheet is winning.”

How the Math Actually Works
The honest answer on cost: it depends. Most mid-market custom platforms ship in 8 to 16 weeks. The relevant question isn’t the build estimate — it’s what you’re already paying every month to avoid building the right thing.

Add up:

Manager time spent on reconciliation
Duplicate data entry across systems
Reporting cycles that lag the business
Middleware that breaks every quarter
Admin hours babysitting failed automations

Once that monthly drag exceeds the cost of shipping a focused system, the decision is usually clear. For most teams running operational workflows through a CRM that wasn’t designed for them, the drag crosses the threshold long before they realize it.

Where the Line Sits
Custom isn’t always the answer. We’ve said this before, and it stays true: if your workflow is standard sales motion — contacts, deals, tasks — HubSpot or Pipedrive will outperform anything custom for the same price. If your team is small and your process is still changing every month, SaaS keeps options open. Don’t harden guesswork into code. Forrester research found that 67% of software projects fail because of the wrong build vs buy choice. Most of those failures aren’t technical, they’re the result of teams building something that should have been bought or buying something that should have been built.

The line moves when the workflow becomes the product. The CRM vs spreadsheet split isn’t really about software — it’s about whether the official system can model how your team actually works.

The decision isn’t between features. It’s between renting someone else’s data model or building your own.

The Practical Audit
Before your next CRM renewal — or your next “let’s just buy one more plugin” decision — run this check:

List the objects your business actually runs on. Not the ones the CRM offers. The ones your team talks about every day.
List the workflows that those objects move through. Where do they enter? Who approves? Where do they exit?
List the daily exports. Every CSV pulled every morning is a vote against the current system.
Find the shadow spreadsheets. Ask your operators which spreadsheet they trust more than the CRM. There’s always one.

If the answers point to a system that doesn’t model your real business, no plugin will fix it for long. That’s when custom CRM development stops being a nice-to-have and starts being the clean way to remove drag.

If your team built a shadow spreadsheet next to your CRM, that’s the signal. Talk to us. We’ll map what stays on a managed tool and what needs to be built — based on what your business actually does, not what the demo shows.