DEV Community: Lusivision

AI Budget 2027: Where to Spend and Where to Cut

Lusivision — Sun, 13 Sep 2026 00:00:00 +0000

Budget season is here, and this year the conversation is different. For two years the answer to "should we spend on AI?" was just "yes, and more." That reflex is running out of road. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, most of them killed by unclear value and costs nobody modelled up front. At the same time the pilots that did reach production are paying for themselves several times over. So the 2027 question is not whether to fund AI. It is which parts, at what level, and what to stop paying for.

This is a planning guide for whoever owns the number: a founder, a CFO, a head of engineering. It is not a list of tools. It is a way to sort what you are already spending, decide what deserves more, and find the line items quietly draining the budget with nothing to show. If you spent 2025 and 2026 running experiments, 2027 is the year the finance team asks what came of them. Have an answer ready.

Start from what shipped, not what was promised

Before you allocate a single euro for next year, do the unglamorous part: list every AI and automation line item you are currently paying for, and next to each one write what it actually produced in the last quarter. Not the pitch. The result. Hours saved, tickets deflected, revenue influenced, or "nothing measurable yet."

Most teams have never done this, and the exercise is uncomfortable on purpose. You will find seat licenses nobody logs into, a pilot that impressed everyone in March and has not been touched since, and one small unglamorous automation that quietly saves a person two days a month. That last one is your template. The point of the review is to enter budget planning with evidence instead of enthusiasm, because next year the people signing off have run out of patience for enthusiasm.

The four buckets your 2027 budget actually has

Every AI line item belongs in one of four buckets. Sorting them this way turns a vague "AI budget" into decisions you can defend.

Run is what is already in production and delivering. It has users, a measurable output, and an owner. This is the safest money you will spend and usually the least discussed, which is a mistake, because it is where your credibility lives.
Scale is a proven pilot ready to serve more people or more of the workflow. This is where the highest return sits in 2027, because the hard discovery work is done and you are buying reach, not hope.
Experiment is deliberate, time-boxed bets with a defined question and a kill date. Fund a few of these on purpose. Just cap them and never let one drift into permanent half-funded limbo.
Kill is everything that has been "almost there" for two quarters. Naming this bucket out loud is the single most valuable thing budget season does.

The common failure is spending 80% of attention on Experiment while Run and Scale get rubber-stamped. Flip it. The money that compounds is in the workflows already working.

What to fund in 2027

Fund the boring middle of your workflows. The wins that survive contact with a real business are rarely the flashy customer-facing demo. They are invoice processing, support triage, document handling, data entry between systems that never talked to each other. We wrote about picking that first workflow, and the logic holds for a whole portfolio: start where the work is repetitive, high-volume, and measurable.

Fund the integration work before the model work. The projects that get cancelled are usually not short of intelligence, they are short of clean data and connected systems. If your tools do not talk to each other, an agent on top of them just automates the gaps. Budget for the plumbing.

Fund total cost of ownership, not sticker price. A model API that looks cheap per call gets expensive when an agent runs it in parallel across thousands of background tasks. Model the real usage before you commit, the way we lay out in the true cost of running AI agents.

And fund ownership. A production AI system with no named owner is a cancellation waiting to happen. That is a real headcount or a real slice of someone's time, and it belongs in the budget, not in the gaps between other jobs.

What to cut

Cut the pilot that has been three months from production for nine months. It is not going to make it, and the sunk cost is not coming back.

Cut duplicate tools. Most companies accumulated three overlapping AI point solutions during the buying frenzy of the last two years. Consolidate to one and negotiate the renewal from a position of "we might leave."

Cut the seat licenses your usage data says nobody touches. Cut vanity projects with no owner and no metric. And be honest about build versus buy: some things you built in-house in 2025 are now commodity features in a tool you already pay for, and some things you bought never fit and should be built properly. We break down that decision in build versus buy.

A simple way to size the number

Skip the top-down percentage-of-revenue guess. Build the number from the buckets. Run and Scale are near-known: you have real usage and real costs, so you can forecast them within reason. Experiment is a deliberate cap you set, not a residual, maybe 15 to 25% of the total depending on how much you still need to learn. Kill is a negative line, and it should be a real one.

The output is a budget you can walk a finance team through item by item, each with a purpose and an expected return. That is a very different meeting from "we need more for AI because everyone else is spending." The teams that keep their funding through 2027 are the ones who can point at the 11% of pilots that reached production and say, plainly, "ours is in there, and here is what it returned."

Sizing a 2027 budget you can defend is a strategy problem before it is a spreadsheet problem. If you want a second read on where your spend should go, tell us what you are running today and we will help you sort it into keep, scale, and kill.

How Much Does It Cost to Maintain Custom Software? (2026)

Lusivision — Sat, 12 Sep 2026 00:00:00 +0000

Almost every quote for custom software answers the wrong question. It answers "what does it cost to build" and goes quiet on "what does it cost to keep running." Maintenance is the cost that stays, month after month, long after the launch party. And it is not small. A widely cited industry rule is that 60 to 70% of a software product's lifetime cost lands after it ships, not before.

That surprises people who think of software like a website they commission once and forget. Custom software is closer to a car than a poster. It runs every day, it depends on parts that wear out or get recalled, and the security patches never stop arriving. Ignore that and it does not fail gracefully; it rots quietly until one skipped update turns into an outage or a breach.

The good news is the numbers are knowable. This is what custom software maintenance actually costs in 2026, what the money buys, what pushes it up or down, and why the cheapest-looking option, no maintenance at all, is usually the most expensive one you can pick.

The rule of thumb: 15 to 20% a year

The working figure most experienced teams use is 15 to 20% of the original build cost, per year , to keep custom software healthy and evolving. Some simple products sit lower, around 10%. Anything business-critical, heavily integrated, or under compliance pressure often runs higher, up to 25%.

So a 60,000 euro build is not a 60,000 euro decision. It is roughly a 9,000 to 12,000 euro-a-year commitment on top, for as long as the software matters to you. Over five years that maintenance can quietly equal or exceed the build itself. That is not a markup or a scare tactic; it is the actual cost of owning working software instead of a snapshot that slowly drifts out of date.

Budget the whole life, not the launch day

When you compare quotes, put every option on a five-year total cost of ownership, not a build-day sticker price. A cheap build with no maintenance plan almost always loses to a slightly pricier one that keeps the software alive, because the difference shows up in year two, not year zero.

What that money actually buys

"Maintenance" sounds passive, like paying to leave something alone. It is the opposite. The work splits into four concrete buckets, and only one of them is fixing bugs:

Corrective. Fixing what breaks: the form that stopped sending, the report that returns wrong totals, the edge case nobody hit until a real user did.
Adaptive. Keeping up with a moving world underneath you. Operating systems, browsers, payment APIs, and cloud services all change. When Stripe deprecates an endpoint or iOS ships a breaking update, someone has to adapt your code or it stops working.
Perfective. Small improvements real usage reveals: a slow query, a confusing screen, a step users keep getting wrong. Not new features, just sharpening the ones you have.
Preventive and security. Patching dependencies, rotating certificates, closing vulnerabilities, testing backups. The invisible work, and the most important. A typical app pulls in hundreds of open-source packages, and a serious flaw in any one of them is your problem the moment it is published.

The last bucket is why maintenance is not optional. Software you shipped in 2024 is running on a stack the internet has been probing ever since. Every month without patches is a month the gap between "secure" and "your version" gets wider.

What moves the number up or down

Two builds priced the same can carry very different maintenance bills. Four things drive most of the difference:

