The AI in your ticketing system should be yours
Choose how a model reaches your ticket data, where inference runs, and who maintains the connection. A commercial API and a model your team serves have different data handling, cost, and operating requirements.
Evaluate a supported model endpoint for the feature you need, or build a plugin for a specific model-backed action. Validate the connection and its output, then configure the permissions and independent review around that action.
Use a supported model API or a customer-built plugin that calls your chosen provider. Review its credentials, processing terms, retention settings, and usage costs.
Serve inference on infrastructure your team operates. Verify endpoint compatibility, capacity, allowed connections, and the data the integration sends before relying on a local processing boundary.
Connect a domain model through a supported endpoint or a plugin your team builds. Your engineers own the adapter, output validation, deployment, and compatibility checks.
A custom integration can select models for different tasks. Define and test that routing in your service; check output quality, latency, and cost for each workflow.
Choose the model and the action gate separately. Recheck both when the integration changes.
Four decisions behind the model choice
Use the same evaluation for a hosted API and inference you operate. Name the owner, required evidence, and acceptance test for each decision.
Check the supported endpoint, request format, and returned output. A new model or version needs regression checks against the work your operators actually review.
Identify which ticket text and attachments reach the model. Include inference, logs, retention, support access, and any further service calls in the data-flow review.
A commercial API carries provider usage costs. Locally served inference needs hardware, capacity planning, monitoring, and upgrades. Include integration maintenance in either case.
Test the proposed output with synthetic examples and operator review. Decide what model identifiers, inputs, results, and decisions the integration must retain for later investigation.
Put a model-backed action behind a clear contract
A customer-built plugin can call a model as part of a ticket action. Its developer owns the prompt, selected context, output validation, and external credentials. This extension path is separate from the product's built-in AI configuration.
Your plugin exposes a discovery and execution contract. For example, a customer-built action could read supplied ticket context and return a summary for an operator to check.
Latch checks action permissions and configured approval gates. Maker-checker keeps the requester from approving or executing the same request; approval and execution are separate steps.
The plugin reports its result and can request supported effects, such as a ticket comment. Include model and version details in that evidence if your review requires them; test what is retained.
Review the discovery and execution contracts in the TypeScript or Go SDK and the plugin system. Verify the allowed endpoint and failure behavior; a locally hosted service is not automatically an allowed plugin destination.
The model proposes. The workflow decides.
A model-backed action could return a proposed response for an operator to inspect. A separate action that changes another system needs its own permissions, input validation, and review decision. Do not give a suggestion service unnecessary downstream authority.
Configure approval for the action and use two-person review where required. Amount thresholds and other business rules belong in the integration logic; the current action gate is not an arbitrary monetary rule builder.
Keep the saved request, independent review, and reported result connected to the ticket. Verify the records and retention controls your workflow needs, including any model identifiers returned by the plugin. A denied network call or permission check does not imply a complete operator-visible timeline entry.
Give operator feedback an explicit purpose
Operators can review suggestions and correct the work. Those decisions can inform your own evaluation process, but using them to train or improve a model requires a separately designed data pipeline, permissions, and tests.
For deployment on your infrastructure, document the model endpoint alongside identity, mail, storage, logs, and integrations. Review data flows and operating responsibilities. Local inference alone does not prove the entire installation is disconnected or that no data leaves it.
When bringing your own model is not worth it
A supported commercial API may fit when its data terms meet your requirements and your team does not want to operate inference hardware. Check the integration effort, provider bill, and output quality before choosing it.
Operating inference yourself may fit a specific processing-location requirement or workload. Include hardware, monitoring, upgrades, and custom adapter maintenance in the decision. The platform team path covers that ownership; compare the model options in your deployment and cost review.
Choose the deployment and control detail you need
Start with self-hosted ticketing or the complete approval workflow. The feature pages explain how independent review, action records and deployment controls fit together.
Evaluate your infrastructure, operating responsibilities and customization path.
Keep the incoming ticket, independent review and external result together.
Prevent the action requester from approving or executing their own request.
See configured action gates, request states and separate execution checks.
Review decision and execution records alongside the controls needed for independent retention.
Inspect identity, storage, integration traffic and operational responsibilities.
Bring email, forms and API requests into one ticket queue.
Apply ticket records, checklist reviews and configured approval actions to claims work.
Questions teams ask before committing to a model
What security reviewers, platform leads, and finance ask when the AI in the ticketing system is a choice rather than a default.
Which models can we actually use?
Verify support for the exact endpoint and feature you need. A customer-built plugin can connect a commercial API, locally served model, or domain model when its contract and network destination meet the deployment policy. A reachable URL alone does not establish compatibility.
Does our ticket data go to a model we do not control?
The data boundary depends on every configured AI feature and integration. Review built-in model settings as well as plugins, the context they send, provider terms, logs, and other service calls. Local inference needs a tested data-flow and network policy.
How hard is it to swap models later?
A compatible endpoint may need a settings change; a different API or output format may need adapter work. Recheck prompts, output validation, permissions, review gates, retained evidence, and failure behavior before switching. Agree an owner for those regression checks.
What stops the model from taking an action on its own?
For plugin actions, Latch enforces applicable permissions and the configured action gate. Keep proposals and sensitive execution separate, and configure maker-checker when independent review is required. Your integration still owns downstream permissions, business rules, and input validation.
Can we tell which model was responsible for a decision?
Define the evidence required for that workflow. A plugin should return the model identifier, version, and relevant result when they are needed for review, and you should verify how those details are retained. Do not assume every AI path automatically records a complete model history.
Do we need an ML team to run this?
A commercial API avoids operating the inference hardware, but its integration still needs an engineering and workflow owner. Serving a model yourself adds capacity, monitoring, security, and upgrade work. Choose the arrangement your team can support and validate.
Bring the model and the action you want to evaluate
Follow a ticket through the product, then review the endpoint, integration work, data handling, and action controls your workflow needs.