Frontline Wire

There’s Nothing Wrong With a Gas Car. Electric Is Just Better.

A gas car is a good machine. It starts every morning, gets people where they need to go, and every mechanic knows how to fix it. Most enterprise software is the same. Your intranet works. Your ticketing system works. Your scheduler works. People know where things are. That software is not broken. The point is not that AI-first software fixes something that failed. It is that it is a different machine. Most AI in software today is still a battery in the trunk. A chatbot sits on top of the old system, answers a few questions, and leaves everything else the same. That is not AI-first. In an AI-first system, intelligence is built into every workflow. Search gives you the answer instead of ten documents. Building a page or form takes a prompt instead of an afternoon. The experience adjusts based on who you are, where you work, and what you need.

So why is the transition taking longer than people expected? Because the technology being ready was never the hard part. Electric cars were available long before most people bought one. People replace a car when the old one wears out, not the day something better appears. Companies do the same thing with software. They move when a contract ends, a system becomes painful enough, or the cost of staying starts to outweigh the cost of switching. There is also real work involved. The knowledge has to be cleaned up. Access and permissions have to be right. Leaders need to trust the answers. Employees who know exactly where to click have to learn a new way of working. That does not mean the technology is not ready. It means companies are being responsible about how they adopt it.

Adding an AI feature is easy. We can do it in a week. So can our competitors. So can your internal team. The hard part is everything around it. You need one employee record every application can trust. You need one permission model so AI can act for someone without seeing information it should not see. You need audit trails that can survive a security review. And you need to reach everyone, not just the people sitting at desks. That is where the gap is still the widest. Frontline employees often have no company email, no laptop, and only a few minutes between shifts. They need the answer now, not another link to open later. For them, six disconnected systems are not just annoying. They are the reason information gets missed, requests get delayed, and shifts go uncovered.

You do not have to convert the whole fleet at once. Nobody does. Companies run many systems, bought at different times, with different contracts and renewal dates. Nobody converts a fleet in a weekend. You replace the next vehicle, then the one after that. Keep running what works. But when the next system comes up for renewal, ask a simple question: do we want a better version of the same machine, or do we want a different machine? You can start preparing now. Clean up the knowledge. Fix the permissions. Run one pilot. Let one team experience the difference. Just make sure the next system you buy is built for where the world is going, not where it has been.

If you are thinking through what that transition could look like for your organization, contact us. We would be happy to have a deeper conversation.

Playbooks aren't smarter cron.

People hear "scheduled automation" and reach for cron. Wrong map. Cron is a clock with a script taped to it. One script, one system, hard-coded branches. Change the logic? File a ticket. Cron automates keystrokes.

A Playbook fires on a schedule or on a real event — a no-show, an incident, an offboarding — and runs the workflow: gather, let the model decide at the joints, act, wait, escalate. Approval gates. Allowlist for what runs unattended. Kill switch. An admin builds it in the UI. No deploy. It reaches the same 885 tools an external agent would, through the same MCP boundary.

"Email the attendance report Monday at 8" is cron with nicer clothes. Fine. Keep it.

"When someone no-shows, find the fairest available worker, ask them, wait, escalate to a manager if it's still open" — that's not a script you schedule. That's judgment you delegate.

Cron triggers a task. A Playbook pursues an outcome.

Want to see it in action? Schedule a demo.

Frontline AI is moving through five phases. We are already at phase three.

Customers are not going to log into ten different AI copilots, one per vendor. They are going to bring their own agent and expect every piece of software they buy to be reachable from it. That single shift is what separates the next generation of workforce platforms from the current one.

There is a useful five-phase map for getting there. Copilot. Delegation. Headless, where any external agent can reach the product through open interfaces. Agent-to-agent, where the product is one node in a wider agent stack. And the fully autonomous picture beyond that.

Most SaaS vendors are still at phase one or two. We are through phase three, and we are the first workforce platform there.

Our MCP server went live on May 12, 2026, built on MCP spec 2025-06-18 with OAuth 2.1 and Dynamic Client Registration, exposing 885 tools across the full product surface. A customer can bring their own external agent today, authenticate through standard OAuth, and have it read data and take action in MangoApps through that server, our CLI, or our public API. Shipped, in production, ready to use.

I want to be realistic about pace. Real customer adoption of cross-agent workflows is still years away. Inference is expensive, frontline teams are stretched, and a shift of this magnitude takes time to absorb. That is fine. The point of leading here is to be ready when customers arrive, not to claim everyone is using it tomorrow.

The next investment is the orchestration layer, so MangoApps can sit cleanly alongside a customer's CRM, ERP, and analytics inside one agent stack. We are tool-rich inside our boundary today. We are building the bridge across boundaries next.

This is the work that decides who leads frontline AI for the next decade. We intend to be the platform customers can build on when they get there.

