DAKSH is the LLM that writes a workflow before any call happens. It turns an author's rough description, pasted brief or one-line edit into structured data: steps, branches, NITI rules, condition branches, FAQ, language tables, aliases and clips. VARTA reads all of it during calls without making any LLM calls of its own for it. That split keeps the runtime cheap and language-neutral: adding a language only takes DAKSH work.
GPT-4o and GPT-4o mini, structured JSON only. Can be slow and thorough, because no caller is waiting. Cost is logged per workflow.
Reads what DAKSH wrote. Regex and rules first, LLM last. Cost is stamped on every call.
Every DAKSH feature follows the same path: a screen in the designer or Build tab, a request, a generator that calls the LLM, and a result that lands on the workflow. What changes is the kind of result, and so how much it has to be checked before it's allowed in.
The chat returns typed operations: add, edit or delete a step, a branch or a NITI rule, or change workflow settings. The server applies them to a copy.
Safe because: typed schemas, per-field edit allowlists, goto checks after the patch, a health audit, all-or-nothing apply.
Proposals appear as "ghost" changes on the canvas: a new step, a retargeted branch, a VIRAM scenario, new side-question keywords. The browser applies them when the author accepts.
Safe because: a person reviews every ghost. Step mode caps at 3 ops; broadcast can only edit.
A whole workflow from a spec or brief, at temperature 0. When the output would be truncated, it builds in batches of 6 steps and repairs any step that didn't come back.
Safe because: it imports as a copy with new ids, validates the whole step graph, and a guard blocks specs pasted into the wrong mode.
Named stages write fields straight onto the workflow: extraction, NITI, VIRAM, reflexes, aliases, language data, clips.
Safe because: each stage falls back to empty or heuristic output, so a failed LLM call doesn't break the build. Reflex phrases are the exception: if they fail, the build stops rather than ship an agent that can't recognise "yes".
Analyse turns the author's prose into a step graph. Build does everything that makes it callable: clips, rules, language data and the compiled graph. Conditions, FAQ, NITI-from-text, VIRAM parsing and locale tokens are not part of this pipeline; the author runs them from the designer.
Every generator asks the model for structured JSON, never free text, so each result can be validated before it touches a workflow. Most use GPT-4o; the narrower field drafts use GPT-4o mini.
| Generator | What it writes |
|---|---|
| Structure | |
| Chat edits | Conversation turns and a pending patch; drafted prose gets one self-audit revision |
| Step suggestions | Up to 3 ghost changes for one step |
| Flow draft | Ghost changes for the whole flow |
| Broadcast | Edit-only ghost changes across many steps |
| Rebuild and author | A full workflow imported as a copy; authoring from a brief also returns clarifying questions |
| Graph audit | Up to 8 findings, each with a ghost fix; cached by the workflow structure |
| Rules and branching | |
| NITI from text | Rules for a step, from a plain-English sentence |
| Condition drafts | Draft condition branches, schema-checked and audited before the author sees them |
| FAQ drafts | FAQ entries, checked for valid patterns and duplicates |
| PRASANG groups | Side-question scenario groups used across the whole workflow |
| VIRAM parsing | An empathy scenario prompt |
| Language | |
| Language data | Filler words, number and letter maps, email cues, date words and currency multipliers |
| Slot aliases | Words a customer might use for a slot value |
| Phonetic variants | Likely mishearings, from letter rules rather than the LLM |
| Translation | A sibling workflow in another language; any invented step ids are dropped |
| Locale tokens | Date and time words the author reviews and saves |
| Reflex and runtime catalogs | Reflex phrases, interjection cues, system lines and off-topic keywords |
| Helpers | |
| Policy phrases | Abuse and please-wait phrase lists |
| Test values and L4 dry run | Inputs for the tool tester, and a dry run of the real L4 prompt |
| Workflow field (written by DAKSH) | Read at call time by |
|---|---|
| Reflex phrases | L1 DHADKAN (धड़कन) (Heartbeat), compiled into a regex cache |
| Interjection cues | L1 INTERJECT |
| Off-topic keywords | L1.7 OOS |
| Filler words · number and letter maps · email cues | L2 PEHCHAAN (पहचान) (Recognition), which cleans the transcript; number words are also used by L1 and L5 |
| Date words · currency multipliers | The date parser and the transcript clean-up |
| Authored branches | L3 MAARG (मार्ग) (Path) |
| System prompt | L4 BUDDHI (बुद्धि) (Intellect) |
| NITI rules · slot aliases · phonetic variants | L5 NITI (नीति) (Policy), including global rules |
| Condition branches | The navigator, L5 NITI and L4 |
| FAQ · PRASANG groups | The FAQ resolver, and L5 NITI → PRASANG (प्रसंग) (Context) |
| System lines | Every system line the engine speaks |
| Audio clips | L6 VANI (वाणी) (Speech), which plays the matching clip |
| Step graph | The navigator, which walks the graph |
Typed operation schemas with per-field allowlists, goto checks after every patch, workflow health audits, and full graph validation on rebuild. If a drafted condition has any error or warning, all drafts for that step are dropped.
A reply cut off at the token limit is detected in spec checks, rebuild, authoring and language data. A truncated reply is rejected or split into batches; it's never accepted half-finished.
Conditions, FAQ, aliases, locale tokens and language data return empty defaults on failure, and analyse falls back to heuristics, so the build keeps going. A missing API key gives a clear message in the chat, and 401/429 errors are explained.
Nothing is auto-applied: patches wait for Apply, and ghosts wait for accept. Rejected conditions go into a ledger so they aren't proposed again, and steps with an approved rule are locked.
Chat threads and shared phrase catalogs are cached, audits are cached by the workflow's structure, and audio is reused by a SHA-256 fingerprint over text, SSML, voice, model, language, provider and speech rate.
Everything the engine says, recognises or parses is DAKSH-written data. Supporting a new language means running DAKSH again, not changing the engine.