Observe
Telemetry, logs, traces, events and topology arrive across the estate. This is the half every monitoring product already does; on its own it is still a tool, not a service.
What Is Service as Software?
Category Definition
SaaS sells you a tool and leaves the work with your team. Service as Software delivers the work itself: agents observe, investigate, resolve and verify, and your people govern the loop instead of running it.
The definition
Service as Software is the inversion of SaaS. Software as a Service sells a capability and leaves the labour with the customer: you buy the monitoring platform, and your engineers still triage the alerts, chase the root cause and run the fix. Service as Software sells the completed work: the system itself carries an incident from detection through investigation to a verified resolution, and a person supervises rather than executes.
The term comes out of venture and analyst writing on agentic AI, and the argument behind it is economic: software has historically competed for the tools budget, while the human work it can now absorb is paid for out of services and headcount budgets that its proponents describe as an order of magnitude larger. Whether or not that framing holds for your estate, the buying question it raises is real. When a vendor claims to deliver work rather than a tool, the burden of proof changes: not “what can your product show me” but “what does your product finish, and how do I know it finished”.
| SaaS | Service as Software | |
|---|---|---|
| What you buy | A tool your team operates | Work the system completes |
| Who does the work | Your engineers, assisted | Agents execute; your engineers verify and govern |
| Unit of value | Seats and features | Resolved incidents, executed procedures, verified outcomes |
| What scales | Licences, while the queue still scales with people | Capacity to absorb repetitive work, independent of headcount |
| The failure mode | Shelfware: a tool nobody adopts | Ungoverned action: an agent nobody supervised |
The shapes of the two models, not a claim about any specific vendor.
What it looks like in operations
Operations is the natural first home for Service as Software because so much of the work is repetitive by nature: reading, correlating, matching, routing and running the same procedures against the same classes of failure. In Opstral, the work loop is explicit. The platform calls it OIAO: Observe, Investigate, Act, Optimize.
Investigate
Sentinel, the reasoning core, correlates the signals, builds the root-cause case and attaches the evidence. The output is an investigated incident, not a page to a human at 3 a.m.
Act, under governance
Approved procedures run as Action Tickets: scoped to a blast radius, gated by an approval path where policy requires one, reversible, and recorded. This is where work is actually delivered.
Verify and optimize
An exit code is not a recovery. Outcomes are verified against the system's real state, and what the loop learns feeds the next incident. Verification is what lets a human trust work they did not do.
The part the buzzword skips: governance
Delivering work means touching production. The generic Service as Software pitch treats that as a detail; an enterprise change board treats it as the whole question. Software that acts on your systems needs what a human operator needs, made explicit: an approval path, a scoped blast radius, a rollback, and an audit trail that explains every action after the fact.
This is why we describe the platform as governed Service as Software. Autonomy is not a confidence score that unlocks production access; it is a set of permissions your organisation grants procedure by procedure, domain by domain, as the evidence record grows. The known failure mode of this category will not be agents that could not do the work. It will be agents that did work nobody supervised, on systems nobody scoped. Governance is not the brake on the model; it is the reason the model can be approved at all.
Evidence, with its basis
A page that says “we deliver the work” owes you the record. In production deployments documented in our case studies, roughly sixty percent of recurring network faults are resolved autonomously end to end, and MTTR fell by 43 percent measured six months after go-live against a documented baseline. Every figure on those pages carries the basis on which it was measured, and figures measured on one estate are not forecasts for yours. That is the standard the category should be held to; hold us to it too.
How it is priced, honestly
The pure form of Service as Software implies outcome pricing: pay per resolved incident, per executed change. We are not going to pretend that is how Opstral is sold today. The commercial shape is a platform licence with per-domain modules, because outcome pricing requires a baseline both sides trust, and that baseline does not exist on day one. What we will commit to is making the outcomes measurable from the start, so the work the platform absorbs is visible on your numbers, not ours.
When not to buy it
- Your incident volume is low and mostly novel. Service as Software earns its keep on repetitive work; an estate without recurring classes of failure has little for it to absorb.
- You want visibility, not action. If dashboards are the goal, buy observability; you will pay less and get exactly what you asked for.
- Your organisation cannot grant even governed execution. If no approval path could ever end in an agent acting on production, the model reduces to an expensive advisor.
- You are buying a headcount decision dressed as a technology decision. What an organisation does with absorbed work is its own call; a platform purchase is the wrong place to hide it.
Frequently asked questions
Service as Software is software that delivers completed work, such as a resolved incident or an executed procedure, rather than a tool that helps humans do that work.
SaaS sells capability and leaves the labour with your team; Service as Software sells the finished work itself, with humans supervising and governing rather than executing. The unit of value shifts from seats and features to outcomes.
No. Managed services outsource work to another company's people, on their tooling and their reporting. Service as Software keeps the work inside your environment and your governance, executed by software you can audit action by action.
No. It absorbs the transcription half of operations, the repetitive reading, correlating and procedure-running, and leaves the judgement half with engineers who now supervise a better queue. Every autonomous action exists because an engineer wrote the procedure and someone with judgement scoped its blast radius.
The version of the model an enterprise can actually approve: every action is scoped to a blast radius, gated by an approval path where policy requires one, reversible, and recorded in an audit trail. Autonomy expands procedure by procedure as the evidence record grows, not by a confidence score.
Ask what the product finishes, how completion is verified, and what evidence exists with a stated measurement basis. Then ask to see the governance model: approval paths, blast-radius scoping, rollback and audit. A vendor who can only demo detection is selling SaaS with a new label.
The term is young and its meaning is still being negotiated in public. What will not change is the buying question it introduces: does the software finish work, and can you verify that it did. Our answers, with their measurement bases, are on the case study pages; the governance model that makes them approvable is documented across Sentinel and the platform pillars.