Response guarantees. A contract that promises to fix a critical failure within two hours costs far more than one that gets to it "sometime this week." You are paying for availability, not just labour.
Technical complexity. A small static-ish app maintains itself almost. A multi-service system with a database, a queue, three integrations and custom business logic has many more places to break, and keeping it healthy takes more hours.
Integrations. Every external system you talk to is a system that can change without asking you. The more third-party APIs in the mix, the more adaptive work lands on your plate whether you wanted it or not.
Compliance and uptime needs. GDPR obligations, audit trails, or a real uptime commitment all add continuous work that never appears on a mockup but is very real on the invoice.

If a maintenance quote seems high or low, one of these explains it. The cheapest retainers usually assume away the security work and the response time you will end up needing anyway.

The cost of not maintaining

The tempting move is to skip the retainer and deal with problems "when they happen." It works right up until the day one happens and nobody knows the code.

Unmaintained software fails in a predictable pattern. Dependencies drift so far out of date that a simple change needs a costly upgrade project first. Security patches nobody applied pile up until one gets exploited. When something finally breaks, the fix is emergency work at emergency rates, often with the system already down for hours or days, done by someone rediscovering how it all fits together. The classic ransomware post-mortem is not exotic malware; it is a known vulnerability, patched by the vendor months earlier, that nobody on the maintenance side ever applied.

Add it up and ad-hoc "maintenance" is almost always more expensive than a plan, and far more stressful. You trade a predictable monthly cost for unpredictable outages and rushed rebuilds. For anything the business actually depends on, that is a bad trade.

Budgeting it from day one

Three habits keep the real cost honest. First, decide the maintenance model before you build, not after: a monthly retainer with a defined response time and a bucket of included hours is the norm, and it should scope security, hosting, monitoring, and small changes explicitly. Second, set the yearly figure at 15 to 20% of the build and hold that line in the budget from the start, so there is money left to iterate instead of watching the product stall. Third, treat the first year as the noisiest: real users surface the bugs and rough edges a launch never does, so front-load a little extra capacity there.

If you are still at the build-price stage, what custom software really costs in 2026 sets the number this one is a percentage of. And if you have inherited a system that was never maintained, our guide to modernising legacy software is the next step before the bill compounds any further.

AI Agent Orchestration: Making a Fleet Behave Like One System

Lusivision — Fri, 11 Sep 2026 00:00:00 +0000

Most companies already have the agents. A support agent, a sales agent, a finance bot, a document classifier, a coding assistant. What they do not have is anything that tells those agents when to run, in what order, with whose data, and what to do when one of them fails halfway through. That missing piece is orchestration, and in 2026 it is the difference between a demo that impresses a room and a workflow that survives a Monday.

Orchestration is not a model and it is not a framework logo. It is the control layer that decides which agent handles a task, passes the right context between steps, enforces the rules, and recovers when something goes wrong. Get it right and a handful of narrow agents behave like one dependable system. Get it wrong and you have automated the chaos: faster, more confident, and harder to unpick. This is a practical look at the orchestration patterns that actually hold up, the failure modes nobody warns you about, and how to decide whether to build the layer or buy it.

What orchestration actually is

Strip away the jargon and orchestration answers four questions on every task. Which agent or tool should handle this step? What does it need to know, and where does that context come from? What happens to the output, does it go to a user, another agent, or a system of record? And if the step fails, times out, or returns garbage, what then?

A single agent answers these implicitly inside one prompt. The moment you have two agents that must cooperate, the answers have to live somewhere explicit, because the agents cannot reliably negotiate it between themselves. That somewhere is the orchestrator. It is the part of the system that is boring on purpose: deterministic routing, clear state, logged decisions. The intelligence lives in the agents. The reliability lives in the layer around them.

The patterns that hold up

There are really only a few orchestration shapes, and most real systems are a combination of them.

The sequential pipeline is the workhorse. Step one feeds step two feeds step three: extract the data, validate it, then act on it. It is easy to reason about and easy to debug, and most business workflows are pipelines wearing a trench coat. Start here and only add complexity when a pipeline genuinely cannot express the work.

The router (sometimes called a supervisor) sits in front of several specialist agents and sends each request to the right one: billing questions to the billing agent, technical questions to the support agent, everything else to a human. A good router is cheap, fast, and does nothing clever. Its only job is to classify and hand off.

The parallel fan-out runs several agents at once and merges the results, useful when you want three analyses of the same document or you are racing two approaches and taking the first good answer. It buys speed at the cost of token spend and a harder merge step.

The hierarchical pattern nests these: a top-level orchestrator delegates to sub-orchestrators that each own a domain. It is powerful and it is where teams most often over-engineer. Whether you even need to split work across agents at all is a real decision, not a default, and we pull it apart in single-agent versus multi-agent systems.

Where orchestration breaks

The patterns are the easy part. The failures are where the engineering actually lives, and they are almost never about the model.

State is the first. An agent three steps into a workflow needs to know what the earlier steps learned, and if that context is lost, stale, or silently truncated, the agent makes a confident decision on bad information. The second is error handling. A human who hits a broken step stops and asks. An agent retries, hallucinates a plausible value, or charges ahead, so every step needs an explicit answer for failure, not an optimistic default. The third is the handoff itself, the seam between two agents where work falls through, gets duplicated, or contradicts itself, the exact gap behind agent sprawl. The fourth is cost, because an orchestrated workflow can quietly fan out into dozens of model calls per request, and without a budget the bill scales with traffic in ways nobody modelled.

The orchestrator is where reliability is won or lost

It is tempting to pour effort into smarter agents and treat the wiring as plumbing. It is the opposite. A mediocre agent inside a well-orchestrated workflow, with clear state, real error handling, and a human checkpoint on risky actions, beats a brilliant agent wired up with hope. When an AI project fails in production, the cause is usually the layer around the model, not the model, which is the whole argument of why enterprise AI projects fail.

Keep a human in the loop where it counts

Full autonomy is the wrong default for anything that spends money, touches a customer, or cannot be undone. The orchestrator is exactly where you place the checkpoint: pause the workflow, surface what the agent intends to do, and require a human approval before the irreversible step runs. The rest of the pipeline stays automatic. Done well this costs you seconds on the few steps that matter and nothing on the ones that do not, and it is the single cheapest way to keep an autonomous workflow from turning a small mistake into an incident. We go deeper on getting this balance right in human-in-the-loop AI agents.

The same layer is where you enforce identity and permissions, so every agent authenticates the same way and you can answer "what is this workflow allowed to touch" in one place, and where you centralise logging so every decision, cost, and error lands in one view rather than scattered across tools, the discipline behind observability for AI agents.

Build or buy the layer

You do not have to write an orchestrator from scratch. Frameworks like LangGraph, CrewAI and AutoGen give you graph execution, state, and retries out of the box, and we compare them in AI agent frameworks. For cross-vendor coordination, emerging standards like A2A are starting to replace one-off glue code.

The honest rule: buy the execution machinery, own the logic. A framework should handle the graph, the state, and the retries so your team does not reinvent them. Your business rules, your routing decisions, and your human checkpoints are not a framework's job and should never be locked inside one. Reach for a managed orchestration platform when your team is small and the workflows are standard. Build a thinner custom layer when your routing and compliance rules are genuinely yours, which for most real integrations means wiring agents into the systems you already run, the problem we lay out in connecting agents to your existing systems.

Where to start

Pick one workflow where a human is currently ferrying work between two or three tools, and orchestrate exactly that. Model it as a simple sequential pipeline, put a human checkpoint on the one step that spends money or touches a customer, log every decision from day one, and measure the hours it returns. One real workflow running reliably teaches you more than any orchestration diagram, and it gives you the template for the next one. This crawl-walk-run discipline is the same one that separates a production practice from a pile of demos, which we cover in AgentOps.

If you are running a handful of agents that each work well alone but refuse to work together, tell us what you have and we will help you design the layer that turns them into one system.

AI Agent Sprawl: The Dozen Agents That Don't Talk

Lusivision — Thu, 10 Sep 2026 00:00:00 +0000

