Resolve AI: evidence, agent teams and production incidents

Resolve AI builds agents for on-call work, incident investigation and other production operations. Its proposition is that engineers should receive a useful investigation before they spend an incident switching between logs, dashboards and source code. The buying decision is whether those agents can assemble the right evidence in your environment and remain controllable when a proposed action could affect production. A convincing diagnosis and a safe remediation are two different achievements.

01 / ProductAn investigation layer across the production toolchain

The current Resolve AI platform separates on-call agents, incident work and operational tasks. That structure maps to different engineering situations: an alert needing initial assessment, a complex outage requiring several hypotheses, and recurring background work. A buyer should choose one of those jobs first rather than treat all production automation as the same project.

The incident product page describes Agent Teams that investigate in parallel, including verification of findings against production evidence. Engineers use Workbench to follow the investigation, redirect it and pursue side hypotheses. This is a collaboration model, not simply a chatbot summarizing an incident channel after the event.

The integrations page lists connections across telemetry, infrastructure, code and collaboration tools, with MCP, APIs and webhooks as extension routes. The practical value depends on the specific data available through those connections. A logo in an integration catalog does not establish that every required field, historical query or account permission is present in a deployment.

02 / AudienceFor teams whose incidents cross system boundaries

Resolve is particularly relevant when a production problem spans several services and the investigation depends on combining different evidence types. A database symptom might originate in an application rollout; an application timeout might originate in a shared dependency. An agent that can follow those relationships could reduce the manual coordination burden, but only if it can distinguish a cause from a nearby event.

The Dynatrace blueprint helps frame a comparison with a broader observability and dependency-analysis platform. The Sentry blueprint is useful when the starting point is application errors and the code associated with them. Resolve should be evaluated for the investigative work it adds around the existing stack, including how its findings return to the people responsible for a service.

A small application with one clear alert and one obvious recovery procedure may not need a separate multi-agent investigation layer. Conversely, an organization with inconsistent service ownership may need to fix that operating problem before an agent can route findings effectively. A good pilot chooses a team with accessible evidence, a clear escalation path and a history of incidents that can be reviewed honestly.

03 / WorkflowA proposed investigation into a partial checkout failure

Consider a proposed pilot for checkout errors affecting one region after a release. This is a design scenario, not an incident we tested with Resolve. Give the pilot a known historical incident and the same data window the original responders had. Preserve later postmortem conclusions outside the initial input so the agent must investigate rather than paraphrase the answer.

The on-call page describes agents that triage alerts and gather findings before an engineer is paged. In the proposed workflow, the first task is to establish impact: which requests failed, which region and client versions were affected, and whether the condition is ongoing. These questions prevent the investigation from confusing a noisy monitoring failure with a real customer-facing outage.

Next, ask the agent team to compare plausible explanations. A recent deployment may be relevant, but a database resource limit, payment-provider incident or configuration drift could produce similar symptoms. The investigation should show evidence for and against each leading hypothesis. Parallel workers are useful only if their results are reconciled; several copies of the same assumption do not constitute independent confirmation.

An engineer can use Workbench to add missing context or challenge an inference. For example, if the agent blames a deployment that never reached the affected region, the correction should change the causal story and the next query. Preserve that correction as part of the record. The ability to recover from a wrong lead is more informative than a polished first answer on an easy example.

Keep the pilot’s investigation permissions read-only. If the agent proposes reverting a commit or running a workflow, route that proposal through a separate approval step with the expected effect and rollback path visible. Resolve’s incident page describes engineer-approved mitigation from the same surface. The fact that a button is conveniently placed beside evidence does not eliminate the need to understand the action.

After an approved repair, verify the customer outcome as well as the alert state. A silence can stop notifications without restoring checkout. A rollback can remove new errors while leaving already-failed transactions unresolved. Record the actual production change, the signals that recovered and any remaining work. This gives the team an incident record that can support a postmortem and a later evaluation.

04 / PricingCredits represent work, but the conversion needs a quote

The current pricing page describes a credit-based model. Credits are consumed as agents perform defined types of work, including chats, alert triage, investigations, incidents and background tasks. The page directs buyers to request pricing rather than publishing a numerical credit tariff or a complete conversion table. Treat that as a commercial model to clarify, not a publicly calculable subscription price.

A useful proposal should explain how a single incident consumes credits as it moves from initial triage to deeper investigation and follow-up work. Ask whether repeated triggers, abandoned investigations and engineer-driven side threads are counted separately. These are questions about the agreement, not assertions that each item necessarily creates an additional charge. The team needs a worked example using its own incident pattern.

Deployment also matters. The security page describes shared and dedicated cloud options, with a satellite component used to control access to customer systems. Ask the quote to identify the chosen deployment, included integrations, support and any minimum commitment. A result-based business case can be useful, but it should use measured staff time and incident outcomes from the pilot rather than borrowing percentages from unrelated customer stories.

05 / DistinctionsVerification and steering are visible parts of the workflow

Resolve’s incident design makes a verifier and an engineer workspace part of the product story. That is a meaningful distinction to examine: a useful result should connect timing, code changes, dependencies and observed behavior, while allowing a responder to challenge the conclusion. A claim of root cause is stronger when another person can follow the evidence without reconstructing every query.

The on-call workflow also creates an opportunity to separate urgency from investigation depth. A transient alert with no current customer impact may need a concise explanation, while a regional outage deserves a sustained inquiry. A pilot should measure whether the agent allocates attention appropriately. Investigating every warning with maximum effort can create cost and distraction without improving reliability.

Over time, engineer corrections can become useful operational knowledge, as the product pages describe. The quality of that memory matters. A one-time exception should not become a universal runbook, and a workaround from an old architecture should not silently govern the next system. Ask how the team can inspect, update and retire learned context when services change.

06 / QuestionsReconcile investigation controls with optional actions

Resolve’s public security page uses broad no-write-access language, while the current on-call and incident pages describe mitigation actions, including configurable autonomy for known patterns. The safest reading is to distinguish read-only investigation from explicitly enabled action capabilities, but the public wording is not fully reconciled. Confirm the permissions and approval rules for each integration in the actual deployment rather than assuming one blanket setting applies to everything.

The security material also describes data isolation and limited access, but this article did not inspect a customer deployment or independently audit those controls. Confirm what the satellite reads, what derived information is retained, and how access is restricted by environment or namespace. An integration that can read a large telemetry system deserves a deliberate scope even if it cannot change application data.

Finally, test missing and misleading evidence. Remove one connector, introduce a delayed log stream and include an incident that self-resolved before the alert arrived. A useful agent should identify the limits of its conclusion. We did not independently verify Resolve’s accuracy, claimed time savings or service availability; those remain outcomes for the proposed pilot to establish.

07 / DecisionBuy a better investigation, then expand the action boundary

Resolve AI belongs on the shortlist when an engineering team spends substantial effort assembling incident context across tools. Begin with historical cases, require an inspectable evidence trail and measure how much useful work reaches the responder. Add remediation only after the investigation has earned confidence and the team has defined precisely what the agent may do without a new approval.