Letting a production system improve itself first requires that somebody actually reads it.

Systems like the recommendation feed, the search ranking and the notification push enter an awkward state the moment they go live: everyone agrees they matter, and almost nobody can say how they actually run. Changing one metric means months of scheduling, and after the change the proof still has to come from live traffic. What Pavo sets out to do is turn reading the system, finding the change and proving it works into a pipeline that can run again and again.

It is not an assistant for end users but a platform that sits behind engineering and product teams: it runs inside the customer own cloud account, connects to the code repository, the data warehouse, the dashboards and the experiment platform in read only mode, sends nothing out by default, and its goal is to make one particular metric actually move.

What refuses to move is often not the model but the fact that nobody can say how the system runs

A recommendation feed has been live for three years, the code has turned over several times, the dashboards have been rebuilt twice, and the reason a certain feature was weighted up at the start is scattered across the memory of a few old colleagues. When a newcomer takes over, or when an agent takes over, the first wall is never how to write the code but how this system actually runs. Worse, changing a metric is expensive by nature: guess wrong once and it is an incident, so the team only makes the small changes it is sure about, and the big change that would really move the number sits at the bottom of the backlog.

Step one: read the scattered experience into a book with citations

The first module is called System Knowledge. It pulls the information in the connected sources into individual facts, each carrying a type and a source: which file and which line this sentence came from, which query, which experiment. Extracting is not the end of it; the facts are then distilled into a manual that can be reviewed chapter by chapter, the System Book.

The manual does not rest on the model talking to itself. Pavo pairs it with a check called Knowledge Bench, where the team writes the questions and scores the answers; a score that falls short means the knowledge has not really been understood, not that it looks about right. The vendor puts the principle in one line: knowledge is verified, not assumed.

Step two: hand the problem to a team of agents that each own a small piece

The second module is Agent Studio, and its job is to spend the understanding that has been accumulated. Give it a real problem and it first breaks the problem into a plan: the scientific framing, the module split, the rules of evidence, all laid out on the table for you to confirm. Nothing moves until you nod.

Once confirmed, the work is divided across a team of agents. Each agent owns one small, checkable task, and above them sits a Director that allocates tasks, watches how the others are doing, keeps their findings aligned and steps in when something goes wrong.

The value of that structure is that it can be inspected. Every result is an answer with a type, references and a version, stating clearly what it proved and equally clearly what it did not. The vendor explanation is direct: throw a weeks long research question at a single agent and it will run for hours, make a hundred small decisions you never saw, and come back confidently wrong; the answer is not a cleverer agent but structure around the one you have.

Making it stop where a decision is needed

Pavo separates decision points from progress updates: it stops only at boundaries that need a call, and tells you what changed, why the call is yours and which path each option opens. The rest of the time the team runs on its own.

How one round of improvement runs

Join the two steps and you get the whole loop: connect the stack, build the system knowledge, run a programme in Agent Studio, deliver a change that moves the metric. What was found is written back into the manual and becomes the starting point of the next round.

In the enterprise shape, that loop is compressed into eight weeks: the first week fixes the metric and the success criteria, the second connects the systems, weeks three and four evaluate several candidate approaches in parallel and pick the winner offline first, weeks five and six release the winner as a live experiment, weeks seven and eight measure the gain and turn to the next problem. The vendor notes that as understanding deepens, the time a team needs to answer a harder research question falls from weeks to days.

What it keeps inside your own environment

Whether a platform like this can enter an enterprise usually comes down to the data question. Pavo offers three deployment shapes: hosted on its own cloud, multi tenant but isolated per organisation; deployed into the customer own cloud account, single tenant, encrypted with the customer keys, off the network by default; and a hardened version for regulated industries, with every service self hosted inside the customer network and no third party integrations deployed.

Three principles run through all of them: connections are read only and connectors only pull from your sources without ever writing back; customer data is not used to train models; external language models run under zero retention terms. The platform holds SOC 2 Type II and ISO/IEC 27001 certification, with an independent penetration test once a year.

What to know before you start

Pricing is not public. The cost has two parts: a platform fee set by the size of the system, and research work billed by usage, in a unit called ASU, defined as one applied science agent working one session. The vendor states plainly that there is no per seat charge, that connecting more data sources costs nothing extra, that the platform fee runs on an annual contract, and that there is a ninety day exit window.

There is no version for individuals, and getting from first contact to a working loop means going through a sales process. Teams that want to run the loop themselves take the self serve route; those who want the metric proved once before committing can take a resident scientist, where one applied scientist embeds with the team, runs a round around a single metric in about eight weeks, and hands the loop back. If your agent system already logs its call chains, connecting does not require moving the stack and can start from the history you have; conversely, it needs real production data and enough system context, or the full value does not show up.

What it solves was never getting AI to write your code. It is turning a production system nobody can explain into public knowledge that can be reviewed, verified and improved again and again.