Support AI agent · Agent assist
Support Copilot AI Agent
Hand a draft to the person answering, surface only the part of the record the reason for contact justifies, and leave the sending to a named queue lead who edits what goes out.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named lead
- Never sends
- After launch
- Agent Care
What this agent does
Drafts the reply, never sends it
In
- 01
A draft is offered to the person answering, and this agent never speaks to the customer at all.
- 02
A reply is sent by that person, and Art. 50(1) binds the provider of a system, not you.
Reason
- 03
A draft reviewed and sent by a human as the main interlocutor is excepted by the Guidelines.
- 04
A reply whose review is a mere possibility circumvents the duty, which that paragraph refuses.
- 05
A draft whose object is the customer problem sits outside the four verbs of Annex III 4(b).
Decide
- 06
A draft scored per person, or a ticket routed by behaviour at the desk, moves it inside.
- 07
A draft tool that also scores is not classified by halves, says guidance that is still draft.
Out
- 08
A draft tuned to mood is prohibited for the person answering, high-risk for the customer.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Drafting, scoping the record to the reason for contact and logging every read belong to the agent. Sending belongs to a named queue lead, who edits the draft and owns what goes out.
Example workflow
One reply, drafted to sent
- 1Ticket arrives at the queueEmail, chat, web form, an in-app session or a thread routed in from another queue
- 2Record scoped to the reasonThe reason for contact, the fields it justifies and every read logged against the ticket
- 3Reply drafted for a personThe draft, what each claim rests on, the flagged lines and confidence
- 4Controls appliedRecord-scope checks, source checks on each claim, inference checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing reaches the customer at any of them — the agent is drafting, and the lead lane opens at the confidence gate.
Goes to the named queue lead to send.
Adds a second reviewer read first.
Queue lead review
The draft is held with the record it drew on, its flagged lines and the confidence.
Approve · Edit the draft · Send to reviewer
Sent — by the named queue lead
- 6Conversation record updatedOnly where write access and records policy allow it
- 7Outcome evaluatedDraft survival by intent, edit outcomes, review depth and what review found
Edits
Each lead edit is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Sending a drafted reply to a customer.
- Deciding what the customer is owed.
- Scoring or ranking the people at the desk.
- Inferring the emotion of anybody at all.
Automation boundary
Agent acts unaided
- ✓Draft the reply and show the source of each claim.
- ✓Surface only the part of the record the reason for contact justifies.
- ✓Log every read, and every edit made before sending.
- ✓Show how much of the draft survived, counted by intent not by person.
Nothing reaches the customer here; a named queue lead edits the draft and sends it.
- Judging whether a review was deep enough.
- Telling a customer a claim has been checked.
- Choosing which tickets a person is given.
- Changes to scope, drafting or approval rules.
Example output
One drafted reply, annotated
This serves a desk where staff who over-read a customer record have been prosecuted as individuals while their employer was not; below is one draft exactly as the agent leaves it.
Draft output · single reply
Illustrative example- Conversation
- Inbound, billing query
- Drafted line
- Your last invoice was raised on the older plan rate
- Record surfaced
- Billing fields only
- Claim rests on
- Plan record, 3 August 2026
- Confidence
- Held unsent
- Sent by
- The named queue lead, by name
As received
Taken from the ticket and the plan record as they stand — nothing on this side is written by the agent.
What the record holds
- Ticket thread
- Plan record
- Read log
Why nothing left here
Sending a reply to a customer is a call a named queue lead makes.
What the score decides
Below the configured threshold the draft picks up a second read before the lead.
Action
ApproveEdit the draftSend to reviewerValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every reply that leaves
From the ticket in front of you
Draft it, then hand it over
The customer-success ticket-deflection agent answers the customer directly; this one never speaks to the customer, and the person at the desk is its user rather than its subject.
Review is not a rubber stamp
The exception is not a checkbox but a claim about what the person did, and an approval faster than the subject line can be read is not a review.
What was checked, and not found
No US law requires telling a customer that a human reply was AI-drafted: the California bot statute misses on the bot, the forum and the intent, Utah needs an interaction that never happens, Colorado repealed its act.
Build an evidence trail
The draft, the agent who edited it and the reply that actually went stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Ticketing and support desks
- Zendesk
- Intercom
- Salesforce
- Ticket threads and queue rules
Customer records
- CRM
- billing
- order systems
- Entitlement and plan fields
Knowledge and help centre
- Zendesk Guide
- Notion
- Published articles and when each changed
Agent
Support copilot
- Reads the ticket
- Drafts the reply
- Holds for the lead
Workflow and records
- Jira Service Management
- Slack
- Approvals and the record of sending
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the customer
Six brakes on one descent, the last the firmest. What still rolls is drawn in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a draft may go out
- L3
- Leaves the sending to a named lead
- L4 – L5
- Keep the reply and the draft behind it
- L6
- Suggests nothing at all when signals degrade
How Nestack evaluates it
Evaluate the whole drafting run — not only the reply that goes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the reply the customer reads
- E1Final-output evaluationDid every claim in the draft rest on something in the record?
- E2Step-level evaluationDid the agent read only the fields the reason for contact justified?
- E3Tool evaluationDid it read the correct ticket and write the correct thread?
- E4Confidence calibrationDo weak drafts actually attract more editing before they are sent?
- E5Slice evaluationHow does performance change across specific ticket intents?
- E6Business outcomeHow many drafts needed an edit before the lead sent them?
Floor — the reply the company answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, each placed where the draft first goes wrong.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- PE-03
Record surfaced too wide
The whole record opens for a one-field question.
Stage gathers
The ticket, the reason for contact and the fields
02 · Reasoning
2 modes
- PE-04
Claim drafted, never checked
A sentence asserts what no record carries.
- PE-06
Article cited after it changed
The draft quotes a page that has since moved.
Stage proposes
The record read, the draft and the confidence
03 · Tool / write
2 modes
- PE-02
Thin draft passed forward
A weak draft moves on without the second read.
- PE-05
Draft bound to the wrong ticket
The reply is filed against another thread.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- PE-01
Approved without being read
The draft is sent faster than it could be read.
Stage returns
The reply the customer reads and the record
05 · Change / Version
1 mode
- PE-07
Edit lost before sending
The record keeps the draft, not what actually went.
Stage tracks
Model, prompt, scope rules and article dates
- Sev-1 · a reply sent that nobody read
- Sev-2 · an unchecked claim reaches a customer
- Sev-3 · signals degrade, drafting stops
Affected slices
Refund requests absorb most of the editing
An intent-level review-depth figure can read clean while refund and goodwill requests carry most of the editing. Nestack reports the edit rate by intent, not only across a whole desk in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Refund and goodwill requests | 9.3% | 3.7× | Review | |
| Entitlement and plan disputes | 6.6% | 2.6× | Review | |
| Technical fault reports | 4.1% | 1.6× | Watch | |
| Order status queries | 1.7% | 0.7× | Normal |
Bar: edit-rate lift vs. order-status baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What an unread draft costs
A cycle ends when the draft that went out unread is a standing case. That suite is what the next reply sent is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Approvals speed up on one ticket intent.
- 02
Diagnose
The draft that was approved in the time it takes to read a subject line is worked backwards until one cause is left standing.
- 03
Improve
The change ships numbered, and the drafts that forced it ride with it.
- 04
Verify
One draft case still failing is enough to hold the release back.
- 05
Learn
It is kept for good, and the drafting rules are amended in the same commit.
Learn → Detect
The return edge. The next draft is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, drafting workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Support-queue discovery and automation-boundary work.Week 1
- 02Ticketing, record and knowledge feeds.Week 1, Week 2
- 03Reason-for-contact and prohibited-inference mapping.Week 1, Week 2
- 04Ticket and record reading.Week 2
- 05Drafting logic and claim binding.Week 2, Week 3
- 06Confidence scoring and reviewer routing.Week 3
- 07Queue lead review workflow.Week 3, Week 4
- 08Ticketing-and-record integration.Week 5
- 09Draft and review cases.Week 4, Week 5
- 10Guardrails and sending controls.Week 4
- 11Draft-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne queue, one intent set | ProductionProduction support systems | AdvancedMultiple queues / brands |
|---|---|---|---|
| Introduced at Pilot | |||
| Drafting to your record and rules | ✓ | ✓ | ✓ |
| Queue lead approval | ✓ | ✓ | ✓ |
| Reply-corpus baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by intent | — | ✓ | ✓ |
| Lead review workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Ticketing-and-record integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-brand drafting rules | — | — | ✓ |
| Multi-stage lead approvals | — | — | ✓ |
| High ticket volume | — | — | ✓ |
| Multi-queue drafting controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, ticket volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your live queues and the intents each one carries
→Intent mapping and record-scope binding
Week 102Representative tickets from each intent
→Ticket ingestion, drafting logic and the reply baseline
Week 203The record fields each reason for contact justifies
→Record-scope mapping, intent binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Ticketing, record and knowledge assessment, then integration setup
Week 205Drafts you would not want quoted
→Review cases and failure-mode testing
Week 406What no draft may commit
→Confidence scoring, reviewer routing, guardrails and release controls
Week 307A named queue lead who sends the reply
→Queue lead review workflow, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
The bands below are counted, not spaced for looks; the fifth carries two because those two coincide.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Queue discovery, record-scope mapping and the automation boundary
W2Ticketing and record integration and the reply baseline
W3Drafting logic, confidence scoring and review controls
W4Evaluation suite, draft cases and failure-mode testing
W5Knowledge integration, pilot drafts and targeted corrections
W6One support month run under the queue lead, then Agent Care handover
- Reading the band
- A bar sits on the weeks its own work is named in, and week five carries two because both run.
- At the end of W6
- When the reply record validates, Agent Care takes the agent on.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Customer Support AI agent
Build a support copilot around the review your desk cannot now show it actually did.
Show us one queue and the replies it sent last week. The person who reviews the draft and sends it is the interlocutor, and the exception rests on that being true rather than on a button existing. Bring one reply approved faster than it could be read.
- Typical delivery
- 4–6 weeks
- Deployment
- Your queues
- Named lead
- Never sends
- After launch
- Agent Care available
Nestack Agents · Support copilot
AGT-SUP-04 · Agent Care available after launch