Most operating questions in a mid-market company cross three or four systems. Is this account profitable at the hours we actually spend on it? Who on the team is the only person who can ship for this customer? Which vendor could take a revenue path down if we cancelled it tomorrow? The project tool knows the tasks, the time tracker knows the hours, the code host knows the commits, finance knows the invoices, and nobody joins them until a board meeting forces a spreadsheet.
At DevriX we spent the last year building the layer that does the joining, which is in effect an agentic operating system for the business, and we built it on our own company first. It runs as a fleet of specialized AI agents over the systems we already used, answers a fixed bank of operating and diligence questions every night, and reports what changed and needs a decision. We call it the AI Ops Hive, or the Hive for short. Commercially, it is the operating layer behind our client work, and the one we now offer to run inside mid-market and PE-backed companies next to our engineering and RevOps work.
In July I described the first version in The AI Intelligence Fleet Behind Our Private-Equity Value-Creation Work. This is the update: the problems it answers today, with examples from our own books, and why most of the effort went into something other than the agents.
What an agentic operating system is
An agentic operating system is a set of AI agents, each owning one part of the operation, connected to the company’s own systems through governed and mostly read-only access, with a shared memory of what has already been found and a person approving anything that changes the outside world.
In AI operating model terms, two contrasts make it concrete. A chatbot waits for a question; an agentic operating system works on a schedule and comes to you when something moved. A BI dashboard shows charts and leaves the reading to you; this layer reads the charts and hands over the decision, with the evidence attached.
Most of what is published about agentic operating systems today describes a platform you could buy and the layers it would need. What follows is narrower and more useful to an operator: what one answers once it has run against a real company’s tasks, hours, code, invoices and servers for months.
Starting from the questions
The work starts from questions, not from agents. A few of the ones operators and deal teams ask us, and the systems each one has to join:
| Question an operator or deal partner asks | What has to be joined to answer it |
|---|---|
| Which accounts take more hours than they pay for? | Project tool, time tracker, contracts |
| Which customer is quietly at risk while we under-use their plan? | Time tracker, search and analytics data, CRM |
| Who is the single point of failure, and for which customers? | Tickets, commits, team roster |
| How concentrated is revenue, and how well does it renew? | Invoicing history, CRM |
| Which vendors and servers sit under a revenue path? | Server inventory, DNS, vendor accounts |
| What will a diligence team find before we tell them? | All of the above |
Each of these is a join across systems that were never designed to agree on who a person is, what a client is called, or which month a number belongs to. That join is most of the product, and the agents are what keep it current.
Reading Asana against the time tracker
The project board was the first system we connected and the most misleading one.
On one multi-site program over six months, 1,390 hours were logged. Under half of them, 48%, went to planned build. Coordination took 16% and rework after client feedback took 14%. No one on the team would have guessed that split, and every individual task looked reasonable. It changed how we write fixed scopes: work starts at a complete intake, review rounds are counted, client and third-party delays pause the clock day for day, and changes arrive as written orders.
On another account, a retainer contracted at 100 hours a month ran at 296 hours in September and 313 by late October, while the client’s search clicks stayed flat. Nothing was hidden. The time tracker showed the hours, the contract showed the retainer, analytics showed the traffic, and each system was correct about its own slice. The layer put the three side by side and asked the question a CFO would ask.
The open-ticket count turned out to be the least reliable number in the company. Across the boards we read, more than two thirds of open tickets had no assignee and close to half had not been touched in six months. A dashboard that counts open tickets measures how rarely anyone closes stale work, not how much work exists. The useful reading is what was done in the last 90 days, by whom, and for which account.
This is what I mean by Asana analysis, and the same reading works on Jira, Monday or ClickUp. The task tool holds intent. Hours hold cost. Commits and deploys hold what actually shipped. Read together, they tell you which accounts carry the business and which ones the business carries.
Operational efficiency graphs
Under the questions sits a business graph: one identity per person across the time tracker, the project tool and the code host, one identity per customer across billing entities, brands and domains, and a history of the company going back to its first invoices in 2013.
That sounds like plumbing, and most of it is. The same engineer is spelled three different ways across three systems. A client pays from a legal entity whose name appears nowhere else. One customer runs dozens of sites that roll up to a single account. Until those resolve, utilization and margin per account are guesses, and every efficiency conversation turns into an argument about whose spreadsheet is right.
Once they resolve, efficiency becomes a picture:
- Retention risk before the renewal call. One client’s search clicks fell 25% against the prior period while they were using 61% of their plan. That is a retention conversation, not a delivery one, and it is better started by us than by them.
- Over-servicing that the client does not see. Another account ran at 110% of its contracted hours while its search clicks fell 31%. The right move is to raise it before they do, with the numbers.
- Key-person concentration. On our own team, the graph put a name on a risk every services company has and few measure: a small group carries most of the tickets and commits, and single engineers are the main contributor on several accounts at once. No org chart shows that. A buyer’s diligence team will find it in a week.
- Plan against actual. Allocations, tracked hours and shipped work per person and per account, so capacity planning starts from what happened rather than from what was planned.
These are the operational efficiency graphs operators ask about. Drawing the chart is the easy part; the identity work underneath is what makes it accurate.
The Hive, seat by seat
The Hive runs on a framework we call NanoClaw. About twenty agent seats run on it today, each with a name, a job, its own memory, a schedule and a short list of what it may and may not touch. Between them they run more than 300 skills, from a nightly business graph rebuild to a weekly board brief. A few of the seats:
- Pam watches the work: which projects are pacing to their retainer, which Asana tasks have gone quiet, and who has stopped logging time.
- Ophelia owns the shape of the business: utilization, billable mix, rate floors, capacity for new deals, and the business graph underneath.
- Aristotle acts as CFO and board advisor. His weekly brief carries at most three points, each with a number, an owner and a date.
- Drew reads search and analytics across our own sites and client sites, including where we show up in AI answers.
- Chris audits client sites for conversion, performance and accessibility.
- Sam and Abraham run the commercial side: deal, leadership and hiring news turned into account signals, and a first touch written when something changes at a company we can serve.
- Perry handles private equity thought leadership and earned media.
- EdOps keeps the infrastructure honest: server inventory, patch status, certificates, vendor keys and model spend.
Seats hand work to each other. A delivery risk Pam finds becomes a capacity question for Ophelia and, if it touches revenue, a point in Aristotle’s brief, instead of three separate alerts about the same account.
Due diligence on live data
The question bank now holds 291 questions across 18 lenses: quality of earnings, retention, pricing, go-to-market, marketing, customer fit, delivery, capacity, people, technology, security, legal, data and AI, vendors, governance, value creation, network and competition. Each one is written against generic entities such as customer, invoice, person, ticket, commit and site, so the same bank runs on another company once its systems are mapped in.
Each answerable question is backed by a function that runs on live data, and the full set is graded every night. The grading matters more than the count. In the first runs it caught two errors that would otherwise have reached a board pack as facts. A historical P&L snapshot had copied one figure into both recurring and one-off revenue for six years, which doubled revenue for the period once summed. Expenses had been recorded only from late 2025, so earlier years showed a margin close to 100%. Both looked plausible on a slide.
The questions it cannot answer are listed too, each with the record that would answer it: contract notice periods, change-of-control clauses, payment dates, satisfaction surveys. In diligence, a named gap is a finding in its own right.
This is the practical side of continuous technology due diligence. AI due diligence does not mean a model reading a data room once. It means the questions a deal team will ask are already answered, dated and sourced when the deal team arrives. Scoring a target’s own AI maturity works on the same principle, which I covered in what AI readiness actually tells you in a deal.
Vendors, servers and AI spend
Some of the most expensive problems in a mid-market company sit in accounts nobody opens.
In October, the shared key for one of our SEO data providers was being drained every night, about 20,000 units a night, until the monthly plan was empty. It looked like a leaked or stale key, and rotating it would not have stopped it. The layer read the vendor’s per-query log, traced the calls to one server, and found an internal tool re-scoring all 411 businesses in its database every night against the same key. It was gated off and deployed the same day.
In the same week, before cancelling a server-management subscription, we checked what the server still needed from that vendor. The certificate renewal looked local: a scheduled job on the server itself. It downloaded its script from the vendor every week. Cancelling would have let the site’s certificate lapse within four weeks, with nothing on the server to say why. The renewal, the deploy steps and a full backup were moved under our control first, and the subscription went after.
The same layer keeps the server estate mapped by host, notices when a server has quietly stopped applying security patches, and keeps model spend under a daily ceiling with a ledger built from receipts rather than estimates. I wrote about why that last part matters in AI agent implementations require production token cost forecasts before deployment.
What the reports look like
Most of the Hive’s output is short reports to me and to the team leads. A few excerpts from recent ones, with client names, people and figures changed:
Aristotle, weekly board brief. Over-service: a multi-site client ran about 290 hours against a 100-hour retainer this month, so close to 190 hours earned no marginal revenue. Its expansion deal was last touched ten days ago and the close date has passed. Decide this week whether to reprice at renewal or cap the scope.
Aristotle, same brief. Pipeline: 11 open deals, 3 of them untouched for 60 days or more and 4 already past their close date. The weighted total is overstated until those are closed out or re-dated.
Delivery watch, morning. Launch week on a client rebuild: the client flagged a missing homepage logo as a regression before go-live, unanswered for 20 hours. Suggested reply: confirm we are on it now, and that the launch banner comes down at go-live.
Delivery watch, coverage. One active client has no project board under any name we know, so none of its work is watched. Add the board or confirm the work is tracked elsewhere.
Ophelia, capacity. A departing engineer is the only person on one client build, and the hiring pipeline has no strong candidate for the role. This is the single point of failure in current staffing.
Pam, team signal. One engineer has shown sustained late-night activity for two weeks. Worth a conversation about load, not a performance flag.
Drew, search scorecard. A PE buyer question (“virtual CIO services for private equity backed companies”) now ranks first on one of our pages and is already in the answer set. Keep the answer block near the top and dated.
An agentic system can produce more reporting than any human will read, and ours did. When we audited four weeks of our own automated email, the reports took about seven and a half hours a week to read, and between 65% and 84% of their lines repeated something already sent.
The rules now are simple to state and took a while to enforce. Lead with the decision, not the largest number. A finding that was already reported does not come back unless its substance changed. “Nothing found” and “everything found was already sent” are different outcomes and are reported differently. Every cap is stated, because a truncated list that reads as complete is worse than a long one. The same discipline applies to the board reporting I described in Board Reporting for PE Portfolio Companies That Actually Drives Decisions.
Why it took a year
Connecting a model to a project tool takes an afternoon, and the demos look good. The year went into the parts a demo skips. It is the operating side of an argument I made earlier, that agentic AI is not there yet for most multi-agent deployments.
Names are the clearest example. One of our news radars once attached 512 signals to an account called “Private Equity”, because a two-word phrase passed a check built for single generic words. Another extractor checked a person’s LinkedIn URL and email against the source page and checked the name against nothing. Each guard existed and worked; it simply was not applied to the field that mattered. Finding that class of failure, then finding every other place the same guard was missing, is most of the work.
Data lies in quieter ways too. A table’s highest row number is not its row count. A store that keeps the top 50 pages of a site makes everything below them look like it has no traffic. A sync with no scheduled caller reads as zero hours, which an unattended report will happily describe as a client leaving.
None of that lives in a model. It lives in the operating discipline around the model: run the thing, read its output, check that the column is populated rather than present, and grade the answers every night. That discipline is what I would look for in anyone offering to build this for you, and it is the part that does not transfer through a prompt or a screenshot.
Working with DevriX
For a mid-market company, the engagement starts with read-only access to the systems you already run: the project tool, time tracking, the code host, CRM, accounting or ERP, analytics and the server estate. The first readout is the question bank answered on your data, with each gap named and each answer dated and sourced. From there, DevriX runs the layer as part of an operating team that acts on what it finds across your platforms, integrations and data, with a person approving anything that writes to a live system.
This is not AI implementation consulting in the usual sense of a roadmap, a pilot and a handover. The layer keeps running, and the team that runs it is accountable for what it finds.
For a sponsor, the same questions run across portfolio companies through one mapping per company, so the operating partner reads one set of answers instead of five sets of slides. It sits naturally next to the digital value-creation work most holds already plan for.
If you want to see what the question bank says about your company or a portfolio company, the AI value creation page has the details, and a 20-minute call with me is the quickest way to find out whether it fits.
