AI Support Agents with Customer Context

A customer reports a problem outside normal support hours. A useful first response needs more than a model: it needs the customer's service level, relevant documentation, and the history of similar cases. The system must gather that context, start the conversation, and bring in a person when the case needs one. Harper's own support agent shows how to put those responsibilities together in one application, while keeping Zendesk and external AI providers in place.

How Harper brings support together

Harper runs its own production support agent as a single application. It handles partner-submitted support tickets. When Zendesk sends a ticket or reply webhook, the application verifies it, stores processing state, and fetches the authoritative conversation from Zendesk. It matches the end customer against synced records, determines the SLA, and retrieves relevant docs and that customer’s ticket history from vector indexes.

Webhook handlers, operational tables, vector indexes, and background jobs belong to the same Harper application. Application code gathers the first context and sets limits. Within those limits, the model can search docs, ticket history, and attachments for a few rounds, and the application then posts a reply, classification, and status to Zendesk, or escalates to a person.

Background jobs sync records and index docs and ticket history, with coordination records kept in the same application. This implementation needs no separate vector database or job queue. Zendesk, the model and embedding APIs, the docs sources, and the escalation and observability tools stay external.

Alternatively, assemble from separate services

A typical build keeps the same workflow and external dependencies. A hosted webhook service receives Zendesk events and hands them to application workers. Workers read from an operational database and a vector retrieval layer, call the model, and post back to Zendesk. Scheduled jobs sync records and re-embed docs and ticket history. PostgreSQL with vector support can serve as both the operational database and the vector store, and a queue is optional for durable execution.

These are responsibilities, not a mandatory shopping list. One backend can host the API, support logic, and scheduled jobs, and the team chooses which components need independent deployment and scaling.

Where coordination adds up

The cost sits between the pieces. Each service needs its own deployment, credentials, monitoring, and retry behavior. Indexes must stay in step with synced records, or the agent answers from stale context and customers notice. When a webhook fails halfway, someone must know which service owns the retry. Index freshness and retry ownership exist in any design. Harper reduces how many places they live; it does not remove them.

Why Harper matters

• Fewer boundaries to own. Intake, state, retrieval, and background jobs share one application. That cuts deployment targets, service credentials, and network hops between them, which means less infrastructure work for the team.
• Answers grounded in customer context. Customer records live in the same application as the vector indexes that hold docs and ticket history. Support logic puts the customer's record, SLA, and filtered history in front of the model, so replies reflect the person asking.
• Workflow engineering stays yours. Harper does not remove matching rules, SLA logic, escalation, or recovery design. It gives that code one place to live.
• Operational results in context. Harper's own support agent handles first responses, follow-ups, and triage around the clock, and detects when a case needs a person. Median first response is one minute. With the agent and expanded human coverage working together, median full resolution fell from 121 hours to 18.6 hours within two months. The agent keeps every case moving, so engineers spend their time on the problems that need them.

Plan for reliable support

Harper provides the application runtime, tables, and vector search. The team writes the support workflow and the jobs that sync and index its data.

Webhooks can arrive twice or out of order, and work that fails after the webhook is acknowledged won't be resent by Zendesk. Design for duplicate handling and for recovering failed work yourself, rather than assuming exactly-once execution. Decide how jobs claim work and what happens when one stops midway.

Retrieval scopes need deliberate filters and testing, since customer-filtered history is only as private as the filters you write.

Bound what the model can do. Tool use limits, reply caps, and shadow mode let you automate in steps. In shadow mode, riskier actions such as closing a case or sending a follow-up are recorded as internal notes until you enable them. Define clear rules for when a case goes to a human.

Related resources

• Harper documentation: how tables, vector indexes, application components, and background jobs work in one Harper application.
• HarperFast on GitHub: public repositories and starters for building Harper applications.
• Agents on Harper: A Practical Guide (PDF): how to build agent workloads with local data, durable state, and application logic in Harper’s unified runtime.

Want to see a working support agent on Harper? Request a demo.

Start with one support queue

Pick one queue and run the agent in shadow mode first, then allow limited replies. Measure first-response time, how often reviewers judge answers well grounded, the share escalated to humans, model cost per ticket, and time to recover after a failed webhook or a delayed index sync. Compare normal operation with those failure cases. Bring your ticket volumes, SLA rules, and current stack to a conversation. Discuss your architecture with Harper.

‍