Chanakya
The Orchestrator — decides and directs.
The one you actually talk to. It reads what you asked for, decides how it should be done, hands the pieces to the specialists who do them, and holds the approvals — nothing irreversible happens without coming back through here.
What it can reach
- Reads and edits your files
- Runs your terminal
- Search, fetch and language tooling
- Calls in the other five as needed
- Holds every approval
- Read-only modes remove its mutating tools
You say “reconcile last month’s invoices against the bank statement and flag anything that doesn’t match.” This agent works out that this is a real multi-step job rather than a question, picks the mode and the model for it, and asks for a plan before anything is touched.
How it works
This is the session loop, and it is the one stage that runs on every single job. It reads your request against the project and — when you leave the mode on auto — decides for itself whether this is build work, planning, or read-only analysis, and which model tier the job warrants. Then it decides which of the other five it actually needs. A small request never leaves this agent; a large one gets broken up, and each delegated piece runs in its own child session whose result folds back here to be judged rather than being handed to you directly.
It is also where permission lives. Every mutating tool — writing a file, editing, running a command — is gated here, and the read-only modes remove those tools from the list entirely rather than asking the model to behave. That gate is ordinary code; it is not an instruction the model can talk itself past. A delegated worker also cannot delegate again, so a run can never fan out beyond one level.
What runs it
Every turn starts on Bala. It reads what you asked for, decides whether the job is simple or complex, and if it is simple it answers there. Complex work goes up: Yuva for ordinary jobs, Rishi when the job needs planning across several steps. This is only what happens on Auto — pick a model yourself and that choice is never overridden.
The desktop app can run your own API keys or a local model instead. The same tiering then applies to whatever you pointed it at.
Then it hands over
Takes one goal and turns it into a dependency-ordered graph of smaller tasks — what has to happen before what, what can run at the same time, and what counts as each piece being done.
Why the name
c. 4th century BCE
Chanakya — also known as Kautilya and Vishnugupta — is the author traditionally credited with the Arthashastra, a treatise on statecraft, economics and administration. He is associated with Takshashila as a teacher, and with the founding of the Mauryan empire under Chandragupta Maurya.
The Arthashastra is not a book of maxims. It is an operations manual: how to sequence a decision, how to weigh a course of action against its cost, how to delegate and still stay answerable for the result. Scholars continue to debate how much of the surviving text is one author and how much is later accretion; the method in it is not in dispute.
Someone has to decide — and stay answerable for the decision after delegating the work.
- Understand what was actually asked before choosing how to do it.
- Delegate the work, but keep the decision and the approval.
- A delegated result comes back to you; it does not go out on its own.
engine/src/chanakya — session loop, task objects, routing, approvals
This agent is not Chanakya, does not reconstruct his views, and does not speak with his authority. It is an orchestration runtime named after him.