# How does DAKSH, VARTA's design-time LLM author, build a voice agent workflow?

How DAKSH turns an author's brief, pasted spec or one-line edit into a validated voice-agent workflow — steps, rules, language data and pre-built audio — so live calls need no LLM for any of it.


DAKSH (दक्ष, "skilled" or "expert") is the LLM that writes a VARTA 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. The VARTA engine 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.

The [interactive version of this page](/architecture/daksh) includes the system map and the patch lifecycle as diagrams. The runtime that reads this data is covered in [VARTA Engine Architecture](/architecture/varta-engine).

## Design time versus call time

| | DAKSH — design time | VARTA — call time |
|---|---|---|
| Model use | GPT-4o and GPT-4o mini, structured JSON only | Regex and rules first, LLM last |
| Speed | Can be slow and thorough, because no caller is waiting | Microseconds for most turns |
| Cost | Logged per workflow | Stamped on every call |

## Five entry points, one workflow document

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 is allowed in.

| Author surface | Generator | Result | How it is checked |
|---|---|---|---|
| Designer drawer and broadcast bar (step, draft, audit, broadcast) | Ghost proposers | Ghost changes previewed on the canvas | The author accepts each one; step mode is capped at 3 changes |
| Rebuild as copy (paste a spec or a brief) | Rebuild generator, temperature 0 | A full workflow, with missing steps repaired | Imported as a separate copy with new ids |
| DAKSH chat (Build tab drawer, one thread per workflow) | Chat orchestrator and patch applier | A validated patch | Validated on the server before commit, all-or-nothing |
| Build tab (Analyse, then Build) | Named pipeline stages | Fields and fingerprinted audio | Written directly as part of a build, with safe fallbacks |
| Field editors (NITI, conditions, FAQ, PRASANG, locale, policy) | Per-field generators | Drafts | The author reviews, then saves |

## Four ways DAKSH edits a workflow, and what makes each one safe

- **Typed patch (DAKSH chat).** 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, and all-or-nothing apply.
- **Ghost changes (designer suggestions).** Proposals appear as "ghost" changes on the canvas — a new step, a retargeted branch, a VIRAM scenario, new side-question keywords — and the browser applies them when the author accepts. *Safe because:* a person reviews every ghost. Step mode caps at 3 changes; broadcast can only edit.
- **Full rebuild (rebuild as copy).** 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 did not 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.
- **Pipeline stages (Build tab).** 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 does not break the build. Reflex phrases are the exception: if they fail, the build stops rather than ship an agent that cannot recognise "yes".

### The chat patch lifecycle

1. The author's message is saved to the workflow's thread first.
2. The orchestrator converses with the recent thread and a workflow snapshot, asking for structured JSON with up to 3 retries.
3. Operations are parsed and schema-checked; invalid ones are dropped.
4. The resulting patch is shown to the author and waits for Apply.
5. Apply runs on a deep copy, all-or-nothing, checking every new goto against the steps that exist after the patch.
6. A valid patch is committed after a workflow health audit, then the reflex cache, branch keywords and step graph are recompiled and the workflow is saved.

Only a patch's own new gotos are checked; broken gotos already in the workflow do not block it. A failed apply is sent back to the LLM with the errors so it can fix its own patch. After 3 failures in a row the thread freezes, and the pending patch is cleared, instead of looping.

## The build pipeline, in order

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.

**Analyse**

1. Extract sentences into steps (LLM; heuristics after 3 failed retries)
2. Split compound collection steps (LLM)
3. NITI rules from prose — "if X go to step Y" becomes gotos (LLM)
4. VIRAM empathy configuration (LLM)
5. Fuzzy-matching configuration (no LLM)
6. Upgrade slot templates (no LLM)
7. UI help text (LLM, with a heuristic fallback)
8. Universal responses
9. Step fillers and emotions (opt-in; off by default, and when off, LLM-invented fillers are removed)
10. Neutral filler phrases
11. Preview the step graph — the author reviews it before Build (no LLM)

