Company
Our story
Four people who ran enterprise operations for a living built the platform they kept wishing existed. Three things we ran into over and over became three components of the product, rather than three items on a roadmap.
- Four foundersEvery one of them came from inside enterprise operations and delivery, rather than from adjacent to it.Full bios on the About page
- Four domainsInfrastructure, services, security and process, under one operating loop instead of four tool stacks.What we set out to unify
- Three scarsEach one became a component of the platform rather than a feature request against somebody else's.How the product got its shape
- No standing accessNo agent holds production credentials. Every action is approved or bounded by policy written in advance.A founding constraint, not a setting
Where it came from
Three things we kept running into, and what each one became
None of these is a market insight. They are things that happened, repeatedly, on other people's estates, to people who are now building this. We think that is the only honest reason to claim you understand a problem.
The person who fixed it was the only record
A major incident gets resolved at three in the morning by the one engineer who has seen it before. The fix works. Nothing is written down, because writing it down was never anybody's job at three in the morning. Six months later that engineer leaves and takes the only copy with them. That became ProcBot. A procedure written once, in executable form, is the only kind of knowledge that survives a notice period.
Exit code zero is not a service recovering
Automation reports that it ran. The ticket closes. The service is still degraded, and somebody notices an hour later through a customer complaint, which is the most expensive possible detector. The gap between a command succeeding and a system being healthy is where most bad automation lives. That became Sherlock. Something has to verify the outcome against live signals and be willing to return a verdict nobody wants.
Nobody should hand production access to software on trust
Every one of us had seen an ungoverned script do more damage in four seconds than the fault it was written to fix. The instinct that follows is not to slow the software down. It is to insist that whatever acts on production carries the same controls a human change would carry, and can be refused by the same people. That became the Action Ticket. Pre-check, execute, post-check, and a rollback armed before anything runs.
What we were looking at
Every tier-one estate we worked in was fragmented the same way
One large airline runs dozens of systems that do not know about each other. Hybrid cloud and modern service architecture multiplied both the scale and the number of places a fault can start. The observability tooling did evolve, but it evolved into pieces: one product for traces, another for logs, another for metrics, another for monitoring, and a separate world again for CMDB, ITSM and delivery pipelines.
Two things we did differently
The decisions that shaped the platform
Unifying the domains was the obvious part, and plenty of vendors claim it. Two less obvious decisions did more to determine what the platform actually became.
Process is the domain nobody was monitoring
Every estate we walked into had something watching infrastructure, and usually something watching applications. Almost none had anything watching whether the business process itself completed. An order that stalls between two systems produces no alert anywhere, because no component failed. The first party to notice is the customer.
So process is a first-class domain here rather than a reporting layer bolted on afterwards. It is the reason the platform reaches into ITSM, CMDB, delivery pipelines and the procedure library rather than stopping at telemetry.
Two measures, deliberately kept apart
Services and processes carry a business impact value: what this costs the company while it is down. That is what lets an incident be described to a board in language they already use, rather than in severity levels that mean nothing outside the operations floor.
It is a different number from blast radius, which is what a proposed action can break, and which is what gates autonomy. A high-impact service can still carry a low-radius fix. Collapsing the two into one score is a mistake we were careful not to make, because each answers a different question and each is owned by a different person.
How process operations worksHow blast radius gates an action
Who built it
Four founders, and where the experience comes from
We describe the scale rather than naming the organisations, for the same reason every case study on this site says the customer identity is withheld. It would be inconsistent to protect our customers' names and trade on our former employers'. Full biographies, patents and profiles are on the About page.
- Co-founders
Sandeep Neema and Rajeev Gupta
Carrier-grade platforms, and the delivery of them250+ solutions delivered for tier-one enterprisesSandeep is a repeat technology founder with over twenty-five years building carrier-grade platforms. Rajeev has led complex, multi-million-dollar architecture, development and deployment programmes for telecom and enterprise customers. Between them that is long enough to have watched three generations of monitoring tooling arrive, promise convergence, and fragment again. Their conclusion was not that the tools were bad. It was that operations had never been given a single place to run from, and no amount of better dashboards was going to produce one.
- Co-founder and President
Jayesh Verma and Shiv Chandra Pathak
Operations, from the floor upward10+ years inside live enterprise estatesBoth spent their careers inside enterprise operations rather than adjacent to it: telecom OSS, observability at enterprise scale, multi-cloud, security and automation, working L1 through L3 and subject-matter escalation on the same teams. The three scars at the top of this page are theirs. So is the insistence that no agent gets production access without an approval path, which is now the constraint the whole governance model is built on.
What this is for
Where the value actually lands
Enterprises carry a large, permanent bill for operations work that is repetitive by nature: reading, correlating, matching, routing and running the same procedures. Autonomous execution takes the cost of that work down, and it does so whether or not anyone is watching it happen.
Questions we get asked
Frequently asked questions
Why build a platform rather than keep consulting?
Because the same three problems turned up on every estate, and consulting fixes them one customer at a time and then leaves. The knowledge problem in particular is unfixable by consultants: whatever you teach a team walks out with the individual who learned it. A procedure written in executable form stays. That asymmetry is the argument for a product.
Why not just integrate the tools an enterprise already has?
We do integrate them, and the platform reads from observability tooling, CMDB, ITSM, pipelines and the knowledge base rather than replacing them. The part that cannot be integrated is the loop itself. Observe, investigate, act and optimize has to be one process with one record, or the correlation ends up happening in whichever engineer is awake, which is exactly the state we were trying to leave.
You keep saying process. What do you mean by it?
The business transaction, not the infrastructure underneath it. An order that stalls between two systems, a payment that never reaches settlement, a provisioning request that silently stops. No component has failed, so no monitoring tool raises anything, and the first party to notice is the customer. Almost every tier-one estate we worked in had this gap and had stopped noticing that it did.
Does the platform ever act without a human?
Only where an action has earned it, on the evidence of having run with approval first, and only within a blast radius written into policy in advance. Every procedure in the current library still carries an approval requirement. That was a founding constraint rather than a caution we added later, and some actions are designed never to move at all.
Go deeper
Where to read next
- CompanyWhy NowGovernance became the blocker rather than capability, and why waiting only moves the start date.
- PlatformSentinel AIProcBot, Sherlock and the rest, doing the work the three scars above describe.
- EvidenceRecorded deploymentsWhat we have actually run in production, with the basis stated on every figure.
Bring us the incident that keeps coming back
The one that gets fixed the same way every month by whoever remembers how. We will walk through what writing it down as a procedure would look like, what its post-check would have to prove, and whether it should ever run without somebody pressing go.