The answer has to already be written down somewhere.
not another chatbot, not another coding agent.
not a chatbot - doesn't just retrieve from docs, it investigates: pulling from source code, tickets, known issues, past resolutions and it's own crafted knowledge of your products.
not another coding agent - dekx investigates, reproduces, validates and responds.
it runs locally, so proprietary code and customer data never leave your infrastructure to get an answer.
The answer has to already be written down somewhere.
Only see code, and only help in the IDE.
Every step is a real tool call against your own systems — root-cause reasoning across code and documentation, not search and not autocomplete.
Retries re-dispatch on a 504 from the subscriber without checking the delivery ledger, so a slow endpoint receives the same event twice. Fix: set ledger_check=true in the retry policy — validated against the repro — or upgrade to 4.2.6. Immediate workaround: de-duplicate on event_id.
Semantic and fuzzy search of prose with a code parser.
Docs, KB articles and tickets are split along their own structure — sections, steps, code blocks, threads — so a retrieved passage is a whole thought, not an arbitrary window of characters.
A tree-sitter pass reads source by syntax rather than by line: functions, types, config keys and call sites become addressable units, each traceable back to file and line.
Those units are connected — symptom to source, ticket to fix, doc to the version it describes. Retrieval follows the edges, which is what lets an answer explain itself.
Repos, issue trackers, doc sets and past resolutions connect through MCP and stay current, so the graph reflects the latest — not a snapshot.
A profile per product — versions, components, repos, doc sets. Investigations get scoped to the customer's actual deployment, 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
Built on your own machine — linking docs to code paths, tickets to resolutions, versions to known issues. Incremental, and nothing leaves your network to be embedded.
Connect once. Every system becomes tools your copilot — or any MCP-compatible client — can call, with scoped, read-first permissions you control.
Support engineering isn't a search problem. It's a reasoning problem over your product, your code and every single data located in random places.
A profile per product pins every investigation to the customer's actual deployment — version, components, repos, doc set. General assistants answer about software; dekx answers about yours.
Retrieval can only return what someone already documented. dekx traces 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.
Every proposal comes with a reproduction it ran and a fix it validated, and every claim in the draft reply carries the file, line or article it came from. You review evidence instead of auditing prose.
On a support engineer's laptop or inside your VPC. Local offline model proprietary code and customer data stay where they are or a remote model with PII redactions for when you want more reasoning — the choice is yours.
Your platforms connect once through the MCP hub and stay current. Work in the dekx interface, the tools get called for you.
dekx doesn't replace your support engineers, it empowers them.
The judgment, the trust, the call on what a customer actually needs — that stays human.
What dekx removes is everything standing between your engineers and the results.
Investigating a specific case reads the same code and docs your team already shipped. What it finds along the way doesn't stay in the investigation run.
Tracing a symptom to its line of source surfaces the defect behind it, before another customer files it. Every finding and it's fix arrives with a reproduction attached.
When the answer isn't in the documentation, and isn't a bug in the code, dekx says so. The gap, the wrong assumption, the step that only works one way. It provides you a running list of what to fix or what you can do.
Customers on older releases hit behaviours current docs no longer describe. dekx pins the answer to the version in front of it and flags where the two have diverged.