Resolve

Resolve is a plausible fit for an IT or managed-service team that already has a system of record and wants to remove repeatable handoffs between a ticket or alert and an approved resolution. Its current public material describes workflows that can read a ticket, validate it against configured identity and policy context, execute across connected systems, verify the result, and write an audit trail back to the ITSM record. [S1][S5]

The trade-off is action authority. An orchestration layer can concentrate a large amount of access: an error in identity mapping, a weak approval rule, a stale CMDB record, or an over-broad service account can turn a routine workflow into a cross-system incident. Pilot one low-risk, reversible workflow and make a service owner accountable for each connection, approval, exception, log, stop path, and recovery. [S1][S2][S5]

Best for: IT and MSP teams with established service and change practices, dependable ITSM and identity data, least-privilege access, and the operational discipline to test a small workflow before expanding it.

Not for: Teams seeking a self-serve substitute for service ownership or incident judgment; organizations without a reliable system of record, service taxonomy, CMDB or identity source; unmanaged client tenancy; or a rollout that starts with privileged, destructive, security-sensitive, or cross-client actions.

Fulfill a routine identity or access request

• Trigger: An approved password-reset, access, software-provisioning, or onboarding request enters the ITSM system or a supported self-service channel.
• Inputs: Authenticated requester identity, ticket, approved entitlement policy, CMDB and identity context, target account or group, least-privilege service account, approval rule, and named identity owner.
• Output: Resolve says its workflow can read the ticket, validate the path, execute an action across connected systems, verify the result, and update the system of record. [S1]
• Human checkpoint: The identity owner validates non-standard, privileged, failed, duplicate, or mismatched requests and reviews a sample of completed routine requests before auto-close is trusted.
• Success measure: Correct-identity rate, policy-compliant fulfillment, unauthorized-action rate, completion time, manual touches, re-open rate, audit completeness, and recovery time.

Triage and remediate a recurring L1 incident

• Trigger: A ticket, monitoring event, or alert matches a documented, low-risk incident pattern such as a VPN, endpoint, or application-health problem.
• Inputs: Ticket or alert context, service and CI record, maintenance window, approved diagnosis and remediation steps, access to the target systems, verification test, rollback rule, and on-call owner.
• Output: Resolve describes ITSM automation that can validate context, execute across directory, identity, network, cloud, or SaaS systems, verify the fix, and write back to the service record. [S1]
• Human checkpoint: A service owner reviews exceptions, confidence gaps, policy conflicts, production changes, repeated failures, and any action that reaches outside the pre-approved runbook.
• Success measure: Correct diagnosis, MTTR, false remediation rate, escalation rate, repeat-incident rate, rollback time, SLA effect, and complete ticket evidence.

Deflect a standardized employee request

• Trigger: An employee asks a common IT question or initiates a standard request through Slack, Teams, or email.
• Inputs: Approved knowledge, request category, requester identity, eligibility rules, service catalog policy, channel context, and an escalation queue.
• Output: Resolve says conversational self-service can resolve routine requests before a ticket opens, and its AgentLab materials describe agents grounded in customer knowledge and connected systems. [S1][S2]
• Human checkpoint: The service desk owns the knowledge source, reviews sampled answers and closures, and receives any low-confidence, sensitive, ambiguous, or out-of-policy request with the original context.
• Success measure: Deflection quality, answer accuracy, ticket creation rate, wrong-policy rate, escalations, employee effort, reopened work, and unsafe-answer rate.

Run a bounded MSP maintenance workflow

• Trigger: A scheduled client maintenance window or monitored client event reaches a defined threshold.
• Inputs: Correct client and tenant identity, approved maintenance plan, authorized monitoring and management connections, documented change record, client-specific approval, verification checks, and rollback.
• Output: Resolve positions the platform for MSPs coordinating monitoring, observability, infrastructure, network, cloud, and service-management systems. It says agents and prebuilt workflows can handle routine needs and operational signals. [S8]
• Human checkpoint: The service-delivery owner confirms the tenant, scope, window, credentials, affected assets, execution evidence, client communications, and recovery before and after each pilot run.
• Success measure: Correct-client rate, successful change rate, client-impacting error rate, completion within window, alert reduction, manual effort, evidence completeness, and rollback time.

1. The team selects one request or alert type with stable inputs, a named process owner, an existing manual runbook, and a safe manual fallback.
2. Resolve is connected to the ITSM system and the specifically required identity, infrastructure, network, cloud, monitoring, or SaaS systems. Its published ITSM flow describes reading a ticket, validating it against CMDB, identity, and entitlement policy, executing, verifying, and writing back. [S1]
3. A configured agent or workflow selects an allowed path. Resolve says AgentLab uses plain-language role and guardrail definitions, reusable skills, and governance-aware deployment; this does not remove the buyer's responsibility to test the actual instructions, permissions, and connectors. [S2]
4. For actions, use explicit approval gates for irreversible or privileged work. Resolve says its governance features include role-based access, segregation of duties, change approvals, rollback rules, and activity-level logging. [S5]
5. The workflow verifies the result, records the event and steps, updates the system of record, and sends exceptions to a named queue. A buyer should rehearse stopping a workflow, revoking access, correcting records, rolling back, and returning to the manual runbook. [S1][S5]