**Build**

1. Synthesise all clips, reusing audio when the fingerprint matches (TTS)
2. Sync PRASANG groups (no LLM)
3. Carry over FAQ and the system prompt (LLM)
4. Number normalisation map (LLM)
5. Reflex, interjection and drift phrases — if reflex phrases fail, the build stops; interjection cues fall back to built-in defaults
6. Runtime text and off-topic keywords, only for languages beyond Hindi and English (LLM, cached)
7. Slot aliases, such as "job" meaning salaried, only when an API key is set (LLM)
8. Phonetic variants from letter rules: aspiration, vowel glide, sibilant, retroflex (no LLM)
9. Direction and tone profile
10. Language data: fillers, number and letter maps, date tokens, currency (LLM)
11. Compile the reflex cache, branch keywords and step graph (no LLM)
12. Pre-cache rule and PRASANG clips, and persist (TTS)

## Every place DAKSH calls the LLM

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.

| Group | Generator | What it writes |
|---|---|---|
| Structure | Chat edits | Conversation turns and a pending patch; drafted prose gets one self-audit revision |
| Structure | Step suggestions | Up to 3 ghost changes for one step |
| Structure | Flow draft | Ghost changes for the whole flow |
| Structure | Broadcast | Edit-only ghost changes across many steps |
| Structure | Rebuild and author | A full workflow imported as a copy; authoring from a brief also returns clarifying questions |
| Structure | 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 |
| Rules and branching | Condition drafts | Draft condition branches, schema-checked and audited before the author sees them |
| Rules and branching | FAQ drafts | FAQ entries, checked for valid patterns and duplicates |
| Rules and branching | PRASANG groups | Side-question scenario groups used across the whole workflow |
| Rules and branching | VIRAM parsing | An empathy scenario prompt |
| Language | Language data | Filler words, number and letter maps, email cues, date words and currency multipliers |
| Language | Slot aliases | Words a customer might use for a slot value |
| Language | Phonetic variants | Likely mishearings, from letter rules rather than the LLM |
| Language | Translation | A sibling workflow in another language; any invented step ids are dropped |
| Language | Locale tokens | Date and time words the author reviews and saves |
| Language | Reflex and runtime catalogs | Reflex phrases, interjection cues, system lines and off-topic keywords |
| Helpers | Policy phrases | Abuse and please-wait phrase lists |
| Helpers | Test values and L4 dry run | Inputs for the tool tester, and a dry run of the real L4 prompt |

## What VARTA does with each field

| 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 |

## How DAKSH is kept from breaking a workflow

- **Schemas and validation.** 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.
- **Truncation is detected.** 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 is never accepted half-finished.
- **Failures return empty.** 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 provider authentication and rate-limit errors are explained.
- **Authors keep control.** Nothing is auto-applied: patches wait for Apply, and ghosts wait for accept. Rejected conditions go into a ledger so they are not proposed again, and steps with an approved rule are locked.
- **Caches.** 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.
- **Language stays out of the engine.** Everything the engine says, recognises or parses is DAKSH-written data. Supporting a new language means running DAKSH again, not changing the engine.

## Questions this page answers

**What is DAKSH in VARTA?**
DAKSH is VARTA's design-time LLM author. It writes a voice-agent workflow — steps, branches, rules, language data and audio clips — before any call happens, and never runs during a live customer call.

**Can DAKSH change a live workflow without the author approving it?**
No. Chat patches wait for Apply, designer suggestions wait for the author to accept each one, a full rebuild arrives as a separate copy, and field drafts wait for the author to save.

**What stops a bad LLM edit from breaking a workflow?**
Typed schemas with per-field allowlists, goto checks against the steps that exist after the change, a workflow health audit, all-or-nothing apply, and a thread freeze after 3 failed applies in a row.

**Why does VARTA split authoring from the live call?**
So the expensive, language-specific LLM work happens once, at design time, where it can be slow, checked and cached. During the call the engine reads that data with rules first, which keeps calls fast, cheap and deterministic.