Build an agent that triages tickets

Give the first version a narrow boundary

Use a disposable set of tickets with an agreed triage rubric. The agent may read a ticket and search an approved knowledge base. Its result must include the ticket ID, a proposed category, supporting source IDs and a draft reply. An uncertain case goes to a person with a reason it could not be resolved.

If everything the model needs already fits in one request, try a single classification step first. Add a tool loop when the task requires fetching additional records or deciding which permitted lookup comes next. Neither version needs billing, outbound email or a vector database just to demonstrate the job.

Keep execution in your application

For Claude client tools, the model returns a tool-use request; your code runs the function and returns a result tied to its request ID. External text returned by tools remains untrusted. These are protocol facts from Claude: handling tool calls, not proof that a particular support integration works.

1. Read: load only the records the signed-in operator may access. Give each trial a durable run ID.
2. Check: accept only allowed tool names and validated arguments. Enforce permissions in the tool handler even when the arguments match the schema.
3. Run: perform the bounded lookup, record its result and return a safe error if it fails. Set a maximum number of calls and an overall time limit.
4. Review: show the draft beside its source material. Any later write action needs an explicit approval for the exact target and change.

Store enough state to distinguish a completed lookup from a failed attempt. A stop control should prevent further calls, while leaving an operator able to inspect what already happened. Redact secrets and unnecessary customer data from those records.

Rehearse these failures

Ticket contains instructions to ignore the rules

Treat the ticket as customer content. It cannot grant new tools, permissions or authority to send a reply.

Lookup asks for another customer’s record

The application denies access and records the denial; the model does not receive the record.

Tool times out or returns malformed data

Stop or retry within the documented limit. Show an unresolved state rather than a fabricated answer.

Run is resumed twice

Recognize completed work by run and action IDs. A later approved write must not happen twice.

No supporting answer exists

Return an uncertainty reason and hand the ticket to an operator with the original context.

Measure accepted work, then add components

Compare the proposed priority and reply with an operator’s decision. Record unsupported claims, missed escalations, review time, tool failures and total usage per accepted ticket. These are suggested measurements; no result for this integration is claimed here.

A server endpoint can host the first loop. Investigate Vercel for deployment or Supabase for persistent run records only when your hosting and storage requirements justify them. Check permissions, job duration and recovery on the configuration you actually choose.

Budget model input and output, repeated calls, external lookup charges, compute and operator review. A consumer chat subscription does not establish the price of your API workload. Use current provider pricing and the recorded trial usage.