Verified facts

• Resolve's current ITSM page describes a workflow that reads a ticket, validates it against CMDB, identity, and entitlement policy, executes across configured systems, verifies the fix, and writes back to the ITSM record. [S1]
• Resolve says AgentLab supports plain-language agent role, scope, instruction, and guardrail definition; the dated announcement says teams can test agent behavior, roles, and permission confidence before wider deployment. [S2]
• Resolve's governance page describes activity-level workflow logging, workflow stop and log-export functions, plus role-based access, segregation of duties, change approvals, and rollback rules. [S5]
• Resolve's published subprocessor page lists active and new providers, optional model and search services, and stated regions. [S6]

Vendor claims

• Resolve states that its platform can close L1 tickets, resolve routine requests, and correlate or remediate operations alerts. It also advertises volume, ticket, cost, and time outcomes. These are vendor capability and outcome claims, not a forecast for an individual buyer. [S1][S3][S8]
• Resolve says AgentLab expands the integration of Espressive Barista capabilities. Confirm which assistant, agent, migration, knowledge, and support capabilities are included in the selected offer. [S2]
• Resolve announced a 2023 SOC 2 Type II examination and describes its public security capabilities. Obtain current reports and scope rather than treating the announcement as a current contractual guarantee. [S5][S7]

B2Bagents assessment

Resolve is most credible where the buyer has already documented a recurring service or operations workflow and needs a governed execution layer across tools. The value proposition is not merely ticket reduction: it is the ability to connect intake, policy checks, approvals, action, verification, and recordkeeping in one controlled path. That same cross-system reach makes narrow scope, clear service-account ownership, client segregation, and tested rollback more important than the agent label. This is an editorial inference from the documented workflow, governance, and MSP materials, not a hands-on test. [S1][S2][S5][S8]

• The reviewed sources do not establish the exact Resolve edition, AgentLab availability, agent behavior, connector list, service limits, workflow count, implementation work, support response, usage measure, price, term, renewal, cancellation, or exit terms for a buyer.
• Public pages list integrations and describe write-capable resolution flows, but do not prove the field-level scope, service-account rights, client isolation, action permissions, connector behavior, or rollback for a specific tenant. [S1][S5]
• Resolve's security announcement is dated 2023. It does not establish the current report period, exceptions, product scope, regional service, model path, retention, support access, or contractual terms. [S7]
• The subprocessor list identifies current and prospective providers and several possible regions, but it does not replace a tenant-specific data-flow assessment or contractual DPA. [S6]
• Espressive's former website redirects to Resolve, and Resolve's dated AgentLab announcement refers to integration of Barista capabilities. The selected plan's transition status, feature availability, data migration, and support responsibility need direct confirmation. [S2]
• A workflow can fail through stale knowledge, incorrect ticket data, wrong identity, overly broad permissions, hallucinated or weak agent reasoning, a changed external API, partial execution, duplicate execution, absent write-back, or a verification check that is too shallow. [S1][S2][S5]

Good-fit conditions: repeatable request or incident patterns; reliable ITSM, identity, CMDB, and monitoring data; current runbooks; named owners for every target system; precise approval and change policy; low-privilege service accounts; a test environment; and a manual fallback.

Poor-fit conditions: undocumented processes; inconsistent ticket and CI data; no client-separation design; a desire to automate judgment-heavy incidents; unclear authority over credentials or production changes; or a project that cannot measure errors, exceptions, and recovery.

Predictable failure modes and controls:

• A ticket matches the wrong workflow. Use deliberate eligibility rules, ticket-category and CI checks, a low-risk starting scope, sampled review, and forced escalation for uncertain or sensitive cases. [S1]
• An agent uses an incorrect instruction or tool path. Test representative and adversarial cases, freeze approved workflow versions, restrict skills, preserve a manual route, and do not expose privileged actions until evidence supports it. [S2]
• A service account performs a wider action than intended. Apply least privilege and segregation of duties; test token rotation, system-specific authorization, approval gates, offboarding, audit records, and emergency revocation. [S5]
• An automated change harms the wrong client or environment. Carry client and tenant identity through every trigger and connector, require a client-scoped approval, validate the target before execution, and retain change and rollback evidence. [S8]
• A workflow succeeds technically but fails to resolve the incident or update the record. Require a business or service verification check, inspect the ticket write-back, measure reopens, and stop expansion after unexplained closures or missing logs. [S1][S5]

Start with one routine, reversible workflow: for example, a scoped password reset for a non-privileged group, a known endpoint remediation, or a monitored alert with a read-only diagnostic stage and a separately approved action. Do not start with broad identity administration, cross-client MSP automation, security containment, production configuration changes, or external communications.

The buyer should name an ITSM owner, process owner, system owner for every target, identity owner, change manager, service-delivery owner, client approver where relevant, security and privacy owner, platform administrator, on-call escalation owner, and commercial owner. Give each one an explicit read, approve, change, stop, export, and recovery responsibility.