Why AI changes the deployment conversation

Traditional SaaS gave buyers a fairly simple deployment question: cloud or on-prem, public cloud or private instance, standard controls or extra controls. AI makes that conversation much more important because workforce AI is only useful when it has broader context. It needs to reason across policies, people data, schedules, tasks, training, support history, approvals, and exceptions. That is exactly what makes it valuable, and exactly what makes governance harder.

This is especially true in frontline-heavy organizations. A store manager asking about a payroll exception, a nurse checking a policy, or a plant supervisor escalating a safety issue is not just using generic collaboration data. They may be touching employee records, compliance rules, union agreements, benefits information, schedules, or performance history. That changes the bar for enterprise buyers.

CISOs and enterprise architects need control over identity, keys, network access, logging, data flows, model routing, residency, retention, and incident response. HR and compliance leaders need audit trails, approvals, responsible ownership, and clear boundaries on what an agent can and cannot do. One rigid deployment model will not work for every company, every country, or every workflow.

At MangoApps, this is why we support multiple deployment models instead of forcing every enterprise into one pattern. Some customers want fully managed SaaS. Others need private cloud, customer-controlled network boundaries, or on-premise deployment for stricter regulatory environments. The principle is simple: same app, same AI, deployed where enterprise IT requires it.

The AI conversation cannot just be about better answers. It has to be about where the data lives, how it is accessed, who controls it, how actions are traced, and how safely the system can operate across the rest of the enterprise stack. In the AI era, deployment flexibility is not an infrastructure detail. It is part of the trust model.

AI ARR needs a gross margin test

A lot of AI companies are announcing they grew ARR to 8 or 9 figures in just a few months.

First, congratulations. That is impressive. But we should be careful not to compare apples to oranges.

In traditional SaaS, revenue often came with 80%+ gross margins once the product was built and scaled. In many AI businesses, a meaningful part of every dollar goes back into compute, inference, model costs, and infrastructure.

That does not make these bad businesses. It just means the revenue profile is different.

A grocery store can be a great business. So can a software company. But $100M of grocery revenue and $100M of high-margin SaaS revenue are not the same thing.

The better question is not how fast ARR is growing. It is how much durable gross profit is left after serving the customer. That is where the real comparison should start.

AI will not reduce the need for customer success and implementation. It will make them more important.

Customers increasingly expect software to adapt to their workflows, policies, language, permissions, and operating model. That doesn't happen by bolting on AI features. It takes strong implementation, clean data, thoughtful configuration, workflow design, and ongoing customer success.

Companies that understand this shift and organize around it will lead. Companies that think AI eliminates the need for Customer Success (CS) team and put AI chatbots as the answer will miss the point.

At MangoApps, we've always treated Customer Success as one of our most important functions. Engineering builds the product; Customer Success makes sure it works in the real world, across real organizations, with real complexity. The average MangoApps deployment touches about a dozen systems and 3 policy frameworks before go-live — none of which AI can figure out on its own. Our 75+ NPS score, year after year, reflects that belief.

As AI makes software more personalized for every organization, the winners will be the companies that do the hard work after the sale: connect the right systems, understand the customer's workflows, configure the product correctly, govern the data, and keep improving it as the organization evolves.

That's where SaaS leadership will be decided.

No, companies won’t stop buying software

Companies are not going to stop buying software and start building everything themselves. That idea is not grounded in history. We can all cook at home, but restaurants are massive businesses. We can all make coffee, but people still line up at Starbucks.

The reason is simple: people and companies do not only pay for capability. They pay for convenience, reliability, speed, polish, support, trust, and the ability to focus on their own business. AI coding makes building software easier, but easier does not mean easy, and it definitely does not mean everyone should build everything.

I have been agentic coding for over 18 months. I enjoy engineering. AI coding is a great accelerator and confidence booster. But building a meaningful product at scale still requires architecture, permissions, integrations, UX, security, workflow design, support, and a lot of judgment. AI does not remove those challenges. It shifts where the hard work lives.

So no, I do not think companies will stop buying software. I think we will see more software everywhere. Some will be internal tools, and those tools will get better. But most durable software will still come from teams whose entire job is to build, support, and evolve it. AI will change who can build software. It will not change what it takes to build great software.

There is a lot of discussion right now about the coming “SaaS collapse.”

AI is one of the most important technology shifts we will see in our lifetime. It will reshape software, disrupt categories, and challenge how products are built and priced. That part is real. But what is coming next is not a collapse. It is a reset in how software serves the business.

For decades, companies have been forced to adapt themselves to software. They bought rigid systems, bent workflows to fit predefined models, trained employees around generic experiences, and layered tool after tool to fill the gaps. The result has been complexity and a constant mismatch between how a business operates and how its systems actually work.