Two years ago the question was whether to deploy an AI agent at all. In 2026 the question has quietly flipped. The average enterprise now runs about 12 AI agents, a number expected to hit 20 by 2027, and roughly half of them work completely alone. A support agent here, a sales agent there, a finance bot the accounting team stood up on its own, a document classifier a single manager expensed through a SaaS trial. Each one made sense on its own. Together they form something nobody designed and nobody owns: a fleet of small, capable systems that cannot see each other, share nothing, and hand off nothing.

This is agent sprawl, and it is the natural sequel to the SaaS sprawl most companies are still untangling. The pattern is the same, the speed is faster, and the cost is harder to see because each agent genuinely does something useful. The trouble is not any single agent. It is the gaps between them, where work falls through, gets duplicated, or quietly contradicts itself. This is a practical look at how you ended up here, what the sprawl is actually costing, and how to get from a dozen disconnected agents to something that behaves like one system.

How you ended up with twelve agents

Nobody set out to build a sprawling fleet. It accreted, one reasonable decision at a time. A vendor shipped an agent inside a tool you already paid for, so you switched it on. A team hit a bottleneck and bought a point solution rather than wait for a roadmap. An engineer wired up a workflow in an afternoon because the API made it easy. Every one of those was the right call locally.

The result is a familiar shape. Agents bought, agents built, and agents that arrived bundled with software you licensed for something else. They live in different clouds, authenticate in different ways, log to different places, and answer to different owners. It is the same dynamic we described in SaaS sprawl and consolidation, except an agent is not a passive subscription sitting in a spreadsheet. It takes actions. Twelve tools that overlap is a budgeting problem. Twelve agents that overlap and act is an operational one.

Why disconnected agents cost more than they save

The bill from sprawl rarely shows up as a line item. It shows up as friction, and it comes from four places.

The first is duplicated work. Two agents summarising the same inbound email, two systems both updating the CRM, two models paying for the same tokens to reach the same answer. The second is the handoff that never happens. Your support agent resolves a ticket that should have triggered a refund, but the finance agent never hears about it, so a human stitches the two together by hand, which is the exact work you automated the agents to remove. The third is contradiction: two agents acting on stale or conflicting copies of the same data, quoting different prices, promising different dates. The fourth is the one finance notices last and hardest, the compound token spend of a dozen agents nobody is watching as a whole.

Half of your agents are working blind

An agent that cannot see what the others have done will redo it, contradict it, or miss the handoff entirely. When roughly half your fleet operates in isolation, you are not running 12 automations. You are running 12 islands and paying people to ferry work between them. The savings you booked per agent are being eaten in the gaps you never priced.

The signs you have a sprawl problem

You usually feel this before you can name it. A few tells are reliable. Nobody in the company can list every agent that is running and what each one is allowed to do. Two teams describe the same automated workflow differently because each only sees their half. A customer gets two AI-generated replies to one question. Costs climb without a matching climb in output. And when something goes wrong, an agent takes a bad action, quotes the wrong figure, loops on an edge case, no single dashboard tells you which agent did it or why, a gap we go deep on in observability for AI agents.

If two or three of those sound like your week, the problem is not that your agents are bad. It is that they are strangers.

From sprawl to a system

Consolidation does not mean ripping out eleven agents and crowning one super-agent. That trades one failure mode for another and rarely survives contact with reality, which is part of why the single-agent versus multi-agent decision is rarely all-or-nothing. What you are building instead is the connective tissue the fleet is missing: a thin layer that lets specialised agents stay specialised while sharing the four things they currently do not.

Shared identity, so every agent authenticates and is authorised the same way, and you can answer "what is this agent allowed to touch" for all of them at once, the non-human identity problem most fleets have never centralised. Shared context, so an agent can read what another already learned rather than starting cold. Shared observability, so one place shows every action, cost, and error across the fleet. And an orchestration layer that routes a task to the right agent and manages the handoff between them, increasingly over emerging standards for agent-to-agent interoperability rather than one-off glue code.

Get those four in place and the individual agents barely change. What changes is that they stop being islands.

What to centralise first

You do not build all four layers at once. Sequence them by pain. For most companies the order that works is: observability first, because you cannot fix what you cannot see, and one pane of glass over every agent's actions and spend usually pays for itself in the first month by exposing the duplicated work. Identity and permissions second, because ungoverned agents taking actions is the risk that turns an embarrassment into an incident, the discipline we lay out in governing and supervising agents.

Shared context and full orchestration come third, once you actually know what your agents do and can trust who they are. Trying to orchestrate a fleet you cannot observe or govern is how you automate the chaos rather than resolve it. This is the same crawl-walk-run discipline that separates a production practice from a pile of demos, the heart of running agents as real operations in AgentOps.

A ninety-day plan

Start with an inventory, and expect it to surprise you. List every agent running in the company, who owns it, what data it reads, what actions it can take, and what it costs. Most teams find two or three nobody remembered and at least one pair doing the same job. That map alone is worth the exercise.

From there, work in the order above. Put every agent behind one observability layer so actions and costs are visible in a single place. Retire or merge the genuine duplicates the inventory exposed. Then decide which handoff, the one where humans are ferrying work between two agents today, is worth wiring together first, and connect exactly that one, measuring the hours it returns the way you would any other automation, using the method in how to measure AI ROI. One real handoff working beats a grand orchestration diagram nobody ships.

If your agent count has quietly climbed past what anyone can name, and the savings you expected are getting lost in the gaps between tools, tell us what you are running and we will help you turn the fleet into a system before the next agent joins it.

Connect Your Software Before You Add AI (2026)

Lusivision — Wed, 09 Sep 2026 00:00:00 +0000

Look at how work actually moves through most growing companies and you find the same pattern. An order lands in the e-commerce platform. Someone retypes it into the accounting tool. Stock gets updated in a spreadsheet. The customer's details get copied into the CRM, maybe, if whoever handled it remembered. Five systems touched one order, and not one of them told the others what happened. A person was the integration, moving data by hand between apps that were never introduced.

Every company reaches this point. You buy good tools one at a time, each solving a real problem, and a few years later you are running a dozen of them that all hold a different, slightly-wrong version of the truth. It works, in the sense that the business keeps running. It just costs far more than anyone measures, and it quietly blocks the thing everyone now wants to do next: put AI to work.

The tax you pay for disconnected systems

The cost of systems that don't talk shows up in three places, none of which appears on an invoice.

First, the manual re-entry. Every time a human copies a number from one screen to another, you pay for their time and you buy a chance of a typo. Multiply one order across five systems by every order in a month and the hours are real. Recent surveys put technology integration in the top three business challenges for nearly half of small and mid-sized companies, and this is why.

Second, the decisions made on stale data. When your sales figures live in one tool, your costs in another and your stock in a third, nobody can answer "how are we actually doing this week?" without an afternoon of exporting and reconciling. So the question gets asked less often, and the business steers on gut feel instead of numbers that are three systems out of sync.

Third, the errors you find late. The order that shipped but never got invoiced. The customer marked active in the CRM and cancelled in billing. Disconnected systems don't fail loudly; they drift apart, and you discover the gap when a customer complains or the year-end numbers don't tie out.

A person is not an integration

When your process depends on someone remembering to copy data from one system to another, you don't have a workflow, you have a single point of failure with a pulse. It works until that person is on holiday, leaves, or simply has a busy day. The task that "always gets done" is exactly the one that silently stops.

Why this is the real blocker for AI

Here is the part most teams get backwards in 2026. They see a demo of an AI agent booking appointments or resolving billing questions, and they want that. So they buy an AI tool and bolt it on. Then it underperforms, and they conclude AI isn't ready.