Resolve lists ITSM integrations and says its platform runs alongside the existing system of record. It also describes integration across identity, endpoint, monitoring, network, cloud, and SaaS systems. For every actual connection, validate the source and target fields, client boundary, authentication, service account, network path, data read or written, model path, rate limits, retries, duplicate protection, approval, logging, retention, support access, credential rotation, offboarding, and manual fallback. [S1][S5]

Write the exit procedure before enabling writes: stop agents and workflows, revoke secrets and accounts, remove integrations, preserve required ticket and change evidence, correct partial actions, revert to the manual runbook, export available workflow and log data, and follow contracted retention and deletion terms. The reviewed public sources do not establish a complete buyer-specific exit path.

Resolve says a remote executor can execute inside the customer's network, connecting outbound over TLS. Its governance page says activity logs include event source, invoked workflow, and activity-level steps; it says workflows can be stopped and logs exported. It also describes role-based access, segregation of duties, approvals, and rollback rules. [S5]

Resolve's published subprocessor page identifies AWS, Azure OpenAI, Elastic, Anthropic, OpenAI, Groq, and other providers with stated locations and optionality. It says regions include the US, EU, GovCloud, and Canada, but it also notes that personal data may be accessed, processed, or stored internationally. [S6]

Resolve announced a SOC 2 Type II examination in December 2023. This is useful procurement context, but not sufficient evidence for a production decision in 2026. Obtain the current SOC report and period, scope, exceptions, service coverage, ISO evidence where relevant, DPA, complete subprocessor and model-provider list, architecture and data-flow diagrams, regional commitments, retention and deletion behavior, encryption, SSO/MFA/RBAC, audit logging, support access, vulnerability and incident process, continuity, export, and transition terms. [S7]

No reliable public list price was found in the reviewed current product, MSP, and ITSM pages; the public call to action is a demo request. Treat the commercial model as quote-based until the vendor provides a written proposal. [S1][S8]

Ask the vendor to separate platform edition, named users, agents, agent runs or other usage, workflow count, connectors, remote executors, environments, implementation, migration from Espressive where applicable, training, managed services, support tier, security-review support, overages, pilot scope, term, renewal, cancellation, data export, deletion, and transition assistance. Compare those costs with the staff time and risk controls that remain after automation, not only with ticket volume.

1. Scope: Choose one routine, low-risk request or alert with a documented manual runbook, named IT and system owners, clear eligibility, least-privilege access, verification criteria, and a manual fallback.
2. Baseline: Measure request volume, ticket age, manual touch time, MTTR, reopen rate, SLA attainment, error rate, escalation rate, change failures, access exceptions, audit completeness, and operating cost.
3. Test set: Include routine, duplicate, incomplete, stale, wrong-identity, unauthorized, privileged, unusual, malicious-instruction, unavailable-target, partial-success, retry, wrong-tenant, incorrect-write-back, verification-failure, workflow-stop, credential-revocation, rollback, and manual-recovery cases.
4. Pass threshold: Agree in advance on correct workflow selection, identity and target validation, authorization, action success, independent verification, system-of-record accuracy, safe exception handling, complete logs, recoverability, and net benefit after owner and control effort.
5. Stop conditions: An action reaches the wrong person, client, environment, or system; a privileged or irreversible action bypasses approval; a log or ticket record is missing; an unauthorized data disclosure or write occurs; a workflow cannot be stopped or recovered; a control cannot be evidenced; or the pilot cannot beat the controlled manual baseline.

Compare Resolve with the directory's Atera, Atomicwork, Aisera, Freshservice, Moveworks, MSPbots, NinjaOne, Rewst, SuperOps, and SysAid profiles. The useful axes are whether the buyer needs an execution layer across existing tools or a service-desk platform; MSP versus internal-IT tenancy; identity and infrastructure action scope; agent-building approach; ITSM write-back; approval and rollback design; remote execution; price model; and the evidence needed before routine actions become unattended.

1. Which exact actions can our selected edition run, and where? Demonstrate one ticket and one alert from source record through policy, approval, connector, action, verification, ITSM update, log, stop, and recovery. [S1][S5]
2. How are agents tested before production? Show the AgentLab test and permission-confidence path using the buyer's routine, ambiguous, malicious, privileged, and integration-failure scenarios. [S2]
3. How do you isolate clients and environments for an MSP? Provide the actual tenant, credential, role, log, approval, and export model for a workflow that touches multiple client systems. [S8]
4. What data reaches the platform, executor, model, and subprocessors? Map ticket, employee, CMDB, identity, knowledge, alert, and action data through the selected region and optional AI features. [S5][S6]
5. What is in the current security evidence? Provide the current SOC report and scope, DPA, subprocessor list, model terms, regional commitments, retention, deletion, support access, incident terms, and exit process. [S6][S7]
6. What does the quote include over the full term? Separate users, agents, workflows, connectors, executors, environments, implementation, migration, support, consumption, overages, renewal, cancellation, export, and transition. [S1][S8]