Built around your products.
Product-centric
A profile per product pins every investigation to the customer's real setup — version, components, repos, docs. General assistants answer about software; dekx answers about yours.
Support copilot · MCP hub · Knowledge graph
The copilot that investigates for you, with you.
Not another chatbot. Not another coding agent. dekx reads the ticket, digs through your code, docs and past tickets, finds the root cause, tests the fix and drafts a reply with sources.
- Runs on your machines
- Local or remote models
- Multiple tools, one context.
- Customer data stays home
Chatbots
Can only repeat what is written down
If the answer isn't already in the docs, the bot has nothing to give.
Coding agents
Only see code, only live in the editor
They don't read tickets, know your customers, or write a reply.
dekx
Investigates, tests, replies
- Finds the root cause.
- Tests the answer.
- Drafts a reply with sources.
The investigation
One ticket in. A full investigation out.
Every step is a real action on your own systems — reading code and docs and reasoning about them. Not search. Not autocomplete.
- 01Read the ticket#4821 · duplicate webhook deliveries
- 02Match the product profileAcme Cloud 4.2 · Events API
- 03Search the knowledge graphdocs · KB · past resolutions
- 04Trace the source codedispatcher · retry policy
- 05Reproduce itgenerated sample, run locally
- 06Propose and test fixesworkaround, config change, upgrade path — each one tested
- 07Draft the replyready for the customer, every claim cited
dekx · local harness
Root cause and a tested fix
Retries re-send on a 504 from the subscriber without checking the delivery ledger, so a slow endpoint gets the same event twice.
Fix: set ledger_check=true in the retry policy — tested against the repro — or upgrade to 4.2.6. Quick workaround: de-duplicate on event_id.
docs/events/retries.mdKB-1180ticket #3902dispatcher.go:214release-notes 4.2.6
How it works
Docs read as docs. Code read as code.
Prose is split along its own structure and code is parsed by syntax. Then everything is linked into one graph, so an answer can show where it came from.
Structural chunking
Docs, KB articles and tickets are split where they naturally break — sections, steps, code blocks, threads. A retrieved passage is a whole thought, not a random slice.
Code parsed as code
A tree-sitter pass reads source by syntax, not by line. Functions, types, config keys and call sites become units you can point to — down to file and line.
Linked into a graph
Those units are connected: symptom to source, ticket to fix, doc to the version it describes. Retrieval follows the links, which is what lets an answer explain itself.
Fed by your systems
Repos, issue trackers, doc sets and past resolutions connect through MCP and stay current. The graph reflects today, not a snapshot.
The platform underneath
Indexed knowledge. Every system. Scoped per product.
Product profiles
One profile per product
Versions, components, repos, doc sets. Each investigation is scoped to what the customer actually runs — not your whole company.
# profiles/acme-cloud.yaml product: Acme Cloud versions: [4.0, 4.1, 4.2] components: [events-api, dispatcher, webhooks-ui] sources: docs: ./docs/**/*.md code: acme/events, ./sdk tickets: zendesk(brand=cloud) issues: jira(EVT), linear escalate_when: no repro × 2
Knowledge graph
Everything your products know, in one place
Built on your own machine. It links docs to code paths, tickets to resolutions, versions to known issues. Updates in small steps, and nothing leaves your network to be indexed.
- Documentation and guidesmd · sites · PDFs
- KB articlesZendesk · Notion
- Tickets and resolutionsZendesk · Salesforce
- Source code and samplesrepos · GitHub
- Issues and release notesJira · Linear
- Team decisionsSlack threads
MCP hub
One MCP server for your whole support stack
Connect once. Every system becomes a tool your copilot — or any MCP client — can call, with read-first permissions you control.
ZendeskJiraLinearSalesforceNotionSlackGitHubConfluenceDocs sitesLocal files/reposYour API
Why dekx
It works where others stall.
Support engineering isn't a search problem. It's a reasoning problem over your product, your code, and data scattered across many places.
Finds answers nobody wrote down.
Investigation, not retrieval
Retrieval can only return what someone already documented. dekx follows a symptom into the source, reads the code path, and reasons to a root cause. The tickets nobody can answer from the KB are the ones it's for.
Nothing reaches a customer unproven.
Evidence by default
Every proposal comes with a reproduction it ran and a fix it tested. Every claim in the draft reply names the file, line or article it came from. You review evidence instead of proofreading prose.
Runs on your systems.
Local and private
On an engineer's laptop or inside your VPC. Use a local model and nothing leaves — or a remote model with PII redaction when you want more reasoning. Your choice.
- Ollama · vLLM · any OpenAI-compatible
- Bring your own key, redaction enforced
- Index and logs on disk you own
- No vendor copy of your code
Many tools, one conversation.
One surface
Your platforms connect once through the MCP hub and stay current. Work in the dekx interface; the tools get called for you.
Outcomes
Faster investigations. Fewer escalations. Happier customers.
dekx doesn't replace your support engineers — it gives them more. The judgment, the trust, the call on what a customer really needs stays human. dekx removes everything standing between your engineers and the answer.
- Knowledge scattered across six systemsOne indexed graph every engineer can ask
- Six tabs, three apps per ticketOne surface, tools called for you
- Escalations because there's no reproductionRepro, workaround and sample code in hand
- New hires learning the product for monthsDay one with the team's whole history
- Answers written from memoryEvery claim cited and checkable
- Tier-1 and Tier-2 repetition eats the dayRepeat volume handled, hours left for the tickets that need time
- Experience locked in your most senior engineersThe biggest lift lands on the newest+34% for newer agents in a 5,000-agent study. Read the article →
Beyond the ticket
But there's more.
Working one case means reading the same code and docs your team already shipped. What dekx notices along the way doesn't stay inside that one investigation.
Bugs revealed
Tracing a symptom to its line of source shows the defect behind it — before another customer files it. Each finding and its fix arrives with a reproduction attached.
Gaps in the docs
When the answer isn't in the documentation and isn't a bug, dekx says so — the missing step, the wrong assumption. You get a running list of what to fix.
Version drift
Customers on older releases hit behaviour the current docs no longer describe. dekx pins the answer to the version in front of it and flags where the two differ.
The dekx log
Field notes from an investigative support copilot.
Your support team and the success of your customer's story
63% of consumers will switch after one bad experience — and most leave without complaining.
Read · 4 min →Anatomy of an agent trace: how dekx works a ticket
Everything the agent did on one ticket — intake, redaction, retrieval, reproduction, root cause — and the three gates where a human decides.
Read · 8 min →Triage, investigation, reproduction: the unspoken monotony
A 401 that fails a third of the time, three worker nodes and a clock three minutes in the future. Where the hours actually go.
Read · 4 min →Early access
Put dekx in the queue with your team.
We're onboarding a small group of support organisations before launch.
Be first to know when dekx launches. No spam.
Great. You're on the waitlist — we'll email you at launch.