The AI was never the problem. An agent can only act on the data it can reach. Ask it to resolve a billing dispute and it needs the order, the invoice, the payment status and the customer history, which live in four different systems that don't share. Ask it to tell a customer when their delivery arrives and it needs the shipping tool to be connected to the order it came from. An agent pointed at a fractured landscape of disconnected apps can't do the job, no matter how capable the model is. This is a large part of why so many enterprise AI projects fail: the pilot works on a clean demo and dies on contact with the real, siloed data.

Integration is not a step you do after AI. It is the ground AI stands on. Companies that connected their systems first are the ones now getting real value from agents, because the agent has a single, current picture to act on. The ones that skipped it are still debugging why the bot gives customers wrong answers.

What "integration" actually means

It does not mean ripping everything out and buying one giant platform that does it all. That is the expensive over-correction, and it usually trades a dozen tools you chose for one you didn't. Integration means making the tools you already have share what they know, so a change in one shows up in the others without a human in the middle.

There are a few honest ways to get there, and the right one depends on your scale:

Native connectors. Many tools already integrate directly. If your e-commerce platform can push orders straight into your accounting software, use that first. It is free and it is maintained for you.
Automation platforms. Tools that watch for an event in one app and trigger an action in another cover a huge range of "when X happens, do Y" needs without custom code. For standard workflows, this is often enough.
A custom integration layer. When the logic is specific to how you work, when the volume is high, or when off-the-shelf connectors don't fit your systems, a purpose-built layer that speaks to each system's API is what holds it together reliably. This is where a studio like ours usually comes in.

Most companies end up with a mix: native connectors for the easy links, automation for the middle, and custom work for the few connections that are core to the business and too important to leave to a brittle chain of third-party triggers.

Where to start without boiling the ocean

You don't fix this all at once, and you shouldn't try. The move is to find the one connection that hurts most and close it first.

Follow the pain. Which piece of data does someone retype most often, and where does a mistake cost you real money? That handoff is your first integration, not the one that's most technically interesting.
Map before you build. Sketch the systems you run and draw the lines where data has to move. Most teams have never seen their own stack on one page, and the drawing alone reveals which connections matter and which are noise.
Fix the source of truth. Decide which system owns each kind of data. The CRM owns the customer, the accounting tool owns the invoice. Integration gets far simpler once each fact has one home instead of three.
Then, and only then, add AI. With clean connections and a single source of truth, an agent finally has something solid to act on. Now the demo you saw is achievable, because the data underneath it is real.

If you're weighing whether to build these connections in-house or buy your way out, our build vs buy framework applies directly, and how to scope a custom software project covers sizing the work before you commit.

The unglamorous truth of 2026 is that the companies winning with AI mostly did the boring work first. They got their systems talking. If your tools still pass notes through a human, that is the project worth doing before anything with "agent" in the name. Tell us what your stack looks like and we'll help you find the connection worth fixing first.

Outcome-Based AI Pricing: A Buyer's Guide (2026)

Lusivision — Tue, 08 Sep 2026 00:00:00 +0000

The pitch has changed. A year ago an AI vendor sold you seats: pay per user, per month, same as any SaaS. In 2026 the deck says something more seductive. Pay nothing until the agent actually does the work, then pay per result: 0.99 per support ticket it resolves, a flat fee per qualified lead, a cut of each invoice it processes. Intercom's Fin agent built tens of millions in revenue on exactly this model, charging per resolution, and every vendor watching has noticed. Gartner expects pure seat-based pricing to be effectively obsolete by 2028, with most software refactored around consumption or outcomes.

On paper, paying only for results is the fairest deal a buyer has ever been offered. In practice it moves the risk around rather than removing it, and the places it moves to are easy to miss until the invoice arrives. Only about 5% of enterprise buyers were actually contracted on outcome pricing as of mid-2026, and the ones who signed badly are learning why the number is still that low. This is a practical look at how outcome-based AI pricing works, when it genuinely favours you, and the specific things to nail down before you sign. It sits alongside our broader breakdown of how AI agents get priced; this one is written from the buyer's side of the table.

What actually counts as an "outcome"

The whole model rests on one definition, and it is the one vendors are vaguest about: what is a billable outcome? "Resolution" sounds obvious until you ask whether a ticket the customer reopens two hours later still counts. "Qualified lead" is a number on an invoice until you learn the agent flagged a competitor's intern filling in a form.

Before anything else, pin the unit down in plain language. A resolved support ticket is one the customer did not have to follow up on within a defined window. A qualified lead meets criteria you wrote, not the vendor. A processed document is one a human did not have to touch. If the vendor cannot state the unit in a sentence you would defend to your own finance team, the pricing is not really outcome-based, it is usage-based wearing a nicer label.

Where outcome pricing quietly costs more

The trap is not the headline rate, it is the counting. Three patterns catch buyers repeatedly.

The first is the false-positive resolution: the agent marks a ticket solved, bills you, and the customer comes straight back because it was not. You pay twice for one unresolved problem, and your CSAT drops while the invoice rises. The second is attribution. If the agent "closes" a deal that a human salesperson had already nurtured for three months, who earned the fee? Loose attribution windows let a vendor claim outcomes it barely touched. The third is the missing cap. Outcome pricing feels safe because it scales with value, until a viral week triples your ticket volume and the bill lands with no ceiling on it, on a month where revenue did not triple to match.

Demo economics are not production economics

The rate you are quoted is modelled on a clean scenario: well-formed inputs, common cases, a happy path. Production traffic is messier, and messy traffic produces more edge cases, more retries, and more disputed outcomes. Build your budget on the pessimistic version of the volume, not the demo. The gap between the two is where most AI budget conversations go sideways six months in, a pattern we cover in the total cost of owning an AI agent.

The clauses to insist on

A good outcome contract is mostly definitions, and the leverage is highest before you sign, never after. Four things belong in writing.

Independent measurement. You, or a system you control, count the outcomes, not the vendor's dashboard alone. At minimum you get raw logs and the right to audit them. Second, a conservative attribution window: state exactly how much time and how much prior human involvement still lets the agent claim credit. Third, false-positive handling: define what happens when a billed outcome turns out to be wrong, whether it is credited back, and inside what window. Fourth, a hard cap on outcome-linked fees per month, so an unusual spike cannot detonate the budget. Buyers who negotiated AI pricing inside a broader platform renewal, rather than as a standalone purchase, reportedly landed 30 to 45% better terms, because they had something to trade.

When outcome pricing is the wrong model

Outcome pricing is not automatically the buyer-friendly choice, and sometimes the flat fee is the smart buy. It works when the outcome is discrete, measurable, and high-volume: support resolutions, document processing, lead qualification. It works badly when the outcome is fuzzy or slow. If you cannot cleanly attribute the result to the agent, or the "outcome" is really a long chain of human and machine steps, you will spend more on arguing about the count than the pricing ever saves.

Low volume is the other tell. Per-outcome rates carry a margin the vendor sets assuming scale; at a few hundred events a month, a flat or usage-based plan is often cheaper and far simpler to reconcile. Run the arithmetic at your real volume before you fall for the elegance of the model. The same discipline applies to the underlying decision of whether to buy the agent at all or build it, which we walk through in build versus buy for software.

Run a pilot that gives you leverage

The strongest position a buyer can be in is holding real numbers from your own environment. Before signing an annual outcome deal, run a bounded pilot, 60 to 90 days, on a single workflow, with the measurement rules already written down. You are not just testing whether the agent works. You are collecting the true outcome rate, the false-positive rate, and the real per-unit cost at your volume, which becomes the evidence you negotiate the full contract against.

Tie the pilot to a business number you would have paid for anyway, so the counter-factual is honest: what a human did before, how long it took, what it cost. That is the only way to know whether the outcome price is a bargain or a premium, and it is the same method we recommend for measuring AI ROI generally. A vendor confident in its agent will welcome a measured pilot. One that pushes hard for an annual commitment before you have data is telling you something about the agent it would rather you not measure.

