← Back to context

Comment by aurareturn

7 hours ago

The bulk of the work is context engineering which is done outside of Fin. Once you do the context engineering, it's very easy to duplicate Fin's features. Seriously. Just try it.

You don't need a fancy editor for "if this then do this". A simple text document is all you need. And if you do need a fancy editor, it's extremely easy to build it in 2026. Maybe 1-2 days.

I'm not a SaaS believer anymore.

Maybe you've done this yourself. I'm honestly jealous if solving customer support was as easy as your describe.

In my case, I've spent the past 12 months running implementations at multiple companies. I've engaged directly with smart engineering teams to assist. It was not that easy.

What you outlined might work for a simple ecom business. It probably does 95% of the job for a simple case where you're delivering information. But it will fail the second it needs to take action or deliver personalized information based on client's account data.

That leads to the exact issue people here complain about... an LLM that doesn't actually answer the question, can't solve the problem, and is worse than talking to a human

  •   But it will fail the second it needs to take action or deliver personalized information based on client's account data.
    

    And why would Fin be better here? It's very easy to give your agent context on the customer.

    In 2026, every time I've tried to build a custom tool to replace a SaaS, I've succeeded. The biggest problem with SaaS is that they build a one size fits all. When you build a custom tool, you control everything from data to UI and it works for your business.

    • Many, many people do not have the capacity to build and maintain custom solutions (whether in-house skills, or simply bandwidth) and therefore outsource to vendors.

      It's an incredibly common aspect of business. Enterprise level contracts often include the sort of white glove service to help fill in these sort of gaps. On simpler plans, having the tooling provided frees up just enough capacity to handle the exceptions to keep the process running smoothly (since one doesn't have to build and run simultaneously).

      Sometimes people want to minimize the hassle with stuff. It's why car washes and oil change places and coffee shops exist.

      3 replies →

the bulk of the context engineering for users of these ai support platforms is done in the platform

and the amount of context needed to automate f500 is non trivial, plus you usually cant use reasoning because latency would blow up and you get escalated on

if this was so easy as you claim theres many millions for you to be made selling it to enterprises, but you wont

  • F500 is exactly the kind of scale where I fully expect support agents to be developed in house. They'll try Fin. Then one day, a single dev inside the company demos a custom agent that outperforms Fin and cost almost nothing.

    • tech forward f500 is possible (but.. even anthropic used fin)

      most f500s are going to outsource. i think sierra is already at 40% of the f50? and each of those deals they have to compete against teams of inhouse engineers and convince execs to buy instead of build

      the reality is agents at scale is a hard problem and most f500 engineers are not equipped to solve it