By team
AI agents for customer support teams
The same forty questions, answered by hand, all day. Most of them are lookups — an order, a balance, a booking, a policy — and the answer already exists in a system the agent has to open in another tab. We build support agents that read those systems directly, cite where the answer came from, and hand over the moment a question stops being routine.
Two weeks to a written build plan · no obligation to build with us
- Answers cite the record or the policy
- GroundedAnswers cite the record or the policy
- Nothing personal before authentication
- Identify firstNothing personal before authentication
- Refunds and credits need a person
- Drafted, not sentRefunds and credits need a person
- To a written build plan, via the audit
- 2 weeksTo a written build plan, via the audit
Where the time goes
If two of these are true, there is something here
Written the way the people doing the work describe it, not the way a process document does.
Most tickets are lookups
Where is my order, what is my balance, when is my appointment, is this in stock. Each one is a person opening another system and reading a field out loud.
The knowledge base is out of date and everyone knows it
Agents answer from experience because the documented answer is wrong often enough not to be trusted — which means the answer a customer gets depends on who picks up the ticket.
The queue has a different shape at 2am
Volume outside working hours is small enough not to justify a shift and large enough that those customers wait until morning for something that takes forty seconds.
Every channel is its own inbox
Email, chat, WhatsApp, social and the phone, each with a different history, so a customer repeats themselves at every hop.
What we connect to
The systems you are already running
The helpdesk is rarely the problem. The problem is that the helpdesk cannot see the systems where the answers live, so we connect it to them.
- Helpdesk platforms
- Zendesk
- Freshdesk
- Gorgias
- Intercom
- HubSpot Service Hub
- Custom ticketing
- Where the answers live
- Shopify / WooCommerce
- ERP and order systems
- Member and account databases
- Carrier tracking APIs
- Booking systems
- Channels
- Web chat
- WhatsApp Business API
- Facebook and Instagram
- SMS
What we build here
Five things worth building for customer support
Each one names the systems it touches, because an integration that is not named is an integration nobody has thought about yet.
- 01
Grounded answers from live records
Order status, tracking, balances, bookings and eligibility answered from the system that holds them, after the customer is identified — with a link to the record behind every answer so an agent can check it in a second.
- Touches
- Helpdesk · order / account systems · tracking APIs
- What changes
- The largest ticket category stops needing a person.
- 02
Policy answers that cite the policy
Returns windows, warranty terms, cancellation rules and eligibility answered from your published policy documents with the clause quoted. Where the policy does not cover the case, it says so rather than improvising.
- Touches
- Policy documents · helpdesk · retrieval index
- What changes
- Consistent answers, and a visible gap list where policy is silent.
- 03
Drafted actions for agent approval
Refunds, credits, replacements, address changes and cancellations prepared with the amounts, reasons and records filled in, for an agent to approve or change with one click.
- Touches
- Order system · payment provider · helpdesk macros
- What changes
- Agents spend their time deciding rather than assembling.
- 04
Triage and routing
Every ticket classified by intent, urgency and sentiment, tagged, prioritised and routed to the right queue — with anything that reads as a complaint, a vulnerability or a legal risk escalated to a person immediately.
- Touches
- Helpdesk · routing rules · escalation paths
- What changes
- The queue arrives sorted, and the serious ones surface first.
- 05
One conversation across channels
Customer identity resolved across email, chat and messaging so history follows them, and an agent picking up a WhatsApp thread can see the email exchange from last week.
- Touches
- Helpdesk · channel APIs · identity resolution
- What changes
- Customers stop repeating themselves at every hop.
How it is put together
How a ticket gets answered without a person
The design principle throughout is that it is better to hand over than to guess. A support agent that says "let me get someone" is a good outcome; one that invents a returns policy is not.
- 01
Classify
Intent, urgency and risk first. Complaints, vulnerability signals, legal threats and anything about safety leave the automated path immediately, before any answer is composed.
- 02
Identify
Nothing personal is disclosed until the customer is authenticated through your existing mechanism. Unauthenticated sessions get generic help and a route to verify.
- 03
Retrieve
The answer comes from the live record or the current policy document, and the source is attached to the reply internally. An answer with no source is treated as no answer.
- 04
Check policy
If the customer wants an action, your rules decide whether it is in policy. In policy and low value may proceed; outside policy, high value or ambiguous goes to an agent with a draft.
- 05
Hand over cleanly
When it hands over, the agent receives the full thread, what was already checked and what was already promised. Nothing is worse for a customer than repeating themselves to the human they were escalated to.
Your data
What we will and will not do with it
Stated plainly, and without claiming a certification we do not hold. If a requirement here is harder than what is written, say so on the call and we will tell you whether it is buildable.
No unattended refunds or credits
It prepares them; a person approves. The time saved by removing that click is small and the downside of an automated refund loop is not, which makes this an easy trade to get right.
It says it is automated
We build agents that identify themselves. Customers mind a useless answer far more than an honest automated one, and several jurisdictions are moving towards requiring disclosure anyway.
It does not answer outside the record
If the answer is not in a record or a policy document, the reply is that a person will pick it up. A grounded system with a narrow scope beats a confident one with a wide scope every time in support.
Proof
Deflection by letting people serve themselves
IAB is a membership body whose operations ran through the office inbox. We built the portal that let 10,000+ members do for themselves what they had been emailing to ask for — with identification before any record was disclosed. That is the same mechanic as support deflection, and it was live in four months including the record migration.
- Members served
- 10,000+Members served
- To live, including migration
- 4 monthsTo live, including migration
- Engagements over three years
- 9Engagements over three years
Technology
What this gets built with
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Agents
- LangGraph
- Retrieval with citations
- Intent classification
- Structured output
- Integration
- Zendesk / Freshdesk APIs
- Shopify
- ERP adapters
- WhatsApp Business API
- Webhooks
- Knowledge
- pgvector
- Policy document indexing
- Freshness checks
- Answer-source logging
- Measurement
- Deflection rate
- Escalation reasons
- CSAT by path
- Per-run cost logging
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 1–2
Sit with the work
We watch the process as it is actually done, not as the process document says. The output is a map of every step, which system it touches and how long it takes.
DeliverableProcess map and a shortlist of what is worth automating - 02Week 2–3
Design the access layer
Which systems get read, which get written to, what scope each credential carries, and which decisions stop for a person. Agreed in writing before anything is built.
DeliverableArchitecture and permission model - 03Week 3–8
Build against your real data
Built in your sandbox against real records, not a demo dataset. The write path goes through a review queue from the first day, so nothing lands in a live system unseen.
DeliverableRunning system in staging, with the review queue - 04Week 8–10
Run it beside the humans
It runs in parallel with the people doing the job. We compare the two outputs, fix what differs, and only then start letting the routine path through unattended.
DeliverableAgreement rate report and a go-live threshold - 05Ongoing
Hand over and watch
Source code in your repository, deployment in your accounts, cost and failure dashboards you can read without us. Support if you want it, not because you are locked in.
DeliverableRepository, runbook and monitoring
Why Devs Core
Three reasons that are checkable
We run two of our own products
Cadenza and Budge are ours. What an agent costs per run, where it fails and which decisions need a person came from operating them, not from a vendor deck.
The write path is reviewed by default
Anything that changes a record in a system of record goes through a queue a person can see. You choose what graduates to unattended, and when.
You own the code
Source in your repository, infrastructure in your accounts, model keys in your name. There is no runtime of ours you have to keep paying for.
Questions
Customer Support — the questions we get asked
How much of our ticket volume can realistically be deflected?
It depends entirely on how much of your volume is lookups, which we can measure from your existing tickets before you commit to anything. We would rather give you a number from your own data in the audit than quote an industry percentage that means nothing for your queue.
What stops it from making up a policy?
It answers from your policy documents and records only, with the source attached, and it is built to say it does not know rather than to fill a gap. Grounding is the whole design — a support agent that improvises is a liability rather than a saving.
Should it pretend to be a human?
No. It should say it is automated and hand over quickly when it is out of its depth. Customers tolerate that; they do not tolerate discovering it after fifteen minutes of a circular conversation.
Can it work on WhatsApp, where most of our customers are?
Yes, through the WhatsApp Business API, and in several markets that is the channel that matters most. The same agent can serve email and chat, with identity resolved across all three.
What happens when it gets something wrong?
Every answer logs its source, so a wrong answer traces to either a wrong record or a wrong policy document — both fixable causes rather than mysteries. Rollout starts in draft mode, where agents see suggested replies before any go out on their own.
Will it replace our support team?
It removes the lookups. What is left is the work that actually needs judgement, which is usually the part your team wants to do and never has time for. If your intention is headcount reduction, that is a decision you should make deliberately rather than discover.
Related
What customer support buys most often
- Read more
AI Agent Development
Agents that take real actions in your systems — reading live data, drafting work, and writing back only what a person has approved.
From $6,500 - Read more
AI Integration Services
The access layer between the software you already run and any AI model — so an agent can reach your ERP, CRM or helpdesk without being handed the keys.
From $8,000 - Read more
Process Automation
Replace the manual steps between two systems — the re-keying, the copy-paste, the spreadsheet that reconciles what neither system knows.
From $4,500 - Read more
AI Readiness Audit
Two weeks that end in a written plan: which processes are worth automating, what each would cost, and what has to be fixed first.
From $2,400
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com