If you are weighing an outcome-priced AI agent and want a second pair of eyes on the contract, or help running a pilot that produces numbers you can actually negotiate with, tell us what you are being sold and we will help you price it properly before you commit a budget.

Why 95% of Enterprise AI Projects Fail (and the 5% That Don't)

Lusivision — Mon, 07 Sep 2026 00:00:00 +0000

The stat has been quoted in every AI deck since the summer, usually without the source: 95% of enterprise AI pilots deliver no measurable return. It comes from MIT's State of AI in Business study, which looked across roughly 30 to 40 billion dollars of generative AI spend and found that the overwhelming majority of projects never moved a number on the P&L. Not a rounding error. Nineteen out of twenty.

The easy read is that AI is overhyped. That is the wrong lesson. The same study found a 5% that worked, and worked well, and the difference between the two groups had almost nothing to do with which model they picked or how much they spent. It came down to whether the AI was wired into a real workflow with real data, or bolted on as a clever demo that nobody could actually use on Monday morning. This is a plain look at why the 95% stall, what the 5% do differently, and how to run a pilot that lands on the right side of that line.

What MIT actually found

The headline number is real, but the detail underneath it is more useful than the shock. Three findings do most of the explaining.

The failure is organisational, not technical. Pilots die from unclear ownership, no workflow redesign, and tools that get quietly abandoned once the novelty wears off, far more often than from a model that wasn't smart enough.
Bought beat built. Projects that partnered with a vendor or specialist to embed AI into a specific process succeeded roughly twice as often as teams building general-purpose tooling in-house from scratch. Ambition without focus was a reliable way to end up in the 95%.
A "shadow AI economy" is already delivering. While official pilots stalled, most employees were quietly using ChatGPT and Claude to get real work done. The value was there. The company programme just wasn't capturing it.

Read together, those three say the same thing: the constraint is not intelligence, it's integration.

The model was never the problem

Frontier models in 2026 are good enough for the vast majority of business tasks. The bottleneck sits in the layer around them, the part that turns a chat window into something that runs a process.

That layer is where the 95% underinvest. A pilot gets scoped as "add AI to support" and the budget goes on a subscription and a prompt. What it needed was access to the ticket history, the order system, the refund rules, and a defined hand-off to a human when the agent is unsure. None of that is glamorous, and none of it shows up in a demo, which is exactly why it gets skipped.

A working demo proves almost nothing

Every failed pilot had a demo that worked. A single clean run shows the model can do the task, not that it will do it reliably on your data, at your volume, inside your process. Those are different claims, and only the second one pays.

What the 5% do differently

The successful projects are boring in the same ways. Across the winners, the pattern repeats.

One narrow process, owned by one person. Not "AI for the company." A single workflow with a name, a baseline metric, and someone accountable for the outcome. Invoice matching. First-line support triage. Contract review. Scope you can measure in a quarter.
Connected to real institutional data. The agent reads your systems, not a generic knowledge base. This is the single biggest predictor of whether a pilot survives contact with actual users.
The workflow gets redesigned, not decorated. Dropping AI on top of a broken process just makes a broken process faster. The 5% rebuild the steps around what the agent is good at and where a human still needs to sign off.
Success is a number agreed up front. Hours saved, error rate, cycle time, cost per case. If nobody defined what "working" means before the build, the pilot ends in a debate about vibes and quietly dies.

None of this requires a bigger model. It requires treating the project as software with a business owner, not as an experiment that will justify itself later.

Buy, build, or partner

The MIT finding that bought beat built gets misread as "never build." That is too blunt. The honest version is about focus.

General-purpose platforms bought off the shelf work when your process is standard. The moment your advantage depends on something specific, your data, your rules, your integrations, a generic tool hits a wall and the last 20% is where all the value was. That is the case for a custom build, or a partner who builds the specific thing rather than handing you a toolkit and wishing you luck. The failure mode to avoid is the in-house team asked to build a general platform with no clear first use case. That is the exact profile of the 95%.

Pick the process before the technology

Decide which one workflow you want measurably better this quarter, then choose buy, build, or partner to fit that workflow. Teams that pick the tool first and hunt for a use case second are the ones writing off the spend a year later.

How to run a pilot that clears the bar

Before you approve the next AI project, make it answer five questions. If it can't, it's a 95% pilot with a nice slide.

Which single process, and who owns the result? A name and a person, not a department.
What is the baseline, and what is the target? The current cost or error rate, and the number that counts as a win.
What data and systems does it need to touch? Listed explicitly, with access sorted before the build, not discovered halfway through.
What happens when it's unsure? A defined escalation to a human beats a confident wrong answer every time.
How will you measure it in production? If the plan is "we'll see how it feels," you have no plan.

The 95% and the 5% are not separated by talent or budget. They are separated by whether someone did this unglamorous scoping work before writing a cheque. The good news is that it is entirely within your control.

If you have an AI project that keeps demoing well and then stalling, tell us which process you want to fix. The way out of the 95% usually starts with narrowing the scope, not buying a better model. It is worth reading this alongside our take on AI agent ROI from pilot to payback and why agents fail in production, which cover the testing and measurement side of the same problem.

Guardian Agents: The AI That Watches Your AI (2026)

Lusivision — Sun, 06 Sep 2026 00:00:00 +0000

In February 2026 Gartner published its first Market Guide for a category most people had never heard of: guardian agents. The timing was not an accident. Companies spent the previous year putting AI agents into production faster than anyone could govern them, and the bill for that gap started coming due. A guardian agent is the answer the industry landed on: an AI whose whole job is to watch the other AI.

The prediction that made people pay attention is a specific one. Gartner expects guardian agents to take 10 to 15% of the entire agentic AI market by 2030, and reckons that by 2029 independent guardian agents will make almost half of today's risk and security tooling redundant in more than 70% of organisations. That is a lot of money moving toward a problem that did not have a name eighteen months ago. This is a plain look at what these agents do, why they suddenly matter, and what it means if you are the one deploying agents in a normal business rather than a Fortune 500.

What a guardian agent actually is

Strip the label and a guardian agent is an oversight layer that happens to be an agent itself. It sits between your working agents and the systems they touch, and it does the supervisory work a human manager would do if they could watch every action in real time: check that an action fits the rules before it runs, flag the ones that look wrong, and block the handful that are clearly out of bounds.

The reason it is an agent and not a static rulebook matters. A firewall rule is fixed. A guardian agent reasons about intent, so it can catch a request that breaks no single rule but is obviously off, a refund three times larger than any this customer has ever had, an email drafted to the wrong external domain, a database write that would touch ten thousand rows when every past run touched ten. That kind of judgement is exactly what a list of if statements misses, and it is why the why AI agents fail in production pattern so often traces back to an agent doing something technically permitted and completely wrong.

Why 2026 forced the issue

The trigger was volume. Gartner's own numbers put agent adoption inside enterprise software going from under 5% in 2025 to roughly 40% by the end of 2026, and multi-agent systems on track to power 70% of AI applications by 2028. When one agent handled one task, a person could review its work. When fifty agents are calling each other across your stack, nobody is reading the logs, and the failure mode changes.

An agent that makes a mistake at human speed is a nuisance. An agent that makes the same mistake at machine speed, across every record, before anyone notices, is an incident. The more capable your agents get, the faster a bad decision propagates, and the shorter the window a human has to catch it. Guardian agents exist because the thing supervising machine-speed action also has to run at machine speed.

The gap most teams have right now

Ask yourself one question: if an agent in your business did something harmful at 3am, what would stop it before it finished, and how would you know it happened? For most teams deploying agents in 2026, the honest answer is "a human notices the next morning." That gap is the entire reason this category exists.

The three jobs Gartner splits them into

The Market Guide sorts guardian agents into three roles, and the split is a useful way to think about your own needs.

Reviewers. They inspect what an agent produced, generated content, a drafted decision, a proposed action, and judge whether it is accurate, compliant and on-policy before it ships. This is the closest thing to an automated second pair of eyes.
Monitors. They watch agent behaviour over time and raise the alarm when something drifts, an agent that starts calling a tool it never used, a spike in a certain action, a pattern that looks like it has been manipulated. This is the observability layer, made active. It builds directly on the same telemetry we cover in AI agent observability.
Protectors. They can actually intervene: block an action, revoke a permission, quarantine an agent that has gone off the rails. This is the part that turns oversight from a report into a control.

Most organisations need all three eventually, but they rarely need them at once. The reviewer role tends to pay for itself first, because it stops bad output before a customer or a system ever sees it.

What this means if you are not a bank

The Gartner framing is written for large enterprises with security teams and budgets to match. If you run a smaller business, the lesson is not "go buy a guardian agent platform." It is that oversight is not optional, and you can get most of the value with far less machinery.

The core idea, an independent check between an agent and the action it wants to take, scales down cleanly. A human in the loop on the small number of high-stakes actions gives you the reviewer role for free. Hard limits in code, a cap on refund size, a rule that any external email above a threshold gets held for approval, give you a basic protector without a single new vendor. And the observability you should already have gives you the monitor. Guardian agents are what you reach for when the volume of decisions outgrows a person's ability to spot-check them, not before.

The same discipline we push in governing and supervising agents applies here: decide what an agent is allowed to do, decide what it must never do without a human, and put a real barrier between the two. That is guardian thinking whether or not you ever deploy a guardian product.

How to add oversight without stalling the rollout

The mistake teams make is treating oversight as a project they will get to after the agents are live. By then the agent has already been trusted with things it should not have been, and pulling that trust back feels like a downgrade. Build the guard rail in from the first deployment instead.

Name the actions that can never run unsupervised. Money out, data deletion, anything sent to a customer under your name. Everything else can move faster.
Give the guard the power to stop, not just to warn. A monitor that files a ticket is useful. A protector that halts the action is what actually prevents the 3am incident.
Keep the guardian independent of the agent it watches. If the same model, prompt and permissions run both, they fail together. Separation is the whole point.
Log every intervention and review the pattern. Where the guardian keeps stepping in is where your working agent needs fixing, or your rules need tightening. Treat those blocks as the most valuable signal you have, the same way the OWASP LLM risks list treats a blocked prompt injection as a near-miss worth studying.

Guardian agents are going to be one of the defining infrastructure categories of the next few years, and the market numbers say the money agrees. But the underlying move is old and simple: never let a powerful actor operate without a check. If you are putting AI agents into your business and are not sure where the check should sit, tell us what the agents will do and we will help you design the oversight before the first one goes live, not after something breaks.

How to Scope a Custom Software Project in 2026

Lusivision — Sat, 05 Sep 2026 00:00:00 +0000

Most custom software projects do not fail in the code. They fail in the two weeks before anyone writes a line of it, when nobody wrote down what the thing was actually supposed to do. A vague brief turns into a vague estimate, the estimate turns into a fixed budget, and three months later the client and the developers are arguing about whether "reporting" meant a CSV export or a live analytics dashboard. It was never written down, so both sides were right, and both sides lost.

Scoping is the cheapest insurance you will ever buy on a software project. An afternoon spent writing down what you need, in plain language, saves you weeks of rework and tens of thousands of euros in change requests. This is not about producing a 60-page requirements specification that nobody reads. It is about being specific enough, early enough, that the people building your software and the people paying for it are looking at the same picture. Here is how to do that, whether you are about to brief an internal team or choose an external development partner.

Start with the problem, not the feature list

The most common scoping mistake is showing up with a list of features instead of a description of the problem. "We need a dashboard, a mobile app and an integration with our CRM" tells a developer what to build but not why, which means they cannot tell you when your idea is the wrong one. Start instead with the job: what is broken today, who feels the pain, and what does a good day look like once this exists.

Write it as outcomes a real person cares about. "A warehouse manager can see every open order without opening five tabs." "A new client is onboarded in ten minutes instead of two days." Those sentences are testable later, which a feature list never is. They also let a good team propose a simpler solution than the one you imagined, and the simpler solution is usually the one worth building.

Separate must-have from nice-to-have, ruthlessly

Every project has a real budget, whether or not anyone says the number out loud, and the fastest way to blow it is to treat every request as equally urgent. Split your requirements into three buckets: what the software cannot ship without, what makes it genuinely better, and what you are only including because it would be nice. Then be honest that the third bucket is where budgets go to die.

The MoSCoW split, used properly

Must-have, Should-have, Could-have, Will-not-have-this-time. The trick is the last one: writing down what you are explicitly not building this round is as valuable as the must-haves, because it stops the quiet expansion that turns a three-month build into an eight-month one. Scope creep is rarely one big decision; it is thirty small "while we are at it" additions nobody priced.

This is also where the real conversation about money happens. If you know what custom software actually costs, you can trade features against budget deliberately instead of discovering the ceiling halfway through the build.

Write down the workflows, screen by screen

Features are nouns; software is verbs. The part of a scope that saves the most pain is a walk through the actual flows: the steps a user takes, the decisions the system makes, what happens when something goes wrong. You do not need wireframes to do this, though rough sketches help. You need sentences.

Take the boring path first. "The user logs in, sees their open tickets sorted by due date, clicks one, edits the status, and the customer gets an email." Then take the unhappy path, which is where estimates quietly explode: what happens when the payment fails, the file is too big, two people edit the same record, the integration is down. Half the cost of real software lives in the edge cases, and naming them early is the difference between a firm quote and a moving target.

Nail down the integrations and the data

The single biggest source of scope surprises is the stuff at the edges: the systems your new software has to talk to. An integration with a well-documented modern API is an afternoon. An integration with a 15-year-old ERP that has no API and a database nobody is allowed to touch is a project of its own. If you do not surface these early, they surface during the build, at the worst possible time.

List every system involved, who owns it, and whether it has a real API. Do the same for your data: where it lives now, how clean it is, and who has to sign off on moving it. Data migration is almost always underestimated, because the demo runs on ten perfect records and production runs on ten years of messy ones. If your project starts from a spreadsheet, that is fine, but say so; moving from Excel to real software has its own gotchas worth planning for.

Define what "done" means before you start

A scope without acceptance criteria is a wish. For every must-have, write the sentence that lets both sides agree it works: "An admin can export the full order history as a CSV in under five seconds" is checkable. "Good reporting" is not. These become your acceptance tests, and they protect everyone, the client from a half-finished feature marked complete, the developer from an endless series of "actually, can it also..." after sign-off.

Fixed scope, fixed price, fixed time: pick two

You cannot lock all three. If the scope is genuinely fixed and fully specified, a fixed price and timeline are reasonable. If you expect to learn and change direction as you go, which is normal for anything genuinely new, price it as time-and-materials against a prioritized backlog instead, and protect the budget with the must-have list rather than a frozen spec. Pretending an evolving project is a fixed one is how both sides end up unhappy.

Scope for the first version, not the final one

The instinct on a first project is to specify the endgame: every feature you will ever want, built in round one. Resist it. The version that teaches you the most is the smallest one that solves the core problem for real users, which is the same logic behind building an MVP first. Ship that, watch how people actually use it, and let the roadmap for version two come from evidence instead of guesses. A scope that assumes you already know everything is a scope that is wrong, because you will learn more in the first month of real usage than in any planning meeting.

This is also the best defence against the expensive mistakes that sink software projects: over-specifying, under-testing the assumptions, and committing a year of budget to a plan drawn before anyone touched the working product.

A scope document you can actually use

Keep it short enough that people read it. A good scope for most projects fits in a handful of pages: the problem and who has it, the must / should / could / won't lists, the key workflows including the unhappy paths, the integrations and data, the acceptance criteria, and the constraints (budget, deadline, compliance, the tech you are locked into). That is enough to get a real estimate and to hold everyone to the same agreement, and it is short enough that it stays current instead of rotting in a drive.

None of this requires you to be technical. It requires you to be specific about your own business, which is the one thing no developer can do for you. If you want a second pair of eyes on a scope before you commit a budget, or help turning a rough idea into something a team can quote, tell us what you are trying to build and we will help you shape it before anyone starts writing code.

React Native vs Flutter in 2026: Which to Choose

Lusivision — Fri, 04 Sep 2026 00:00:00 +0000

Every app project reaches the same fork in the road early: React Native or Flutter? It gets treated as a deep technical question, argued with benchmarks and frame-rate charts, when for most businesses it is really a hiring and maintenance question wearing a technical costume.

Here is the part the benchmark posts bury. In 2026 the performance difference between the two, for a normal business app, is small enough that your users will never notice it. React Native's New Architecture (Fabric and the JSI bridge) is now the default, and Flutter's Impeller renderer is production-stable. Both ship 60fps interfaces, both save you 30 to 60% against building separately for iOS and Android, and both are backed by companies that are not going anywhere. So the interesting question is not "which is faster." It is "which one will your team still be shipping happily in three years, and which one can you hire for when you need to grow the team?" This guide walks through how we actually make that call with clients, and where each framework genuinely pulls ahead.

The performance gap has basically closed

For years the honest answer to "React Native or Flutter?" leaned on performance, and Flutter usually won the benchmark. That argument has mostly aged out.

React Native's New Architecture removed the old JavaScript bridge that used to cause jank under load. Flutter's Impeller engine cut frame times in complex scenes and killed the shader-compilation stutter that plagued early builds. Put a standard business app (lists, forms, auth, payments, a dashboard) on either one today and the difference is measured in milliseconds nobody will feel.

There are still edges. Flutter holds a small lead on heavy animation and GPU-bound UIs, and tends to be a touch smoother at a consistent frame rate. React Native tends to start faster and is easier on the battery. For roughly 90% of apps, both deliver a result users would call "fast," and the tie-breaker lives somewhere else entirely.

Your team is the real deciding factor

This is where the decision is actually won or lost. React Native runs on JavaScript and TypeScript; Flutter runs on Dart. That single fact drives most of the practical trade-off.

Hiring and cost. JavaScript developers outnumber Dart developers by something like 20 to 1. React Native roles also dominate the job market, with several times more open listings than Flutter. If you need to staff up fast or hand the code to another team later, React Native is the easier bet, and usually 15 to 25% cheaper to build with a JavaScript team already in place.
Shared skills with the web. If you run a React web app, React Native shares the language, the mental model, and a chunk of your logic. One team can move between web and mobile instead of two teams that don't speak the same language.
UI consistency out of the box. Flutter draws every pixel itself, so a screen looks identical on every device and OS version. For a brand-heavy, design-led product, that control is worth a lot, and teams often reach a polished MVP slightly faster.

The honest tie-breaker

Pick the framework your people can maintain for years, not the one that wins a synthetic test. A team fluent in React that fights Dart for six months will ship a worse app than the same team on React Native, whatever the benchmark said.

Pick React Native when...

React Native is the sensible default for most business apps in 2026. Reach for it when:

You already have JavaScript or TypeScript developers, or a React web product to share code and people with.
You expect to hire, or to hand the codebase to another team, and want the largest possible talent pool.
Your app is business-logic heavy: content, commerce, bookings, dashboards, account flows.
Fast time-to-hire and lower build cost matter more than squeezing out the last frame of animation.

Pick Flutter when...

Flutter earns its place when the interface itself is the product:

The app is animation-heavy or visually rich, with custom motion, transitions and bespoke UI that must feel identical everywhere.
You want one design system rendered pixel-for-pixel across iOS, Android, web and desktop from a single codebase.
Brand and visual polish are the differentiator, and you have (or can hire) the Dart talent to sustain it.
You are starting fresh with no existing JavaScript investment to leverage.

The framework is not the biggest number in your budget

It is worth keeping this in perspective. The React-Native-versus-Flutter debate takes up most of the oxygen, but the framework is close to a rounding error next to feature scope, backend and integrations, and design polish. Those three decide whether your app costs $80K or $250K far more than the runtime does. We break that down in what a mobile app really costs to build in 2026, and the same logic in euros for the Portuguese market in how much a mobile app costs in Portugal.

Choose the framework your team can own, ship a genuine MVP, and put the saved argument-time into the features that actually move your numbers. Both React Native and Flutter are excellent in 2026. The wrong choice is spending three months picking instead of building. If you want a second opinion on which fits your team and roadmap, talk to us and we will give you a straight answer.

AI Agents for SaaS Companies: Where They Pay Off in 2026

Lusivision — Thu, 03 Sep 2026 00:00:00 +0000

A SaaS business has a strange cost structure. The product scales for almost nothing, but the work around it does not. Every new customer adds support tickets, onboarding calls, a renewal to chase and an integration question nobody on the roadmap planned for. Headcount in support, success and sales creeps up while gross margin creeps down, and the team that was supposed to be shipping features spends its week answering the same questions instead. That gap, between a product that scales and an operation that does not, is exactly where an AI agent belongs.

An agent is not a chatbot bolted onto your docs. It owns a task end to end: it reads the ticket, checks the account in your own systems, drafts or takes the action, updates the record, and escalates the one case in twenty that needs a human. For a software company, that is not a novelty feature, it is a way to hold margin as you grow. But the same technical fluency that makes SaaS teams quick to build agents also makes them quick to over-build them, wiring an autonomous system into billing and customer data before anyone has proven the boring version works. This guide covers where agents genuinely pay off inside a SaaS business, and where they do not.

Support: deflect the repeat questions, not the hard ones

Support is the obvious first place, and for good reason. A large share of any SaaS inbox is the same twenty questions: how do I reset this, why did the sync fail, where is my invoice, how do I add a seat. An agent grounded in your real docs and account data answers those instantly, at any hour, in any timezone your customers live in. The RAG pattern for customer support is what keeps the answers tied to your product instead of invented, and it is the difference between deflection you trust and a bot that confidently makes things up.

The trap is measuring the wrong number. Deflection rate looks great until you realise the agent is closing tickets customers then reopen angrier. Measure resolution that sticks, and route anything involving a refund, a bug or a frustrated churn-risk account straight to a human. The agent should own the volume, not the judgment.

Onboarding and activation: the revenue nobody staffs for

Most SaaS churn is decided in the first two weeks, before a customer ever files a ticket. They sign up, hit one point of friction, and quietly never come back. Almost nobody has the headcount to babysit every trial through activation, which is exactly the work an agent is good at: watching for the account that stalled on step three, nudging it with the right help at the right moment, answering the setup question before it becomes a reason to leave.

This is customer onboarding as an agent problem, and it pays back faster than most because activated customers are the ones who renew. You are not replacing a human onboarding team, you are giving every self-serve signup the attention only your biggest accounts used to get.

Churn and expansion: act on the signal you already have

Your product emits churn signals constantly, and most of them die in a dashboard nobody opens. Usage dropped, the champion stopped logging in, seats went unused, the renewal is 60 days out and engagement is flat. A human success team can only watch the top accounts. An agent can watch all of them, flag the ones drifting, and either open a play for a human or handle the routine save itself.

Point the agent at the account, not just the inbox

The highest-value agent in a SaaS business usually is not the one answering tickets. It is the one reading product usage and acting on it before a customer decides to leave. Wire it to the same signals your best customer-success and churn workflows already use, then let it work the long tail your team never has time for.

The same machinery drives expansion. An account bumping against a plan limit or adopting a premium feature is a signal to act on now, not at renewal. An agent that surfaces those moments turns your usage data into pipeline instead of hindsight.

Sales and lead handling: speed is the whole game

Inbound that sits for a day is inbound you lost. An agent that qualifies a demo request, enriches it, books the meeting and updates the CRM the moment a form is submitted beats a human doing it Monday morning, because the prospect was comparing three tools and you were the one who answered first. This is the AI SDR pattern: let the agent handle speed and consistency at the top of the funnel, and keep your reps for the conversations that actually need a person.

Engineering: agents in the workflow, not on the roadmap

SaaS teams reach for coding agents fastest, and here the honest advice is the least exciting. AI coding agents help engineering teams most on the unglamorous work: triaging bug reports, drafting tests, handling dependency bumps, turning a support escalation into a reproducible ticket. Pointing an agent at your core architecture and hoping it ships features unsupervised is how you generate technical debt faster than you can review it. Use them to clear the drag around engineering so your people ship the hard parts.

Buy an agent, or build your own

Plenty of point tools now add an agent to a single SaaS job: a support copilot, an onboarding assistant, a CRM autopilot. For one narrow task with no deep integration, buy it. The build case appears when the value is in the wiring, which for SaaS it usually is. Your advantage is your product data: usage, account state, billing, the exact signals a generic tool cannot see. An agent that reads them is an integration project with your existing systems, not a widget, and it is worth understanding why so many agent pilots die in production before you start: almost always a fuzzy job description and no owner, not the model.

There is a strategic reason SaaS founders should care beyond their own ops. Agents are starting to eat the seat-based SaaS model itself, where customers pay for outcomes an agent delivers instead of logins. Learning to run agents inside your business is also how you learn to build them into your product before a competitor does.

How to start without breaking trust

Pick one workflow that is high-volume and low-stakes, and prove it there first. Tier-one support deflection or trial-activation nudges are the classic entry points: a human reviews the edge cases, the cost of a mistake is small, and the payback shows up in weeks. Run it in shadow mode before it acts on its own, and price the whole thing, seat plus usage plus integration, using our total cost of ownership framing rather than the sticker price.

The SaaS companies that win with agents in 2026 are not the ones that automated the most. They are the ones that held margin as they scaled by handing the repetitive operational work to a machine and keeping their people on the product and the relationships. If you want a straight read on which workflow in your SaaS is worth automating first, tell us how your week actually runs and we will help you find it before anyone builds anything.

AI Agents for Professional Services Firms in 2026

Lusivision — Wed, 02 Sep 2026 00:00:00 +0000

A professional services firm sells one thing: expert time. A consultant, a lawyer, an accountant, a designer, an engineer, all of them bill for judgment the client cannot produce in-house. The trouble is how little of the working day actually goes into that judgment. Between scoping calls, proposals, status updates, note-taking, timesheets, chasing documents and answering the same client question for the fifth time, the billable hour is surrounded by hours nobody pays for. As the firm grows, that unpaid work grows faster than the headcount, and the newest clients quietly get the thinnest slice of attention.

That surrounding work is exactly where an AI agent belongs, and it is a different proposition from a general chatbot. An agent owns a task end to end: it reads the incoming request, checks your systems, drafts the output, updates the record, and escalates the one case in twenty that needs a partner's eye. Done well, it hands your experts back the hours that were being burned on admin and puts them back into the work clients actually pay for. Done badly, it lets a machine speak for a firm whose entire value is trust. This guide covers where the line sits, what to automate first, and how to deploy an agent without betting the firm's reputation on it.

What "professional services" covers, and why agents fit

Professional services is a broad tent: management and IT consulting, law, accounting and audit, marketing and creative agencies, architecture and engineering, recruitment, and independent advisory of every kind. What they share is the shape of the work, not the subject. Every one of these firms runs on a pipeline of proposals, a book of clients who need regular contact, a mountain of documents, and a billing model tied to time. That common shape is why the same handful of agent use cases pays off across all of them.

We have written the deep-dive versions of this for specific practices already, on AI agents for law firms, for accounting firms, and for financial advisors and wealth management. This piece is the map that sits above them: the pattern that holds whatever your firm actually sells.

The billable-hour math

The case for an agent in a services firm is simple arithmetic, and it is worth doing before anyone builds anything. Take a firm of twenty fee earners at a blended rate of 120 an hour. If admin and low-value follow-up eat five hours a week per person, that is 100 hours a week the firm cannot bill. Recover even half of it and you have freed 50 billable hours a week without hiring a soul.

You will not recover all of it, and you should not promise yourself you will. But the point stands: in a business where the product is time, an hour returned is not a soft efficiency gain, it is revenue you could not otherwise sell. That is what makes the numbers here easier than in most industries, and it is why measuring the result is straightforward. Our framework for measuring AI ROI applies almost directly, because the unit is already money.

What to automate first

The useful version of an agent in a services firm is boringly specific, and that is the point. Start with the work that has a clear finish line and no judgment in it.

Proposal and scoping drafts. The agent assembles a first-draft proposal from past engagements, the client brief and your rate card, so a partner edits instead of starting from a blank page.
Meeting prep and follow-up. It builds the pre-meeting brief from the CRM and prior notes, and afterwards drafts the notes and the follow-up email for review.
Client servicing questions."When is our next review", "can you resend the invoice", "what's the status of the deliverable". Predictable, non-advice questions answered instantly, at any hour.
Document chasing. Engagements stall on missing paperwork. An agent politely and repeatedly chases the signature, the file, the approval, so nobody on your team has to nag.
Time and billing hygiene. It prompts for missing timesheet entries and drafts the narrative for each line, so invoices go out on time and reconstructing the week stops being a Friday ritual.

Each of these is a closed loop you can measure, and none of them touches the advice. That is what makes them safe to hand over first.

The line: judgment stays human

Here is the boundary, and in professional services it decides everything else. The agent handles the work around the expertise, never the expertise itself. It does not give the legal opinion, sign the audit, approve the structural drawing, or make the strategic call. Those are what the client is paying a licensed, insured, accountable human to do, and they are exactly where a confident, wrong machine causes real damage.

The agent drafts, a named human decides

Write the boundary down before you build. Anything that carries professional liability, a recommendation, an opinion, a sign-off, routes to the person who is accountable for it, full stop. The agent prepares and escalates; it never improvises past its lane. This is the human-in-the-loop discipline every serious deployment uses, and in a firm that sells its judgment it is not optional.

Buy a tool or build your own

Plenty of point tools now bolt an agent onto a single job: note-takers, proposal writers, inbox assistants. For one narrow task with no sensitive data, buying is often the right call, and you should. The build case appears when the value is in the wiring, which in professional services it usually is. An agent that cannot see your CRM, your document store and your billing system is just a second inbox someone reconciles by hand. One that can see them is handling some of the most confidential material your clients own.

That makes the serious version an integration project with your existing systems, not a chatbot pasted onto a website. For a firm handling privileged client information, a private AI assistant grounded in your own data is usually the right shape, so answers come from your real engagements and never leak into a public model. And because most services firms have tried a pilot that quietly died, it is worth knowing why AI agents fail in production before you start: almost always a fuzzy job description and no owner, not the technology.

How to start without risking the firm

Pick one workflow that is high-volume and low-stakes, and run it first. Post-meeting note drafting is the classic entry point: a human reviews every note before it is saved, the cost of a mistake is a quick edit, and the hours saved show up within weeks. Prove it there, measure two numbers, hours returned to fee earners and whether client-facing quality held or improved, and only then widen to the next loop.

The firms that win with AI in 2026 are not the ones that let a machine give the advice. They are the ones who used it to clear the admin so their people could give more of it, to more clients, without burning out. If you want to map which part of your firm is worth automating first, tell us how your week actually runs and we will help you find the one workflow most worth building.