Pythian Says AI Cut Database Resolution Time by 80%

A database incident arrives with an unwelcome companion: the hunt for what to do next. Someone must read the ticket, find the relevant knowledge and assemble a sensible starting point. Pythian’s wager was to give that opening act to AI, so the engineer could enter with something more useful than a blank page.

In an August 27, 2026 Google Cloud account, Pythian CTO Paul Lewis and SVP of business development Vanessa Simmons describe a Gemini Enterprise rollout across 500 employees in 27 countries. They report an 80% reduction in database mean time to resolution and threefold active user engagement. The company had made itself the test customer. [1]

The attraction is easy to understand. Preparation can consume an incident’s early minutes without improving the database at all. If useful context reaches the person responsible sooner, the whole response can begin further along. That is the promise worth examining beneath the handsome percentage.

Paul LewisChief Technology Officer

Vanessa SimmonsSVP, Business Development

Co-authors of the Google Cloud account. Portraits: Pythian.

A ticket gets a head start

The executives describe a workflow spanning 15,000 monthly database tickets: agents read incoming tickets, search knowledge bases and produce preliminary mini runbooks before engineers intervene. [1]

Read, retrieve, draft, hand over. The sequence matters. A ticket supplies the problem; existing knowledge supplies potential context; a runbook turns that material into a proposed course of action. The engineer then encounters an assembled starting point rather than scattered pieces. This is an interpretation of the workflow’s practical value, rather than a published breakdown of where each minute was saved.

A preliminary runbook is still preliminary. A plausible instruction deserves scrutiny, particularly when the next action concerns a live database. The useful distinction is between preparing a recommendation and owning the decision to act on it. The account explicitly places an engineer after the automated preparation. It offers no basis for declaring that every ticket now resolves itself.

THE HUMAN HANDOFF

“before an engineer touches them”

Paul Lewis & Vanessa Simmons, on when the runbook is prepared · Google Cloud

Two numbers, two different stories

Resolution time measures how long an incident takes to finish. Active engagement measures participation in the AI rollout. An improvement in one does not explain, or substitute for, an improvement in the other.

An 80% reduction leaves one fifth of the former mean. On an illustrative index where the starting average is 100, the new average would be 20. Those are relative units, not observed minutes. The executives’ account supplies neither the original duration nor a measurement window, ticket-severity breakdown or control group. [1]

Similarly, threefold engagement means three times the starting level; it is not a claim that every employee used the system, or that each became three times as productive. Neither reported metric establishes a reduction in engineering headcount.

For a buyer trying to assess the result, the useful questions follow naturally: were comparable incidents measured, how much checking did the drafts require, and did faster closure preserve the quality of the fix? Averages can be persuasive. They become more informative when the reader knows what went into them.

Give the people and the process their own teams

Pythian separates its centers of excellence. The people productivity COE handles enablement and builds no-code agents for nontechnical teams. The process productivity COE engineers custom agents and deeper workflows. [1]

The organizational logic is stronger than the terminology. Teaching an HR colleague to use an assistant and integrating an agent into database operations are different jobs. The first needs a grasp of everyday work, confidence and habits. The second needs engineering decisions about systems, data and what happens when a workflow fails. Making one team responsible for both can leave one ambition waiting politely behind the other.

There is also a lesson about responsibility. Asking every employee to invent an agent makes adoption depend on personal enthusiasm. Giving enablement a named owner creates somewhere to take a confusing output, a poor fit or a task that the tool does not yet handle well. Giving custom engineering its own owner makes the harder integration work equally visible.

The launch is the easy photograph

The operating model moves from Field CTO strategy and governance to platform deployment, dual COE execution and production XOps. XOps owns continuous monitoring, prompt tuning and model observability as behavior changes over time. [1]

The reasoning here is practical: a workflow has a life after its demonstration. A new model, a changed knowledge base or an altered ticket format can make yesterday’s instruction less useful today. A successful launch captures one moment. Operations must deal with the moments that follow.

Prompt maintenance therefore belongs beside the agent’s performance, rather than in a forgotten document belonging to its original builder. If a draft becomes less accurate, someone needs to notice, investigate and repair the instruction or its surrounding context. Otherwise the engineer may inherit the verification work that automation was supposed to reduce.

This is also where the economics become more interesting. The cost of building an agent is only part of the calculation. Keeping its recommendations useful determines whether the initial saving survives.

One Gemini name, different work

Gemini Enterprise and Gemini in Google Workspace need careful naming. Google describes Gemini Enterprise as a search, assistant and agent platform that connects organizational information and can host custom agents. Workspace’s Gemini features bring AI into collaboration tools such as Gmail, Docs and Meet. [2][3]

Pythian’s separate Workspace consulting offer covers migration, security and Gemini adoption. It emphasizes role-based workflow training, prompt libraries, internal champions and structured change management. Its services page also discusses enterprise deployment and custom agents; that breadth does not make the internal database result a measured outcome of its Workspace adoption service. [4]

The distinction matters when software access is mistaken for a completed change. A person drafting a document needs different guidance from someone assessing a proposed database response. A generic introduction can show both where to click. Role-based training can teach each what a useful output looks like, what requires checking and when to ask for help.

Change management addresses the less glamorous questions: who has time to learn, which task should change first, and where a colleague can report trouble. Without answers, an available tool can remain an unused invitation.

The engineer enters with a draft

Pythian’s account offers a specific place to begin thinking about enterprise AI: the interval between receiving a problem and being ready to address it. Preparing that interval is a concrete design choice, one that can be inspected at the handoff.

The next useful test is equally concrete. Does the engineer receive relevant evidence and an actionable draft, or a new pile of prose to untangle? Can the team tell when that usefulness deteriorates? Can employees learn the workflow without becoming its unpaid designers?

A machine can be impressively quick at producing an answer. The more valuable achievement is helping the responsible person reach a sound decision sooner. In database operations, the draft earns its place when it makes that next human judgment easier.