Vishwakarma
The Builder — does the work.
The layer that actually touches things. It picks a worker that can do the job asked of it, and that worker opens the files, makes the changes, runs the commands, and fills in the forms — on your machine, inside the permissions you set.
What it can reach
- Reads and edits your files
- Runs your terminal
- Fills forms and portals
- Connected accounts you switched on
- Chooses a worker by declared capability
- Falls back when a worker is unavailable
It opens the statement, pulls the invoice rows, and writes the matched pairs into a new sheet — in your files, on your machine, with the change shown to you before it stands.
How it works
This is a registry of execution engines rather than a single worker. A task declares the capability it needs — editing a repository, running tests — and an engine is chosen because it declares that capability, never because of its name. One engine is Upfyn’s own; the others are adapters that drive command-line coding tools. If the engine it would prefer is not installed or not signed in, it reports itself unavailable and the work falls back to the built-in one rather than failing.
It is also the most tightly fenced part of the system, because it is the part that writes. It runs on your machine under permissions you set; the read-only modes remove its mutating tools outright, so “don’t change anything” is enforced by the tool list rather than by asking nicely. The optional command-line worker is around 325 MB and is fetched the first time you use it — shipping it inside the installer would take the download from roughly 125 MB to 500 MB, and re-ship it on every update.
What runs it
The dispatch is ordinary code — it starts the worker and watches it. The worker runs on whichever model the job was routed to, so any of the three can be behind this stage depending on what was asked.
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
Finds the project’s own checks — the build, the tests, the linter, the type-checker — and actually runs each one. A check passes when the command it runs succeeds, and for no other reason.
Why the name
Of scripture, not of record
Vishwakarma is the divine architect of Hindu tradition — the devashilpi, the maker of the instruments and the cities of the gods, named in the Rigveda and elaborated across the later texts. Unlike the other five, he is a figure of scripture rather than a person in the historical record, and this page does not blur that line.
The tradition around him is a tradition about craft: the honour sits with the finished, working object and with the hands that made it. Vishwakarma Puja is still observed by engineers, machinists, carpenters and factory workers across India, on their tools.
A plan is worth nothing until it exists as a working object — so the work is measured by the finished thing, never by the intention behind it.
- Execute the step you were given, not the one you would have preferred.
- Change the real artefact — the actual file, the actual form, the actual sheet.
- Pick the worker by what it can actually do, not by what it is called.
engine/src/vishwakarma — execution engines: registry, native worker, CLI adapters
This agent is not a religious artefact and carries no religious claim. Vishwakarma is a deity in living worship; naming a builder after the tradition’s builder is a nod to that idea of craft, and nothing more.