AI changes that dynamic in a fundamental way. It makes it possible to deliver software that is contextual, role-specific, and aligned to how each organization actually works, without the cost and time of traditional customization. When that barrier goes away, expectations change. Businesses will no longer accept one size fits all systems.

If there is one thing I have learned from building companies for over 20 years, it is this. You want complete alignment with your customers. When customers are thinking about building custom or in-house solutions, you do not fight that instinct. You enable it. That is what AI now makes possible, and it is a core part of how we think about MangoApps AI.

At MangoApps, we are building for this shift. A unified, brandable workforce platform that adapts to every role, every team, and every workflow. Frontline employees, desk workers, managers, field teams, HR, IT, and communications each get an experience that actually fits how they work.

The future of SaaS is not just more intelligent software. It is software that finally fits the business.

One of the biggest misconceptions I see right now is that AI agents are ready to take over most work. They’re not. Especially in frontline organizations where accuracy directly impacts customers, operations, and safety. Even in one of the most advanced use cases like agentic coding, accuracy is still in the 80 to 90 percent range. For most enterprise scenarios, that simply isn’t good enough. Imagine a store associate, nurse, or technician getting it wrong 20 percent of the time.

We’ve seen this movie before. Voice didn’t really take off until accuracy crossed that ~95 percent threshold. AI will get there. The level of investment going into this space makes that inevitable. But as you get closer to 90 percent, every 1 percent improvement becomes significantly harder.

It works in coding today because developers are used to it. Debugging is part of the workflow. That tolerance doesn’t exist in most frontline environments where errors have real consequences.

So the practical approach is simple. Focus on use cases where 80 percent accuracy is acceptable and keep a human in the loop to catch the rest. That’s exactly where we’re focused at MangoApps, enabling frontline AI use cases that are grounded in reality. From helping a technician troubleshoot an issue in real time to guiding a store associate during a customer interaction, all with the right guardrails in place.

When AI can do 80 percent of the work in 5 to 10 percent of the time, that’s a massive gain. If you’re not leaning into that, you’re leaving real productivity on the table.

At MangoApps, we believe the next generation of frontline software should feel less like software and more like a natural extension of how people already work. Frontline teams should not have to pause what they are doing, find a device, navigate a system, and fill out forms just to get an answer, report an issue, or ask for help. In many of these moments, the most natural interface is voice, and increasingly, live video.

We have been investing in voice-first experiences for over a year. The opportunity is clear, but the economics are still catching up. Today, a minute of live voice interaction can cost anywhere from $0.15 to $0.25, which translates to $9 to $15 per hour. So the real question is not whether voice can be added, but where it actually makes sense.

That is the focus for us at MangoApps. We are looking closely at which frontline workflows are valuable, urgent, and human enough to justify a voice-first or video-first experience. For the frontline, voice is not a novelty. It has the potential to become the interface that finally aligns with how work actually gets done.

“AI Employees” — I don’t buy that term.

These systems are not employees. They don’t have judgment, accountability, or context. Calling them employees feels like marketing stretching the truth and it sets the wrong expectations for both the buyer and the team building it.

What we are actually building is closer to an autopilot. In a plane, autopilot handles the routine so the pilot can focus on decisions that actually require judgment. The pilot stays in command. That is the right mental model for AI in the enterprise.

At MangoApps, we think of these as workflow autopilots. A helpdesk that triages and resolves common issues. A hiring pipeline that sources and schedules. A payroll process that flags exceptions. The system runs the routine and people step in where it matters.

This framing matters for two reasons. It tells the buyer the truth. You are not hiring a coworker, you are putting a process on autopilot and the value is in the work it completes. It also tells the team the truth. You are not building a person, you are building a system that can be trusted to run a workflow well.

Software is software. Let’s call it what it is.

The “Alex Rodriguez Rodriguez” Bug

An employee named Alejandro goes by Alex. He sets “Alex” as his preferred name, opens his welcome email — “Dear Alejandro.” Logs into the dashboard — “Welcome, Alex.” Then sees a recognition from his manager — “Great job, Alex Rodriguez Rodriguez!” Same employee, three different experiences. At that point, it doesn’t feel like personalization. It feels like the system doesn’t really know who he is.

Most platforms get this wrong because they treat a name as a single field and reuse it everywhere, then bolt on “preferred name” without defining where it should apply. So the wrong version leaks into the wrong places.

We split it into two: display_first_name for anything user-facing (emails, notifications, recognition, UI), and legal_name for where it actually matters (HR, payroll, compliance). The “Rodriguez Rodriguez” bug was just bad concatenation — preferred name + last name without checking duplication.

It’s a small detail, but it shows up everywhere. When a manager recognizes someone, it should look right across desktop, email, mobile, and feed — not vary by surface. Personalization isn’t about adding a field. It’s about being consistent everywhere it shows up.